Futaba S-FHSS Protocol Overview

In order to analyse the Futaba R3006SB RF Architecture, I needed to know the data rate so I could estimate receiver sensitivity. This led me to the C source code for the Devo implementation of S-FHSS. Since not everyone reads C, I thought I would summarise what I learned about the S-FHSS protocol from this excellent resource, read in conjunction with the CC2500 datasheet.

Protocol Description

An S-FHSS transmission consists of multiple hops, with adjacent hops being on different frequencies. Each hop consists of one or more packets. Each packet consists of the following fields:

1. A 32-bit preamble which consists of alternating “0” and “1” bits and is used to synchronise the receiver clock.
2. A 16-bit synchronisation word with the value 0xd391). This is used to identify a valid frame and determine the start of the user data block.
3. The byte 0x81. This may be a protocol indicator, e.g. to distinguish between FHSS, S-FHSS and T-FHSS transmissions.
4. A 16-bit transmitter ID. This is what the receiver remembers when it binds to a transmitter. The receiver will ignore any packets that do not have the ID of the transmitter that the receiver is bound to.
5. Two bytes 0x00 (probably unused).
6. Eight bytes that contain 10-bit values for 4 RC channels, a 5-bit hopping_code (values 0 to 27) that determines the frequency hopping sequence, and a 6-bit field that indicates which frame this is (for example, the first or second data frame). For details of the packing of these fields into the eight bytes refer to the devo source code.
7. A 16-bit CRC to detect errors in the packet.

The total length of a packet is 168 bits and it is transmitted using 2-FSK at a symbol rate of 128,143 baud (and hence a bit rate of 128 kbps) so the transmission time is 1311µs. The FSK deviation is 38 kHz (so the frequency shift is 76 kHz).

Since each packet only contains values for 4 RC channels, multiple packets are transmitted for radios with more than 4 RC channels. When multiple packets are transmitted, the time from the start of one packet to the start of the next packet is 1,650µs.

After all packets have been transmitted, the transmitter changes frequency. The 2.4 GHz frequency band is divided into 30 RF channels, each with a channel width of 1.5 MHz. The next RF channel is calculated as

next_rf_channel = current_rf_channel + 2 + hopping_code

RF Channel numbers wrap around from 29 to 0. So if hopping_code is 0, then the channel number is incremented by 2. If it is 27 (the maximum value) then the channel number is effectively decremented by 3. Presumably a single-channel increment or decrement is not allowed to reduce the chance of two adjacent hops being interfered with by a single narrow-band interferer on the boundary between the hop frequencies. I don’t know why he minimum decrement is 3, though – it would make sense for it to be the same as the minimum increment.

There’s also a bit of cunning that essentially decrements the channel number each time it wraps from 29 to 0, to prevent certain hopping codes from generating short sequences of frequencies (although a more elegant alternative might have been to have 31 channels, since this is a prime number which would have prevented the problem in the first place). I verified that the resulting sequences do all hop onto each of the 30  channels before the sequence is repeated, so it serves its purpose.

The time from the start of a hop to the start of the next hop (on a different frequency) is 6800µs. This allows a maximum of 4 frames per hop, with 200µs remaining to change frequency between hops (the CC2500 frequency synthesizer has a settling time of 90µs so this should be achievable). However as far as I can see, S-FHSS only supports a maximum of 8 RC channels, which would require only 2 frames per hop.

It is possible that the T-FHSS protocol uses the additional 2 frames per hop for telemetry.

Observations

Packet Overhead

The use of two transmit packets per hop incurs significant overhead. Taking into account the preamble, sync word, protocol id, transmitter id, hopping code,  frame type indicator, and CRC, about 94 bits are unnecessarily duplicated by using two packets instead of one. Since the two packets together consist of  336 bits, this represents an overhead of about 28% – not to mention the idle time of 339µs between packets. When idle times are taken into account, the overhead is almost 50%. This means that for a given power output, the energy per bit is only about half of what it could have been, resulting in a higher than necessary bit error rate.

Forward Error Correction

The lack of Forward Error Correction (FEC) is surprising. FEC includes additional bits in the transmitted packet that allow the packet to be recovered even when some of the transmitted bits are corrupted, making transmissions more robust against interference. Although FEC would increase the packet length, this could be compensated by reducing redundancy in the data.

For example, by combining the two transmitted packets into one, and removing redundant bits, one could transmit the same data, complete with 1/2 rate forward error correction (in other words, there is one additional FEC bit for every data bit), using 304 bits per frame instead of the current 336 bits per frame (by frame I mean the data transmission required to transmit the values of all RC channels, so two packets in the current protocol). This would allow the same data rate to be used, achieving the same (or better) frame rate, but with a significantly better bit error rate performance and hence longer operating range. The CC2500 implements FEC in hardware, so this could be added using the existing transmitter and receiver hardware designs and without any additional CPU overhead.

Bandwidth

The 1.5 MHz bandwidth RF channel seems excessive given the 128 kbps data rate. This means spectral efficiency is only 0.085 bit/s/Hz. Minimum-shift keying (MSK), which is supported by the CC2500, should be able to achieve a spectral efficiency of 0.5 bit/s/Hz, which is 5.8 times better. I suspect this is due to the relatively poor filter shape of the CC2500 (see graphs on p. 49 of the datasheet), combined with a receiver architecture that has no additional narrow-band filtering. So I’ll count this as reasonable given the cost constraints.

Data Rate

By eliminating redundancy, including the dead time between packets, it would be possible to reduce the user data rate without affecting control latency. This would further increase the energy per bit for the same output power, resulting in longer range and reduced susceptibility to interference.

Hopping Codes

Only 28 hopping codes are available, even though there are something like 29! (10^31) possible hopping codes with 30 channels. This again increases the possibility of a conflict between two S-FHSS systems operating in the same vicinity.

The actual probability of conflict between two S-FHSS systems is

Pconflict = 2 / (No_of_RF_channels * No_of_hopping_codes) = 0.24%

By “conflict”, I mean that the two radios will interfere with each other on every single hop, which would almost certainly result in the complete failure of both links.

Note that the factor of 2 in the numerator is because the two hop sequences will not be time aligned, which doubles possibility of interference as only a small overlap between frames on the same frequency would be sufficient to cause a conflict, as no forward error correction is used.

Frame Rate

It seems clear that a high frame rate was a priority when developing this protocol, as both the range and the robustness against interference from other users has been compromised to achieve a 6.8 ms frame duration, resulting in a frame rate of 147 frames per second. (By “frame” I mean the complete transmission of all channels – in the case of S-FHSS this consists of a single frequency hop, possibly with multiple packets).

Although my initial thought was that 147 frames per second is unnecessarily high, when one considers that a couple of adjacent frames may get knocked out by interference, which would reduce the frame rate to about 50 frames per second, then it seems reasonable.

Conclusion

Better protocol design would give longer range and better resistance to interference while retaining the same frame rate and using the same hardware. The key improvements would be to reduce data redundancy, add forward error correction, reduce the user data rate and provide for more hopping codes.

Overall I’m not as impressed with the protocol as with the receiver design. If an engineering student submitted the receiver design as a final year project, I’d give him or her an “A” since, while there are some limitations to the design, they are reasonable trade-offs to meet the cost constraints.  If s/he brought me this protocol, I’d give it a “C” – still a passing grade, but should try harder.

Postscript: I calculate the maximum range of the S-FHSS protocol when using a 100 mW transmitter in Estimating the Maximum Range of a 100mW Futaba S-FHSS RC System.