Timer "t1s_4" value discreptancy!

tiscando

Senior Member
Hi,
I have just found a widespread discreptancy with t1s_4 being 49910.
This is where I think this has started:
The internal timer part of the settimer command reference manual pages say:
"Finally 65536 - 15625 = 49910, so our preload value become 49910."
All I could say about this calculation is that either 65536 should be 65535, or 49910 should be 49911.

Should it be 65536?
- If the preload value is 65535, then every time a minor tick occurs, the minor register overflows to 0, the timer wordvariable gets incremented (major tick), and the minor register gets preloaded with 65535 again. Thus, there is 1 minor tick per major tick, so 65536 - 65535 = 1.
- I calculated 34286 and 3036 using 65536, and I get the result of the major tick period being correct for their purpose for both of them.

So yes: where it is 49910, should be 49911.

However, I see 49910 everywhere, and I even simulated
w0=t1s_4
And I get the value 49910, not 49911, in w0 in the variables panel.

This means, the timer is running 0.2304s slower per hour. For anyone who uses settimer, try replacing "t1s_4" with "49911" and see if you get better results.

I calculated 49910 using 65536, and I got the major tick period being 1.000064sec.

I thought I post the same here, so that it's direct reference in the programming editor forum, as well as in the thread "external 4MHz crystal inaccurate timing" in the active forum section, where it might be a solution to. edit: didn't see that Janne was using 34286 rather than 49910. :eek:
 
Last edited:

hippy

Ex-Staff (retired)
Thank you for your observation. It seems to me that you are right that t1s_4 should be 49911 but I will have to double check my maths. If it needs changing it is a simple matter of altering the compiler so the t1s_4 constant is given a different value and this does not affect any firmware. The error at worse would be 64us per second, 0.2304 seconds per hour, an accuracy of 0.0064%. Inaccuracies from using an internal oscillator would likely be far greater.

A workround if needed would be to define "SYMBOL X1s_4 = 49911" then use "SETTIMER X1s_4" or similar.
 

tiscando

Senior Member
Thank you for spotting this. Is an external resonator going to be +-0.1s per hour like or more/less accurate? And the internal HFIntOsc going to be (far greater) like +-0.8s per hour?
 

hippy

Ex-Staff (retired)
That depends on the resonator and its manufacturer's rating.

For a 4MHz resonator with +/-100ppm accuracy, that's 100 parts per million, that's 0.0025% ... 0.0025% of 3600s is 0.09s.

For an internal oscillator with accuracy of 2% ... 2% of 3600s is 72s.
 
Last edited:

tiscando

Senior Member
PIC HFIntOsc accuracy chart

72s...
I would like to get into the 'ppm' unit of tolerances - How many 'ppm's in +-1%?

I found out on most PIC datasheets that the HFIntOsc's frequency's tolerance is +- 1% if Vdd=3.5V and T=25'C. There is a region chart which also has a circle on these above co-ordinates (Vdd Vs. Temp). Outside the circle is +-2%, and and on lower voltages or large temp extremes, it is +-5%.

I was looking through the PIC datasheets at the maximum rating sections, and for most PIC(axe)s:
- Vdd max=6.5V recommended <=5.5V
- max diode current =20mA
- Iout =25mA
- Vpp max=13.5V
- max Iss =300mA
- max Idd =250mA

Thank you for your information ;)

TC~
 

tiscando

Senior Member
So 100% is a million parts per million, and 1% is 10'000 parts per million (ppm)...

But:
For a 4MHz resonator with +/-100ppm accuracy, that's 100 parts per million, that's 0.0025% ... 0.0025% of 3600s is 0.09s.
What?

Should it be "100ppm, that's 0.01% ... 0.01% of 3600sec is 0.36s"?
 
Last edited:

hippy

Ex-Staff (retired)
Should it be "100ppm, that's 0.01% ... 0.01% of 3600sec is 0.36s"?
Yes, that seems to be the case. Slight case of dividing by 4 because it was 4MHz where as ppm is per million, not per 4 million. Hands-up to poor maths there, and always worth double checking numbers no matter what the source.
 
Top