Results 1 to 14 of 14

Thread: MTR 2000 Issues - Potential Solutions

  1. #1
    Join Date
    May 22, 2012
    Posts
    609
    Thanks
    206
    Thanked 260 Times in 130 Posts
    Country: United States

    Default MTR 2000 Issues - Potential Solutions

    Recently I have come across an issue with a VHF-2 MTR 2000 station periodically reverting to carrier squelch operation. This MTR 2000 functions as a voted receiver in a public safety system. When the station reverts to CSQ, all hell breaks loose at the dispatch center (naturally).

    After some conversations with the SSC about it, it was decided a station firmware upgrade was required. This was done, the station is working on the last firmware release available.

    No joy. It did it again.

    Some conversation with SSC and others has revealed that there is potential for "codeplug poisoning" in the MTR 2000 station, where reading the station, making a change, and writing back to the station could introduce erroneous data resulting in undesired operation at undesired times.

    It's been suggested that when programming an MTR 2000 station, the best way to do it is to create a new codeplug in the MTR 2000 RSS, make all the changes to the new codeplug, and then write the fresh codeplug into the station.

    If anyone ends up with weird behavior on their MTR 2000, try this method and see if it doesn't solve your problem. I have not had any issues with the affected station since doing this, I'll report back if I do.


  2. #2
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,539
    Thanks
    550
    Thanked 1,112 Times in 579 Posts
    Country: Christmas Island

    Default

    We had MSF5000's doing exactly the same thing. The problem according to some Motorola engineers is related to a stack overflow in the station firmware. Is your MTR connected to a console or a CIU? I remember that has something to do with it, IIRC it had to do with when one IS connected to a console the stack gets regularly reset by keyups from the console, IIRC. When they aren't the problem would occur, it happens after a specific number of incoming keyups from the receiver without seeing a console keyup. It would take somewhere between 24-48 hours for the problem to occur, and it pissed of many a maintenance person that had to go and reset/reprogram the station constantly.

    At one point we considered putting in a coffee-pot timer to issue a spurious console keyup once a day at midnight! We finally upgraded them to Quantars and most of the issues went away.

    Which brings about the next possibility - does resetting the station restore proper operation, or did you have to reprogram it to fix it? The reason I ask is another issue I remember that is sort of similar.

    Another problem with the MSF's IIRC is when you change modes, or scan channels, each time a frequency change happens the station re-writes all of the EEPOT's. EEPOT's are little devices that act like pots that hold all of the tuning values, but have serial EEPROM's in them to "remember" their settings. That means that the EEPOT's get re-written several times a second when scanning. Apparently they get stupid after several million read/write cycles and the stations would lose their tuning values (deviation and squelch type, mostly) after scanning about a several day period. Reprogramming the station fixed the problem.

    Basically there are 2 major issues which sometimes appeared similar, but the key difference is that the 1st problem required a simple reset, the 2nd problem required full reprogramming to fix it.

  3. #3
    Join Date
    May 22, 2012
    Posts
    609
    Thanks
    206
    Thanked 260 Times in 130 Posts
    Country: United States

    Default

    This is just a receiver (though it is a full-blown MTR 2000 transceiver, it's not being used as such). Resetting the station did fix the problem, but it just occurred again after time.

    I've never had any trouble with the MSF 5000 stations in that regard. I'm familiar with EEPOTS and EEPROM life-cycles... All too familiar...

  4. #4
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,539
    Thanks
    550
    Thanked 1,112 Times in 579 Posts
    Country: Christmas Island

    Default

    Sounds like it might be similar to #1, then the station "forgets" it's PL and reverts to CSQ, and a reset fixes it. That is exactly the same symptoms we were getting.

    Maybe the coffee-pot timer idea would work, design a relay to briefly kill the power to the station for 1/2 second at 2:36 AM or something

  5. #5
    Join Date
    May 22, 2012
    Posts
    609
    Thanks
    206
    Thanked 260 Times in 130 Posts
    Country: United States

    Default

    Well so far, the station has remained in PL since being reprogrammed with a "fresh" codeplug. We'll see if it stays that way!

  6. #6
    Join Date
    May 30, 2012
    Posts
    223
    Thanks
    28
    Thanked 54 Times in 27 Posts

    Default

    I've heard of this exact issue, with the 'fresh' codeplug being the fix. Although I've never had the issue, it kind of boggles the mind that simply reprogramming the station could potentially 'poison' it, as you say.

  7. #7
    Join Date
    May 22, 2012
    Posts
    609
    Thanks
    206
    Thanked 260 Times in 130 Posts
    Country: United States

    Default

    Yeah, no kidding. I guess it boils down to poor coding or something to that effect - perhaps the "rewrite" of the station from a "read" of the thing only changes what was actually changed, but in actuality creates problems elsewhere in the codeplug.

    Everyone knows that the Motorola way of doing things is not a perfect science.

  8. #8
    Join Date
    Feb 26, 2012
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    What has always puzzled me about this is why only MSF's/MTR2000's have this issue and not other motorola RSS/CPS programmed radios (that you often cannot just create a blank codeplug for) dont have this problem. d119 thank you for the excellent tip on MTR2000's

  9. #9
    Join Date
    Dec 12, 2011
    Location
    Avalon
    Posts
    1,201
    Thanks
    274
    Thanked 314 Times in 152 Posts
    Country: United States

    Default

    I think it has something to do with who develops the software, the fixed end equipment is developed by different software teams. You can tell by looking at the software which ones were developed by the same groups and which ones were not.

  10. #10
    Join Date
    Feb 26, 2012
    Posts
    26
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Yea I totally agree on the different software teams... another one that ive always gone "Why for the love of god did you do this?!?!" is the RSS for the analog sabers where you hit one key and it blasts ur tuning data while writing and another to keep the same tuning data... ive had to fix so many radios that people have blown the tuning data out during a write and it no longer works right.

  11. #11
    Join Date
    May 22, 2012
    Posts
    609
    Thanks
    206
    Thanked 260 Times in 130 Posts
    Country: United States

    Default

    Yep. Well as I've said before, I will let folks know if the MTR in question falls out of PL again. I fixed it up week before last, so we'll see. Last time it ran several months before doing it, but then last time I didn't do the new codeplug trick.

  12. #12
    Ramal121 No Longer Registered

    Default

    OK, so I need to make a fresh codeplug as stated above. Using the default VHF in the "DEFPCF" folder, the station ID shows as "invalid". Won't this prevent me from writing the station???

  13. #13
    Join Date
    Dec 12, 2011
    Location
    Avalon
    Posts
    1,201
    Thanks
    274
    Thanked 314 Times in 152 Posts
    Country: United States

    Default

    The station id doesn't get written so probably not.

  14. #14
    Join Date
    May 22, 2012
    Posts
    609
    Thanks
    206
    Thanked 260 Times in 130 Posts
    Country: United States

    Default

    Quote Originally Posted by Ramal121 View Post
    OK, so I need to make a fresh codeplug as stated above. Using the default VHF in the "DEFPCF" folder, the station ID shows as "invalid". Won't this prevent me from writing the station???
    You can go in and change the station parameters (band, bandsplit, power level, accessories, etc) in the default codeplug to match what your station has. If something is off, it'll error out and not write. Once you have it matched up, you can then put the clean codeplug in.

    There are FSB's that exist for the MTR 2000 firmware that you might be able to get gratis through UO. I recommend trying to upgrade the station to the latest firmware if at all possible.

    Knock on wood, we haven't had any more problems with the station in question since a firmware upgrade and clean codeplug load.