DM42- clock losing time

[bobhwasatch]

I tried this out a week ago. My DM-42 clock was about 23 ppm fast. I put in a correction of -24 and the drift is now much less (will give it until next week and check exactly).

So it would appear the the correction should be the opposite sign of the error.

[NoisyBoy]

Some discoveries to share:
• bobhwasatch is absolutely right. Sign-wise for the compensation variable C, a -ve value slows down the clock, and vice versa.
• Starting from C=-14 (from the crystal frequency deviation measurement), after a couple tries, I found a value of C=-16 gives my calculator almost perfect time keeping in 24 hours. I will keep track of it for a few more days to see if I can further improve on the accuracy. Once that’s done, I will reset the value to 0 and see what happens to the clock. I am not sure if the calculator circuitry is looking for a 32.768 kHz signal for perfect time keeping. I have a feeling the calculator will gain time with C=0 despite the crystal is 13.765 ppm below the spec frequency. Back on my earlier post, my assumption that my crystal frequency drift of -13.765 ppm does not translate to an annual time lost of 434.09 sec.
• With regard to how RTC adjustment works, as soon as you copy the time correction file over to the DM42 FAT partition, it is automatically picked up by the DM42 when you disconnect from the computer. There is no need to restart or do anything to activate it.
• The current implementation requires you to measure time drift in ppm, reverse the sign, then convert to the correction factor C. But after you apply this correction factor C, the DM42 clock setting line shows the correction value in ppm! I believe it is more intuitive to eliminate C and allow users to enter the compensation drift in ppm instead of the back and forth conversion.
• I had some disk integrity issue with my new DM42, its FAT partition caused Windows 10 Pro File Explorer to run slow and the DM42 to hang. After running a disk repair, operation is much faster, and no further issues detected. Make sure you disconnect/eject the DM42 in Windows before you unplug, otherwise you will corrupt files on the DM42. After my DM42 hung, some files in the FAT partition were corrupted and I had to rebuild the partition. Thanks to Swiss Micros excellent website, all the files I needed to rebuild were on the website.

[Over_score]

Here a small spreadsheet to do this calculation: https://www.cjoint.com/doc/20_08/JHjgDj ... ection.xls

[x55]

Here a small spreadsheet to do this calculation...

Thanks. Easier than by hand using naked keyboard. But what is the "True date" format?

[Over_score]

But what is the "True date" format?

In my case (french configuration) it is DD/MM/YYYY hh:mm:ss

[x55]

But what is the "True date" format?

In my case (french configuration) it is DD/MM/YYYY hh:mm:ss

Thanks

[chr yoko]

ISO 8601 date format is YYYY-MM-DD

https://en.wikipedia.org/wiki/ISO_8601

we should only use this to avoid any confusion.

In Japan they are already "up to date".

US and European style are incorrect and confusing !
also ISO style is best in file names, you always get last version on top

[x55]

But what is the "True date" format?

In my case (french configuration) it is DD/MM/YYYY hh:mm:ss

Problem solved. My mostly-irrational aversion to Microsoft products led to my using an alternative 'Office' suite on this Android tablet I am constrained to use at the moment. When I uninstalled it and installed Microsoft's own port instead the "True date" fields were rendered as intended, with the date in a conventional format. Thanks again, apologies for wasting your time.

[NoisyBoy]

I have been tweaking with the correction factor and finally settled on a correction factor C=-22.

After daily checking for a week, there is no detectable drift from the reference clock in my lab. I will keep it running for another month and see what happens.

But so far, it appears that despite the crystal oscillates at a frequency 13.765 ppm below the spec frequency of 32.768 kHz, once you get the proper correction factor dialed in, it can be very accurate. Forget about using the crystal frequency error to calculate C, as in my case, the proper correction value is -21ppm while frequency error is -13.765ppm.

The best way to tweak it is to compare it against a clock that is accurate, and fine tune the correction factor.

I hope this helps.

[NoisyBoy]

After over a month, I have to declare that once you dial in the proper correction value, the clock is highly accurate and consistent. After 34 days, the delta is under 1 sec. Which represents an accuracy better than 0.34 ppm.