LowPowerLab Forum

Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: SadE54 on April 15, 2016, 01:19:48 PM

Title: Frequency Hopping
Post by: SadE54 on April 15, 2016, 01:19:48 PM
I'm curious if someone here tried to use frequency hopping with RFM modules ?
I would use such a system to avoid frequency jamming and get a very robust link.
Title: Re: Frequency Hopping
Post by: joelucid on April 15, 2016, 01:30:29 PM
Also with hopping you can legally transmit at 30 dBm @ 915 Mhz in the US. So I think this is very worthwhile to do. Haven't yet, but would like to at some point.
Title: Re: Frequency Hopping
Post by: SadE54 on April 15, 2016, 02:12:15 PM
The main problem is to get a distributed accurate time synchronization between nodes. There's solution like mentionned in another topics , but not so easy to implement !  :-\
Title: Re: Frequency Hopping
Post by: WhiteHare on April 15, 2016, 02:28:07 PM
I think Question #1 would be whether or not the RFM69 can hop channels fast enough and in such a way as to meet the regulatory definition.  If not, then you'd be limited by the same rules as without frequency hopping.

If that hurdle could be cleared, then another benefit to frequency hopping is that, IIRC, the regulatory requirements on overall duty cycle are, broadly speaking, not as constrained (maybe even non-existent) if frequency hopping is utilized in a manner that meets the regulatory definition, and that in itself would be very motivating to have (e.g. to speed up long streams of data, such as OTA programming updates, especially when higher Tx powers are needed.

Looking at the datasheet, it doesn't seem like the hardware gives you much help at all, other than offering up a 20-80uS lock speed on the new frequency when you change channels.  Choreographing the channel hopping appears to be a task left entirely up to you and your mcu to manage. 
Title: Re: Frequency Hopping
Post by: WhiteHare on April 15, 2016, 07:04:19 PM
Here's what TI has to say on the general topic of what what would be needed to meet FCC regulatory requirements:

Quote
Frequency Hopping Spread Spectrum
Even higher output power can be used if the system employs some form of spread spectrum such as
frequency hopping or direct sequence spread spectrum. The reason such allowances are made is that
spread spectrum systems are less likely to interfere with other systems than are single frequency
transmitters. They also have the advantage in that they are often more immune to interference from other
systems. The limitations and qualifications of a spread spectrum transmitter are defined in FCC section
15.247
An application qualifies as a frequency hopping system under section 15.247 if:
The transmitter pseudo-randomly hops between frequencies that are separated from each other by at
least the 20-dB bandwidth of the data channel, but not less than 25 kHz.
The 20-dB bandwidth of the hopping channel is not larger than 500 kHz.
If the 20-dB bandwidth of the hopping channel is less than 250 kHz, the system must use at least 50
hopping frequencies. The average time of occupancy at any frequency (dwell time) must not be larger
than 0.4 seconds within any 20 second period.
If the bandwidth of the hopping channel is larger than 250 kHz, the system must use at least 25
hopping frequencies. The average time of occupancy at any frequency must not be larger than 0.4
seconds within any 10 second period.
see http://www.ti.com/lit/an/swra048/swra048.pdf , page 7, for the original text plus additional commentary.

Looking at this now with fresh eyes, I don't think it would be very hard to code some control software that would meet those requirements with a single RFM69 module on either end of the link.  So, if you have an itch to do it, I don't see any red flags or other reasons not to.

That said, laws may have changed or there may be other factors I'm not aware of, so as usual with this type of stuff, it's still your responsibility to become educated enough about it that everything you do is certain to be legal.  (I hate feeling like I should add disclaimers like this, when it should be obvious anyway, but that's the world we live in.)
Title: Re: Frequency Hopping
Post by: perky on April 15, 2016, 07:14:33 PM
The specs for 915MHz I think allow a relatively slow channel hopping frequency but you need at least 25 (or 50) channels. I think the spec says repeating the complete sequence every 20 seconds for 50 channels and every 10 seconds for 25 channels, which allows a 400ms dwell time on each frequency. For slow hopping frequencies a big problem then is how long it takes for a receiver to lock onto the sequence in the first place (the aquisition phase).
Mark.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 15, 2016, 07:43:42 PM
I read it that way too when I first looked into this, and that was how I remembered it, but when I re-read it now, I don't see it saying that you need to use *all* the 50 or 25 frequencies in the designated time period, but just that you pseudo-randomly pick frequencies from a set of that many and that you can't spend more than 0.4 seconds on any one frequency within that 10 or 20 second moving window of time.  If that's right, then I don't see anything which keeps the RFM69 from being able to do it.
Title: Re: Frequency Hopping
Post by: perky on April 16, 2016, 12:11:11 AM
I've read that you have to spread out transmission equally across the channels. That precludes, for example, transmitting more regularly on a beacon channel. The biggest problem, especially for battery operated systems that don't transmit often to save power and whose receivers wake up and go back to sleep again, is how does the receiver lock on to the transmission sequence? How long will it take, and will the receiver need to be on for all that time? With 10s of seconds between each transmission, and 50 channels, and no beacon channel...

Section 15.247 (g)
Frequency hopping spread spectrum systems are not required to employ all available hopping
channels during each transmission. However, the system, consisting of both the transmitter and the
receiver, must be designed to comply with all of the regulations in this section should the transmitter be
presented with a continuous data (or information) stream. In addition, a system employing short
transmission bursts must comply with the definition of a frequency hopping system and must distribute its
transmissions over the minimum number of hopping channels specified in this section
.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 16, 2016, 01:59:17 PM
how does the receiver lock on to the transmission sequence?

I'm sure there are more efficient ways of doing it, but off the top of my head I suppose that info could be included as overhead in each of the packets that gets sent.  Then once a receiver snags a packet (which it could eventually do just by listening long enough on one of the known channels), it would then know how to follow along.

I do wonder what the FCC's particular definition of "pseudo-random" is in relation to this.  What is the test?  A lot seems to hinge on the meaning of that term.

Anyhow, I notice TI does give a blueprint (albeit for a TI radio) for how to implement frequency hopping in a manner which they seem to imply is FCC compliant:   http://www.ti.com.cn/cn/lit/an/swra482/swra482.pdf  So, I suppose their approach (which can be abstracted from their particular hardware) gives some notion as to one way of doing it.  I definitely do get the impression there are a lot of different ways to skin this particular cat.

[Edit:  http://www.ti.com/lit/an/swra041/swra041.pdf is even more on-point and has some good flowcharts.]
Title: Re: Frequency Hopping
Post by: joelucid on April 16, 2016, 03:53:45 PM
That's a good pointer, thanks. I like how they implement it without time synchronization.  Would work with stock moteinos.

I tested the wdt today for stability and found that when you measure 3 min periods at constant temps the variation is < 6 ms. So it might actually be possible to use it to synchronize nodes. The Rc oscillator of the radio is even more stable and would be great to use. But it requires some modding of the mote.
Title: Re: Frequency Hopping
Post by: perky on April 16, 2016, 06:42:01 PM
It would be interesting to know just how fast a RFM69 could scan channels just looking for a RSSI, given it reportedly takes at least 2 bit periods to get a reliable indication, plus the time to switch channels and any other things like AFC/AGC settling time and SPI. With 50 channels you're looking at at least 12.5 bytes of preamble for the RSSI time alone, and probably many more on top of that for the other overheads. Having said that you can afford a high bit rate as you'll have a lot more power available. It's an interesting idea.
Mark.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 16, 2016, 09:21:57 PM
Some very sloppy math suggests around 4.3ms: 

[50 x ((80us as worst case to lock next channel + (time for 2 bits at 300kbps))]

So, on average, maybe about half that time, or 2.15ms, for it to find it (doesn't account for cases where the transmitter changes channels back to one the receiver had already scanned though, so that the receiver might find nothing even if it searched all 50 channels in a row).

Anyhow, it's possibly  the right order of magnitude. 

Feel free to use a sharper pencil.   ;D

It does drive home the point, though, that frequency hopping probably isn't a great substitute for use in the typical scenario of ultra low power nodes (ones that 99.99% of the time wake up, listen briefly, and then just go back to sleep if they don't hear anything).

[Edit: Nonetheless, for high throughput scenarios and/or scenarios where power consumption is of less concern and/or for higher security and/or scenarios where really long range can't otherwise be obtained, frequency hopping does seem to offer some unique advantages. ]
Title: Re: Frequency Hopping
Post by: joelucid on April 17, 2016, 04:01:54 AM
Quote
Some very sloppy math suggests around 4.3ms: 

[50 x ((80us as worst case to lock next channel + (time for 2 bits at 300kbps))]

Oh it's typically much worse: you'd need the filter delays which add to around 7/rxbw. Plus hopping is particularly interesting with lower bitrates where it would cost much more. So I think the asynchronous method is only a solution for VERY low duty cycle applications (the sewage pit comes to mind).

But if one could really get down to 10ms of accuracy after 3 min with the WDT you could chop time up into 400ms windows, keep 10ms at the beginning and the end unused. Send a 400ms sync beacon at least every 3 minutes and get it to work.

Initial sync would be done by putting the mote into listen mode with a 300ms idle period or so at one frequency. Since the gw broadcasts beacons at changing frequencies they have to meet at some point. How long it takes depends on the interval between beacons sent. Send one every 10 seconds and you'd sync on average in 25 * 10  = 250 seconds (assuming 50 channels) - pretty long to be honest. You would want to have a "join" mode where the gw sends beacons more often than usually for when you add nodes. Simply continuously broadcast beacons and you'd sync on average in 25* 0.4 = 10s.

You could the further subdivide the 400ms into a couple of windows for different BW settings to share one gw. It would all work much more efficiently with an RTC (much less than one sync packet every 3 minutes needed, plus less than 10ms uncertainty). But at a high level it seems even stock Moteinos should be able to participate.

Joe

 
Title: Re: Frequency Hopping
Post by: WhiteHare on April 17, 2016, 06:58:49 AM
Well, if it were truly going to take that long, then I think the argument could be made for having a node book a suitably large appointment window with a secondary gateway and *transmitting* to the gateway on a pre-arranged frequency (that's picked pseudo-randomly and coordinated in advance each time).  The notion is that the secondary gateway would be dedicated to listening just for that particular node during the appointment window, and it could be a very large window because the secondary gateway wouldn't be on batteries.  It changes the paradigm somewhat, but I think it might (?) still fit within the rules.  Since gateways are cheap compared to a pile of lithium batteries, might as well leverage them.   8)
Title: Re: Frequency Hopping
Post by: joelucid on April 17, 2016, 10:26:36 AM
Quote
Well, if it were truly going to take that long, then I think the argument could be made for having a node book a suitably large appointment window with a secondary gateway and *transmitting* to the gateway on a pre-arranged frequency (that's picked pseudo-randomly and coordinated in advance each time).

I think often you don't know in advance when a client will want to talk. You want to enable it to send immediately - say within 500ms. Unfortunately that means either one gw per profile of short windows.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 17, 2016, 02:35:32 PM
Even if I make what seem like overly conservative assumptions, it just doesn't seem to add-up to be all that bad.

Here are what I consider to be some overly conservative assumptions:
1.  It takes 500 microseconds to switch channels.
2.  50 channels are hopped among.
3.  The node wakes up and listens continuously on just one of the channels (doesn't matter which).
4.  The gateway sends out 100 bit frames (a number I picked out of thin air just to be conservative) at 300kbps.
5.  Included in the frame is information on what the next several channels are, in order, that it will jump to.
6.  After sending the frame, the gateway listens on the same channel for a time period of 100 bits to see if it gets a response.  Here again, 100 bits is just a thin-air number picked just to be conservative. 
6.  After jumping to the next channel, the gateway listens for a period of 100 bits for a response from the node.  Again, this is just a thin-air number I picked to be conservative.
7.  If the gateway doesn't detect anything, it switches to Tx mode, sends a 100 bit frame, and hops to the next channel in its schema.

So, on average, to cover all 50 channels, it would take the gateway roughly 50 x [500us + (airtime for 200 bits at 300kbps)], which my back of the envelope says is 58 milliseconds.  Thus, on average, you'd expect it to take half that, or 29ms, for the gateway to connect with the node, right?  And that's using what seems like very conservative numbers as well as a conservative listen strategy for the node.

OK, so now that I've written this down, I see where the flaw is.  It's going to take the node far longer than I've allowed to react to the packet it receives from the gateway once it finally does receive the gateway's packet on the channel it's listening on.  In fact, on first blush, it seems as though that reaction time may well strongly influence how long the process takes, unless maybe the look-ahead on the channel hopping schema is long-enough that it accounts for that delay, and the node can catch up by jumping to the right channel where the gateway is after the node's lengthy reaction delay.  Well, that does seem possible, so maybe it's not so bad after all.   

[Edit: So, conservatively assume the node's reaction time is 4ms.  Then, on average, with these conservative assumptions, the time for the node to sync up with the gateway might be 29+4=33ms.   I'd expect the actual number, without the inflation caused by overly conservative assumptions, to be less than that.  :)

Does that sound about right, or have I left something out? ]

Title: Re: Frequency Hopping
Post by: joelucid on April 17, 2016, 04:29:52 PM
29ms sounds good until you realize that sending the same information on a synchronized frequency hopping net would take less than a ms. Quite a bit of overhead.

In effect your suggestion is to receive 25 packets on average in order to send one. If you instead listen to a sync packet every three minutes and if the clock accuracy is good relative to packet length you'd break even at what 25 * 3 = 75 minute sleep between packets.

So I think the answer is stay in sync of you can.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 17, 2016, 06:13:29 PM
Yes, that does seem like it might be an easy way to compare the asynchronous vs synchronous approaches.  So, if I'm understanding correctly, what that implies is that if the node sends a packet to the gateway on average less often than once every 75 minutes,the sync approach is more energy efficient because the node would on average spend less total time in Rx mode, whereas if the node sends a packet to the gateway on average more often than once every 75 minutes, then the async approach would be more energy efficient.  And if it were 25 channels instead of 50, then the breakeven point would be 37.5 minutes rather than 75 minutes.  Would that be your understanding as well?

Title: Re: Frequency Hopping
Post by: captcha on April 18, 2016, 12:27:54 AM
Is the RFM69 easy to instruct to send/listen on another frequency? If so, what is the available range of frequencies that can be accessed (several kHz? MHz?). Thinking of the channel separation I wonder how far away the channels need to be in order to be 20dB away.
Title: Re: Frequency Hopping
Post by: joelucid on April 18, 2016, 02:27:51 AM
I've seen over the weekend that a number of hopping schemes use a dedicated control channel. That obviously makes things quite a bit easier. A bit hard to argue  that this uses all frequencies equally on average I think. Still.

LoRa for example:

Quote
The frequency hopping transmission and reception process starts at channel 0. The preamble and header are transmitted first on channel 0. At the beginning of each transmission the interrupt the channel counter FhssPresentChannel is incremented and the interrupt signal FhssChangeChannel is generated. The new frequency must then be programmed within the hopping period to ensure it is taken into account for the next hop, the interrupt FhssChangeChannel is then to be cleared by writing a logical 1.

Since it's pretty widely used it might be ok for us to use it too.

I think that'd be pretty easy to do: start each transmission with a short packet on the control channel immediately followed by the real packet on the next hopping channel. Control packet includes index into frequency table, done.

Overhead is just the control packet.
Title: Re: Frequency Hopping
Post by: perky on April 18, 2016, 05:03:22 AM
I thought LoRa used chipping rate that is significantly faster than a single bit, so even though the algorithm may start on channel 0 by the time any message (even the shortest ones) is transmitted it has been spread out over the entire range and hence the 'peak' at channel 0 compared to others is tiny. With the RFM69 we're talking of hopping frequencies in the order of many bytes, so if we used that algorithm that would end up with very high peaks at channel 0. According to the 915MHz rules that's not allowed.
Mark.
Title: Re: Frequency Hopping
Post by: joelucid on April 18, 2016, 05:23:46 AM
Quote
I thought LoRa used chipping rate that is significantly faster than a single bit, so even though the algorithm may start on channel 0 by the time any message (even the shortest ones) is transmitted it has been spread out over the entire range and hence the 'peak' at channel 0 compared to others is tiny. With the RFM69 we're talking of hopping frequencies in the order of many bytes, so if we used that algorithm that would end up with very high peaks at channel 0. According to the 915MHz rules that's not allowed.

No, the entire header is sent on channel 0. That includes 12 symbols preamble, packet length, header CRC, forward error correction code rate. Even with implicit header mode its still typically 12 symbols preamble.

I think if only the tiny sync packet is sent on the predefined channel and everything else equally distributed across all other channels it would be very close to what lora does. We could switch AGC off (doesn't do any good in the current implementation anyway), switch to 1 byte preamble, 1 byte sync word, 1 byte table index, no crc for the control channel.

That's 4 bytes  on the control channel. If average packet length on the other channels is 40 bytes plus 3 bytes preamble, 2 bytes sync word, 2 bytes CRC = 47 bytes, you get 4 / 50th of all traffic on the control channel. Pretty close to even. 
Title: Re: Frequency Hopping
Post by: perky on April 18, 2016, 06:40:49 AM
Mmm, not sure a typical system (especially battery operated nodes) will be transmitting 40 byte packets. The larger the packet size the more evenly it would be ditributed assuming a micro packet for the control. It may come down to the definition of 'evenly distributed' as to what might be allowed.
Edit: I'm wary of systems that use pre-defined channels for control things anyway, it's not particularly robust if that channel happens to be blocked by something.
Mark.
Title: Re: Frequency Hopping
Post by: joelucid on April 18, 2016, 08:16:31 AM
The jammed channel concern is valid.

I don't think the average channel occupancy one is: if the control channel is underoccupied compared to the others I'd happily have the gw blast some additional noise regularly on it. Similarly the gateway could pollute the other channels if that's really what the fcc wants  :)
Title: Re: Frequency Hopping
Post by: WhiteHare on April 18, 2016, 08:18:32 AM
I'm imagining that on a waterfall graph, that such a control channel would stand out as being persistently different from the other channels.  i.e. From that perspective, I think it would be hard to argue that the algorithm is"pseudo-random."   

Nonetheless, if there are known precedents where it is allowed, then maybe their definition of pseudo-random is more pseudo than random.   ::)
Title: Re: Frequency Hopping
Post by: joelucid on April 18, 2016, 08:38:57 AM
Quote
I'm imagining that on a waterfall graph, that such a control channel would stand out as being persistently different from the other channels.  i.e. From that perspective, I think it would be hard to argue that the algorithm is"pseudo-random."

Yeah - given that LoRa does it this way I think it's unlikely this would be an issue. If need be however one could change the control channel at a slower pace - say once an hour - based on a random sequence. Certainly makes the sync problem MUCH easier than keeping within a couple of ms.

 
Title: Re: Frequency Hopping
Post by: SadE54 on April 19, 2016, 03:18:58 AM
Using control channels seems non sense to me for a hopping system , from a security point tof view. I think the channel hopping has to be purely time related. there's already used system to sync nodes / gateway . The question is if it's possible with moteino constraints. A 16 bits counter seems not enough. A 32 bits one could be emulated, sure, but at 1Mhz , moteino will be awaken every 65ms to manage it.I guess a Cortex M0 will be OK for this type of application :)
By the way , LORa is already spread spectrum, harder to jam. The RFM module is just lacking AES :-/
Title: Re: Frequency Hopping
Post by: joelucid on April 19, 2016, 03:55:10 AM
Quote
Using control channels seems non sense to me for a hopping system , from a security point tof view. I think the channel hopping has to be purely time related. there's already used system to sync nodes / gateway . The question is if it's possible with moteino constraints. A 16 bits counter seems not enough. A 32 bits one could be emulated, sure, but at 1Mhz , moteino will be awaken every 65ms to manage it.I guess a Cortex M0 will be OK for this type of application :)
By the way , LORa is already spread spectrum, harder to jam. The RFM module is just lacking AES :-/

If your motivation is security - sure. I think for most Moteino users the primary motivation to consider frequency hopping is being able to legally operate their motes at full power though. Particularly if you've built a prototype and now want to start selling it.

BTW the RFM69 does do AES. 16 bit is not an issue here. Not having an RTC is one if you want to sync your nodes (nothing to count :-( ). As I've said the WDT could get you ~10ms sync if you sync every 3 minutes.
Title: Re: Frequency Hopping
Post by: SadE54 on April 19, 2016, 04:16:30 AM
For AES , I was talking about the lack of AES on the Lora RFM9x modules  ;)
And you're right the solution is depending of the objective here.
Mine is to develop an open source/hardware secured RF module for home security.
Title: Re: Frequency Hopping
Post by: perky on April 19, 2016, 04:52:15 AM
I'm not sure the WDT is accurate enough for any timing purpose like this, it's clock just isn't designed for accuracy. You may have measured some and found it to be useful, but it isn't specified to the accuracy you want so the actual variation across multiple processors over temperature and voltage may well be too great to make it useful. I'd much prefer to use a low power 10ppm watch crystal, the xmega parts like the atxmea8E5 can run those for about a microamp or so.
Mark.
Edit: Maybe a Moteino based on an atxmega8E5 and a 32.768kHz crystal would be a nice thing to have.. ;-)
Title: Re: Frequency Hopping
Post by: joelucid on April 19, 2016, 06:02:27 AM
Quote
I'm not sure the WDT is accurate enough for any timing purpose like this, it's clock just isn't designed for accuracy. You may have measured some and found it to be useful, but it isn't specified to the accuracy you want so the actual variation across multiple processors over temperature and voltage may well be too great to make it useful. I'd much prefer to use a low power 10ppm watch crystal, the xmega parts like the atxmea8E5 can run those for about a microamp or so.

Agreed. It's a crutch at best. The 328p also runs a 32.768khz crystal at <1uA btw. Or then maybe splurge and add an am1815. Anyway i think the control channel approach is probably preferable to wdt timing to support freq hopping on unmodded Moteinos.
Title: Re: Frequency Hopping
Post by: executivul on April 19, 2016, 07:05:57 AM
For all of you interested in frequency hopping maybe the openLRSng may be of some interest: https://github.com/openLRSng/openLRSng it's mainly used with different radio modules for long range rc planes/quadcopters, but the receivers look alot like moteinos 328p+rfm :)
Title: Re: Frequency Hopping
Post by: SadE54 on April 19, 2016, 07:40:03 AM
For all of you interested in frequency hopping maybe the openLRSng may be of some interest: https://github.com/openLRSng/openLRSng it's mainly used with different radio modules for long range rc planes/quadcopters, but the receivers look alot like moteinos 328p+rfm :)

The hopping scheme is ok for 1 TX and 1 RX , but in the case of a star network , it cannot be used .
Anyway , nice project for RC :)
Title: Re: Frequency Hopping
Post by: WhiteHare on April 19, 2016, 10:41:17 AM
For all of you interested in frequency hopping maybe the openLRSng may be of some interest: https://github.com/openLRSng/openLRSng it's mainly used with different radio modules for long range rc planes/quadcopters, but the receivers look alot like moteinos 328p+rfm :)
but in the case of a star network , it cannot be used .

Really?  Why do you say that?
Title: Re: Frequency Hopping
Post by: SadE54 on April 19, 2016, 11:10:54 AM
The RX need to be bound the TX . Rx is listening on a a full hopping cycle on a random channel . When it get a frame from the TX the link is bound and from now RX and TX are using fast sync and channel is changing every frame. If a frame is lost or no ack received , a new sync cycle is done. I don't see how the RX could be bound with several TX at the same time  ???
Title: Re: Frequency Hopping
Post by: perky on April 19, 2016, 11:20:32 AM
It could if the server sends a node address in each packet. The server would always send a packet and look for a response from the addressed node, the node would only send a response if it was addressed. The polling time for a node (rate at which data is sent to the server) would be equal to the number of nodes times the delay between each packet.
Mark.
Title: Re: Frequency Hopping
Post by: SadE54 on April 19, 2016, 11:30:40 AM
It could if the server sends a node address in each packet. The server would always send a packet and look for a response from the addressed node, the node would only send a response if it was addressed. The polling time for a node (rate at which data is sent to the server) would be equal to the number of nodes times the delay between each packet.
Mark.

OK but it's limited to specific networks where power saving is not the priority. In case of sleeping nodes that just have to wake to send and event to gateway , I guess it could be difficult to implement
Title: Re: Frequency Hopping
Post by: WhiteHare on April 19, 2016, 11:44:24 AM
I'm not sure the WDT is accurate enough for any timing purpose like this, it's clock just isn't designed for accuracy. You may have measured some and found it to be useful, but it isn't specified to the accuracy you want so the actual variation across multiple processors over temperature and voltage may well be too great to make it useful. I'd much prefer to use a low power 10ppm watch crystal, the xmega parts like the atxmea8E5 can run those for about a microamp or so.
Mark.
Edit: Maybe a Moteino based on an atxmega8E5 and a 32.768kHz crystal would be a nice thing to have.. ;-)

Related, but somewhat tangential to this, I've been looking for  RTC's that 1. have a built in TCXO, 2. can be soldered by hand, and 3. are on the low-end of current consumption.  What I arrived at was NXP's PCF2129T, which claims to have a 3ppm clock over a wide temperature range.  I would have liked to use a DS3231, which claims a 2ppm clock over a narrower range, but it appears to be much more of a power hog.  So, I plan to put a DS3231 on a gateway and the PCF2129T on a battery operated node.  Yesterday I ordered a PCF2129T to give it a try.  The price on mouser was $3.10.  I liked that the TCXO is built in and the whole RTC is pretty much self-contained.   That said, if anyone is aware of a better choice that meets the same criteria, please post a head's up  before I get too far down the road with this.

Title: Re: Frequency Hopping
Post by: perky on April 19, 2016, 01:45:33 PM
Phew, what's the current consumption of a TXCO? It's got a heater in it, right?
Edit: scrub that, got confused with OXCOs.. Doh.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 19, 2016, 02:35:39 PM
The answer seems to heavily depend on which TCXO.  However, as just one datapoint, the the PCF2129 has a "Low supply current: typical 0.70 μA at VDD = 3.3 V" (http://www.nxp.com/products/interface-and-connectivity/interface-and-system-management/real-time-clocks/rtcs-with-temperature-compensation/accurate-rtc-with-integrated-quartz-crystal-for-industrial-applications:PCF2129),  and so I'm guessing its integrated TCXO is probably a large chunk of that (maybe somewhere in the 400-600na range?).

I ordered just one primarily  to convince myself that it really is 700na so that I don't fall prey to possible misleading marketing spin.  If it tests out at the advertised 700na, then I'm fine with that, and I may order more.  The AT version of the chip, which has somewhat weaker specs than the T version, can be had for under $2 each on AliExpress if you buy 10 or more.
Title: Re: Frequency Hopping
Post by: SadE54 on April 20, 2016, 02:31:52 AM
Nice found for PCF2129T
I really like the timestamp features on pin input . It's to bad there's no timestamping with the internal counter but time (and with 1s resolution) :-/ It could have been used for precise time sync.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 20, 2016, 07:23:32 AM
Nice found for PCF2129T
I really like the timestamp features on pin input . It's to bad there's no timestamping with the internal counter but time (and with 1s resolution) :-/ It could have been used for precise time sync.

Agreed! As far as I'm concerned, a 32-bit binary timestamp with microsecond resolution would be preferable.  I don't really care about leap-year or days of the week or what month it is, so is there a better category than RTC to look in that would have an integrated TCXO?
Title: Re: Frequency Hopping
Post by: WhiteHare on April 20, 2016, 08:58:07 AM
So, the ideal might be what's called a "real-time timer" instead of a "real-time clock".  The Arduino Due has a 32-bit RTT driven by a 32Khz signal.  I guess I'll end up building what amounts to a virtual RTT (of sorts) from an RTC chip. 
Title: Re: Frequency Hopping
Post by: SadE54 on April 20, 2016, 09:13:56 AM
Maybe a mcu like lpc800 , low pin , low power Cortex M0 could be programmed as a RTT ?
It can count in deep sleep mode , waking up on interrupt from moteino ?
Title: Re: Frequency Hopping
Post by: WhiteHare on April 20, 2016, 03:48:30 PM
Ideally, from my perspective, the clock would be a 32 or 64 bit binary counter I could  simply read and/or write directly, with each oscillation of a 1Mhz+ crystal adding one to the count, but even with an RTC it's still far from that, because they are all mostly 1 second resolution!  So, at best, they can pump out faster square waves into the atmega328p's rather short timers, but converting that to the virtualized ideal clock equivalent, while remaining highly energy efficient,  seems nowhere near as straightforward as it should be.
Title: Re: Frequency Hopping
Post by: joelucid on April 20, 2016, 04:00:53 PM
I don't think you'll find an ultra low power 1mhz oscillator. There's a reason rtcs run at slow clock speeds. The am1805 gives you a 1/100th s resolution time. Plus it has a 4096hz countdown timer which you can use in combination with the regular clock to create a 250us resolution timer. That's plenty for frequency hopping. At 55nA.
Title: Re: Frequency Hopping
Post by: joelucid on April 21, 2016, 02:04:52 AM
BTW, I think a tcxo is overkill. I actually looked a bit yesterday because I'm planning to put a temp sensor on the GW for temp compensation of the radio crystal. So I thought if I can find a cheap tcxo that would allow me to read the temperature out, that might be a better use of board space than a separate temp sensor.

But all tcxo rtc's I could find either couldn't read out the temp or were too big or too expensive or all 3 of these ...

I think since you're syncing with a server anyway and have an (albeit uncalibrated) temp sensor on the radio you should just use a regular RTC and build up a temp compensation table in EEPROM at runtime. Cheaper, smaller, more accurate, better.
Title: Re: Frequency Hopping
Post by: WhiteHare on April 21, 2016, 10:37:38 AM
That's a good idea. but it trades something that's already been fully characterized for something with lower specs.  Either way, it looks like it will be challenging to get and maintain a tight time sync.  The PCF2129T gives me a little extra confidence that if it works well at the test condition temperatures, it will work well at the other temperatures too.  You're right, though, that by itself may not be enough to fully justify it. 

If anything, I'm concerned it may be underkill and that with or without it I may have to settle for a somewhat loosey-goosey time sync, not a spot-on time sync like I was hoping for.  So far, how close together are you able to maintain your time sync?  Within Microseconds?  Milliseconds?
Title: Re: Frequency Hopping
Post by: joelucid on April 23, 2016, 06:49:36 AM
Quote
So far, how close together are you able to maintain your time sync?  Within Microseconds?  Milliseconds?

With the am1815 within a 1ms with a sync packet about every 10 minutes. That's without temp compensation, just frequently recalibrating the RTC.

But frankly I'd like something that works with stock moteinos. Or simple 328p + rfm69 module boards.

I've been testing the rc oscillator of the radio as timing source. It's more stable than the wdt. At the same temperature readings 5 minutes apart come out within 6ms. It does vary quite a bit with temperature and I'm sure vcc as well. There's also the challenge that it is auto calibrated by the radio on startup. That calibration is bad enough not to be useful, but hurts if you want to do your own.

But if you could compensate for current temperature, then adjust for any calibration the radio might have done on startup, I think it's not completely unreasonable to hope you can keep all nodes within 10ms of the gateway at 5 min syncs. It would require using listen mode as timer unless one wants to mod the moteino. You would sync more frequently initially when building up your calibration tables.

If that works it would allow a grand unified approach: listen mode, frequency hopping, multiple bitrate coexistence all 'legit' and using the existing hardware. Supported by a super low noise wifi gw that might double your current range (or halve your energy expenditure). Managed by an extension of ATC that tunes not only transfer power, but also choses the best bitrate/tx power available for a node.

Joe
Title: Re: Frequency Hopping
Post by: joelucid on April 25, 2016, 05:28:50 AM
Quote
If that works it would allow a grand unified approach: listen mode, frequency hopping, multiple bitrate coexistence all 'legit' and using the existing hardware.

It wasn't that easy since listen mode only has a resolution of 4.2ms at the > 1s range. With that granularity any clock differences quickly add up to intolerably large amounts of time. But I think I've figured out a scheme to make all of this work with stock Moteinos:

The key is not to calibrate the clients to the server, but the server to the clients: When a listen mode client joins the network it sends two requests to the gw (hopping appropriately via control channel), separated by one well defined listen mode period (say 10s). The server measures that interval using its crystal and can derive when the client will listen in the future.

When the server wants to send something it no longer needs to blast a burst for 3s. It will know with some accuracy (100ms at worst I would think) when the client will come online and can then deliver the packet using a 100ms burst. The client acks back together with any payload it might have for the server, plus frequency band and bitrate settings it will be listening at in the future (giving the client control over frequency hopping as well as bitrate optimization).

Gw acks the client ack. If received the client goes back into listen mode. Otherwise it reestablishes the connection as in the beginning. If the client notices a large temperature shift or if it doesn't receive a regular heartbeat (say every 5 minutes) from the gw it also reestablishes the connection.

AC powered clients use a less complicated version of the same scheme, telling the server at which frequency and with what bitrate they're listening and reestablishing via control channel if the connection is lost. They will be in rx at all times and can do without the listen mode synchronization. The gw will poll them regularly nonetheless to allow all communication to occur at the optimal bitrate. If they spontaneously want to send to the gw they will need to go via the control channel.

In addition to being legit via frequency hopping and saving power/air time by using adaptive bitrates this scheme has another huge advantage: it allows the use of client optimized listen periods. So if you need 300ms latency for some client and can afford the battery hit you can just configure that client for a 300ms listen period. Or if you want your listen period to be 1 minute that is now also possible: it no longer requires a 1 minute burst to wake that client.

I think this will work fine as long as the control channel isn't too slow. E.g. I could see the control channel running at 19200 baud. If you want to go down to 1200 baud for extreme range I think it would be best to just add a second gateway since you don't want to burden esp coin cell nodes with long duration control packets - even if it's only while establishing a connection.

Joe
   
Title: Re: Frequency Hopping
Post by: joelucid on April 25, 2016, 05:38:58 AM
Quote
I think this will work fine as long as the control channel isn't too slow. E.g. I could see the control channel running at 19200 baud. If you want to go down to 1200 baud for extreme range I think it would be best to just add a second gateway since you don't want to burden esp coin cell nodes with long duration control packets - even if it's only while establishing a connection.

Ha! New idea: if you have an AC powered node that does not need frequent communication (the garage controller comes to mind) you can run that at 1200 baud and use it to relay any packets from 1200 baud clients to the server at the control channel.

Only requirement is you have to add a thermometer for temp frequency compensation. The gateway will have a thermometer on board - so maybe it's still best to just add a second gateway.
Title: Re: Frequency Hopping
Post by: drachenminister on July 29, 2016, 03:06:24 AM
Stumbled across this thread and i think this Semtech Application Note might be of interrest:

http://www.semtech.com/apps/filedown/down.php?file=an1231_wsn-fhss.pdf (http://www.semtech.com/apps/filedown/down.php?file=an1231_wsn-fhss.pdf)

They even mention a ZIP file containing code for a generic implementation.
Title: Re: Frequency Hopping
Post by: raggedyanne on October 01, 2016, 10:12:15 AM
Because i rolled my own library & i don't want to share it  ??? Here is a untested software example;
Code: [Select]
byte ack[1]{'#'};
byte rcv[1];
bool coNNected = false;
int x;
int channelS[20] {920250, 922750, 919000, 923500, 925000, 918000, 925500, 922500, 918500, 925250, 920000, 922000, 921000, 919500, 926000, 921500, 924000, 923000, 920500, 924500};

void loop() {
//read sensors , build data array

  while (!coNNected) {
    fixChannel();
  }
coNNected = false;

//go to sleep
}

void fixChannel() {
  monteino.Initialize();
  monteino.Standby();
  monteino.SendMessage(ack, 1);
  monteino.Rx();
  delay(100);
  if (monteino.GetMessage(rcv) != '#') {
    x++;
    if (x > 19) {
      x = 0;
    }
    monteino.Frequency = channelS[x];
  } else {
    coNNected = true;
    x++;
    monteino.Frequency = channelS[x];
    monteino.Initialize();
    monteino.Standby();
    monteino.SendMessage(data, 4);
  }
}