Searching \ for '[PIC] Crystal drift? was Re: [PIC] PIC16F87 int' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'Crystal drift? was Re: [PIC] PIC16F87 int'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Crystal drift? was Re: [PIC] PIC16F87 int'
2005\05\08@130932 by phil B

picon face
This brings up a question that has been bugging me for
a while.  I have a ds1302 RTC and supposed 20 PPM
crystal (32768 hz).  It seems to work ok but I'm
seeing some fairly odd drift with it.  I compare it
against my PC clock which I sync up against the atomic
clock every day.  

What I'm seeing is that the two clocks are not off by
a constant amount but drift around by as much as 30
seconds + or - in a day.  That is to say one day the
RTC will be ahead by 20-30 seconds and the next day it
will be behind by some amount.  The room that its in
stays within 5 degrees F and a I haven't gotten
physically near (2-3 ft) the circuit in question (I'm
using a PIC to send the time via serial I/O).  The
circuit is in a solderless breadboard so I know there
is extra capacitance probably slowing the crystal
down.

So, I would have though under those circumstances, the
RTC would be off by a relatively fixed percentage.  Is
this just a case of the solderless BB causing problems
or is there something else going on?  something that I
might compensate for?  

The PCB its going into has ground rings on both sides
of the board for the crystal, I've routed signals away
from the RTC in general and the crystal in particular
and have lots of grounded copper areas.

Phil Barrett


--- Jinx <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:
{Quote hidden}

> --

2005\05\08@133750 by olin_piclist

face picon face
phil B wrote:
> I compare it
> against my PC clock which I sync up against the atomic
> clock every day.
>
> What I'm seeing is that the two clocks are not off by
> a constant amount but drift around by as much as 30
> seconds + or - in a day.

PC clocks are not a good reference, even if they are supposedly synchronized
to the time standard periodically.  I've seen 10s of seconds off, depending
on when synchronization was done.  I think the algorithm tried to adjust the
PC clock smoothly, so it may not be that close even if it recently checked
the time standard.

Manually check your RTC against a known time standard and see if the issue
goes away.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\05\08@153400 by phil B

picon face
I should have been a bit clearer.  I am checking when
I sync up the time.  At that point the PC clock should
be  pretty close.  Maybe I should have just omitted
the PC clock part from the question.

--- Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com> wrote:
{Quote hidden}

*****************************************************************
> Embed Inc, embedded system specialists in Littleton
> Massachusetts
> (978) 742-9014, http://www.embedinc.com
> --

2005\05\08@160139 by olin_piclist

face picon face
phil B wrote:
> I should have been a bit clearer.  I am checking when
> I sync up the time.  At that point the PC clock should
> be  pretty close.

No, that was my point.  Take a look at the clock when you sync up.  It
doesn't jump suddenly, unless maybe it's way off.  In some cases anyway, the
system appears to try adjusting it smoothly.  It may take a while for it to
get to the "correct" time.  You'll be much better off checking with a real
reference.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\05\08@191913 by phil B

picon face
OK, I'll try it again.  Sync up == check atomic clock.
PC clock is then *very* close to atomic clock (like
milliseconds).  sheesh, maybe some one else has an
idea.

Restatement of problem with omission of anything to do
with PC:

I have a Maxim/Dallas DS1302 RTC and supposed 20 PPM
crystal (32768 hz).  It seems to work ok but I'm
seeing some fairly odd drift with it.  I compare it
against an atomic clock every day.  

What I'm seeing is that the DS1302 is not off by
a constant amount but drifts around by as much as 30
seconds + or - in a day.  That is to say one day the
RTC will be ahead by 20-30 seconds and the next day it
will be behind by some amount.  The room that its in
stays within 5 degrees F and I haven't gotten
physically near (2-3 ft) the circuit in question (I'm
using a PIC to send the time via serial I/O).  The
circuit is in a solderless breadboard so I know there
is extra capacitance probably slowing the crystal
down.

So, I would have though under those circumstances, the
RTC would be off by a relatively fixed percentage.  Is
this just a case of the solderless BB causing problems
or is there something else going on?  something that I
might compensate for?  

The PCB its going into has ground rings on both sides
of the board for the crystal, I've routed signals away
from the RTC in general and the crystal in particular
and have lots of grounded copper areas.

Phil Barrett


--- Olin Lathrop <olin_piclistspamKILLspamembedinc.com> wrote:
{Quote hidden}

*****************************************************************
> Embed Inc, embedded system specialists in Littleton
> Massachusetts
> (978) 742-9014, http://www.embedinc.com
> --

2005\05\08@224338 by Paul Hutchinson

picon face
The crystal inputs of Dallas RTC chips have an extremely high impedance
(~10^9 ohms). IME, a solderless breadboard is definitely not suitable for
this circuit.

Dallas Application Note 58 "Crystal Considerations with Dallas Real Time
Clocks" has very good troubleshooting and PCB layout information.

Paul

> {Original Message removed}

2005\05\09@014512 by phil B
picon face
Thanks,

I agree that SBBs suck and, like I said, I put a lot
of care into the PCB design (I know AN58 well by now)
but am hoping to resolve this wierd drift thing before
committing to solder.  I'd like to build it just once.
I'm probably being just a little too AR about this
but you dont get perfect by accepting good enough.

I wonder if humidity might be a culprit with the SBB
changing capacitance and thus affecting the crystal
frequency.  

This is part of a vehicle presence sensor monitor.
I'll be using it to trigger a number of actions
including a camera and logging the event time so
reasonable accuracy is important.  I'll probably have
to regularly set the time in the RTC.

Thanks,
Phil

--- Paul Hutchinson <.....paullhutchinsonKILLspamspam.....yahoo.com> wrote:
{Quote hidden}

> > {Original Message removed}

2005\05\09@024823 by Robert Rolf

picon face
Pull the xtal leads out of the SBB and solder the
crystal (shortest possible leads)
directly to the pins. GROUND the crystal.

Your clock problem is likely due to noise coupling
into the xtal which is also running at nanowatt power
levels. I had the same problem with the same chip
and the above fixed it for me.

phil B wrote:

> Thanks,
>
> I agree that SBBs suck and, like I said, I put a lot
> of care into the PCB design (I know AN58 well by now)
> but am hoping to resolve this wierd drift thing before
> committing to solder.  I'd like to build it just once.
>  I'm probably being just a little too AR about this
> but you dont get perfect by accepting good enough.

Make sure you use a conformal coating on a scrupulously
CLEAN board (at least around the xtal).

If you want good accuracy you
can also add the spec'd trim cap and tune the xtal
for best rate. I assume you have the CORRECT matching
crystal (6pf IIRC) and that it's being driven at the
correct power level (different styles require different
drives).

> I wonder if humidity might be a culprit with the SBB
> changing capacitance and thus affecting the crystal
> frequency.  

Possibly, since you have quite a large area of conductive
spring wings that are coupled to plastic with an air gap.

> This is part of a vehicle presence sensor monitor.
> I'll be using it to trigger a number of actions
> including a camera and logging the event time so

And what about the camera real time clock (if its a
consumer digital camera)?

> reasonable accuracy is important.  I'll probably have
> to regularly set the time in the RTC.

Not if you implement a correction factor in software.
Once you know the bias and temperature drifts, you
can adjust the displayed time accordingly or log
the offset when you discover an event has occurred,
and project the drift backwards to get the exact time.
Of course it would be best if the xtal were close
to correct value.

How are you putting the date/time into the video (I assume)
stream?

Robert

{Quote hidden}

>>>{Original Message removed}

2005\05\09@045646 by Howard Winter

face
flavicon
picon face
Olin,

On Sun, 8 May 2005 16:01:36 -0400, Olin Lathrop wrote:

> phil B wrote:
> > I should have been a bit clearer.  I am checking when
> > I sync up the time.  At that point the PC clock should
> > be  pretty close.
>
> No, that was my point.  Take a look at the clock when you sync up.  It
> doesn't jump suddenly, unless maybe it's way off.  In some cases anyway, the
> system appears to try adjusting it smoothly.  It may take a while for it to
> get to the "correct" time.

While that may be the better way of doing it (meaning that you don't have "missing" seconds, nor repeated
ones) and some even tweak the PC's time in fractions of seconds regularly based on previous history, not all
of the synchronisers do this.  

For example, "Atomic Time Sync" from http://www.worldtimeserver.com just jumps the PC's time directly to the
time from the time server immediately, so you can be pretty sure it's accurate just after doing the sync.

Cheers,


Howard Winter
St.Albans, Herts


2005\05\09@050415 by Howard Winter

face
flavicon
picon face
Phil,

On Sun, 8 May 2005 16:19:12 -0700 (PDT), phil B wrote:

{Quote hidden}

I'm confused - you say you are using solderless breadboard, then talk about PCB tracks - can you describe the
setup in its entirety, which may give us a clue as to the culprit?  I suspect it could be interference being
picked up somewhere (possibly from the serial lines, as you say they are long) and this is causing extra or
missed cycles.

Cheers,


Howard Winter
St.Albans, England


2005\05\09@110812 by phil B

picon face
Prototype is on Solderless BB.
Final WILL be on PCB, once I believe all issues have
been resolved (and I fix my etch tank, sigh).  

The serial I/O lines are as far away from the RTC as I
can make them on the SBB.  On the PCB, they are on an
opposite part of the board and surrounded by ground.  


Phil

{Quote hidden}

               
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...