I need to synchronise RTCs of multiple Teensies without a wireless module or GPS. I thought it should be possible to do by transferring the programming computer's current time to the RTC when the sketch is uploaded. Is that feasible? If yes, how would one go about doing that? If not, are there alternatives?
Synchronisation of RTCs between multiple Teensy 3.1
- Thread starter tingo
- Start date
- Status
Even if they are very well tuned and operate in the same environment, they willdrift away from each other over time. How long do they need to be synched and what difference in their "local" times is acceptable? We need a number here.
Do the Teensys have some interface left that you can use to set each RTC after programming?
Do the Teensys have some interface left that you can use to set each RTC after programming?
Yes I understand that they will drift. All of the devices will operate in the same room and otherwise in very similar conditions. We'd want them to by in sync for 2 to 8 hours and the acceptable difference would be less than 3 seconds, ideally 1 second.
At the moment they don't, any suggestions for such an interface?
As you're using teensyduino, it should be very easy to write code in setup() that waits for a "set time" string over one of the hardware serials. Just connect all the Teensys to the same serial transmitter and send one string with the current time to all of them.Then have them all set their RTCs to that time.
If you're on linux, you can use a single command to grab the current time, convert it to whatever format you pick, and send it. If you're on windows, this may be possible as well, but I'm just not sure how.
MichaelMeissner
Senior Member+
I would suspect that ultimately you will want to use something like a chronodot (https://www.adafruit.com/products/255) which claims to be ultra-precise, since it is corrected for temperature, which the builtin ARM RTC probably is not. You could always buy one (or a GPS unit), and hook it up to each teensy in turn via i2c, and have a button that when pressed, it queries the ultra-precise time source, and sets the Teensy's. This seems to be a lot simpler than having to hook up the serial port and run some command to set the time.
If the chronodot is moved (hot plugging?) from Teensy to Teensy, it could tell every Teensy the current time - that's fine. But after that the Teensys would have to rely on their own (probably imprecise) RTC again, making the chronodot's precision useless.
Thanks for the suggestion, seems to me that this should work.
So considering Teensy's RTC hardware, what do you think would be a reasonable time window within which the devices' RTCs stay within few seconds of each other after being synced with a chronodot?
Take a Teensy and run a test. Just let it output the time at regular intervals (so you know it's running) and after a few hours calculate how much it's off. There's surely some characteristic values available, but I'd rather use a real device for this test. If you have more Teensys available for this, use them to see if they have different errors. I'd expect them to be "in synch" (a few seconds) for way longer than a day.
Ok will do, thanks a lot!
Constantin
Well-known member
For absolute precision, a GPS module is the way to go - assuming you have a good signal. I've managed to get GPS reception on a Teensy-attached module through roofs and two floors of wood construction - very impressive. This is the most expensive option, but also the one option that will be 100% accurate all the time. You have the option of either using the GPS output (using one of the serial ports on the Teensy) or using the PPS signal as a replacement for the internal clock if the teensy is on all the time. I would go with the serial output.
The Chronodot is a great option for keeping time in non-GPS situations. The chip at the heart of the Chronodot is a temperature-compensated clock which is available in a I2C version (the one used in the Chronodot) as well as a SPI version. I've had great success with the Chronodot and highly recommend it.
The least expensive option is a home-made temperature compensation for the RTC crystal on the Teensy 3 board. This option works very well if you add a accurate temperature sensor to your teensy (DS18B20, for example), your teensy is running all the time, and you have done some measurements. If the teensy is not connected to power, then the RTC on it may continue to run (via a external battery you need to supply) but the temperature compensation will not be functional. Plus, you would have to characterize each crystal PPM error by temperature, see this post where I described my method. This is the lowest material-cost method and also the most time-intensive method.
I have some additional testing to do but my guess is that the crystals I have been sourcing are sufficiently similar that for indoor conditions (i.e. 0-40*C) the compensation function would work well enough.
The Chronodot is a great option for keeping time in non-GPS situations. The chip at the heart of the Chronodot is a temperature-compensated clock which is available in a I2C version (the one used in the Chronodot) as well as a SPI version. I've had great success with the Chronodot and highly recommend it.
The least expensive option is a home-made temperature compensation for the RTC crystal on the Teensy 3 board. This option works very well if you add a accurate temperature sensor to your teensy (DS18B20, for example), your teensy is running all the time, and you have done some measurements. If the teensy is not connected to power, then the RTC on it may continue to run (via a external battery you need to supply) but the temperature compensation will not be functional. Plus, you would have to characterize each crystal PPM error by temperature, see this post where I described my method. This is the lowest material-cost method and also the most time-intensive method.
I have some additional testing to do but my guess is that the crystals I have been sourcing are sufficiently similar that for indoor conditions (i.e. 0-40*C) the compensation function would work well enough.
MichaelMeissner
Senior Member+
Certainly. By ultimate solution, I meant having a chronodot on each Teensy.
Ah I see - that makes more sense from a precision point of view. Stiil you'd need to carry one around and use it to set the time on each Teensy. I think Connecting them all to one time source once (for setting the time) wouldn't be more complicated than that.
Indeed GPS would be ideal, but I need the device to consume as little power as possible to achieve battery life of 5-8 hours off a 100 mAh LiPo battery. Also it needs to be small - matchbox size and finally in the majority of cases it will operate indoors.
Excellent, I'll try it!
If the chronodot method fails to provide the required synchrony I'll try this.
Thanks for the suggestions!
Constantin
Well-known member
Battery operation makes me advocate for the Chronodot, it just works and your Teensy can go to sleep for long periods of time. However, the precision offered by the Chronodot may be overkill if your in-field precision requirement is only measured over a few hours. The Chronodot offers <3PPM performance, but that level of performance is usually only measurable over weeks of time.
So, if you are deploying your device for only hours of time, your Teensy 3 may perform well enough with a good set of CFS-206 RTC crystals and the clock offered by your CPU during compile time (NTP server, et al). But if there is a long time period from which you set the clock and the time that the clock is used, then a Chronodot makes more sense.
pictographer
Well-known member
Since these devices are all in the same room, an inexpensive approach might be to use an IR LED on one of the T3s and IR photodiodes to read blinks on the others. Of course, there'd be some work to do writing the software to trim the RTCs based on periodic blinks. There are many IR projects documented on the web. There have even been some that use IR for full-blown networking.
Yeah, the OP says he need 2 or so seconds sync in about 8 hours. I'd think that out of the box would do it.
Else you could use some of the RFMxx data radios to exchange messages of all kinds, including time sync. These radios are about $5 ea. There's an OSH Park board and drivers/protocols from RadioHead and/or LowPowerWireless. I have some higher level software for messaging. And a gateway to a PC or RPi that could get NIST time and disseminate it.
Else you could use some of the RFMxx data radios to exchange messages of all kinds, including time sync. These radios are about $5 ea. There's an OSH Park board and drivers/protocols from RadioHead and/or LowPowerWireless. I have some higher level software for messaging. And a gateway to a PC or RPi that could get NIST time and disseminate it.
MichaelMeissner
Senior Member+
If they are nearby, another solution is to get nRF24L01+ radios, and use them to keep things in sync, with one Teensy being the master, and other slaves. I don't know what the current draw is, so it may be too much power.
onehorse
Well-known member
The nRF24L01+ radios can operate at very low power ~100 uA but adding one to each Teensy is cumbersome to say the least.
The alternative is a chronodot-quality RTC in a very small package that can be added to each Teensy such as this unit, which claims accuracy of 5 seconds per month and 350 nanoA time-keeping current on a 3 V coin cell battery. The beauty of this solution is the small size; a small (0.3 in x 0.6 in) PCB could be designed to solder onto the back pads of the Teensy 3.1 that would contain this (or another) accurate RTC. This one has a version with an internal crystal and oscillator so the circuit is particularly small and simple. After calibration, it claims accuracy of +/- 2 ppm. The Teensys can be synced via serial commo and then run for weeks with little time dispersions between them. Additional temperature compensation can be done in software if necessary.
I am planning to use the above device in just this way.
The alternative is a chronodot-quality RTC in a very small package that can be added to each Teensy such as this unit, which claims accuracy of 5 seconds per month and 350 nanoA time-keeping current on a 3 V coin cell battery. The beauty of this solution is the small size; a small (0.3 in x 0.6 in) PCB could be designed to solder onto the back pads of the Teensy 3.1 that would contain this (or another) accurate RTC. This one has a version with an internal crystal and oscillator so the circuit is particularly small and simple. After calibration, it claims accuracy of +/- 2 ppm. The Teensys can be synced via serial commo and then run for weeks with little time dispersions between them. Additional temperature compensation can be done in software if necessary.
I am planning to use the above device in just this way.
- Status