CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

LP oscillator losing time
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Jim McBride
Guest







LP oscillator losing time
PostPosted: Wed Dec 31, 2003 12:51 am     Reply with quote

I seem to be losing about 12 seconds per day using a 32768 xtal with
the recommended caps for timer one. I would expect and accuracy of
around 20ppm or better which would be less than 2 secs per day. Any suggestions?
SherpaDoug



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Wed Dec 31, 2003 7:47 am     Reply with quote

Look at the drive power. Make sure you are not overdriving the crystal. See if the crystal manufacturer has a recommended circuit.
_________________
The search for better is endless. Instead simply find very good and get the job done.
PCM programmer



Joined: 06 Sep 2003
Posts: 21420

View user's profile Send private message

PostPosted: Wed Dec 31, 2003 10:57 pm     Reply with quote

This AppNote on Dallas Semi's Real Time Clock chips
has some tips on the reasons why RTCs run fast or slow.
http://pdfserv.maxim-ic.com/en/an/app58.pdf
Guest








No time to lose time.
PostPosted: Mon Jan 05, 2004 3:05 am     Reply with quote

Crystals have a certain degree of inaccuacy and they can drift. I assume you mean that it loses 12 seconds every day.

Check the manufacturer's frequency/temperature curve. What's the temp the crystal sees in service. The function is not linear. Check it out and you may be surprised how far the frequency is off at only 10 F - 15 F away from the roll-over temp.

Do other crystals or production units units drift the same?

The overdriving hint was good. This can often be the cause. The 32KHz don't like being pushed around.

Check out the Dallas TCXO. The specs are incredible. Consider changing to it if cost is little factor (laboratory or industrial instruments.) I consulted for a company that uses these in a widget that needs accurate time and all production units checked out at less than +-0.000 seconds per day. (Yes, less than a millisecond per day. Yes, I know what I'm talking about. They used a high-end HP counter and a GPS-sourced clock tick to record drift over 24 hours to screen units.) The units are video/audio program controllers for automated broadcast studios.
Guest








PostPosted: Mon Jan 05, 2004 3:18 am     Reply with quote

I know this is evil of me. I admit it. But if a batch of crystals all lost about 12 seconds of time in a circuit, and were to be used at room temperature, you might consider adding a millisecond every few seconds to tweak it back to 0 ppm error. Depends on the application, time, use, customer, if engineering manager has pointy hair, etc.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Mon Jan 05, 2004 8:28 am     Reply with quote

Maybe the crystal is just fine and the problem resides in software. Long interrupt routines or disabling them for a long period could cause problems. Maybe try testing with a very simple problem that does nothing more than generate the clock.
rnielsen



Joined: 23 Sep 2003
Posts: 851
Location: Utah

View user's profile Send private message

PostPosted: Tue Jan 06, 2004 6:25 pm     Reply with quote

I hope I'm correct in saying this but, if you are using one of the timers, that uses an 8 bit register, it will count to 255 and then roll over. If you used the number 255 in your timing calculation you will lose one count each roll over because it takes 256 counts to roll over and cause an interrupt. This might be the culprit of your lost seconds.

Ronald
ljbeng



Joined: 10 Feb 2004
Posts: 205

View user's profile Send private message

PostPosted: Wed Mar 23, 2005 11:46 am     Reply with quote

Jim McBride,

I recently tried this and saw the exact same results. What did you do to correct this? I tried software fixed but I still saw significant drift. Thanks.
dyeatman



Joined: 06 Sep 2003
Posts: 1825
Location: Norman, OK

View user's profile Send private message

PostPosted: Wed Mar 23, 2005 1:19 pm     Reply with quote

Without seeing your code we cant really do anything but guess how you are keeping time. Are you using interrupts, delays or just loop counters?

I used interrupts and had some drift but it was consistantly the same amount. I then adjusted the interrupt code, similar to what was mentioned above, and fixed the problem.

To actually make the adjustments I first set up a 10ms timer interrupt for my main RTC timing. In the interrupt I toggled a single output pin which I monitored with a scope. I then adjusted my code until the scope showed exactly 10ms time intervals. I then had a drift of less than 1 second per day. This might work for you.

The longer the interval you can monitor and adjust with the scope (100ms, 500ms or 1000ms for example) the more accurate your result will be. To verify mine I also set up a one second output pin and monitored that with the scope.

BTW, when I was done I simply put NOPs in for the same number of machine cycles the pin toggle statement required (from the listing) to maintain my accuracy.
ljbeng



Joined: 10 Feb 2004
Posts: 205

View user's profile Send private message

PostPosted: Wed Mar 23, 2005 1:26 pm     Reply with quote

Code:
#int_TIMER1
TIMER1_isr()
{

   set_timer1(0x8000 + get_timer1());

   sec++;

// clock values are checked here
   if (sec >= 60){
      sec = 0;
      min++;
      if (min >= 60){
         min = 0;
         hour++;
         if (hour >=24) {
            hour = 0;
            day++;
            if (day >= 7) day = 0;
         }
   }
   }
}


I use the 16LF628A.

I use the interrupt for timer 1 to increment a clock. I also use the INTRC_IO directive so I can use pins RA6, RA7 for IO. Battery operted on 2AA or 3AA nicad. Main routine mainly sleeps. The operator can plug in a display/keypad and view the data or set the clock.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Wed Mar 23, 2005 1:43 pm     Reply with quote

Is the PIC running at 32.768KHz?

Take a look at this
Code:

....................    set_timer1(0x8000 + get_timer1());   
0035:  MOVF   0F,W
0036:  MOVWF  7A
0037:  MOVF   0E,W
0038:  MOVWF  77
0039:  MOVF   0F,W
003A:  SUBWF  7A,W
003B:  BTFSS  03.2
003C:  GOTO   035
003D:  MOVF   77,W
003E:  MOVWF  2D
003F:  MOVLW  80
0040:  ADDWF  7A,W
0041:  MOVWF  2E
0042:  MOVF   2E,W
0043:  MOVWF  0F
0044:  MOVF   2D,W
0045:  MOVWF  0E


The amount of time it takes to process all this is where the error occurs. This happens every second so multiply this time by 86400 secs per day.

What you really need is this
Code:

int sec,min,hour,day;
#byte timer1_h = 0x0F
#byte timer1_l = 0x0E

#int_TIMER1
TIMER1_isr()
{

//   set_timer1(0x8000 + get_timer1());
   bit_set(timer1_h, 7);
   sec++;

// clock values are checked here
   if (sec >= 60){
      sec = 0;
      min++;
      if (min >= 60){
         min = 0;
         hour++;
         if (hour >=24) {
            hour = 0;
            day++;
            if (day >= 7) day = 0;
         }
   }
   }
}


And now look:
Code:
.................... #int_TIMER1   
.................... TIMER1_isr()   
.................... {   
....................   
.................... //   set_timer1(0x8000 + get_timer1());   
....................    bit_set(timer1_h, 7); 
0035:  BSF    0F.7
....................    sec++;   
0036:  INCF   29,F

And this will introduce no drift. Setting the MSB should always work for you unless something blocks this interrupt for almost 2 seconds.
ljbeng



Joined: 10 Feb 2004
Posts: 205

View user's profile Send private message

PostPosted: Wed Mar 23, 2005 4:21 pm     Reply with quote

I have a 32768 on pins 12,13 running timer1 and I am using the 4.0 MHz internal oscillator for the main program. All the code in the timer1 interrupt routine should be executed at 1MHz speed which is 30x faster than timer1 can increment from the 32768 crystal. Or am I wrong on this? It seems to me, when the first line in the timer1 ISR is executed, the 32768 crystal should not be able to increment timer1 for another 30 instructions.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Wed Mar 23, 2005 6:01 pm     Reply with quote

Did ya try my code example????????????

@4MHz each instruction takes 1us. At 32KHz timer1 will increment at about 30us. Depending on you other interrupts it takes time to process the interrupts. This is probably less than 30us. The interrupt fires and grabs the timer1 value. Now there is about 17 instructions to add 0x8000 to the "stored" timer value. During this time, I suspect that the timer value is incremented. However, the add routine doesn't get this increment so it actually loses 1 tick or 30us. Over a day, that will be about 2.6 seconds. I'd try my suggestion. Clearly you should be able to see how much more efficient it is!
Guest








PostPosted: Wed Mar 23, 2005 7:39 pm     Reply with quote

Anonymous wrote:
I know this is evil of me. I admit it. But if a batch of crystals all lost about 12 seconds of time in a circuit, and were to be used at room temperature, you might consider adding a millisecond every few seconds to tweak it back to 0 ppm error. Depends on the application, time, use, customer, if engineering manager has pointy hair, etc.

Not at all evil..!
Some RTC chips have it available in hardware.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Wed Mar 23, 2005 8:47 pm     Reply with quote

I just did a test where I sped up the timer1 int by a factor of 128. This introduced the error at 128 times the normal rate. From my calculations, you should lose about 33ms over a 20 minute period. 128 times this is about 4.68 seconds. I ran a test over a 20 minute period and lost about 5 seconds. I then tried the example that I posted. After running 1 hr, there is still no loss of time as verified by my daughter's office Shrek clock from Burger King! Wink
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group