HP48 Clock error data results

[TomC]

I've got several HP48G series machines that have been running for almost 2 weeks now.

Each one shows an error of about -1.88 seconds per day ( although one was -1.5, another -3.3). This means that if one were to set a daily alarm with code that performs 15400 CLKADJ, the calculator would have a more accurate clock. So, the CLKADJ factor will vary from machine to machine.

[I've added a factor to a couple machines and do the daily alarm CLKADJ adjustment and these have maintained about 0.5 second daily accuracy.]

My next step is to write code that will update the needed adjustment parameter. The machine will maintain the updated CLKADJ parameter and we should see it converging to some value. This of course is assuming that the calculators inaccuracy is consistent over time.

TomC

[EdS2]

Do I take it that the clocks are all running a little fast?

That would match up with the idea that even relatively cheap watches perform a factory-trimmed adjustment periodically, by skipping some counted number of clock pulses. So commercial (cheap, high volume) timekeeping crystals will always be built to be a little fast.

See The Accuracy and Stability of Quartz Watches (pdf) or High Accuracy Clock - Inhibition Compensation, What Is It? (video)

[TomC]

Thanks for your reply;

Actually, I have found that every 48 I have looked at is operating slow has a slow clock.

By the way, the 'CLKADJ' command in the 48 adds the amount (in 'ticks') to an internal clock; thus a positive CLKADJ value pushes the internal clock forward - which would correct for a 'slow' clock.

Regards,
TomC

[Jonathan Busby]

(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

[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

[cruff]

Perhaps whomever wrote the clock interrupt routine failed to adjust for the execution time of the interrupt routine itself?

[Dave Shaffer]

(03-01-2021 10:25 PM)TomC Wrote:  Perhaps the stability of the PLL is the issue - Given the technology of the time (1980s-90s), perhaps it simply is the PLL stability.

Unless HP was cutting unnecessary corners, there was nothing wrong with PLL technology in the 80s

We used PLLs in our radio astronomy receivers for Long Baseline Interferometry, with stabilities at the 1e-14 from the mid-70s onward!

[Jonathan Busby]

(03-02-2021 04:12 AM)Dave Shaffer Wrote:  

(03-01-2021 10:25 PM)TomC Wrote:  Perhaps the stability of the PLL is the issue - Given the technology of the time (1980s-90s), perhaps it simply is the PLL stability.

Unless HP was cutting unnecessary corners, there was nothing wrong with PLL technology in the 80s

We used PLLs in our radio astronomy receivers for Long Baseline Interferometry, with stabilities at the 1e-14 from the mid-70s onward!

I don’t think HP was cutting corners. Perhaps HP only made the PLL’s accuracy “good enough” because of design constraints or for cost reasons. Also, maybe they just made a mistake in the implementation and the cost of fixing it didn’t justify any improved reduction in clock jitter because the jitter was small and the clock periods were still in spec. Anyways, that’s just my speculation...

Regards,

Jonathan

[Jonathan Busby]

(03-01-2021 10:25 PM)TomC Wrote:  What I suspect is that there is something in the software/interrupt structure of the code that causes the user clock to 'lose time'.

One culprit may be display refresh which halts the CPU every 244 μS . Also, AFAIK, while in the 48 ISR, when interrupts are disabled, hardware keyboard scans are disabled, so, that can't be a source of inaccuracy in the timer2 ISR.

Quote: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...

Well, when the HP48 is in "deep sleep" ( ie. turned off ) the ROM services timer2 only every 72 hours to update the system time, so, the more the machine is used, the more the timer2 ISR is being serviced with the display turned on.

Regards,

Jonathan

[TomC]

Jonathan:
This '72 hour' update detail is very interesting; does this mean that if the machine is awake more often (than every 72 hours), that its clock will be updated more often and hence more accurate?

TomC

(03-02-2021 10:24 PM)Jonathan Busby Wrote:  

(03-01-2021 10:25 PM)TomC Wrote:  What I suspect is that there is something in the software/interrupt structure of the code that causes the user clock to 'lose time'.

One culprit may be display refresh which halts the CPU every 244 μS . Also, AFAIK, while in the 48 ISR, when interrupts are disabled, hardware keyboard scans are disabled, so, that can't be a source of inaccuracy in the timer2 ISR.

Quote: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...

Well, when the HP48 is in "deep sleep" ( ie. turned off ) the ROM services timer2 only every 72 hours to update the system time, so, the more the machine is used, the more the timer2 ISR is being serviced with the display turned on.

Regards,

Jonathan

[Hlib]

I have long been a fan of accurate timing. My desktop electronic clock gives out +40...+15 seconds per year, depending on the average annual temperature, which might be 0...+30 degrees. The greatest cost value is not the fixed deviation, but the stability of the readings relative to the temperature and relative of the output impedance to the power supply. So, the first release of the 9860gii-2 has a good reverse heat stabilization, at the level of a $150 wristwatch from CASIO, i.e. +20...-20 seclonds per year for the 0...40 °C of annual temperature with correction of the initial constant error by means of the built-in interfaces.

[TomC]

Hlib:

Very interesting - 40 seconds per year error is on the order of 1ppm! Quite impressive.

It is unfortunate that we will have to 'babysit' the HP48, but hopefully we can improve it's performance.

TomC

(03-03-2021 05:37 PM)Hlib Wrote:  I have long been a fan of accurate timing. My desktop electronic clock gives out +40...+15 seconds per year, depending on the average annual temperature, which might be 0...+30 degrees. The greatest cost value is not the fixed deviation, but the stability of the readings relative to the temperature and relative of the output impedance to the power supply. So, the first release of the 9860gii-2 has a good reverse heat stabilization, at the level of a $150 wristwatch from CASIO, i.e. +20...-20 seclonds per year for the 0...40 °C of annual temperature with correction of the initial constant error by means of the built-in interfaces.

[Jonathan Busby]

(03-03-2021 04:02 PM)TomC Wrote:  This '72 hour' update detail is very interesting; does this mean that if the machine is awake more often (than every 72 hours), that its clock will be updated more often and hence more accurate?

Well, first, the system time is controlled by TIMER2 which is directly controlled by the crystal oscillator. TIMER2 is a 32-bit signed countdown timer which decrements 8192 times per second. When it underflows ( becomes negative ) the high order bit is set which triggers an interrupt which causes the 48 to wake up and enter the ISR. The time subsystem usually schedules a wakeup for every 72 hours, but, even if more than 72 hours elapses, the system time is still not affected as TIMER2 can be delayed for up to \(2^{31}\) ticks ( 262144 seconds or ~72.88 hours ) without corrupting the system time. My point is, though, that during these wakeups, since the timer service ISR runs with the display off when the 48 wakes up from deep sleep, the system time should be *more* accurate the longer the calculator is turned off ( except for COMA mode which stops TIMER2 and hence nukes the system time ).

Regards,

Jonathan

[Dave Shaffer]

(03-03-2021 05:59 PM)TomC Wrote:  Very interesting - 40 seconds per year error is on the order of 1ppm! Quite impressive.

I'd note - maybe for your HP calculator, but nowhere near what a crystal oscillator can really do. These are microseconds per year stability! (1 year is ~3e7 seconds)

Check out these refs for parts in the 1e-12 to 1e-14 for a crystal oscillator. We used to use a Sulzer crystal system to clean up the output from our HP Rubidium standards (HP 5065A) for short-term (10-100 seconds) stability.

https://www.hpl.hp.com/techreports/1999/...%20circuit.

http://www.leapsecond.com/museum/sul25-1/

https://ieee-uffc.org/about-us/history/u...lications/