DM42- clock losing time

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
bobhwasatch
Posts: 1
Joined: Sun Oct 13, 2019 2:05 am

Re: DM42- clock losing time

Post by 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
Posts: 12
Joined: Thu Jun 25, 2020 7:49 am

Re: DM42- clock losing time

Post by 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.
User avatar
Over_score
Posts: 118
Joined: Fri May 05, 2017 9:37 pm
Location: France

Re: DM42- clock losing time

Post by Over_score »

Here a small spreadsheet to do this calculation: https://www.cjoint.com/doc/20_08/JHjgDj ... ection.xls
DM42 SN00284 running free42 & SN03835 running WP43S, DM15L, HP41CV, HP42S, HP35s, WP34S, HP Prime
x55
Posts: 19
Joined: Sun Jul 26, 2020 7:32 am

Re: DM42- clock losing time

Post by x55 »

Over_score wrote:
Sun Aug 09, 2020 8:32 am
Here a small spreadsheet to do this calculation...
Thanks. Easier than by hand using naked keyboard. But what is the "True date" format?
--
HP: 55/67/41C/HP-IL/ProtoCODER*/41CL/MLDL**/41CX/16C/71B/42S/33s***/35s ...
DM: 42 ...
Etc: If a calculator has equals, why buy one unless it's the cheapest?
* ProtoTECH, USA / ** Eramco, Netherlands / *** Carly Failurina model
User avatar
Over_score
Posts: 118
Joined: Fri May 05, 2017 9:37 pm
Location: France

Re: DM42- clock losing time

Post by Over_score »

x55 wrote:
Tue Aug 11, 2020 2:48 am
But what is the "True date" format?
In my case (french configuration) it is DD/MM/YYYY hh:mm:ss
DM42 SN00284 running free42 & SN03835 running WP43S, DM15L, HP41CV, HP42S, HP35s, WP34S, HP Prime
x55
Posts: 19
Joined: Sun Jul 26, 2020 7:32 am

Re: DM42- clock losing time

Post by x55 »

Over_score wrote:
Tue Aug 11, 2020 9:47 am
x55 wrote:
Tue Aug 11, 2020 2:48 am
But what is the "True date" format?
In my case (french configuration) it is DD/MM/YYYY hh:mm:ss
Thanks
--
HP: 55/67/41C/HP-IL/ProtoCODER*/41CL/MLDL**/41CX/16C/71B/42S/33s***/35s ...
DM: 42 ...
Etc: If a calculator has equals, why buy one unless it's the cheapest?
* ProtoTECH, USA / ** Eramco, Netherlands / *** Carly Failurina model
User avatar
chr yoko
Posts: 25
Joined: Tue May 05, 2020 11:23 pm
Location: France

Re: DM42- clock losing time

Post by 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 8-)
DM41L SN01063 - DM42 SN05658 - DM15L SN20438 - DM41X SN00173
x55
Posts: 19
Joined: Sun Jul 26, 2020 7:32 am

Re: DM42- clock losing time

Post by x55 »

Over_score wrote:
Tue Aug 11, 2020 9:47 am
x55 wrote:
Tue Aug 11, 2020 2:48 am
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.
--
HP: 55/67/41C/HP-IL/ProtoCODER*/41CL/MLDL**/41CX/16C/71B/42S/33s***/35s ...
DM: 42 ...
Etc: If a calculator has equals, why buy one unless it's the cheapest?
* ProtoTECH, USA / ** Eramco, Netherlands / *** Carly Failurina model
NoisyBoy
Posts: 12
Joined: Thu Jun 25, 2020 7:49 am

Re: DM42- clock losing time

Post by 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
Posts: 12
Joined: Thu Jun 25, 2020 7:49 am

Re: DM42- clock losing time

Post by 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.
Post Reply