RTC's - Any good ones?
Philldapill
Posts: 1,283
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.
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.
Comments
"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
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
Propeller Applications Engineer
Parallax, Inc.
With those, the external processor has to do the frequency compensation, by plugging the temperature into the parabolic crystal frequency curve,
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
The only one NOT recommended above is the one I think most eligeable:
datasheets.maxim-ic.com/en/ds/DS1672.pdf
However it does know of neither leap years nor days of the week but seconds only
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.
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
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
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[noparse]:)[/noparse]
Rich
Post Edited (rjo_) : 1/25/2008 3:16:44 PM GMT
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
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
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 - Home of the Hydrogen Fuel Cell Robot
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
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
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.