Sorry for posting that same message again...
I was getting an error message...
The attachment wasn't uploading correctly...
Sorry for posting that same message again...
I was getting an error message...
The attachment wasn't uploading correctly...
Hi shahidali55,
"tweeking the TimerConst" won't help. 1 count either direction will change the timing by more than you are off. @ 4mhz, 1 count will change the time by about 4 seconds per day.
At 2 seconds per day, it works out to around 23 PPM (parts per million), which is within the normal 50 PPM tolerance of the crystal. Not to mention the +/- 100 PPM variance due to temperature.
To get closer than that, you'll need to calibrate the crystal frequency. You may be able to use a small Trimmer Capacitor in place of one of the capacitors on the crystal. The size needed depends on your crystal, but 0-20pf will probably work.
Other than that, you could simply add 1 second every 12 hours. But if you build more units, that could be problamatic since they won't all be the same.
Here's a couple links to some more crystal info:
http://www.circuitcellar.com/library...ujanos91/3.htm
http://ww1.microchip.com/downloads/e...tes/00588b.pdf
http://ww1.microchip.com/downloads/e...tes/00949a.pdf
DT
I dont think the problem is with the oscillator.
I noticed that the time loss takes place every time the hours increase...
Could it be some flaw in the code execution?
If its losing time on every change of the hour, and the total loss is 2 seconds per day, then each change of the hour would lose 1/12th or 0.083 seconds.
@ 4mhz, that's 83,000 instruction cycles. No, I don't think it's accidently losing that many instructions to increment an hour. And, looking at the ClockCount interrupt routine, if that were the case, it would also happen on every second, minute, and day as well. Which it doesn't.
Why don't you think it's the crystal?
Have you measured the frequency?
DT
when i run Josepino's code, on the same board with the same crystal, i do not get any error.
This is why I think it is a fault in the software...
Too bad the guy only gives out HEX files.
Otherwise, we could see what special magic he has, to cancel out the tolerance of crystals.
DT
Hi Darrel,
Some where Josepino had mentioned on his site that he had used Roman Black's one_sec.asm routine in his clocks (maybe he mentioned this by accident).
I tried making a similar program in PBP but had no success, till now.
Finally i got the progam running. its the exactly same one_sec.asm routine running with instant interrupts, and guess what,... it worked, and really accurately...
Its even more accurate than the Elapsed Timer...
I'll post the code so that it may be useful for someone...
(I'm not as mean and selfish as Josepino...
and thanks a lot for the instant interrupts program...
Chiao...
Hello shahidali55,
It can publish or to send to my mail [email protected] the code and complete circuit since is very interesting its project, congratulations for its idea!.
Leonard
Regards
Originally Posted by shahidali55
shahidali55,
Pardon my stubborness!
Sometimes I get so defensive, I don't recognize when someone knows better.
I've tried your code, and there's definately a big difference.
But now, I must know how much, and more importantly why.
Fortunately, with Instant Interrupts, it was easy to combine both timers into one program, and I'm running it on a telnet server, in case you (or anyone else) wants to see too. I started the test at 12:15 am PST, and have set the time as close as possible relative to GMT. This screen capture was 30 seconds later.
If you have Hyperterminal installed you can see the results by using the TimerTest.ht file in the .zip below. Hopefully in a few days the error will be more evident. T1 is the Elapsed timer, and T0 is your new timer.
password: guest
then type data and press enter
<br>
Here's a reference time http://nist.time.gov/timezone.cgi?Pacific/d/-8/java
Although i started about 1/2 second late.
<br>
Test completed. .zip file removed.
Last edited by Darrel Taylor; - 28th June 2006 at 06:53. Reason: Removed zip
DT
Hello, I have not managed to compile I cosay give errors me, can help me please.
Thanks
Leonard
Originally Posted by Darrel Taylor
Hi Leonard,
To compile this code you need to have Darrel's Instant interrupt file (DT_INTS-14.bas) in the folder along with the source code...
You also need to have enabled the "Use MPASM" option in the compile and options menu...
Hello,
Don't I find the "DT_INTS-14.bas" in none of the folders, can send it please to my mail?. [email protected]
Thank you
Originally Posted by shahidali55
Hmmm,
I fully expected the test to show that the new timer would keep accurate time and give a good indication how far off the Elapsed Timer was, but instead after 24hrs, the Elapsed Timer (T1) was still within 1 second of actual time, and the new timer (T0) had gained almost 8 seconds. Also, my PC's clock was 3 seconds slow. (interesting, but not relevant)<br>
<br>
Since then, I've turned Roman's routine into a subroutine and ran it in loops just to verify it's counting, and can say that it does accuratly count 1 million instructions per second. Well, actually, it counts 3 seconds at 999,936 instructions and every 4th second at 1,000,192. Which over the 4 seconds averages out to exactly 4,000,000 instructions. So in a perfect world, with a 4.000000mhz crystal, it should count perfect time. But it doesn't. (in my case)
This leads me to beilieve that My crystal is off.
So, continuing with with the perfect world theory...
There's 86,400 seconds per day
or 86,400,000,000 instructions per day
an additional 8 seconds is 8,000,000 instructions
for a total of 86,408,000,000
that divided by the 86,400 seconds per day gives
1,000,092.593 instructions per day or a freq. of
4,000,370.37 hz.
That's 93PPM off center frequency. So I've either got a crystal that's almost twice the tolerance. OR I'm still missing something big time.
<br>
DT
Darrel,
This may be stating the obvious, but either:
1) Both timer routines are accurate (Definitely not true)
2) T0 is accurate, T1 is not
3) T1 is accurate, T0 is not
4) Neither timer routine is accurate (if your Xtal is within specs and running fast, T0 runs fast and T1 runs slow, this could explain the results you have shown)
The Xtal error needs to be eliminated to see what’s happening with the last three. One suggestion may work. If you have a RTC handy that will output the 32768Hz, use this as an input to the timers. Then, you can compare the PIC clocks against RTC, all of which would be running at the same exact freq. Some tweeking of the code will be required for this. Also, This may lead to changes in the code which would mask the errors occurring with the 4Mhz Xtal, but it may be worth a try.
I have actually done this with a timer routine similar to the Elapsed timer, and it works fine. I will add it to this post when I get back to my home computer (Found it! Elapsed_Timer_INT_32.bas.txt). It has some significant differences though. It never stops the timer, only adds to the TMRxH byte, and counts 128 "ticks" per second. (edit: I also count DOWN. I think this added some efficiency with the ASM, but can't remember off the top of my head. It's run on an 18F4620)
The other is to get a measure of the actually freq of your crystal, then factor this into the timer errors. And I am not sure how to do this to the accuracy needed to find the problem.
Intriguing problem,
Steve
Last edited by SteveB; - 22nd June 2006 at 20:39.
Hello again Darrel,
I've landed to one conclusion...
The only way to get accuracy is to tweak the counter variable (bres_lo)...
I'm using 33pf oscillator caps...
(4Mhz osc)...
I found that my oscillator is clocking at 4.000176 Mhz (4000176 Hz)
and not 4Mhz...
After tweaking the low byte of the 24bit variable, i was able to get nearly 100 percent accuracy...
Yup, It appears that the capacitor value is crucial to long term timing.
In my test above (8 sec. fast). I was using a PROTO-40 board from the now defunct projectx.com It came with 15pf capacitors on the crystal. After making a program to be able to read the crystal frequency, I found that it was very close to my estimate above. (4,000,358 instead of 4,000,370). It's amazing that a 7pf difference can throw the crystal that far out of tolerance.
After changing the capacitors to 22pf, the frequency changed to 3,999,978
And, after two days of running your Romanesque code, it's showing a loss of 0.5 seconds per day. So it's at least gratifying to know that the frequency measurement was correct, and the overall timing is predictable.
However, now you've thrown me for another loop by saying that your crystal was oscillating fast with 33pf caps. Which doesn't fit in with my theory of more pF = lower Freq. So, yet another thing to figure out. Oy vey.
I guess it won't really matter too much though, since there are only 3 standard capacitor values in the range we need, 15, 22 and 33 pf, there's no way to compensate for inaccuracies by changing the values. So, it seems to boil down to a few possibilities.
- Measure the actual frequency and use a variable capacitor on the crystal to adjust to the correct frequency.
- Use normal fixed capacitors. Measure the actual frequency, and calculate a "Fudge Factor" for the Timer counts.
- Spend several days watching a clock count and compare it to Real time, then calculate the Fudge Factor from the time difference. (I got really tired of this one, takes too long)
So it looks like the only way to go is actually measuring the frequency and adjusting from there, either hardware or software. But how to measure it? Simply putting a frequency counter probe on the crystal will change the frequency significantly due to the extra capacitance. So it needs to be done some other way.
<hr>My first attempt:
I'm using a DS1307 as the time base, and for the moment am using a +/-20ppm 32,768 crystal on it. I've been trying to find a DS32KHZ +/-2ppm oscillator, but can't seem to find anywhere that has one in stock. But I'm not too worried about it now because, after 3 days, the DS1307 is still "Exactly" in sync with real time, so I think it's pretty close to 32,768
Timer1 is set up as a Free-running counter, that never gets stopped or reloaded, so it's just sitting there counting instruction cycles forever. The overflow interrupt simply adds 1 to a 32-bit variable each time, extending timer1's count to 48 bits, which let's it count instruction cycles for a very long time.
The 1hz square wave output from the 1307 is fed to CCP1 input. CCP1 is in Capture mode, triggering on every rising edge. The Capture catches the TMR1 value, and the interrupt handler copies the upper 32 bits to temp vars so they don't change while sending out RS.232
The Timer is started on the first rising edge of the Square Wave input, and the number of cycles received from the 1307 are counted in another 32-bit variable. But since PBP doesn't work with 48 and 32-bit variables, I have to send the data out as hex numbers. Looks like this...<pre>Count 001D 1855 A0E0<br>Seconds 0001 E823</pre>
From there I can cut&paste the numbers into the windows calculator and figure out that after 124,963 seconds (0001 E823) about 34 hours, the pic had executed 124,962,316,512 instructions (001D 1855 A0E0)
Dividing the total by the seconds passed says that 999,994.53 instructions are being executed each second from a crystal frequency of 3,999,978.12 hz.
However, after only 10 minutes, it had it nailed down to 999,994.42 inst/sec. and as time goes on, it just works out the decimal places.
So now, I'm running the Roman code with a constant of 999,994 (0F 42 3A), instead of 1,000,000 (0F 42 40). So far so good.
While this procedure seems to work, it still takes external hardware (DS1307). And frankly, it's a pain in the butt converting all those hex numbers. So I think the next step is to create a program that runs on a PC to do all those conversions, and to handle the timing. instead of the 1307. Hopefully that will make it so you don't need any external hardware on the pic, except for a serial port. Then once the frequency is known it can save the Fudge Factor in EEPROM.
I also thought about using Steve's nice little timer as the time base, but I needed Timer1 for the CCP capture. May want to use that one later though.
<hr>
After the frequency is determined and the constant calculated, It's still not going to keep perfect time. With a +/- 100 ppm variance over the temperature range, it just messes everything up. As seen earlier, 93ppm made a difference of 8 seconds per day.
Granted, I never plan on seeing -10 deg C in my home, or outside for that matter (California). But even 10 or 15 degrees away from 25 deg C could have a big impact.
So I'm thinking that monitoring the temperature and adjusting the constant dynamically as the temperature changes, will yield the best results.
Geez, this is turning into one of those never ending projects. And I just have to find the answers.
BTW shahidali, if you "tweaked" the constant for 4,000,176 hz, if my math is correct should have been (0F 42 6C)? Anywhere close?
<br>
DT
Ya 0F 42 6C is right...
I agree with you ...
I think keeping track of the temp. is the only way...
I'll try to get a DS32 Khz oscillator...
This is the chip I used as my timer input (see my last post). It works as advertised...Originally Posted by shahidali55
which is to say very well
Hi,
Here is a start:
Circuit Cellar Magazine
http://www.circuitcellar.com/
Choosing the Right Crystal For Your Oscillator
http://www.circuitcellar.com/library...os91/index.htm
Circuit Cellar>Selecting quartz crystals for oscillators can be confusing and mysterious.
Four crystal parameters play a key role in system accuracy. The contribution from each must be added to obtain the total system accuracy....
Frequency tolerance....
Frequency stability is a function of temperature and is related to the crystal cut type.
Aging...
Load capacitance....
Ohm it's not just a good idea... it's the LAW !
Post #42 up there had the same link.
And while it's good information, that documents target was only +/- 2 min per month. Which is 4 seconds per day.
This whole thing started because, 2 seconds per day with the elapsed timer wasn't good enough.
<hr>Steve,
Do you remember where you got the DS32KHZ. Can't seem to find one. Can get a thousand of them for around $3,500, but can't find just one for $11.
<br>
DT
Yea, I ran into the same issue when I learned about them. So, after a lot of looking I bought 1k.....Originally Posted by Darrel Taylor
No really, I figured "what the heck," registered with Maxim and requested a sample. What did I have to lose? It required some sort of approval so I guessed it probably wasn't goint to work out. But, after a bit of a wait I was very plesently suprised to receive 2 in the mail! I suppose they consider it good business. I sure tend to look at Maxim poducts first in my search for parts after this.
Steve
Last edited by SteveB; - 29th June 2006 at 02:01.
Apparently, that's the only way you can get them. Geez, what a way to sell a product.
Fortunately for me, Bruce over at Rentron.com had done the same thing, and had an extra 1 left over.
Sweet! can't wait to get it. And .. all the other parts I ordered at the same time. Crystal Mania!
<br>
DT
No, I didn't mention the Roman Black's web page by accident.
I good to know there is people not mean and selfish like JosePino. Anyway, I found quite interesting this forum.
Regards,
Jose Pino
www.josepino.com
Originally Posted by shahidali55
......................
Last edited by shahidali55; - 9th July 2006 at 16:34.
Hello Jose Pino,
I found your LED and LCD clock projects very interesting...
Why dont you put your source codes online??? Its not like everyone is looking to make money by selling your codes or something...
Most of them, like me, just want to learn more in this wonderful world of microcontrollers!!!
About one year and half ago, I was so mad and upset when I found some of my projects were used for commercial applications on Europe, specifically on Germany. After that, I decided not to post source codes and protect it with copyrights and patents.
Later, I started to receive some hate mail (Specially from Spanish-speaking readers) accusing me that my projects are stealed from other web pages, so I started to post algorithms of my projects. (only some of them)
Now, I receive many e-mails from hungy-of-knowledge people over the world asking me for source codes. At this point, I'm thinking seriously to make the source code available to the public.
As you can see, Is really hard to make everybody happy. So, I guess the best thing to do is to make the source code available for everybody. It may take a while until I have some time available to find the source code and put it online.
Regards,
Jose Pino
www.josepino.com
Originally Posted by shahidali55
Hello Josepino,
It'll be great if you put your souce codes online...
Thanks for considering my posts...
Hi Guys.
I'm writing a program to control a drag racing xmas tree and time the 1/4 mile but I need .0000 (ie thousandths) second accuracy.
Looking a the ASM routine I'm wondering if I can just change the 100Hz freq to 1KHz by triggering the interupt more often.
Will this work?
Thanks and Regards
Thirsty
That should work.
But .0000 would be Ten Thousandths of a sec. That'll be harder.
<br>
DT
Originally Posted by Darrel Taylor
Hello Darrel,
I tried using your Elapsed-18 for use with my 18f452 and when I compile I get these errors:
Error(113)c\pbp\10tim~2asm 503:Symbol not previously defined (TimerConst)
Error(113)c\pbp\10tim~2asm 507:Symbol not previously defined (TimerConst)
Would you have any ideas why I'm getting these errors or what I could try to get it to compile? I got my new version of PBP 2.47 installed now.
Thanks
jessey
Hi Jessey,
What OSC are you using?
The Elapsed-18.bas only has constants for 4,8,10,20 and 40 mhz.
If it's something different, it needs a new constant.
See Post #17
<br>
DT
Hi Darrel,Originally Posted by Darrel Taylor
I was running my pic at 16 mhz, I changed it to 4 and its working great now.
Thanks A Lot
jessey
Using a 12F675 I am getting wsave position request beyond ram_end errors how do I fix this?
Hi Darrel,
Could you suggest a good "one of those temperature compensated TTL Oscillators" please ?
Also, if aging for an oscillator is stated, say, +/-5ppm a year or +/- 100ppm a year, what would it mean in your elapsed timer application?
Last question, if I modify your routine to work for 100years, forget about power failures etc., and use a good osc as you may suggest, what would be a possible problem as years pass by?
Thanks.
--------------
Last edited by sayzer; - 24th December 2008 at 18:43.
"If the Earth were a single state, Istanbul would be its capital." Napoleon Bonaparte
The way I understand it is that the Total PPM error stated for crystals includes 10 years of aging.
Say you have a crystal with +/-50ppm tolerance. When you first install the crystal it will be very close to the specified frequency (+/-5ppm), and it's anticipated that in 10 years, the frequency will still be within the stated 50ppm @25°C.
Most crystals have an aging of less than 5-10 ppm per year. If you've come across a crystal that has +/-100ppm per year, throw it in the garbage.
For a recommendation, I'd still have to say the DS32KZ is the best for the price at less than $10.
http://pdfserv.maxim-ic.com/en/ds/DS32kHz-DS32KHZS.pdf
With an indoor application it will hold to +/- 2 ppm, which is 1 minute per year.
For outdoor apps, it's 7.5 ppm, or 4 minutes per year.
TCXO's for the CPU's osc at 10-20Mhz are more expensive, but some are really accurate. Like this one that holds to 0.28 ppm, or about 9 seconds/year. So after your 100 years it would only be off by 15 minutes. ($30US, 3.3V)
http://www.conwin.com/datasheets/tx/tx236.pdf
There are so many possible combinations of tolerance, compensation and time, it's difficult to give a direct answer. But for any of the possibilities, if you can come up with the anticipated PPM Error, this calculator will help to determine how much it would affect the long term timing of a clock.
Press the Recalculate button after changing the Freq or Error.
<table cellspacing="10"><tr><td valign="top"><OBJECT CLASSID="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" CODEBASE="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" WIDTH="400" HEIGHT="250" ><PARAM NAME="MOVIE" VALUE="http://www.pbpgroup.com/CrystalErr/CrystalPPM.swf"><PARAM NAME="PLAY" VALUE="true"><PARAM NAME="LOOP" VALUE="true"><PARAM NAME="QUALITY" VALUE="high"><EMBED SRC="http://www.pbpgroup.com/CrystalErr/CrystalPPM.swf" WIDTH="400" HEIGHT="250" PLAY="true" LOOP="true" WMODE="opaque" QUALITY="high" TYPE="application/x-shockwave-flash" PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer"></EMBED></OBJECT></td><td valign="top">For normal crystals, the PPM tolerance is specified at 25°C. Temperature extremes in either direction can cause a 50ppm crystal to change as much as 100-300 ppm. Granted, those are extremes that would kill a human being, but somewhere in-between are the changes from summer to winter in an outdoor application.
The TCXO (Temperature Compensated Crystal Oscillator) will actively adjust the frequency according to the temperature, so that the frequency is always within the stated PPM tolerance. It usually does this by changing the voltage to a Varactor Diode, which changes the capacitance on the crystal. While it does compensate for temperature, the relative aging of the device remains the same as an uncompensated crystal.
</td></tr></table>
Happy Holidays!
DT
Hi Darrel,
first of all compliments for this excellent job.
I would use "DEFINE OSC 48", because I need to compile for PIC18F4550 using USB.
And using USB in PBP we must set "DEFINE OSC 48" due to PLL...
When I try, I always receive the error "Symbol not previously defined (TimerConst)".
So I tried setting the right TimerConst in the "Elapsed_INT-18.bas" file...
I read all in this thread, and tried using the TimerCalc form, but it seem is impossible getting: 10,000 "Ticks", 100 Freq and 48 OSC all together.
So it means it's impossible using USB and Elapsed Timer at the same time ?
Is there a TimerConst that work with osc @ 48 MHZ ?
Mark
Hi Mark, and thanks!
Yes there is.Is there a TimerConst that work with osc @ 48 MHZ ?
In 2003 I hadn't heard of a 48mhz pic
Hmmm, let's see here,
pulling up mister_e's PicMultiCalc ... (Timer Helper page)
http://www.picbasic.co.uk/forum/atta...achmentid=2957
and ... uht oh, with the existing timer load routine, the best we can do is 99.999hz. Not so good for a long-term timer.
But not a problem, increasing the timer reload time to 10 instructions (add 3 nop's), with a Timer1 prescaler of 2, the reload value is 5541.
I'm sure that will elicit more questions, but I'll let you give it a go first.
<br>
DT
I have given this a good reading over but some of it has gone straight over my head.
I intend to built a control unit based around a 16F877 which will include menu's to control output pins on the PIC, Obviously within the menu there will likely be instructions which will keep the processor busy for a few Ms at a time. My project ideas originally were to include an external clock device such as the DS1307 or the DS1603 to keep track of time whilst the rest of the program (Menu's etc etc) is running and keeping the processor busy.
I was advised on this forum to look at this thread and if this is what I think it is then it will be truly fantastic for my project.
My problem is that when the PIC returns from a menu I want it to display the time on the LCD. Am I right in what I have read in thinking (Besides setting LCD pins & oscillator etc) I can simply include all of the attached files in post number 1 of this thread but modify the 'loop' subroutine within "Test_Elapsed_LCD.pbp" file, to include my menu software?
I understand that this thread creates a time elasped counter and not a clock, but I do have in mind ideas to include buttons with which I can set the hours, minutes & seconds. I will also miss out the displaying of 'Days' when it comes to print on the LCD.
Apologies for what might seem to be a simple question to you guys but I have only been playing for a couple of months with PIC's and I am trying to learn from other people's examples.
Thanks.
hackableFM.
Bookmarks