Frequency Hopping 900MHz -- Noise Floor Mitigation and Algorithim Design

Question

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?

Answer 1

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

Answer 2

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.