[NormS]

This thread was started by a question concerning spread spectrum (SS) technology, so I thought I would take a stab at answering the original post. Disclaimer: I’m not a spread spectrum expert but I am an engineer with an RF, networking and embedded system design background, and I’ve done some research on the entire SS thing. What follows is my own opinion and interpretation of the marketing information from the different companies and some info I’ve gleaned from various SS-dedicated sites and whitepapers. Also, I own a Futaba transmitter, but I'm not a Futaba bigot; JR, Hitec, etc. are all great transmitters.

As I understand it, Futaba’s FASST is a pure frequency hopping spread spectrum system (FHSS) with no feedback from the receiver to the transmitter. Spektrum’s DSM is a direct sequence spread spectrum system (DSSS) that uses receiver feedback at power up to select a pair of clean channels. I believe that DSSS is technically a better approach then FHSS because it has lower latencies and supports higher bandwidths, but it’s a lot more complicated and more prone to multipath problems. FHSS is easier and cheaper and usually transmits at higher power levels; it works well enough for RC requirements. FYI, I think XPS is a hybrid frequency agile DSSS system that uses one frequency until the receiver’s bit error rate hits a limit, at which point they both hop to another pre-determined frequency.

FHSS works more or less like this: The transmitter and receiver use the transmitter’s unique ID code to build a table of frequencies, sort of a hop order list. The transmitter and receiver build the same table, since the receiver uses the transmitter’s ID code once its bound. When it powers up, the receiver syncs with the transmitter by just monitoring one frequency in the table and waiting until the transmitter hops onto that frequency. The receiver knows that it’s the correct transmitter because every frame contains that unique ID code. This is important because over about a 200mS period every FASST transmitter will hop through all frequencies, and the receiver has got to pick the right transmitter; the hop order is a lot different from transmitter to transmitter due to a low cross-correlation between the ID codes and the hop-order algorithm, so there’s no long-term interference between different systems. When the receiver is looking for sync, if that first channel is noisy, the receiver will wait a little and if it can’t find sync it will go sit on another frequency. It will eventually find the right transmitter, and then they will hop together across the entire 2.4GHz range. An alternative to the pre-calculated stored table of hops is to use the ID code to generate the hop sequence on the fly; everything else works the same way. FHSS systems broadcast each hop at the same power. If FASST supports about 100 separate channels and assuming an 80MHz total frequency range and allowing for guardbands, their channel bandwidth may be around 500KHz and their data rate will be in the order of 100-250Kbps. That’s much lower then a DSSS system can potentially have, but certainly adequate for RC usage.

FHSS doesn’t know or care if it steps on someone else’s frequency (another hopper or a DSSS system); if it loses a frame, it will get another one in a couple of milliseconds. BTW, I’ve seen some posts about FASST’s pre-vision technology alluding to pre-vision changing the hop sequence. Its hard to get any real info from all of the marketing stuff, but I don’t believe that’s what it does because of the required complexity and because that’s just not what hoppers do; I think pre-vision is some form of forward error correction coding which will allow the protocol to correct a certain number of bit errors and also detect and discard badly errored frames. There are a ton of error checking/correcting codes out there that are easy to implement and inexpensive from a bitrate overhead perspective. BTW, my understanding is that most military battleground systems use FHSS.

DSSS (Spektrum’s DSM) is a lot different from FHSS. The real baseband data (servo data) is XOR’d with a long, high speed pseudorandom sequence (PRS) which effectively raises (spreads) its bandwidth to maybe a megahertz or two. A DSSS system’s data rate can be very high if it uses a long PRS and a very high speed xor’ing function, since this will increase the overall channel bandwidth. The transmitter and receiver use the same sequence, which is derived from the transmitter’s unique ID code which the receiver gets when its bound to the transmitter. The receiver knows the channel(s) its using (agreed upon during the power up sequencing) but it has to get in sync with the transmitter and then autocorrelate the real data from the high speed data (using the same sequence), which de-correlates any narrowband jamming signal such as a FASST system that hops through their channel. This correlation process introduces something called processing gain which allows a DSSS system to operate at lower power or to get better range at the same average power as compared to an FHSS system. Because of the different pseudorandom sequences in different transmitters, two or more DSSS systems can actually use the same channel at the same time with no interference (this is how CDMA cell phones work) but I don’t think Spektrum makes an attempt to do this because they seem to have a limit of 40 systems at a time. Spektrum uses two channels per link; if one is hit or goes down, its got another one running in parallel and it probably selects the “best” data from either receiver for each frame. If a DSSS system uses a long enough sequence, it is effectively unjamable and if the transmitted power is below the ambient noise its also totally undetectable with any kind of receiver (I bet the spook/delta force type guys love that one!). Speaking as an engineer this is all much cooler then frequency hopping, which is sort of a brute force solution.

DSM may be technically better then FASST (depending on your definition of better), but I think Futaba did a nicer job on the entire system by making their receiver work down to a lower voltage level and reboot/resync faster. Things like that are really important to me, much more important then how cool the approach is. Also, it’s a lot easier to deal with one receiver then several, and FHSS handles the multipath issues that are inherent with 2.4GHz systems better then DSSS. I believe this multipath business is why Futaba can get away with only using a two-antenna diversity system while Spektrum had to use two separate receivers and two different channels. DSSS’s (potentially) better range and higher speed (lower latency) data capability are not that important to me because you can’t fly out of sight anyway, and when you get down to it, we’re just flying little planes around with relatively low resolution servos and we really don’t need to send that much data.

I’m personally waiting for the TM-8 modules from Futaba for a couple of reasons: I think FHSS is good enough and I like their overall system design better then Spektrum’s. The main reason, however, is that I own a Futaba 9c super transmitter and if something goes wrong with the thing I don’t want to get into a pissing contest with two different companies to get it fixed; I’ll just pack the entire thing up and send it off to Futaba and let them worry about what broke. Also, I’m hoping that Futaba offers a software upgrade in the future to my transmitter and module to add features or maybe that ninth channel; this is something that Spektrum can never do in a mixed Futaba/Spektrum system. Notwithstanding the above, I think Spektrum has built some terrific stuff and that they’re a great choice if you like the technology or if you finally get tired of waiting for Futaba to ship their gear. A Spektrum module in a JR transmitter might also someday give you the software upgrade I hope to get from Futaba.

In my mind, a bigger issue concerning the Futaba stuff isn’t FASST vs. DSM2, its Futaba’s apparent lack of compatibility within its own system. You may know that the 6EX/2.4, 7C/2.4 and TM-14 module works with all of their old and new receivers while the TM-7 does not work with the original 6-channel receiver, the R606FS. This clearly indicates that in some sense there is a FASST-1 and FASST-2 system out there, and I would really like to find out what they changed (or fixed) when they came out with the newer stuff. The TM-8 module is listed on their webpage as NOT compatible with the R606FS, but its late shipment is hopefully caused by a redesign to fix this. At least I’m hoping that’s what’s causing it.