Does calibfreq work

I have a question about calibfreq. Does it work?

I need some accurate timing and thought I would use a DS1307 set for 8.192kHz to check on the PicAxe. So I measure the pulse length of that square wave and see how close it is to what it should be. The result is that the PicAxe is somewhere around 50 us slow on each pulse.

So, I thought I'd remedy the problem by using calibfreq in a loop to tweak the oscillator and see if I couldn't bring the measurement closer to the crystal frequency. But as I bump it up using calibfreq 1, calibfreq 2, etc. it seems to have no effect on the timing. Because of the caution in the manual, I haven't gone beyond 4.

Should I go higher? Or doesn't calibfreq have an effect on pulse timing?

Calibfreq has always worked for me. However you have given us little to go on.

Perhaps post your code and tell us what Picaxe chip you are using, and if it has a crystal or resonator.

And you would also need some external means of checking that the 50uS slow measument is correct.

An accuarate measurement of a 1khz PWM output perhaps.

Attached is the code I'm using to measure the pulse width of an external square wave generated by the RTC. That RTC is crystal controlled so I'm assuming the square wave (50% duty cycle) is accurate. I'm running this on an 08M2 chip. My results return an average of -51 to -53. No matter if I set calibfreq to 1,2,3, or 4. I get the same readings.

At 10us resolution for a 61us pulse your only possible readings are 5,6,7 (50,60,70 us) depending on when the pulse edge occurs. That is never going to average to 61us over multiple reads as the resolution is simply not high enough.
Have you tried running the PICAXE at a higher clock frequency using setfreq to give a better resolution?

Hi,

I don't believe that the "calibfreq" steps are officially documeneted anywhere (even in the base PIC data sheet) but the frequency change (in M2s) appears to be around 0.1% to 0.2% per step (max range -32 to +31 steps).

Having accumulated 10 values you appear to be dividing by 10 which, with PICaxe's integer maths, will "throw away" any possible increased resolution. But it's questionable whether repeated sampling as shown will actually give sufficiently "random" samples (to average). PICaxe code may be slow, but it is still fundamentally deterministic (i.e. repeats predictably).

Cheers, Alan.

Sorry to misrepresent. That divide by 10 line should not be there.

The readings are actually the single digit readings, as in 5,2,-3, etc. I'm collecting a 10 pulse sum and then comparing that (because we now have a sample that has a resolution of us, not 10 us) to the 61us expected value. This sampling takes place continually (at intervals) and the correction (calibfreq) is applied according to the variance from 61. The corrections ranging from 5 to -5 with calibfreq seem to have no effect on the result. I was hoping that this constant calibration would keep me close to the standard frequency so that my subsequent output pulses (for another part of the program) are timed as accurately as possible.

If a calibfreq step actually causes a shift of 0.1% I should expect about 0.5% correction or 0.3 us. That could explain why I'm not seeing a difference. I actually need to move the needle by 1-5 us. That would put me up in the "danger zone" per documentation. Seems like calibfreq is not a solution here.

Is it normal for the PicAxe to be this far out of spec?

johndk said:

I'm collecting a 10 pulse sum and then comparing that (because we now have a sample that has a resolution of us, not 10 us)

Click to expand...

No, the overall resolution does not increase to 1us just because you have taken 10 samples at 10us resolution. The solution is to use setfreq to increase the resolution of every single sample, not to simply take more samples at a lower resolution.