HP48 Clock error data results

[TomC]

Jonathan/and others:

Thanks again for your attention/comments.

Perhaps the stability of the PLL is the issue - Given the technology of the time (1980s-90s), perhaps it simply is the PLL stability.

Well, there two questions here - and I wonder if they're related:
- The variable 'ON-D-A' frequencies which are always less than 4MHz
- The slow user clock

It is most curious that all of the HP48s that I have checked are always slow. Not sure exactly how many, but it seems to be more than 10 over the last >10 years.

It is also curious that the error I have found so far (granted a limited population) is close to 2 seconds per day. This equates to about 20ppm - which is a typical spec for a 'run of the mill' clock crystal.

What I suspect is that there is something in the software/interrupt structure of the code that causes the user clock to 'lose time'. Perhaps once I gather more data we can start to surmise where this may be - is it related to amount of time the calculator is on? Is it related to the clock display in the screen? etc. etc... (...or just the PLL!!!)

I am writing a 'CLKADJ adjuster' program that the user will run periodically (perhaps weekly), and calculates a CLKADJ number. This will be scaled to a daily factor and added to the previous CLKADJ number (which of course starts at 0). The machine will keep a history list of when this adjustment was done, and a list of all CLKADJ factor. The machine will also run alarm code daily (at say, 1am, then shutoff). We will then have a list of when the adjustments were done (I will attempt to do this weekly.) Assuming the error is consistent, we should see this list of CLKADJ factors converge to a stable value. Perhaps we can then study if the clock error is dependent on how often the machine is used/not used/running programs, battery condition, etc...
It may be interesting to see if there is a correlation between the user clock error and the 'ON-D-A' error.

Where will we go with this? What will we do with it? Not sure, but the results should prove to be interesting (to me at least ! )

I still have several machines running for over two weeks now with no CLKADJ factors and the (again very limited) data shows consistent error over time.

Pardon my rambling - I hope to have some code up soon.

TomC
ps: Data format expected is something like this:
{{date time} {date time}...{date time}} <---DateTime history list
{0 clkadj1 clkadj2 clkadj3....} <-- CLKADJ factor history list
@ Of course over time, we'll have to maintain a reasonable length of these lists to conserve memory.
+++++++++++++++++++++++++++++++++++++++++++

(03-01-2021 08:03 PM)Jonathan Busby Wrote:  

(02-28-2021 03:26 AM)TomC Wrote:  This of course is assuming that the calculators inaccuracy is consistent over time.

This is what I meant when I said I thought that the HP48's crystal oscillator frequency was not variable. But, if it's not variable ( albeit slow ), then what explains the inconsistent and seemingly random ( in the lower order digits ) of the CPU speed reported by ON-D A? I know for a fact that the clock speed self test turns off the display, disables interrupts and also disables hardware keyboard scanning. So, is there something going on with the PLL?

Regards,

Jonathan