# Frequency Hopping 900MHz — Noise Floor Mitigation and Algorithim Design

I've built a few baremetal fixed frequency RF systems, and am working on a long range frequency hopping product using a ARM Cortex M3. So we got some horsepower here!

I've got the the TX FCC Part 15.247 compliant hopping across 60 channels and using an extremely narrowband signal to hit our range requirements. Average message time is 190ms (~50ms pre-amble, 140ms sync word + packet).

Product market is USA, so everything is being done to be FCC compliant.

It's an odd system because the goal is to simply deliver one single packet and take advantage of the increased transmit limit.

If the system were more bursty, I would just start on Hopping Channel 1, and go through all 60. But we have a very tight latency requirement.

We need the system to respond within 300ms of a transmit. If we loop through all 60 channels, that takes nearly 10 seconds. If we change the bit rate, we won't hit our distance.

I've got the RX cycling ~800us per channel to an asynchronous scan of all 60 channel, taking an RSSI read, and than dwelling on the strongest channel.

On my desktop, I'm getting about 80% of the packets through.

I did some more digging, and it seems like I am getting a lot of ambient noise in the 900MHz range that trips up my detector.

I added an RSSI limit, and that improved the system to about 90% of the packets.

But this is simply on my desktop! From my experience I know this system isn't going to go far, this narrowband signal blends into the noise floor quickly but somehow the receiver is so sensitive it goes quite far (800 meters +).

I have thought about averaging the noise floor which might help (take your pick simple moving average or something more microcontroller friendly [I'm more of an 8 bit guy, so I have to see if the M3 really needs an MCU friendly scheme).

System mechanical really are one unit is TX, and one is the RX. So I haven't really digested a re-transmission scheme yet. The latency timing probably wouldn't work from a user perspective either.

Has anyone tackled a frequency hopping scheme like this? Any ideas how to mitigate the amount of 900MHz noise out there but still get our signal through?

• I like your enhusiasm (M3 = quite some horsepower); keep that up! :) What do you mean with "increased transmit limit"? – Marcus Müller Aug 5 '18 at 15:57
• FCC Part 15.247 allows up to 1 watt of transmit (at the antenna port) for frequency hopping applications with 50+ channels. Odd American regulatory quirk, so you end up having to create this crazy systems. I'm usually banging out consumer RF stuff on an 8051 -- M3 is a Ferrari to me! ;) – Leroy105 Aug 5 '18 at 16:00
• I think you don't need to frequency hop, by the way. The wording is: "limited to frequency hopping and digitally modulated systems" (emphasis mine); so the 1W applies to analog frequency hopping systems (yes, these exist – I had a PAL-style consumer CCTV transmitter that frequency hopped in the blanking periods, IIRC) AND to digital modulation, if I interpret this correctly. So, since your system does digital modulation, you'd already be allowed 1W? – Marcus Müller Aug 5 '18 at 16:05
• § 15.247 (b) (3) supports my interpretation, by the way. – Marcus Müller Aug 5 '18 at 16:06
• LORA slews across a fairly wide range of frequencies inside a single symbol so it is very tolerant of narrow band interference. It is a narrow carrier from an instantaneous perspective, but pretty wide across a symbol (particularly at low symbol rates). Correlation across the symbol helps mitigate broadband noise floor issues. – Dean Franks Aug 5 '18 at 17:17

## 2 Answers

You can send a short packet on a beacon frequency once a second or so and hop through the other 59 frequencies with payload on a predetermined schedule. The short beacon packet has the current position in the hopping sequence.

If you want to implement a "cognitive" system, you can look at the noise floor across all frequencies on the main transceiver and send a mask indicating which frequencies will be used in the hopping sequence in the beacon frame (you will need more than 60 total frequencies so you can skip high noise channels).

This scheme requires the use of a single, unchanging beacon frequency, but you can design the system to have secondary beacons on a variable frequency in the hop sequence. This will give you one second lock-on as remote transceivers are connected to the network and no additional latency for transmitting once you have acquired the sequence.

If you have multiple transceivers and need to allocate timeslots for remote transmission you'll have to design this into your protocol. If you provide information in your question on the number of transceivers, frequency of packets, etc I can refine this answer to your particular situation.

If you are occasionally sending a single packet from/between a large number of remote stations, LORA is probably a better solution than building something from scratch. LORA has an extremely high link budget, so you will probably be able to meet your range goals without going over the 250mW regulatory threshold and using external PAs on your transceivers. In a suburban (high noise floor) environment we achieved >1 mile range (LOS) with Semtech LORA transceivers without external PA (but with a decent antenna on each end). Note that some of the Chinese LORA boards are terrible (mostly low tolerance crystals, but also generally bad RF layout).

• Dean, that's a good suggestion. I know this answer comes from experience, I'm sure. I've thought of an "advertising" channel type approach with the sequence. The math to hit the FCC rules I gotta work on it. No more than 400ms per channel, per 20 seconds. We need to make sure the advertising channel isn't overused in some way. I'm working on some RSSI poll-voting software right now. The bit rates are kind of fixed out of the transceiver in question. LORA would be ideal but the RX current consumption is too high for the product in mind. FH is a real PITA. – Leroy105 Aug 5 '18 at 17:17
• hm, LoRa is a constant envelope thing. So, if you need that link budget, I doubt you can use much less power... – Marcus Müller Aug 5 '18 at 17:19
• Second real limit is we are stuck with this low-symbol rate to hit the distance requirement. If we could speed up the symbol rate, this exercise would get easier. – Leroy105 Aug 5 '18 at 17:19
• LoRa does couple of km without problems. Using an OOK transceiver like the SX1211 on the other hand, you're probably wasting precious SNR. – Marcus Müller Aug 5 '18 at 17:20
• You can deal with the 400ms per 20 seconds by keeping the beacon frames shorter than the normal payload frames. We implemented a fully TDMA system with dynamic time slot scheduling and one hop per time slot. This system was not subject to FCC rules, but it would have been compliant if it stayed within the ISM band. – Dean Franks Aug 5 '18 at 17:27

Quick calculation:

Free space path loss at f=900 MHz for d=1 km in dB:

\begin{align} a(d,f) & = 20\log_{10}(d)+ 20\log_{10}(f) +20\log_{10}\frac{4\pi}{c}\\ & = 20\log_{10}(10^3)+ 20\log_{10}(9\cdot10^8) +20\log_{10}\frac{4\pi}{3\cdot10^8}\\ &=60+ 160 +20\log_{10}9 +20 \log_{10}\frac{4\pi}{3} - 160\\ &\approx 92 \end{align}

Compare the sensitivities of less spartanic OOK transceivers than the SX1211; something like GFSK is way cleverer than OOK, here, because probability of detection and false alarm are just not on your side when using OOK in an AWGN channel with uncertainty about noise floor. Much, much less even in a Rayleigh channel.

So, the solution here really isn't smart estimation of the noise floor – it's using something less prone to noise than OOK.

Since you said you're happy that you have a proper ARM Cortex-M3 at hand, I did a quick check at the "usual suspects" when it comes to producing ARM MCUs with integrated RF frontend.

SILabs has the rather interesting Flex Gecko family:

https://www.silabs.com/products/wireless/proprietary/efr32-flex-gecko-2-4-ghz-sub-ghz

which can talk multiple bands at once, but really, we only care for 900 MHz, right? (If you run the same numbers as above for 2.4 GHz, you'll notice that you could even use that if you have more than 0 dBm TX power, and you do have that with these chips.)

So, what do they promise for 900 MHz?

-126.2 dBm @600 bps, GFSK, 916 MHz

Sounds a lot like your application, right?

So, does that work out in our scenario?

Ok, let's consult the datasheet (p. 54) about TX powers:

Maximum TX Power

• PAVDD connected directly to external 3.3V supply, 20 dBm output power setting: $POUT_\text{max, minimal specified}=18\,\text{dBm}$
• PAVDD connected to DC-DC output, 14 dBm output power setting: $POUT_\text{max, minimal specified}=12.6\,\text{dBm}$

So, because we're grumpy and know that matching circuitry is more exhausting that it should be, we just say: Ok, we emit 10 dBm.

With a TX power of 10 dBm (I think you can do that much without hopping, but I'm not in FCC-land), you'd still receive -82 dBm.

That's (-82)-(-126) dB = 44 dB above sensitivity.

I'd call that a reliable buffer against fading.

So, call off your hopping efforts. Just use an ARM microcontroller that integrates the frontend and can do a little more than OOK.

• +1 -- I'd really have to demo the IC. What I've noticed with these systems is that the bit-rate and modulation of the signal is a huge driver in the range. A 50kbps 2-GFSK, is like 1/10th the distance of this 625bps FSK-2 signal. It's way outside my paygrade to ascertain why the radios work like this, but it's pretty very suprising. – Leroy105 Aug 5 '18 at 17:46
• Also, that Gecko part has an FCC compliant DSSS mode so you can use the 1 watt per FCC 15.247. But I'd bet you'd find it works at a longer range with a narrowband hopping signal. Low bit rate and narrow signals just go insanely far at 900MHz. Too bad you have to go through all the acrobatics to hop with them. – Leroy105 Aug 5 '18 at 17:49
• @Leroy105 well, the more bits per second you send with a constant output power, the less energy per bit you get. That energy is what determines the amplitude relation between signal and noise! – Marcus Müller Aug 5 '18 at 17:53
• Well, frequency hopping systems should really be hopping within one packet (see, for example, GSM), unlike your system, which IMHO isn't a frequency-hopping, but a transmit diversity system in frequency direction. Doing intra-packet hopping however requires complicated time synchronization, so it's something you need to do in hardware. – Marcus Müller Aug 5 '18 at 17:54
• I think you folks get much better treatment under CE RED over in the continent. ;) – Leroy105 Aug 5 '18 at 17:55