Running Moteino from radio crystal

[joelucid]

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).

[WhiteHare]

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

[joelucid]

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.

[WhiteHare]

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.

[joelucid]

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.

[WhiteHare]

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.

[perky]

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

[joelucid]

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.

[SadE54]

Concerning time sync between nodes, you could use the Flooding time sync protocol :
http://web.stanford.edu/class/cs244e/papers/ftsp.pdf
It's seems it's possible to obtain ~1us time syncro between nodes