M7300 Lost MRU, need recovery assistance

[ElroyJetson]

I have an M7300 in a CS7000 console that experienced a glitch during programming. It shows LOST MRU on the display.

I do have backups for the feature string and tracking data.

Does anyone know the step by step process for recovery?

 

[rescue161]

We just had the same thing happen to two CS7000 XG100M radios. Harris TAC had no fix for us, so we had to send them in for repair. Luckily they are under warranty.

 

[ElroyJetson]

That's not an option. I haven't spent the truckload of money and gotten a Harris contract so the TAC is not an option for me.

 

[rescue161]

Lost MRU means that the control head cannot talk to the Main Radio Unit (MRU). It is the same error that FL 01/90 presents in the Motorola world. If you have access to another control head, you can try to swap heads. The problem that you are having is generally caused by updating the firmware of the radio before the firmware is lifted in the control head. If the control head does not recognize the firmware in the MRU, then it can't communicate and thus displays the LOST MRU message.

If you have access to another radio with the same version of firmware that you had in the broken one before you updated it, that would be the easiest solution. You could put the old firmware head on the old firmware radio and do an upgrade on the control head only and then move the updated head back to the problem radio and it should start working. We always do BURNAPP, Control Head and then ECP last when updating the firmware.

Since our radios are under warranty, it was easier for us to have them repair the radios instead of us potentially breaking more radios.

 

[officerdave]

Lost MRU means that the control head cannot talk to the Main Radio Unit (MRU). It is the same error that FL 01/90 presents in the Motorola world. If you have access to another control head, you can try to swap heads. The problem that you are having is generally caused by updating the firmware of the radio before the firmware is lifted in the control head. If the control head does not recognize the firmware in the MRU, then it can't communicate and thus displays the LOST MRU message.

If you have access to another radio with the same version of firmware that you had in the broken one before you updated it, that would be the easiest solution. You could put the old firmware head on the old firmware radio and do an upgrade on the control head only and then move the updated head back to the problem radio and it should start working. We always do BURNAPP, Control Head and then ECP last when updating the firmware.

Since our radios are under warranty, it was easier for us to have them repair the radios instead of us potentially breaking more radios.

talked about this on Harris Facebook page. We have three 7300 mobiles , that on/off show LOST MRU . We are leaning towards an issue with vehicle ground. One mobile we ran a NIB control head and that worked for a while. The frustration is that the LOST MRU is not consistent. Turn the radio on/off several times and radio comes back. We hope to have our install folks go over the squads and address the ground issue.

 

[rescue161]

We had contractors install the wrong fuses in the control head and MRU. They put the 5 amp for the radio and a 30 amp for the head. Of course, as soon as the user keyed the radio, the 5 amp would blow and then the head would display LOST MRU. We saw that a lot.

 

[Forts]

Also an issue if the canbus isn't terminated in a remote head setup.

 

[ElroyJetson]

That particular radio failed when it was installed in a vehicle. One where there had been no prior issues programming it, I might add.

At the moment the failed radio is configured in a CS7000 with attached control head on the radio chassis.

When it was in the vehicle it was set up as a dual head configuration, with a separate remote head run up front.

CAN bus is terminated in every instance.

Since the car was literally new I would not have expected ground issues.

I was programming the radio and got some failures to complete the programming cycle. I had to JUMP the radio and it was giving an error, 0552, I think. (Feature string) I tried to correct it and it went to LOST MRU.

Information on how to correctly reconfigure the M7300 to a different control head configuration is kind of scarce. I've made it work but since I'm kind of short on official instructions it's always been a calculated risk to mess with it.

I suppose that the best course of action would be to get a spare 721 control head and ensure that it's got updated firmware (and if anyone can lead me to some firmware update files, that'd be appreciated...) and then from there try to get the radio back in contact.

If there are any INTERNAL fuses in the radio or control head that I need to know about, tell me about them now, please.

Since the radio had a head configured on it at the time of failure, I don't think that a blown fuse would cause this issue. The radio still powers up. Or at least the attached control head does.

 

[rescue161]

Were the remote heads configured as remote heads or were they originally dash mounts that you converted to remote? If you converted them, did you change the EID to reflect the change? Can you Putty into the remote heads to see if the EID is configured for remote mount? If it has the wrong EID, you will experience a lot of strange behavior.

 

[wa8pyr]

I have an M7300 in a CS7000 console that experienced a glitch during programming. It shows LOST MRU on the display.
I do have backups for the feature string and tracking data.
Does anyone know the step by step process for recovery?

I think this might be a cause but it's been awhile so I'm not 100% sure...

There should be a CAN port on the back of the radio normally used for connecting a remote head; check to make sure there's a dummy CAN plug in there. If I recall correctly, if there's not a loop through either a dummy CAN connector or another control head through that port, the radio won't recognize the attached control head.

 

[ElroyJetson]

Yes, as I mentioned earlier, the CAN terminators are present and connected correctly.

I could use a PuTTY guide to the M7300 and CH721 if you happen to have it.

I must have gotten lucky in that respect because my mobile "scanner" is a dual head M7300 and it works perfectly. I just have to make sure that
the volume/power controls are properly set. They do have a control heirarchy. Leave the radio head turned on, and the remote head actually controls the system.

 

[rescue161]

HyperTerminal or PuTTY will work, which ever you have on hand.

Use this procedure to change the control head’s model information character.
The model information character is the sixth (6th) character in the head’s 12-character EID:

1. If a CAN cable is connected to the control head, disconnect it. The head cannot be communicating with a radio.

2. Turn the control head off by rotating its on/off/volume control fully counterclockwise to the off (detent) position.

3. Set a regulated-output DC power supply to 13.6 VDC and connect it to the control head’s DC power input connector using DC Power Cable CA-012365-001 or CA-012616-001.

4. While holding the control head’s “C” preset button fully depressed, turn the head on by rotating its on/off/volume control clockwise out of the detent position. When it powers-up, it will indicate “NO MRU” in the display. Disregard this indication. The head’s test command mode is now enabled.

5. Using CH-721 Serial Programming Cable CA-104861 (or equivalent), connect the Personal Computer’s (PC’s) serial port to the DB-9 serial port connector on the rear panel of the CH-721. If the PC is not equipped with a DB-9 serial port connector, the use of a suitable adapter is required, such as USB-to-RS-232 Adapter Cable CN24741-0001.

6. At the PC, start the terminal emulation software such as Windows HyperTerminal.

7. Configure the terminal emulation software for the respective serial communication port (e.g., COM1) at 19200 bps, 8 data bits, 1 stop bit, no parity, and no flow control.

8. Set the terminal emulation software’s function, arrow, and control keys to act as terminal keys. For HyperTerminal, this is accomplished via the respective serial port’s Properties dialog box (Settings tab), as illustrated in Figure 5-3.

9. Set the terminal emulation software for TTY (teletype) emulation. For HyperTerminal, this is accomplished via the respective serial port’s Properties dialog box (Settings tab), as illustrated by the left-most dialog box in Figure 5-3.

10. Set the terminal emulation software to echo typed characters locally. For HyperTerminal, this is accomplished via the respective serial port’s Properties dialog box (and Settings tab), and ASCII Setup button, as illustrated by the right-most dialog box in Figure 5-3.


Figure 5-3: Configuring the Terminal Emulation Software (e.g., HyperTerminal)

11. While in the terminal emulation software, enable “Caps Lock” by pressing the respective key on the PC’s keyboard. The control head’s test command mode only recognizes capital (upper-case) letters.

12. Type the following command to send it to the control head. This is the “show EID” command. <Ctrl B> means to hold the keyboard’s “Ctrl” key down while typing the "B" key. Likewise, <Ctrl C> means to hold the keyboard’s “Ctrl” key down while typing the "C" key. The space between the “W” and the “E” must be included, and all letters must be in upper
case.
<Ctrl B>CH-SHW EID<Ctrl C>
The control head will respond with its 12-character EID string, as illustrated in Figure 5-4. The sixth character in this EID string is the control head’s model information character that must be changed in a subsequent step. The other characters within this string cannot be changed.


Table 5-1:

Control Head’s Model Information Character Definitions (6th Character in the 12-Character EID String)
6th CHARACTER CONTROL HEAD MODEL
5 Front-Mount System Model Control Head
6 Remote-Mount System Model Control Head
7 Front-Mount Scan Model Control Head
8 Remote-Mount Scan Model Control Head

13. Select only the twelve reported EID characters and copy them to the Windows clipboard.

14. Open a Windows Notepad session and paste the 12-character EID string into Notepad.

15. Using Table 5-1 as a guide, determine the proper new character for the control head conversion, for example, if converting a System model control head from a remote-mount to a front-mount, the correct new character is 5.

16. In Notepad, change the sixth character of the 12-character EID string to the proper character. The other characters within this string cannot be changed!

17. Copy only the 12-character EID string to the Windows clipboard (with the new 6th character).

18. Within the terminal emulation software, type the following command to send it to the control head. The space between the “D” and the “S” must be included, and all letters must be in upper case.
<Ctrl B>CH-LOD SFM<Ctrl C>
<Ctrl B> means to hold the keyboard’s “Ctrl” key down while pressing the "B" key. Likewise,
<Ctrl C> means to hold the keyboard’s “Ctrl” key down while pressing the "C" key, then release both keys before pressing the key for the next character.

19. Within the terminal emulation software, type the following command to send it to the control head. This is the “clear EID” command. The space between the “R” and the “E” must be included, and all letters must be in upper case.
<Ctrl B>CH-CLR EID<Ctrl C>
The control head will respond with a cleared EID (all 12 characters set to “F” as illustrated in Figure 5-5.
Figure 5-5: Clearing the Control Head’s EID (Example)

FFFFFFFFFFFF

20. Send the revised EID to the control head by sending it the following command. Spaces are significant, and “ENTER NEW 12-DIGIT EID HERE” is use a paste function within the terminal emulation software to enter the EID, before typing the <Ctrl C>:
<Ctrl B>CH-SET EID [ENTER NEW 12-DIGIT EID HERE]<Ctrl C>


CAUTION
Verify the entered string is correct before sending the <Ctrl C> to the control head. If the string is not correct, press the Backspace key until the string is erased, type or paste in
the correct string, and then press <Ctrl C>. An example is shown in the following figure:
Figure 5-6: Sending the Revised EID to the Control Head (Example)
The control head’s EID is now revised to match the new mounting configuration.

21. Disconnect DC power from the control head, and then disconnect the serial cable.

22. If performing a front-mount to a remote-mount conversion, connect the radio to the control head via the CAN link, power-up both units, and verify basic control head operation. Be sure to terminate the radio’s antenna port with an appropriate antenna or 50-ohm load.
If performing a remote-mount to a front-mount conversion, continue with the hardware conversion procedure presented in Section 5.1.2.

 

[wa8pyr]

Yes, as I mentioned earlier, the CAN terminators are present and connected correctly.

I could use a PuTTY guide to the M7300 and CH721 if you happen to have it.

I think I have it but not sure; I'll dig around and see if I can find it.

 

[officerdave]

Our radios started life as remotes and have remained that way. CAN terminators all correct . Harris engineers say that the radio must be on a OEM body ground , sperate from other devices, such as siren control, lights etc. We are going to try and body ground the control head and radio separate to true OEM grounds. Frustrating because it is never consistent lost MRU ..... happened yesterday looked down and " lost MRU " turned off M7300 drove for a while , turned back on and no issue rest of shift . ugh

 

[ElroyJetson]

There are no other accessories in the vehicle. No horn, no lights. Radio only. But it has a remote head and the head is on a separate ground point. I now must conclude that a single ground point for the radio and both heads is an absolute requirement.

What this means is that any attempt to recover will be done with the radio installed in the CS7000 chassis and programmed from there. That SHOULD be sufficient. Since I find that for programming purposes I simply can't trust vehicle grounding.

What a BAD design, to be that sensitive to grounding variances.

 

[rescue161]

Ground is ground, so if there is a difference of potential between the two points that you used as grounds, then one or both of them has a problem.

 

[Radioman96p71]

The CAN bus on the OMAP+ radios follows the CANBUS 2.0 spec, which uses a differential pair for communication similar to Ethernet. There does not need to be a common ground between the control head and the radio for this to work, according to the spec. Just like Ethernet, the CANBUS link operates at a fairly high frequency (40MHz according to the manual) so the twisted pair CAN cable between the radio and the head should be considered more like a feedline than a simple TTL-level cable like the old RS485 of the M7100/Motorola radios.

Anyways, I've seen similar issues where a radio would just randomly go into "Lost MRU" and it's usually either a bad cable (kink in the wire/broken conductor inside), a bad terminator that was causing reflections on the CANBUS or, in a rare case, there was some light corrosion on the filtering capacitors on the CANBUN lines on the logic board which caused excessive noise/reflections.

If the radio is in a permanent "Lost MRU" status either the radio isn't actually booting up because of a failed flash load or there is something physically wrong, it's pretty hard to brick these unless you have catastrophic failure when loading BurnApp/BootApp. Open up a terminal program connected to the serial port on the back, 19200 8-N-1, and turn the radio on. You'll get debug output if the radio is capable of booting and sees the power up signal on the CANBUS. You could also probe the voltage regulators on the board to see if the power-on signal is being received and at least trying to power up the main CPU.

Also, with a properly-terminated control head attached, the CAN-H and CAN-L lines on the CAN connector should be about 2.25-2.5V reference radio ground, if one is much higher than the other then there is a bad connection or bad terminator on the bus. A floating CANBUS should be around 5V reference the radio ground (no accessories or terminator attached). If you have a scope you can probe between CANH and CANL and watch for a waveform that looks balanced between the high and low signals, bias to one side or the other indicates a fault.

 

[ElroyJetson]

I've dug out the failed radio and am preparing to attempt to give it CPR.

This radio is currently installed in a CS7000 console and thus has a control head joined to the radio chassis. The control head has never been separated from that chassis so I have no reason to think that its configuration needs to be changed.

I'll start by seeing if I can establish communications with the radio via the RS232 port on the back of the radio chassis.

To keep things simple I'll use the CS7000 only as a power supply, with all other cabling disconnected.

I'm suspecting that the radio unit has a corrupted flash. Fortunately I know I backed up ALL the information out of that radio when I first got it, so if I can get its heart started, I should be able to restore it to full functionality.

But, what I still need, is the step by step recovery procedure when dealing with a LOST MRU case.

 

[apco25]

I have long suspected the issues in vehicles for lost MRU has to do with voltage drop and ground differential (because of cable length differences, vehicle charging system health, etc) causing the MRU and CH start their boot sequence at slighlty different times. This shouldn't matter given how Canbus works, but it's the only conclusion I've derived on this over the years.

 

[rescue161]

We have seen the same LOST MRU problem with CS7000 base stations, so I don't think it is a ground buss issue.