> > > datasheet for the 16F87, and it says the internal oscillator is
> > > +- 1% accurate, I think, at 25 degrees C.  I think something
> > > must be very wrong for it go get that far out.
> >
> > Do the calculation - half a second in 2 minutes is 0.4%, well in
> > spec. You'll need to use a crystal to keep accurate time
>
> Or use OSCTUNE or adjust your timing block to compensate
> for the 0.4%. Depends on what periods you want to time. Even
> a crystal will not give give accurate long-term stability unless it's
> calibrated and temperature-compensated. 10ppm is ~ 1s / day
>

> Dave Turner wrote:
> > I have it next to an accurate clock here, and it
> > can get as far out as half a second every 2 minutes.
>
> So that's 1/2 a part in 120, or 1 part in 240, or about 1/4 percent.
>
> > I am using the
> > 16F87's internal oscillator, running at 8MHz.  I have checked the
> > datasheet for the 16F87, and it says the internal oscillator is +- 1%
> > accurate, I think, at 25 degrees C.  I think something must be very
> > wrong for it go get that far out.
>
> Huh?  It's specified at 1% and your seeing 1/4%.  Looks like everything is
> working fine.
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com

> On Sun, May 08, 2005 at 03:11:51PM +0100, Dave Turner wrote:
> > Oh, i didn't know the RC could be so innacurate.
>
> RC is never used for timing sensitive applications. At the nominal 1%
> a RTC will drift 36 seconds an hour.
>
> 1% represents 10000 PPM. Most crystals are in the range of 20 PPM.
>
> And each of these will drift differently based on temperature.
>
> My conclusion is that an external source is the best bet. Jinx has posted
> about the $2 USD battery powered clock modules. Also one can use the WWVB
> 60 KHz clock signal broadcast from Colorodo. Finally the easiest and most
> stable tick source is the 60 Hz AC signal out of the power outlet. A
> transformer and an optosiolator will give you 216000 ticks per hour like
> clockwork.
>
> When I get back to my sunrise/sunset controller I plan to use the power
> outlet signal to keep accurate time. The 32Khz crystal will be my backup
> during power outages as this project has a gel-cell battery backup.
>
> BAJ

> On Sun, May 08, 2005 at 04:13:23PM +0100, Dave Turner wrote:
> > Firstly, I'm not running off battery power.
>
> So counting power line ticks is a possibility.
>
> >  After much fiddling with
> > config bits I have discovered that with the PIC running on XT mode, it
> > runs a lot faster than it should if it is using the 32.768KHz clock.
> > Also, on INTRC mode it runs too fast.  On EXTRC, LP or HS mode it
> > doesn't run at all.
>
> There's no need for you to run the system clock from the 32 Khz. Run it
> from the 8 Mhz INTRC and use the 32 Khz to clock Timer 1.
>
> > The reason I'm trying to use the 32.768KHz clock as the system clock
> > is that I don't have a clue how to make a delay by checking a clock -
> > The only method I know is many embedded loops.
>
> My sunrise/sunset contoller implements a full 365 day calendar using a
> 2 second timer 1 heartbeat. Check it out here:
>
> http://www.finitesite.com/d3jsys/clock.asm
>
> >
> > Any pointers to good tutorials / examples about using a non-system
> > clock for a 1 second delay would be extremely welcome.
>
> It's a two second delay but the idea is sound.
>
> You implement it with a simple state machine. In a single big loop you
> increment the smallest value. When that overflows, you reset that value
> and increment the next one higher up.
>
> Check out the code for more details.
>
> BAJ

> Dave Turner wrote:
> > Firstly, I'm not running off battery power.  After much fiddling with
> > config bits I have discovered that with the PIC running on XT mode, it
> > runs a lot faster than it should if it is using the 32.768KHz clock.
> > Also, on INTRC mode it runs too fast.  On EXTRC, LP or HS mode it
> > doesn't run at all.
>
> Sounds like general confusion about the system oscillator.  Get this figured
> out first, because everything else mostly depends on it.  If you're not
> running on battery power, why not run the PIC at its maximum clock speed of
> 20MHz?  All you need is a 20MHz crystal specified for parallel operation and
> two caps around 22pF, with the oscillator set to HS mode.
>
> If the issues is pins or board space, then the internal oscillator is a good
> choice.  You can use it to run the PIC, and the timer 1 oscillator for
> accurate timing.
>
> > The reason I'm trying to use the 32.768KHz clock as the system clock
> > is that I don't have a clue how to make a delay by checking a clock -
> > The only method I know is many embedded loops.
>
> Fix this first.  Since you're willing to have a crystal anyway, I would make
> is a 20MHz crystal on the main oscillator.  Once you've done that, it's very
> easy to set up a periodic interrupt of 1mS, for example, using timer 2 and
> its period register.  This would happen once every 5000 instructions, so
> doesn't add much load to the processor.  As long as 1mS is close enough
> timing for everything else in the system, this will work fine.
>
> Once you've got that, there are many ways to implement timers for longer
> periods.  One way is to have a counter for each delay event you need.  To
> wait, you set the counter to the number of mS to wait.  The interrupt
> routine decrements the counter whenever it's not zero, and sets a flag when
> it decrements it from 1 to 0.  Now the foreground code can go off and do
> other things, and the flag becomes just another event to handle in the main
> event loop.
>
> That's only one of many ways to do this.
>
>
> *****************************************************************
> Embed Inc, embedded system specialists in Littleton Massachusetts
> (978) 742-9014, http://www.embedinc.com

> it was always d'8', and
> the least significant byte was always changed around, starting at 85,
> then after a few resets, 86, then 87, and finally 83.
>
> I setup T1CON with:
> 00001011
> and later tried
> 00001111
>
> That's: system clock not running off tmr1, no prescaler (1:1), osc
> enabled, I tried syncing on and off - no change, tmr1 source is
> external, and tmr1 is on.

> You can work out the maths if you're using a different xtal as the
> main oscillator and using another timer and/or pre-scalers
>
> I'd go along with Byron about using mains cycles as the primary
> timing source (RA4/T0CKI - RB0/INT - RB6/T1CKI). Note
> though that mains frequency varies slightly during the day due to
> demand and you should look at the daily (ie a 24h period) count
> for accurate timing. IOW, the number of mains cycles coming in
> between 7am and 7pm is more than likely going to be be less
> (frequency would be 49.xx or 59.xx Hz) than the period 7pm to
> 7am (frequency will be catch-up 50.xx or 60.xx Hz)

> On Mon, May 09, 2005 at 08:11:03PM +1200, Jinx wrote:
> > > > incrementing untouched by s/w and you're reloading the upper
> > > > byte at a time when it can't be incrementing, then that contention
> > > > corruption shouldn't (can't ?) cause any problems
> > >
> > > Not quite.  Think what happens if TMR1L is at about 0xff when
> >
> > Well, er, I did say when TMR1H can't be incrementing. That implies
> > that you make sure the reload is not during a time when there's the
> > possibility of a TMR1L rollover. Which, as you say, would probably
> > be early in an ISR or whatever
>
> Sorry, you're right - I read it too quickly.
>
> Cheers,
>
> Chris