Clock issue.. I feel vindicated!
- Thread starter VE3RADIO
- Start date
- Status
Me, too. The mobile unit just started doing it this past week. How the heck am I suppose to run the car for 50 hours to charge the battery???
Mike
A patch to fix an aging component doesn't appear to be the best way to fix this problem. I'm not sure if the issue is a failing battery or whatever it is that keeps the time in these scanners but if hardware is failing how can a patch permanently fix it?
Because maybe the issue isn't a failing component...
Maybe it's how the component is charged. Firmware might be able to control that.
I don't know exactly what the issue is, but I would not go so far as to say it's definitely a component issue.
As I understand it, Uniden is still looking into the issue, so they haven't found the exact cause, or if they have they aren't announcing what it is.
Maybe it's how the component is charged. Firmware might be able to control that.
I don't know exactly what the issue is, but I would not go so far as to say it's definitely a component issue.
As I understand it, Uniden is still looking into the issue, so they haven't found the exact cause, or if they have they aren't announcing what it is.
"As I understand it, Uniden is still looking into the issue, so they haven't found the exact cause, or if they have they aren't announcing what it is."
Say what?
Say what?
This battery backup/charge circuit has to be rather simple to understand and fix. I'm guessing Uniden is trying to figure the cheapest way to fix every radio that now seems to exhibit the problem. I have not seen anyone lately saying my clock still works fine.
I used to manage a test department. I would wager that on their worst day my worst technician could have located the source of the issue and come up with a fix within a day or two.
Clock is supposed to keep time.
Clock isn't.
What's so hard to figure out?
I'm still having trouble wrapping my brain around the clear fact that clocks that worked for a year are no longer working well. To even the untrained eye this appears to be a failure, component degradation or component aging issue. How can FW address hardware changes? What if the HW degrades further? Will the FW be able to continue to compensate for that? It will be interesting to follow this saga.
No firmware will fix a hardware component failure. Uniden is working on a temporary firmware patch that will by-pass the use of the internal clock. Then once they figure out which component or components has failed there will be a process for repair or replacement.
I think the best and less stressful approach would be to set the *36HP aside and wait. If you can pick up a Pro-668 at a good price while you can and use that. You may find that it's a pretty awesome scanner.
I think the best and less stressful approach would be to set the *36HP aside and wait. If you can pick up a Pro-668 at a good price while you can and use that. You may find that it's a pretty awesome scanner.
Then you have to get into "is it a hardware issue, or a firmware control issue". As the hardware issue may be intermittent, I'm sure you can appreciate that solving intermittent issues are a PITA. Now when you add modern circuits that are controlled by firmware, the issue gets more cloudy as to the cause. Is the issue not occurring presently, or is it not really a hardware issue.
One of the things I first learned troubleshooting is that you never know if the bad component was the problem OR if something else caused the bad component to fail. If the latter, it's not always an easy thing to identify. Now add software, and you need to know not only electronics, but CPU code.
It's not like troubleshooting a 54 ford engine firing issue.
One of the things that I learned troubleshooting computer problems and ambulance electrical problems was that more often than not there is more than one component at fault.
We used to have dual alternators with dual external regulators on our ambulances. After a while we adopted the policy of replacing an alternator AND it's regulator because so many times both were bad and if we only replaced one component we'd end up having to replace the other.
Not to mention the time a crew came in with the complaint that the tail lights and all of the ICC lights were out on their ambulance. After doing every diagnostic we could think of on the circuit, we replaced all of the bulbs. While the crew told us that it happened all at once, it turned out that it had been going on for months, one bulb at a time.
Troubleshooting electronic/electrical issues is incredibly frustrating sometime. My friend who works in marine electronics manufacturing tells me that it can take weeks to figure out what's wrong with a new design. They don't always get it right the first time, which is why they often have to issue Engineering Change Orders when they do find and correct a problem.
I've seen enough of this stuff over the years, along with software issues, to know that it can be incredibly hard to sort out and no matter how much beta testing you do, stuff still slips by.
We used to have dual alternators with dual external regulators on our ambulances. After a while we adopted the policy of replacing an alternator AND it's regulator because so many times both were bad and if we only replaced one component we'd end up having to replace the other.
Not to mention the time a crew came in with the complaint that the tail lights and all of the ICC lights were out on their ambulance. After doing every diagnostic we could think of on the circuit, we replaced all of the bulbs. While the crew told us that it happened all at once, it turned out that it had been going on for months, one bulb at a time.
Troubleshooting electronic/electrical issues is incredibly frustrating sometime. My friend who works in marine electronics manufacturing tells me that it can take weeks to figure out what's wrong with a new design. They don't always get it right the first time, which is why they often have to issue Engineering Change Orders when they do find and correct a problem.
I've seen enough of this stuff over the years, along with software issues, to know that it can be incredibly hard to sort out and no matter how much beta testing you do, stuff still slips by.
So are you saying that the RTC problem is being misreported by most users? It seems that's what you're saying. If you're not, please clarify what you meant about the bulb problem analogy. Thanks.
Set my radio aside? It's mounted in the dash of my car! How the heck do I "set it aside"??? Not to mention the clock has worked fine for about 9-10 months and then all of a sudden if I turn the engine/power off any longer than a couple of hours I have to reset the clock.
Lesson learned. I'll never buy another Uniden product that has a clock in it.
Mike
I'm still amazed how there are people on this site that actually believe that the clock issue is caused by a FW issue. That makes absolutely no sense and defies logic. There are people on RR right now that have clearly stated that they used to feel that users with RTC issues were whiners and complainers because they never had the problem - until now. Now, these people are in the same boat as the ones who had the problem earlier.
The more likely - and more realistic - reason why some of these people keep saying it's a FW issue is because they have invested so much RR bandwidth over the last year bashing dissenters that they are having a tough time admitting that the problem may have been HW all along. Nobody likes to admit they were wrong.
I'm really glad my 668 doesn't have this issue.
What defies logic is that they used the same hardware design as the HP-x series, and AFAIK none of those have failed.
I will freely admit that it might be a hardware issue, but it still COULD be a firmware issue, as the firmware controls much of the radio including such things you would think would be hardware such as the volume and squelch. More and more the scanner design is CPU controlled. That means more and more the problem could be in the firmware. Specific to that issue, perhaps the CPU controls the battery charging. If so, perhaps it is cutting off early or failing to engage. Hence, what looks like a hardware issue is really a firmware issue.
With that knowledge in hand, does it make more sense now?
You have to understand electronics.
I'm not saying this is how the x36 is designed, but it's one possibility, and fully explains how firmware can control hardware. (or fail to control it)
If the clock battery charging circuit is controlled by the CPU, then the CPU (hence the firmware) controls when it is being charged and when it's not. If a malfunction causes a bit to get stuck in the wrong position, that signal may never be sent to charge the battery. Thus, the battery goes dead and the clock loses time.
Another theory I floated recently is that the display dimming and the clock might be related. If the same regulator is used for both, and if that regulator is failing, it could affect both the voltage the backlight receives as well as that the clock battery receives. Both are conditions that take time to develop, and it's certainly not beyond possibility that they are related. The regulator could also be controlled by firmware.
As I said above, the HP-x series does not seem to exhibit this issue, and they reportedly use the same hardware design.
Firmware doesn't have to have updates to be altered. It reads data off an SD card which I bet has been changed by you many times. Perhaps a corruption in the card set the aforementioned bit.
One more possibility: The firmware is supposed to charge the battery to capacity and stop. What happens if it doesn't stop? Like any battery that is continually charged, it will die a premature death. Note that these symptoms are identical to a "bad battery", and changing the battery will solve the symptom, BUT NOT the CAUSE. Perhaps this is what Uniden is looking into. Again, that's a firmware bug that imitates a hardware flaw.
There are a ton of causes that can make the issue a firmware issue, and it's pointless to guess exactly what the issue is. I only mention a few to prove it's not far fetched that firmware that controls hardware can fail to control hardware given the right (or wrong) circumstances.
One thing that is clear: The RTC failure seems to be caused by a voltage failure. What is causing the voltage failure? Is it a bad battery? A bad charging circuit? A cold solder joint? Or is it something that is in the firmware that is malfunctioning (a bug)?
I'm not saying this is how the x36 is designed, but it's one possibility, and fully explains how firmware can control hardware. (or fail to control it)
If the clock battery charging circuit is controlled by the CPU, then the CPU (hence the firmware) controls when it is being charged and when it's not. If a malfunction causes a bit to get stuck in the wrong position, that signal may never be sent to charge the battery. Thus, the battery goes dead and the clock loses time.
Another theory I floated recently is that the display dimming and the clock might be related. If the same regulator is used for both, and if that regulator is failing, it could affect both the voltage the backlight receives as well as that the clock battery receives. Both are conditions that take time to develop, and it's certainly not beyond possibility that they are related. The regulator could also be controlled by firmware.
As I said above, the HP-x series does not seem to exhibit this issue, and they reportedly use the same hardware design.
Firmware doesn't have to have updates to be altered. It reads data off an SD card which I bet has been changed by you many times. Perhaps a corruption in the card set the aforementioned bit.
One more possibility: The firmware is supposed to charge the battery to capacity and stop. What happens if it doesn't stop? Like any battery that is continually charged, it will die a premature death. Note that these symptoms are identical to a "bad battery", and changing the battery will solve the symptom, BUT NOT the CAUSE. Perhaps this is what Uniden is looking into. Again, that's a firmware bug that imitates a hardware flaw.
There are a ton of causes that can make the issue a firmware issue, and it's pointless to guess exactly what the issue is. I only mention a few to prove it's not far fetched that firmware that controls hardware can fail to control hardware given the right (or wrong) circumstances.
One thing that is clear: The RTC failure seems to be caused by a voltage failure. What is causing the voltage failure? Is it a bad battery? A bad charging circuit? A cold solder joint? Or is it something that is in the firmware that is malfunctioning (a bug)?
jonwienke
More Info Coming Soon!
You're not looking too hard. Mine does...
- Status
Similar threads
