Author Topic: Frequency Hopping  (Read 90819 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Frequency Hopping
« Reply #15 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? ]

« Last Edit: April 17, 2016, 03:04:41 PM by WhiteHare »

joelucid

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

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Frequency Hopping
« Reply #17 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?


captcha

  • Full Member
  • ***
  • Posts: 108
  • Country: au
Re: Frequency Hopping
« Reply #18 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.

joelucid

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

perky

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

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Frequency Hopping
« Reply #21 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. 
« Last Edit: April 18, 2016, 05:33:35 AM by joelucid »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Frequency Hopping
« Reply #22 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.
« Last Edit: April 18, 2016, 06:45:26 AM by perky »

joelucid

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

WhiteHare

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

joelucid

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

 

SadE54

  • NewMember
  • *
  • Posts: 36
Re: Frequency Hopping
« Reply #26 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 :-/

joelucid

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

SadE54

  • NewMember
  • *
  • Posts: 36
Re: Frequency Hopping
« Reply #28 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.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Frequency Hopping
« Reply #29 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.. ;-)
« Last Edit: April 19, 2016, 04:55:06 AM by perky »