Frequency hopping radio device

I’m building a wireless device and I need to use a high power to get a long range. Apparently one of the ways to do this is implement frequency hopping which allows the power to be increased up to 1 watt. I was wondering if anybody on this board has tried to implement a frequency hopping device with success and can offer any words of wisdom.

The FCC regulations require the device to use a minimum of 75 frequencies, hop in a random order with equal weight for each channel, and spend at most 0.4 seconds without hopping.

This is what I have so far:

I’ve divided time into frames of .1 seconds. Each frame has a magic pattern to indentify the start of the frame, a checksum, and a timestamp(frame number). The transmitter hops frequencies at the end of each frame. The frequency is determied by a hardcoded table that both the transmitter and receiver have. The current slot in the frequency table is the frame number mod table size. As the receiver receives valid frames, it uses the frame number to determin the transmitters current position in the table and uses the next table entry to find the next frequency. A timer is set on the receiver after receiving a valid frame. If the next frame is not received before the timer fires, the frequency table pointer is moved. This allows the receiver to sometimes loose frames due to interference and still stay in sync with the transmitter. If too many consecutive frames are missed, the receiver gives up assuming too much interference or that the transmitter has been turned off. I have all of this implemented and working.

The problem I’m hitting is getting the receiver to sync up with the transmitter at power up within a reasonable period of time. Here are two stratagies I’ve tried with various degrees of success.

  1. Pick a random frequency and simply stay on that frequency until the transmitter randomly decides to use it. If a valid frame isn’t detected for a long period of time, pick a different random frequency because that perticular channel may have alot of interference. Since the transmitter is using each frequency with equal weight it takes on average 1/2number of channels * frame length to sync. In my case, this is 1/2.1*75 = 3.75 seconds. This is too long and the only way out that I can see is shorten the frame length. I think to do this either requires using a higher bitrate or decreasing the number of bytes per frame.

  2. The second option I’ve considered is to have the transmitter send multiple frames on the same frequency before hopping. The receiver can actively try to scan the airwaves to find the transmitter. I was thinking first find the signal strength of each frequency and try the stronger channels first. The problem I’ve hit with this approach is that the transmitter needs to stay on the same channel long enough for the receiver to find it, which quickly hits the .4 second limit.

Anybody have any words of wisdom?

Freq. hopping for longer range - you must be talking about the FCC regulations that may allow higher power in unlicensed 900MHz for freq. hoppers. MaxStream makes a number of such radios. They’re in the order of $150ea and can be used with yagis. I have gotten 6 miles line of sight with these. The radios I speak of do the hopping all transparent to the application - buffering, etc. is all automatic.

You can, I think legally, get 1 mile with $20 radios like the MaxStream XBeePro- 60mW, and get the module that has an antenna coax connector. Connect this to a high gain 2.4GHz antenna (at each end), assuming each end is not a mobile and that you can get elevated antennas and a near line of sight path.

Perhaps you could buffer the specific frequencies of the next 3 hops at master, and send out a packet containing those hops every so often, so the receiver can anticipate the transmitters next moves, and meet or beat it there to establish some sort of synchronization?

are you building your own MAC layer for the educational benefit of doing so?

Actually, I didn’t know about the XBeePro modules. When I did a search in the past for similar devices with long range, all I found where big bulky units in the hundredes of dollars range that were more designed for connecting PC equiptment together. The XBeePro looks like a good fit for what I’m trying to do and the price is surprisingly low. Sounds like I should buy a few of them and test them out.

the MaxStream XBeePro is one of perhaps a dozen IEEE 802.15.4 modules on the market. Most are just 1mW; the XbeePro and a few others are 50mW or more. Check out the prior discussions here on ZigBee, and on the Internet. Most ZigBee stuff is 100ft range meshed networking, but with or without the use of the ZigBee network layer protocols, the MAC and PHY under ZigBee, 802.15.4, at 60mW, does a good job at 250Kbps air link bit rate (like 80Kbps net yield) even at poor signal to noise. For long path lengths, you may want to choose a module with a coax connector allowing you to use 10dB or more gain antennas for ther 2.4GHz band.

There are a few 902-928MHz (No. America) 802.15.4 modules on the market but I’ve not seen any with more than 1mW.

Do you know if 2.4GHz has a smaller range then 900MHz given the same amount of power? I was told that the power requirements increase as the frequency is increased. I’m currently using 900MHz equiptment, and I was under the impression that 2.4GHz is used because the antanna is smaller and the frequency range is larger resulting in less crowding.

I’ll do a search for Zigbee modules. I have a slight preference for something with a I2C or a SPI interface but NRZ serial is doable.

Thanks for all your help. This was a big help.

yes, lower freq = longer range for same radiated power, in free space. In non-line-of-sight, sometimes 2.4GHz propagates better than 900MHz. Sometimes not; depends on what the obstructions are.

I suggest that you choose radios based on ease of use and ability to network one-to-many/meshing rather than the interface. Most 802.15.4/ZigBee modules use a 3.3v logic level asynch. serial interface. This is because they are transparent serial port extensions.