PDA

View Full Version : RTC's - Any good ones?



Philldapill
01-24-2008, 10:57 AM
Anyone know of a simple and cheap Real Time Clock that can easily be integrated into the prop? I want fairly accurate time, and through previous attempts, I can only get the time accurate to about 1 second every 3 hours. I posted a topic about this and someone suggested simply adding 1 second every 3 hours to compensate, but the application will have varying temperature and I just figure a RTC is the answer. Suggestions?

By the way, the application is for aquiring a time and date to be used in an electronic gate opener that logs when the gate is opened/closed(people comming/going) for analysis.

Mike Green
01-24-2008, 01:31 PM
Any RTC you use will have the same sort of problem. Any crystal is temperature sensitive (and all to similar percentages). You will need some kind of temperature compensated crystal oscillator. If you're going to get one, you might as well just get a 5MHz temperature compensated crystal oscillator and use that for the Propeller's system clock.

DarrenY
01-24-2008, 04:50 PM
Check out the Dallas DS3231.....

"The DS3231 is a low-cost, extremely accurate I2C realtime clock (RTC) with an integrated temperature-compensated crystal oscillator (TCXO) and crystal"

It's supposed to be accurate to within 2 minutes per year.

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4627

deSilva
01-24-2008, 05:19 PM
A cheap and good one is PCF8583 ($2); Dallas sells more advanced chips... there is one containing a temperature sensor for your own conveniance, but I suspect it is also used for internal clocjk compensation... Have a look into the datasheet - I think it is around $8.. RTC has some good ones, but they have special µC-interfaces (needing 4 to 8 lines)

Rayman
01-24-2008, 10:07 PM
I'm using DS1307 because they are very easy to use and only require +5V and an external crystal.· I'm pretty sure that 1 second per 3 hours is not a problem.· Since it is I2C, I connect it to the existing I2C bus on Pins 28&29 and thereby don't use any extra pins....

Here's a photo of one I installed yesterday:

You can see the backup battery for it and the crystal on pins 1&2 of the DS1307.· I set the time yesterday and it is still accurate to the second today...

PS:· I posted some code for time management with the DS1307 about a month ago...

Paul Baker
01-25-2008, 02:12 AM
There are better matches for the Propeller than the DS1307, the DS1302 and DS1340 both support operation at 3.3V. The DS1307 works, but a 3.3V part should be used if availible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

Rayman
01-25-2008, 02:59 AM
The DS1302 is 3-wire not I2C, so it will use up Prop pins. The DS1340 is I2C, but doesn't come in DIP...

Tracy Allen
01-25-2008, 04:56 AM
The DS1338 is closer in function to the DS1307, same pinout, scratchpad sram and squarewave outputs, but operates on 3.3 volts with a coin cell backup. It is not available in DIP, but can be easily adapted with a little carrier board. The DS1340 has the same pinout, but doesn't have the scratchpad RAM, but it does add the trickle charger option, and it has the capability for fine-tuning the oscillator frequency through a register that adjusts the load capacitance. The Intersil ISL1218 is another one like that, I2C with the same pinout (SO8 or MSOP), also with the tuning feature and a smidgen of sram, more flexibility in the SQW/INT output, and easiest to handle terms of micropower operation.

With those, the external processor has to do the frequency compensation, by plugging the temperature into the parabolic crystal frequency curve,


dF = Fo * K * (T - To)
dF: frequency deviation in Hertz (typical < 1 Hz over 0 to 50 Celsius)
Fo:center frequency (+/- 20 ppm at 32768 hz usual tolerance)
K: parabolic coefficient (-0.035E-6 +/- 0.005E-6 typical)
T: Celsius Temperature
To: Turnover temperature (25 degrees Celsius +/- 5 typical)


The compensation might be done on a minute to minute basis, either by adjusting the capacitance register, or by accumulating microseconds of error and correcting the clock when it accumulates to one second.

Micro Crystal of Switzerland (think Swatch) has also been coming out with interesting RTCs and TXCOs.

The Dallas RTCs like the DS32B35 are remarkable because they handle the temperature compensation internally, using an internal crystal that is presumably tightly matched to the circuit. They get down to +/- 3.5 ppm over the entire range from -40 to +85 degrees Celsius. Not only that, the timekeeping is done in FRAM, so no backup power is necessary, and they even throw in up to 8 kbytes of general purpose FRAM and other goodies. For experimenters, it might take a 20 pin SO to dip adapter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com (http://www.emesystems.com)

deSilva
01-25-2008, 05:24 AM
All constraints unknown from the OP - "...simple, cheap, easy to integrate.."... Boy, I LOVE such requirements - a quick search at digi-key reveals only 5 RTC with 3.3 V, I2C, and DIP package.

The only one NOT recommended above is the one I think most eligeable:
datasheets.maxim-ic.com/en/ds/DS1672.pdf (http://datasheets.maxim-ic.com/en/ds/DS1672.pdf)
However it does know of neither leap years nor days of the week but seconds only http://forums.parallax.com/images/smilies/smile.gif

Note that Dallas gives no data for long term accuracy as all depends on the way you install it, choose and connect the crystal, etc, etc.

Rayman
01-25-2008, 07:28 AM
Just seconds is actually preferable to me! In order to do POSIX time, I had to convert to epoch seconds anyway. I might have to get some of those...

Still, I'm mostly working with proto boards now and those have 5V handy anyway and the I2C from the DS1307 works just fine directly connected to the prop pins...

Paul Baker
01-25-2008, 07:44 AM
Another factor to consider is that there are several load capacitances for 32kHz crystals, you should choose one which is specified in the datasheet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

deSilva
01-25-2008, 08:42 AM
This is what I tried to express by ".. choose and connect the crystal..." Maybe - in a year or so - I shall be able to say what I mean in English :-(

Paul Baker
01-25-2008, 08:54 AM
Sorry deSilva, I missed your comment.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker (mailto:pbaker@parallax.com)
Propeller Applications Engineer
[/url][url=http://www.parallax.com] (http://www.parallax.com)
Parallax, Inc. (http://www.parallax.com)

rjo_
01-25-2008, 09:48 PM
Philapil...

I have some ideas... but I'm not an engineer, so you should take this advice with a small grain of salt.

I don't know all of the real world constraints (which usually drive the choices we make). But if it was me and I didn't have to squeeze every dollar out of the design, I would consider using the Parallax GPS in smart mode... You'd have a universal clock that wouldn't be sensitive to re-set conditions (which might be a real issue) and you wouldn't have to calibrate it or adjust it.

You could use the Prop at just about any clock speed and you would never see an inaccurate time.

Parallax's GPS is robust... and works almost everywhere... including basements!!! I suspect that (under very weak signal conditions) ambient noise can cause the unit to lose signal... so you might want to use a software clock for redundancy... or as a primary clock, which you simply correct according to the universal time of the GPS. The only thing standing between you and absolute time is the propagation delay in the process of requesting a measurement, the GPS obtaining the measurement and reporting it to you.

I think we should always plan for periodic re-set conditions... if you assume that you are going to have unanticipated brown-outs and/or other types of reset conditions, you won't be unhappy when they occur:)

Rich

Post Edited (rjo_) : 1/25/2008 3:16:44 PM GMT

Drone
01-26-2008, 12:12 AM
Hi Phil,

Rich is right, GPS "may" be the way to go. But there are caveats if you want real sub-second accuracy:

With GPS, you have to parse a serial NMEA comma-delimited output from the GPS receiver (typically at 4800 baud) to get the time-date out of the GPS receiver. There's an object in the object-exchnage that does this. Note however, receiving and processing the serial GPS message takes time, hence your time-stamp will be delayed. The NMEA specification says on which bit the time is supposed to be valid, so one way around this is to acquire the GPS data serially, process it, add one second to it, and use the 1 second time-shifted data tiggered as valid on the corret bit of the next NMEA message. This means your time data on start-up will take 1 second to be valid. Also, without a lot of calculations, your time-valid data will be off by one second in terms of date, leap-seconds, and leap-year (Hmm... I think so at-least).

I wish these GPS module vendors would have an option to output the NMEA sentences with the NEXT second's calculated/corrected time, date, leap-second, leap-year stuff rather than the current second's time etc., this would allow processing time with valid time-stamps. But no.

Another alternative is to use a RTC chip that is clocked by a GPS receiver, replace the 32768kHz crystal input with a reference frequency input from the GPS reciever. Unfortunately almost ALL GPS receivers only output a 1 pulse per second signal, and phase locking a crystal replacement synthesizer (e.g. PLL) to 1PPS is a major pain.

One (surplus) GPS module that does output (in addition to 1PPS) a 10kHz signal is the Rockwell Jupiter (search ebaY). These aren't manufactured any more and surplus modules are getting hard to find. Keep in-mind though to maintain accuracy you should periodically parse the NMEA time-date and compare it against the hardware crystal-replacement GPS "disciplined" RTC output just to be safe and correct the RTC if there is disparity (this will of-course cause a glitch in your time-stamps should it occur).

Oh yes, beware, the 10kHz output of the Rockwell Jupiter modules may or may-not be "coherent" with the rising edge of the 1PPS output which "should" be coherent with the valid bit of the NMEA message output. I haven't looked into this. But I'm sure other's have...

There's a good mailing list called Time-Nuts that caters to all kinds of timekeeping stuff. See www.leapsecond.com/time-nuts.htm (http://www.leapsecond.com/time-nuts.htm)

If anyone knows of GPS modules that:

1. Have an NMEA output for the Next second (not current). and/or

2. Have an output that is higher than 1PPS (DDS synthesized output woulld be ideal).

Let us know.

Regards, David

Jonathan
01-26-2008, 12:46 AM
Not sure what just happened, I don't see a dup post, but sorry if there is...

Anyway, the Motorola Oncore UT has > 1PPS. I am using a GT, which only has 1PPS. However, since I am only extracting the time and date, which come first, I can do it fast enough to be synched. At least, when I call the time lady, it's always spot on.

I retransmit the time locally on RF. That way any of my projects that need a time base only need a US$10 rf· receiver. I only have one clock left in my house that doesn't run on this timebase. Which irritates me, as I have to reset it after every power failure (I live waaaay out in the sticks, and the power blips several times a month at least. I'd get rid of it, but it's also an X-10 controller that I still use.

Anyway, 2 thumbs up for GPS synched time. I love not setting the clocks! DST too! If you need a pinch of code for calculating the new DST lemme know.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.madlabs.info (http://www.madlabs.info) - Home of the Hydrogen Fuel Cell Robot

VIRAND
01-26-2008, 02:58 AM
Extra cheap timebase:
A CMOS 4060 ic with a 32768 hz crystal and a few capacitors and a resistor. It outputs 2hz out of pin 3
The Propeller must be on all the time to count halfseconds. Spare cog?
To keep extra accurate time maybe keep the crystal warm with a resistor.

Pins on 4060:
pin 8-GND
pin 16- + (3.3V in Propeller case)
pins 10- to 11- a 10 Meg resistor
pin 10- to 330K resistor to 32768hz crystal to pin 11
pin 11- to 10pf cap to GND
other side of crystal 10pF cap to GND
pin 3- 2hz out
pin 16- 0.1uF cap to pin 8 (GND)
pin 12- to pin 8 or GND

kenmac
01-26-2008, 06:14 PM
Philldapill,
Have you considered using a dedicated Cog to do the RTC job? (instead of external RTC)
It is possible to get it pretty accurate by trimming the program loop delay (trial and error varying of a Constant)

If you need to have a battery backup, it's possible to backup the Prop. by shutting down other Cogs to minimise the load.
This would require one pin monitoring the supply volts, to trigger the changeover to battery and back..
The Prop. running at 5mhz and one Cog, with no output load, draws less than 1mA.
I recently used a similar system, using a cordless phone battery (3.6V NiMh).

If temperature compensation is required, another Cog could be used to monitor temperature, automatically adjusting the clock loop delay accordingly.
I've never gone that far, preferring to have a manual means of adjusting the time if required. (switches)
As a result, I haven't yet determined how accurate it can be set within the program. (I might try one day, just for interest sake)

If you need a separate RTC, Futurlec have a complete DS1307 I2C circuit built on a mini-board, for $US 6-90.(plus postage)

kenmac

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Perth, Western Australia
Time Zone = GMT + 8

Philldapill
01-28-2008, 02:18 AM
This is just an update on the clock issue.

When I first started trying to keep time, I did this on my Education Kit breadboard. I was very irritated that the time was consistantly losing about 2-3 seconds a day, so that in a month, it would be about a minute behind. I tested this by letting it run for 3 days, and comparing the current time to that of my clock-updated-by-internet computer. Now, trying this on my protoboard(different crystal), the thing gains about 4 seconds a day, which isn't terrible(2 minutes a month), but it just goes to show that it appears it is the crystal that has the inaccuracy as stated by guys above.

Temperature for my app. is going to be fairly constant, so I suppose I could just make·a software correction and it should be fine. By the way, I searched in the Object Exchange for simple clock objects, and didn't find any simple ones, so I'm attaching a Clock.Spin file in case anyone wants to use something similiar.