Results 1 to 11 of 11

Thread: XPR8400 with 00:00:00:00:00:00 MAC address

  1. #1
    Join Date
    Dec 21, 2011
    Posts
    4,546
    Thanks
    3,885
    Thanked 6,742 Times in 1,931 Posts
    Country: Canada

    Default XPR8400 with 00:00:00:00:00:00 MAC address

    Hi nose breathers,

    I recently repaired a used XPR8400 with various issues and wanted to share the solution, should you encounter the same stumbler I did.

    The 8400 was a UHF-high (450-520) beast. Originally, the TX brick was dead. I acquired a used, replacement brick. When I installed it, the repeater came back to life, but I did not get a successful lightup sequence on the front panel. I have access to the codeplug decryption tool which was used for debugging the audio fix project. I used this to peer into things, and soon discovered there are serial numbers which must match up, or the repeater will not boot. Those serial numbers are: (These are found in the encrypted codeplug/tuning files)

    - RS_SERIALNUM : This is the serial number of the TX brick.
    - RS_CYPHERSERIALNUM : This is the serial number of the RX BRICK/Repeater. (It's the same serial number as what's affixed to the tag on the back of the repeater.)
    - RS_DEVICESERIALNUM : RX Brick/Repeater serial number.
    - RS_SERIALNUM_RX_BOARD : RX Brick/Repeater serial number.

    These serial numbers are stored in both the codeplug and the tuning file. If they are not set correctly, the repeater will not boot. Just a red light. They're not user accessible; just providing theory so you can better understand the "why".

    If replacing a TX Brick, this is definitely an issue. My replacement brick was sent to me in used condition; perhaps FRU bricks are CBI'd (prompts user to enter serial number(s)?

    After I got the serial numbers sorted out and the repeater booted up, I had to manually enter the tuning values from the RX brick, into the new (decrypted XML) file. The tuning file (TX and RX values) is stored in the TX brick, so if you're replacing a brick, you'll definitely need to retune/align the repeater before putting it into operation. Since my replacement TX brick was already aligned, I copied the RX values from the original tuning file and transplanted them into the new one, along with the valid TX values. Good to go.

    The repeater seemed to be functioning fine, but I noticed I had no network connectivity, my MAC address was 00:00:00:00:00:00 and the TS2 LED on the front panel wasn't lighting up. I checked the flex/harness connections, but it did not resolve the issue. I tried adding the MAC address into the codeplug (decrypted XML field: CS_MACADDRESS) but that did not resolve the issue. The modified codeplug shows the MAC address, but after programming this back into the repeater, it immediately goes back to 00-00-00-00-00-00 in CPS. I also updated the same field in the tuning file, but after programming it into the repeater, it was still zeroed out.

    According to the detailed service manual, ethernet functionality, including the MAC address, are stored on an EEPROM on the Repeater Indicator Board (RIB), which is the board mounted on the inside/front of the repeater.

    I removed this board (PMLN5643AS) and replaced it with a new one. The MAC address immediately showed up on a subsequent CPS read and the TS2 LED was back to life. Network connectivity was also restored. The repeater is now fault-free.

    Short version: If you have no network connectivity/00:00:00:00:00:00 as a MAC address, replacement of the RIB is your solution. It is not a CPS/firwmare/labtool kind of problem. Don't waste your time.

    I called MOTOTRBO tech support asking about the 00:00:00:00:00:00 MAC thing and was told to try a "recover". That doesn't work!


  2. The Following 17 Users Say Thank You to Mars For This Useful Post:

    Astro Spectra (Jul 19, 2018),attache (Jan 03, 2016),com501 (Mar 01, 2018),k1ngfish (Jul 19, 2018),MotFAN (Dec 26, 2015),mss-dave (Oct 03, 2015),n3ltq (Nov 27, 2015),no7rf (Jan 04, 2016),NotATechGuy (May 25, 2016),p47r4ck (Oct 05, 2015),PSEhub (Oct 04, 2015),radioboy (Aug 27, 2016),rainbowpenguin (Oct 03, 2015),SwissMoto (Jul 20, 2018),uplinker (Mar 23, 2016),wdatkinson (Oct 16, 2015)

  3. #2
    Join Date
    Mar 13, 2015
    Location
    WI
    Posts
    87
    Thanks
    57
    Thanked 101 Times in 35 Posts
    Country: United States

    Default

    I can attest to the Repeater Indicator Board being the fix for an invalid MAC. I read somewhere once that this was a common issue with units in a certain range of serial numbers. Also encountered one with a MAC of FF-FF-FF-FF-FF-FF. Replaced the indicator board, and all was well.
    not true does not constitute false

  4. The Following 3 Users Say Thank You to rainbowpenguin For This Useful Post:

    khw (Jul 21, 2018),Mars (Oct 03, 2015),PSEhub (Oct 04, 2015)

  5. #3
    Join Date
    Jan 18, 2013
    Location
    In Your Network
    Posts
    2,609
    Thanks
    2,414
    Thanked 1,744 Times in 880 Posts
    Country: Holy See

    Default

    This needs to be a sticky. I have BOTH of the issues you outlined here, with the brick AND the MAC, and I have, apparently, TWO bad front boards as spares, so MONDAY I am ordering a new board while I square away the problems with the brick. This was caused initially by operating the repeater at a site (a customer rented it) without ANY power protection. (power surge hit the mains).

    Good job, Mars.
    Apparently NOT a radio professional.

  6. #4
    Join Date
    Nov 05, 2012
    Posts
    332
    Thanks
    279
    Thanked 236 Times in 146 Posts
    Country: United States

    Default

    Quote Originally Posted by rainbowpenguin View Post
    I can attest to the Repeater Indicator Board being the fix for an invalid MAC. I read somewhere once that this was a common issue with units in a certain range of serial numbers. Also encountered one with a MAC of FF-FF-FF-FF-FF-FF. Replaced the indicator board, and all was well.
    I thought I was all alone with all Fs on a certain unit. Thanks for affirming that as another potential dud when there is a RIB problem. I suspect this issue is pretty localized to a certain manufacture range. Its out there...

  7. #5
    RFguy No Longer Registered

    Default

    There was a FSB on this. The FSB# is FSB10406

    Applied to the XPR8300. Date codes prior to 0061 and denoted by serial numbers prior to 484TLE0000

    RESOLUTION:
    The repeater indicator board, PMLN5269AS, will need to be replaced to resolve this issue (MAC addresses are
    not field programmable).

  8. #6
    Join Date
    Dec 21, 2011
    Posts
    4,546
    Thanks
    3,885
    Thanked 6,742 Times in 1,931 Posts
    Country: Canada

    Default

    Thanks for this info. But it's important to be aware there are two versions of the RIB board: One is for the 8300 and one for the 8400.

    PMLN5269 (8MB repeater, XPR8300)
    PMLN5643 (32MB repeater, XPR8400)

  9. #7
    Join Date
    Oct 24, 2013
    Posts
    4
    Thanks
    1
    Thanked 1 Time in 1 Post
    Country: United States

    Default

    Interestingly - I bought an XPR8300 off that auction site, and it has a PMLN5643 in it (I scratched my head on that when trying to resurrect another ham's XPR8300 with the 00:00:00... MAC problem). That XPR8300 (UHF1) works fine with the 5643 board.

    The XPR8380 I bought off said auction site had 2014 firmware on the factory sticker/probably newer production - it also has the PMLN5643 board. Then again, the 8380 has more settings than an 8300, so I can see those needing the additional storage.

    Quote Originally Posted by Mars View Post
    Thanks for this info. But it's important to be aware there are two versions of the RIB board: One is for the 8300 and one for the 8400.

    PMLN5269 (8MB repeater, XPR8300)
    PMLN5643 (32MB repeater, XPR8400)

  10. The Following User Says Thank You to n0cf For This Useful Post:

    Mars (Dec 17, 2015)

  11. #8
    Join Date
    Oct 12, 2015
    Location
    Moscow
    Posts
    19
    Thanks
    6
    Thanked 22 Times in 12 Posts
    Country: Russian Federation

    Default

    Hi Mars!
    Replace the LAN9500I on indicator board.

  12. #9
    Join Date
    Dec 21, 2011
    Posts
    4,546
    Thanks
    3,885
    Thanked 6,742 Times in 1,931 Posts
    Country: Canada

    Default

    Quote Originally Posted by attache View Post
    Hi Mars!
    Replace the LAN9500I on indicator board.
    That works, too. In my case, there was widespread ESD damage not limited to the Ethernet controller.

  13. #10
    Join Date
    Oct 12, 2015
    Location
    Moscow
    Posts
    19
    Thanks
    6
    Thanked 22 Times in 12 Posts
    Country: Russian Federation

    Default

    Digit of MAC contain in EEPROM 93C46. FF, 6 Byte MAC and rest is filled FF.
    For Read-Write use 8-bit mode.

  14. The Following 4 Users Say Thank You to attache For This Useful Post:

    Alpha (Jan 14, 2016),bup (Sep 19, 2018),com501 (Jan 14, 2016),k1ngfish (Jul 19, 2018)

  15. #11
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    837
    Thanks
    286
    Thanked 510 Times in 262 Posts
    Country: Great Britain

    Default

    Just of out interest I fixed an XPR8400 tonight that had been close to a lightning event. Reported fault was that the repeater would not connect to its IPSC controller and the visual symptom was no Ethernet lights active on the RJ45 when connected to a switch.

    First dropped in a replacement Connector Board PLMN5644 because that was the easiest to get to and has the RJ45 mounted on it but sill no jack lights. After removing the front panel I swapped out the RIB board PMLN5643 and bingo Ethernet LED goodness. Machine appears otherwise OK and fortunately no re-programming seems to have been required.

    Reminded of this page after doing a quick Google on PMLN5643. In my case I think U8 the ADM8515 is dead as the Ethernet transformer seems OK. The replacement board was about $150. No MAC issue today but this thread was a good background read to support the troubleshooting.
    It is a fine thing to be honest, but it is also very important to be right

  16. The Following 2 Users Say Thank You to Astro Spectra For This Useful Post:

    com501 (Jul 21, 2018),Mars (Jul 19, 2018)