Here is a problem I’ve run into several times now and it seemed to warrant a blog post. An MTR2000 that has previously worked great with the STM32-DVM-MTR2K seems to magically stop decoding. The only tell-tale symptom to be found is that while previously adjusted perfectly, the clip light seems to be on all of the time.
I originally found this issue several years ago. Finding the issue was an exercise in futility. It seemed that every time I started messing with the station, it would work fine. Then every time I took it back to the site, it didn’t. I don’t want to think about (or tell you) how many back-and-forth trips to the site this took. Suffice it to say, eventually I discovered that the thing that made it work again was writing the station (with CPS). But this makes no sense, so after thinking it through a while, I realized that station writes caused warm restarts. Aha! Now we have the fix.
This is undoubtedly in the SCM somewhere, because swapping out the SCM fixed the problem, though SCMs are hard to come by, and I didn’t want to start throwing them away over this! As it turns out, one of the actions in the wildcard is “COLD RESET”, which can be used to trigger a “RESET”, which it a warm reset, just like the one performed by CPS.
But the question remains why this works? I don’t really know. I can only speculate that some reference voltage or frequency in the SCM gets sampled on startup, and in aging SCMs does not stabilize in time. If you have a real fix for the SCM, I’d love to know what it is. I’ve been in them…. replacing the capacitors doesn’t seem like a good return on one’s investment!
The last thing is that you’ll see that I’ve added a 10 second delay. If my theory about a voltage or frequency resource that needs time to stabilize is correct, I figured giving it a few extra seconds makes good sense – so I added the time. The MTR2000 takes a little time to reboot now, but in the grand scheme, it essentially a no-compromise fix.