Reading 32KHz more accurately

[electroRF]

Hi,

I'd like to measure a period between two points, T1 and T2, i.e., calculate T2 - T1 .

I got a 32KHz Clock and a 23MHz Clock.

Between T1 and T2, the 23MHz Clock will be shut off, and will be turned on only after T2.
So, I can only measure the period between T1 and T2 in 32KHz resolution.

However, I'd like to be more accurate.

I'm willing to suspend the time at which I'll be able to calculate T2 - T1 .

I'm trying to think how could I use the 23MHz Clock in order to increase the resolution, i.e., for checking at which point of the 32KHz wave occurred T1, and at which point of the 32KHz occurred T2.

I wouldn't however be able to afford wasting too much cycles for increasing the resolution.

For example, I can't afford While'ing on the 23MHz Clock until the 32KHz Clock ticks.

Do you have an idea?

Thank you very much

 

[MikeMl]

Do you have a long wave receiver or AM broadcast receiver which tunes from 540Khz on up? For example, you should hear the 18th harmonic of 32KHz at 576KHz. If you have a 570Khz or 580Khz AM station locally, you should hear the beat frequency and be able to estimate the actual freq of the 32Khz oscillator. You should be able to find the 18th, 19th, 20th,... harmonic.

If you have an accurate signal generator, you can tune the harmonic first, then sweep the oscillator back and forth until you get a zero beat. Then the oscillator frequency is the generator frequency divided by the harmonic...

This method will not "pull" the oscillator as would happen by connecting even a 10X scope probe to it...

 

[electroRF]

Hi Mike,
Thank you.

Well, I don't have such Hardware available.

All I got is the 23MHz clock as an accessory.

I'm looking for a SW method to handle it.

 

[MikeMl]

What processor do you have? What is it clocked with? Is the 23MHz a separate stand-alone oscillator? Is the 32KHz oscillator stand-alone, or somehow related to the processor? Is the 32Khz divided down to a much lower frequency, like 1 or 2Hz?

 

[electroRF]

Hi Mike,
The two Timers are Stand Alone and not dependent on each other.
The Processor is an internal one, developed by the company.
I'd need to check if the 32KHz can be divided, though I didn't get you how this would help.

 

[MikeMl]

One standard way of measuring the frequency of a relatively low frequency clock (like 32kHz) is to measure its period, and then compute the frequency from f=1/period. If the 32kHz is like a crystal oscillator in your watch which is divided down to 2Hz to step the stepper motor, it is better to use two successive rising edges of the 2Hz signal to start and then stop a counter which is counting a stable, relatively high frequency clock. If you knew the period between those edges to say 7 significant figures, you then can compute the frequency to 7 sig. figures, but make the measurement in less than one second.

For example, when measuring low frequency signals, my HP counter uses this technique. It can display either the period in s, ms or us, or you can ask it to do the math and convert the period into frequency, in Hz, KhZ, or MegHz.

If you tried to read the frequency of a 32Khz signal directly to 7 significant figures, you would have to count it for an interval of more than 100s. Except for the loading effect of a probe pulling the 32Khz oscillator off frequency, my old HP counter could measure its frequency to 8 significant figures...

Two successive rising edges of 32kHz are 1/32000 = 31.25 us apart. There would be 23e6*31.25e-6 = 718, so you would get 717, 718, or 719 counts of the 23Mhz oscillator during that interval. This count is less than 3 sig. figures... You would do much better if you divided the 32Khz down to 1Hz, and then counted the 23Mhz for one second.

 

[NorthGuy]

Assuming (T2 - T1) is around 1s, the resolution of 32kHz clock is about 30ppm. If your 32kHz clock comes from watch crystal, it's likely less accurate than this, so there's no point in increasing resolution.

If (T2 - T1) is much less than 1s, look if your processor has an instruction counter. If it does, you can record it during your measurements and also at every clock beat and then interpolate.

 

[MikeMl]

Counting the 32kHz oscillator directly requires using the 23Mhz to derive the counting interval. To get a 1sec counting interval requires dividing the 23MHz clock by 23e6, which you might be able to do in some combination of using a 16 bit hardware timer/counter in the processor and some software...

 

[electroRF]

Hi NorthGuy and Mike,

Thank you very much!

Let me please post the below image which illustrates the situation.

Between Points <B , E> & <F , I>, the core is in Sleep (the sleep can last hundreds of ms), therefore the 23MHz is turned Off, and only the 32KHz operates, as it's external.

The 23MHz works only when the Core is not in Sleep, i.e. between Points <A , B> , <E , F> .

Say that at Time T(B), I read the 32KHz Ticks, and then also at Time T(E), I'd read the 32KHz, and then calculate what time it is.

Doing this, I'd think that the time at Point E, tE, is:
[ T(E) - T(B) ] / 32KHz = [ 2 - 0 ] / 32KHz = 62.5 us
=>
tE = tB + [ T(E) - T(B) ] / 32KHz = 30us + 62.5us = 92.5us.

Meaning, while the actual time at Point E is 64us (not 92.5us), I'd have an Error of +28.5us .

This Delta will increase every SLEEP Period.

Do you have an idea how I could compensate for it, and keep the Delta Stable?

I can of course "decide" that every Tick is 15.625us, and that way, the Delta will either increase or decrease, "randomly".

But I bet there's a better way to handle it.

Thank you friends

**broken link removed**

 

[MikeMl]

So this has nothing to do with accurately measuring the 32kHz.

 

[electroRF]

Hi Mike,

Yes, you're correct, I am sorry if I misled you.

I hope the purpose is clear now and I'd very much appreciate your comments.

 

[NorthGuy]

Are you trying to restore 23MHz clock after sleep by using the 32kHz clock as a reference?

 

[electroRF]

Hi NorthGuy,
Yes you are correct.

 

[NorthGuy]

You need to maintain the 23MHz count at the last before-sleep 32kHz tick (call it sync tick). Once you wake out of sleep, you need to wait for the next 32kHz tick (nothing you can do until you get it). Then, when you get the 32kHz tick, you'll know the number of 32kHz ticks that has passed since the last sync tick, so you can re-calculate the number of 23MHz ticks that you have missed and add it to the 23MHz value you observed at the sync sleep. Count the time you're waiting for the tick (30us at most) as a part of the wake up delay.

 

[electroRF]

Hi NorthGuy,
Thank you very much

Once you wake out of sleep, you need to wait for the next 32kHz tick (nothing you can do until you get it)

I find it hard to accomplish.

If I get it right, I need to 'While' on the 32KHz until it ticks, in order to get the number of 23MHz between <Sleep-Exit -to- 1st-32KHz-Tick-Post-Sleep-Exit> .

The problem is that the core wakes up due to some event that needs to be serviced.

I cannot delay the service of that event in (Max) 30us.

Is there a more sophisticated way to get the # of 23MHz between <Sleep-Exit -to- 1st-32KHz-Tick-Post-Sleep-Exit> than 'While'-ing ? (which means halting the core's operation)

Thank you NorthGuy.

 

[NorthGuy]

You don't need to postpone processing your event. It's just your event will have to live with very inaccurate 23MHz clock until the next 32kHz tick. Once you get the 32kHz tick (pesumably in the interrupt), you'll restore your "good" 23MHz time.

Often waking up takes quite a bit of time - stabilize oscillator, PLL etc. 15us of extra wait may not be significant compared to all that.

Absolutely no way (except higher resolution clock) to find out where are you in between 32kHz ticks when you wake up. If your 23MHz is so important, don't sleep.

 

[electroRF]

I understand, thank you very much NorthGuy!

The 32KHz is a system's clock, which doesn't yield interrupt to the core, my core can only use it for read.

I guess there isn't other way to detect the 32KHz first tick after sleep-Exit, rather than simply 'while' on it?

 

[NorthGuy]

If you don't have interrupt then, of course, you have to wait. Moreover, you would need to obtain a sync point before entering the sleep too, so you will have to wait twice. Also, if you loop waiting, your error is +- length of the loop, so don't expect good accuracy out of it.