My friend Nacho EA4GZR kept complaining about his Icom IC-7300 not keeping time as it should, gaining “a lot” more than expected as compared to the companion IC-9700 that he has sitting next to it. The IC-9700 has a NTP client, so it was easy to him to see how much the clock was gaining time, quickly. To be honest, I thought he was being picky, but when he showed me the results of his observations, I had to admit that something was wrong, he was not being picky… It did not take long before we met at my lab to take a look at it.
The observations
Nacho had been taking measurements and notes from some time, and he showed up with this:
There was no doubt, the clock was gaining 0,000128 seconds every second. That is more than 11spd, 11 seconds-per-day in watch aficionado’s lingo, or 128ppm, parts-per-million in engineering lingo. Simply unacceptable for a digital clock. Luckily, the frequency reference for the RF circuitry is not derived from the same time source than time.
The Real Time Clock, Seiko Epson RX8803LC
The IC-7300 shares the RTC with other transceivers and receivers of the family. The version chosen by Icom for the 7300 is the RX8803LC UB, with a specified stability equivalent to +-13 seconds per month. Our unit was many orders of magnitude outside the acceptable deviation.
The RTC keeps time at all times thanks a small reachargeable battery that is mounted next to the RTC in the PCB. When the transceiver is powered-on, the main processor loads the time and date from the RTC vía I2C and from then on, it keeps time by means of a 1 pulse-per-second interrupt that is generated by the RTC. The RTC is to the right of the white unused connector the far left, and the button battery is close to it:
It should be possible to measure that 1pps signal and see if it runs faster in the amount that we expect, right?
Exactly what we expected, 128ppm !! There is no way this clock could be that far off the nominal frequency. Nacho ordered a few UA versions, even more that stable than original. It is very small, we removed it with hot air, after protecting the plastic connector with kapton tape:
After removing it, we found it has a transparent window below and the quartz crystal can be seen:
After replacing it what the new one, we believed the operation was over. Guess what? The transceiver was not counting seconds anymore… It loaded the correct time everytime it was turned on but then stopped counting. It was not doing the interrupt to update the time. We found the pullup resistor was burned, we replaced it but the processor was constantly pulling it low, there were no 1pps pulses… I took all the usual precautions but somehow the interrupt pin of the processor got damaged, or maybe it was already and that is why the clock was so far off. In any case, the processor had to be replaced:
At this point, we had replaced the RTC, the pullup resistor and the processor:
Everything assembled back, we verified the were 1pps pulses with the oscilloscope. The transceiver seemd to work fine, what a relief. Now what? Check the actual frequency of the 1 second interrupt signal with the counter:
Yess! It looked a lot better, the error was now 560ppb. Still running a bit fast, but converted to seconds per month, the clock would gain only 1,4 seconds-per-month. That is well inside the limits of the UA version, that is specified to a maximum error of 9 spm.
