Author Topic: Frequency Hopping  (Read 16523 times)

SadE54

  • Newbie
  • *
  • Posts: 36
Frequency Hopping
« 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.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Frequency Hopping
« Reply #1 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.

SadE54

  • Newbie
  • *
  • Posts: 36
Re: Frequency Hopping
« Reply #2 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 !  :-\

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Frequency Hopping
« Reply #3 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. 
« Last Edit: April 16, 2016, 01:16:13 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Frequency Hopping
« Reply #4 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.)
« Last Edit: April 15, 2016, 07:08:51 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Frequency Hopping
« Reply #5 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.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Frequency Hopping
« Reply #6 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.
« Last Edit: April 16, 2016, 01:20:44 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Frequency Hopping
« Reply #7 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
.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Frequency Hopping
« Reply #8 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.]
« Last Edit: April 16, 2016, 03:03:31 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Frequency Hopping
« Reply #9 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.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Frequency Hopping
« Reply #10 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.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Frequency Hopping
« Reply #11 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. ]
« Last Edit: April 16, 2016, 11:39:30 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Frequency Hopping
« Reply #12 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

 

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Frequency Hopping
« Reply #13 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)

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Frequency Hopping
« Reply #14 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.