LowPowerLab Forum
Hardware support => General topics => Topic started by: joelucid on February 28, 2016, 10:13:10 AM
-
I've been doing some work around calibrating the am1805 RTC on some of my boards. I thought it would be good to calibrate them to my Gateway Moteino's crystal so that it could use simple millis() and delay() calls to communicate with RTC nodes during predefined time windows.
However I quickly found that the RTCs and the Moteino were so far apart that the calibration settings of the am1805 could not correct the problem. So I checked out the specs of Moteino's crystal and found --- that it isn't a crystal, but a ceramic oscillator with the accuracy that such a part delivers.
So what to do? I thought that at least the radio needs a precise time source to generate deterministic frequencies. And a little digging in the spec confirmed this, as well as the fact that a fraction of it can be mapped to DIO5. By default the chip starts with 1mhz signal on DIO5.
Now I only needed to mod the bootloader to select 16mhz on DIO5, reflash the 328p to run from external clock source, change RFM69 not to suppress CLKOUT in the radio, get rid of the ceramic resonator and solder a bridge from the radio to XTAL1.
Works like a charm and now I have a gw with a good time source synchronized with my RTC nodes.
If you want to try it the modified Optiboot.c is attached. In RFM69 eliminate the line that sets REG_DIOMAPPING2 to RF_DIOMAPPING2_CLKOUT_OFF and you're good to go.
For flashing I changed the lfuse to 0xc0 which selects the external clock.
(http://i.imgur.com/Gr1nAGo.jpg)
(http://i.imgur.com/ApWlBJr.jpg)
Joe
-
@joe, I'm surprised that you didn't cite the power savings eliminating the internal 8MHz RC for the external 16MHz from the radio...
Surely you're able to get another decade out of your coin cell with this setup (and a very precise decade at that)! ;)
Tom
-
@tom,
I hadn't thought about it for low power nodes for the simple fact that the radio crystal doesn't run in idle or sleep mode. The simplest way to kill such a modified moteino is call radio.sleep() on it.
So it could only work in listen mode where the radio always wakes the cpu. It probably uses more power than the internal oscillator, too. So the only benefits would accrue when the radio has to be active anyway.
-
But that just triggered an idea for a poor man's RTC:
you can select the calibrated 62.5khz RC oscillator on CLKOUT. Use that as asynchronous input for timer2 and you should have a fairly precise clock on your listen mode node. You only keep that clock on while your not in powerDown obviously (you could use powerSave instead and always keep counting, but that costs 500nA, so not viable). But in powerDown you have listenMode on and can determine from your pllLock interrupts how often the listen period has passed.
Hey, maybe the older nodes can still join the RTC crowd and take advantage of the improved listen mode like protocols!
-
You accomplished quite a lot! So, firstly, hats off on the Moteino mod to run off the RFM69's clock. Do you have to do anything to smooth the way for the switchover from 1Mhz to 16Mhz during the bootup, or does it all just engage seamlessly the moment you reprogram the RFM69 to output 16Mhz on DIO5?
Secondly, and no less a pièce de résistance: "now I have a gw with a good time source synchronized with my RTC nodes." Just how synchronized are they, and what do you have to do to maintain the sync?
Thirdly, I'll be quite interested to hear if you can get the poor man's RTC too!
Outstanding work.
-
Just how synchronized are they,
They are synchronized very well. I synchronized my gw and this node I'm working with 2 hours ago and they have drifted less than 2ms apart. That's less than 1ppm.
and what do you have to do to maintain the sync?
I have a command that I can send to a node to synchronize itself and I also do it on boot. how and when I do it will likely keep evolving.
BTW, the very low drift is probably at least partially explained by both boards sitting in the same room. Crystal frequencies can change quite a bit with differing temperatures. Since this board will live outside I expect that I'll have to periodically update the calibration in addition to resynchronizing.
-
BTW, the very low drift is probably at least partially explained by both boards sitting in the same room. Crystal frequencies can change quite a bit with differing temperatures. Since this board will live outside I expect that I'll have to periodically update the calibration in addition to resynchronizing.
Interesting update on this front: While when I went to sleep last night the two clocks were about 5ms apart with a 0 ppm implicated drift, this morning it was 36ms with 10 ppm drift. Clearly both crystals have different temperature coefficients which invalidates the calibration even in the same room when temperature changes.
So as I had suspected frequent recalibrations will be necessary to minimize drift.
-
Ok, I now have the rtc based board and the Moteino continuously synchronized to +- 1500us. Takes about one sync packet per 15min or so.
It's synchronization by recalibration - meaning I overcompensate for drift in order to drift back to perfect synchronization. So no discontinuities in time.
I can move the node from outside to inside (20 celsius temp difference) and it automatically recalibrates without leaving the +=1500us range. Really cool! Allows me to use 5ms wake windows to wake these nodes up individually. Lots of space for many nodes.
-
Very nice. Maybe your method also solves another problem that's been lurking in the background, which is that by doing it that way you can also now reliably do very narrow bandwidth communications (if you wanted to) between the two synced nodes without having to worry that your Tx and Rx frequencies are too far apart? Your method sounds like it would be an inherently more accurate way to address that issue than the other approach that has been tried (elsewhere on this forum), which was using the radio's temperature sensor measurement to programmatically adjust the radio's frequency offset.
-
Good point. That would work if the frequency deviation is caused primarily by deviation in the crystal frequencies between two radios. You'd still need to measure clock out of the radio then since right now I'm calibrating the 32khz crystal of the RTC. But if you did that on GW and node you could compensate with a very high degree of accuracy. Around 1ppm.
Who knows - maybe that's the right mode for underground nodes: ultra wide band wake signal for low power wake. And then super narrow band rx/tx to actually get a signal across. Currently I still hope I can get by with Felix 55khz settings though.
One obvious catch: synchronization requires connectivity which requires synchronization for frequency accuracy. So you better never lose connectivity or you'll have to dig up your sensors :( - or come up with some clever frequency sweeping to reattach. On yeah narrow band frequency sweep with wideband confirmation signal from above ground ... So many possibilities ...
-
Who knows - maybe that's the right mode for underground nodes: ultra wide band wake signal for low power wake. And then super narrow band rx/tx to actually get a signal across.
The more I think about it the more I like it: the rx problem underground will be general attenuation of both signal and noise by the soil. So all strategies that just ramp up the rx amp should work well. E.g. sensitivityboost should be on.
For tx in the other hand the soil will only attenuate the signal. So here improving above ground signal/noise by restricting frequency deviation should bring a big benefit. Can't wait to start working on those soil moisture sensors.
-
Let's see if I can summarize your current configuration.
Your gateway has no RTC chip on it. You have removed the ceramic resonator and instead wired it to the RFM69 crystal.
Your node does have an RTC chip on it (the am1805). The moteino still uses the resonator it came with. What about the RTC? Is it using a crystal or resonator? On Tom's thread about the am1805, he seemed to imply it was needed. The way I read the datasheet, an external clock/resonator isn't needed (though accuracy suffers). However, I presume you aren't using an external clock/resonator for your RTC, and so it's also more motivation to sync with the gateway.
Right so far?
If the above is right, then when I wrote reply #8 above, I was mistakenly thinking that your Moteino node, like the gateway, is also using its RFM69's crystal. I'm not far enough in my reading of the atmega328p's datasheet to know if there's a way to "trim" the node's atmega328p clock (it might be nice if there were) to get it to sync with the gateway atmega328p clock... but I'm guessing not. Even so, I was thinking that with that configuration (i.e. the node also running from its own RFM69's crystal and the gateway running from its RFM69 crystal), it maybe would be easy to compare the node's RFM69's crystal speed against the gateway's RFM69's crystal speed and from that deduce a proper frequency offset to align the node's RFM69's radio frequency with the gateway RFM69's radio frequency. [That's because, as I understand it, the radio frequency is achieved by multiplying the 32Mhz frequency by a constant and then adding/subtracting an offset to arrive at the actual radio frequency.] Anyhow, there may be other/better ways to do it, but that was the notion I was assuming when I wrote reply#8.
[The TL;DR for the benefit of anyone else reading this: an accurate syncing of the radio frequencies would be useful because the RFM69 crystals are maybe 10ppm (the HopeRF datasheet leaves out that vital information, but another thread on this forum tries to narrow down what it probably is), and aren't temperature compensated, and that by itself isn't good enough to ensure that some of the narrower Tx and Rx frequency bands even overlap, let alone are adequately aligned. In theory someone could make a hardware module similar to the RFM69 but which uses an accurate TCXO, but, AFAIK, no one does at the moment, so we have to work around the inaccuracy of the given hardware if we want to utilize the SX1231h's full potential. ]
-
You're correct on the gateway front. On the client side I run on the internal 8mhz oscillator and the RTC does use s crystal. You still need to calibrate it to offset temperature drift. The internal 8mhz oscillator of the 328p can be calibrated. It can even be accelerated up to 12mhz if you want to. But it doesn't really matter since you can't run it in powerDown.
That's the essential advantage that the RTC gives you: a precise clock that only uses 55nA (I do run with xtal on to be able to get precise sync) while you're in powerDown. I still think your point is very valid though: if you have a clock that's calibrated to the gw clock then you can measure the freq of the radio crystal. And that should allow you to align frequencies more closely than you ever could using temp correction. Which makes it easier to use very narrow band communication which might be important for underground nodes.
-
OK, that makes sense then: given the energy cost of doing the sync compared to the energy cost of running a dedicated RTC crystal, you'd rather use a dedicated RTC crystal so you don't have to sync as often to keep the RTC time accurate. If you don't mind my asking, which crystal did you pick for your xtal? Are there TCXO crystals that would also work as an XTAL, so you can sync even less often, or in comparison are they simply too expensive or use too much current or...it wouldn't matter anyway?
I still think your point is very valid though: if you have a clock that's calibrated to the gw clock then you can measure the freq of the radio crystal. And that should allow you to align frequencies more closely than you ever could using temp correction. Which makes it easier to use very narrow band communication which might be important for underground nodes.
Agreed. You may have already said or implied this on the other thread, but just to recap for completness: if you could do it in a very accurate and precise way, you could also probably infer pretty accurately the temperature at the node (well, at least the temperature of RFM69's crystal oscillator)--probably even more accurately than the +-1C you'd get from trying to measure it directly using the RFM69's built-in temperature sensor. So, even for above ground nodes that are operating wideband, there's that as a possible motivation for doing it. :)
Offhand, I'm not sure how it could be done if not running the node's atmega328p off the node's RFM69 crystal, but maybe there's some other way to count the radio crystal's clock cycles fast enough without loosing too much precision...
-
Are there TCXO crystals that would also work as an XTAL, so you can sync even less often, or in comparison are they simply too expensive or use too much current or...it wouldn't matter anyway?
The thing is: the am1805 can only be calibrated with a resolution of 1.9 ppm. So you have to adjust the calibration regularly anyway to stay synchronized. I do measure the temperature via the radio and increase the frequency of my calibrations temporarily when there's a significant temp shift. But other than that the temp compensation comes for free.
Offhand, I'm not sure how it could be done
Just count clkout of the radio using timer2 during an interval determined by the calibrated RTC. Problem is you have to measure pretty long (like a couple of seconds) to get a fairly precise reading down to ppm. And operating the crystal costs 1.2mA or so. But then you don't need to do it often and you know when you have to do it by detecting shifts during RTC recalibration.
So I think this is quite doable.
You could also do this using stock Moteinos by recalibrating the RC oscillator in the radio and then measure it (either on clkout or using listen mode timer) during a period of time set by the gw moteino. But that will be less precise.
Joe
-
BTW one reason I'm suddenly excited about narrow band communication is that given the synchronization between nodes and Moteino I can now switch the gw into narrow band rx during agreed time slices. So each node can use the comms settings that optimize its battery life (obviously you always want to use as high of a bitrate as possible to keep tx time down).
-
I'm not sure what XTAL you're using, but I haven't found any that seem any good. I did find this RTC, though, which has a built-in 2ppm XTAL and consumes only 60na when running in xtal-mode: http://www.microcrystal.com/images/_PDF/5_Real-Time-Clock_RV/RV-1805-C3.pdf, or this 1.5ppm one that has a TCXO and consumes 240na: http://www.microcrystal.com/images/_PDF/5_Real-Time-Clock_RV/RV-8803-C7.pdf
-
I'm using this one (http://www.abracon.com/Resonators/ABS07.pdf). Nice and small. The micro crystal RTC is interesting. It seems to be the am1805 with integrated crystal. Ambiq licenses their technology out. Abracon also has a version of it.
-
That's interesting. http://abracon.com/realtimeclock/AB-RTCMC-32.768kHz-IBO5-S3.pdf does look the same as the first one I mentioned from Microcrystal, and it's not as expensive (at least not here in the US). However, it doesn't appear that Abracon has an RTC that matches the second one (1.5ppm TCXO and 240na) from Microcrystal.
-
However, it doesn't appear that Abracon has an RTC that matches the second one (1.5ppm TCXO and 240na) from Microcrystal.
Yup. And all these 50-60nA ones are based on Ambiq's sub threshold technology - hence the super low power consumption. The second one certainly looks cool - but keep in mind that 15min have around 1M ms, so even at 1.5ppm you're off by around a ms every 15 minutes. So I suspect regular sync pings will be required anyway.
I think you can do those by server push (so only rx needed on client and you can probably do them at 2V client voltage) and overall it should cost less than 100nA at 1 ping per 15min. Or ~30nA at the 9V level.
-
I'm thinking there may be an easier way than syncing the node clock to the gateway clock. As long as the node sends out a beacon signal at regular intervals (provided the interval is reasonably consistent from one to the next and drifts relatively slowly), then perhaps the gateway can simply keep track of the times it receives the beacon signals and from that compute when the node will be listening. To illustrate, suppose the node has completed 99 listen windows, and after the 100th time it sends a beacon signal to the gateway. Then, by the gateway knowing when it received the last two beacons, it seems like the gateway should be able to compute the start times of the next 100 listen windows.
Of course, just by itself that wouldn't guarantee the listen windows or the beacons of different nodes don't overlap, so in that sense it wouldn't be as good, but maybe there's a way to dance around that and prevent it from happening if the gateway notices that the beacons of different nodes have started to drift too close together.
-
You might want to look at the Timing-sync Protocol for Sensor Networks (TPSN). This allows clients to synchronize their internal clocks with a server's clock, it's done by a client sending a timestamp in the request packet and the server sends back it's own timestamp. This makes an assumption that from when the timestamp is sampled at the transmitter the time for the receiver to actually get the packet is constant and is the same for both client and server. If the client is regularly sending packets to a server and getting replies this effectively lets you get synchronization for free (apart from a few more bytes in the packets):
https://www.cs.uic.edu/~ajayk/ext/ClockSyncWSNsurvey.pdf
-
Thanks guys, good ideas and pointers. My mid term plan is a bit different than what you describe, and that's because of the asymmetrical costs of TX vs RX. I think it's best to have the GW send periodic time stamped beacons that the clients can use to sync their clocks.
This is partially motivated by my next use case: sprinkler controllers. They are special in that there are no status updates, just on/off commands. So it should be possible to only transmit very rarely and do the synchronization by receiving sync packets.
-
Concerning time sync between nodes, you could use the Flooding time sync protocol :
http://web.stanford.edu/class/cs244e/papers/ftsp.pdf (http://web.stanford.edu/class/cs244e/papers/ftsp.pdf)
It's seems it's possible to obtain ~1us time syncro between nodes