Independent tests prove lack of frequency hopping with XPS

[Flatlandman]

	Quote: Originally Posted by Wojcigitty
	Hard man fly turbine in ice and snow. Hard man easily deal with lockout and land jetplane on cratered minefield runway. XPS for hard man. Yeeeeeaaaah.

Hard man deadstick jet on 2 foot wide runway thats an obese 20 feet long lol.

[BZFrank]

	Quote: Originally Posted by Flatlandman
	Hard man deadstick jet on 2 foot wide runway thats an obese 20 feet long lol.

Yes, the strip is a bit short. Guess he was training for aircraft carrier landings.

The real troubling aspect of this incident was however that this very turbine plane was flying for months with the very same XPS setup on that same field before without incident. The (multiple) lockout did strike 'out of the blue'.

Original Thread (in german): http://www.rc-network.de/forum/showthread.php?t=89247

Frank

[Happy|Harry]

the same thing happened to a friends scratch built Fw190 on an IFS(XPS) setup, around 20-25 flawless flights and then on the final flight the Rx went into failsafe for a second or so then control came back, though it was sluggish, then as he was turning to bring it in for landing it dropped into failsafe again and crashed . after the crash everything worked as normal again, but he's never used the IFS setup again as he has no trust in it anymore!

phil

[Flyfast1]

	Quote: Originally Posted by Wojcigitty
	However, it's to be expected that, out of nowhere, another device could start broadcasting on the same frequency as XPS and use up all available bandwidth. FASST and Spektrum have methods of dealing with this.

Agree. My biggest concern has been other modelers turning on their system on the same channel, and the XPS system handles that scenario quite well. My flying site is fairly remote, so I don't think I have to be concerned about conventional 2.4GHz noise sources because I don't think they would have enough power to be a problem and I don't use any 2.4Gig video devices. If high powered radar shows up, well then all bets are off anyway.

That being said, if the XPS system does not change channels if interference occurs on the channel being used, which it is looking more and more that it doesn't, then I hope that XPS makes a firmware upgrade available to address the issue. That would provide an extra measure of security.

-Ed B.

[XJet]

	Quote: Originally Posted by Flyfast1
	That being said, if the XPS system does not change channels if interference occurs on the channel being used, which it is looking more and more that it doesn't, then I hope that XPS makes a firmware upgrade available to address the issue. That would provide an extra measure of security. -Ed B.

Don't hold your breath for an effective fix to the no-hop problem. It's an intrinsic limitation of the RF modules being used and no amount of work on JD's part can overcome that limitation to provide the kind of robust and reliable frequency agility that RC flying really needs.

Those who fly miles from anywhere will probably have no issues with XPS's lack of agility (although the lack of diversity is another issue) so whether XPS is a good choice definitely depends on what you fly and where you fly it.

[Chris F]

From what we know about the XPS system so far, would it be fair to say that although it has some safety features associated with 2.4 GHz like selecting a free channel at start up, our old analogue systems are more solid interference wise? I use a MPX Evo and XPS is the only 2.4 option for me at the moment. With the extra cost of the XPS system including Rx's and lack of frequency agility it would appear I would be crazy to change from 36 MHz. If this is the case would I only be changing over for the gimmick of flying on 2.4 GHz?

[Flyfast1]

	Quote: Originally Posted by XJet
	Don't hold your breath for an effective fix to the no-hop problem. It's an intrinsic limitation of the RF modules being used and no amount of work on JD's part can overcome that limitation to provide the kind of robust and reliable frequency agility that RC flying really needs. Those who fly miles from anywhere will probably have no issues with XPS's lack of agility (although the lack of diversity is another issue) so whether XPS is a good choice definitely depends on what you fly and where you fly it.

XJet,


Are you saying that there is no way to make the XBee modules change channels once a channel has been initially selected and is being used? If so, that is indeed disappointing.

I agree having other antenna options would be good, although I have not had any issues so far. As I have said on other posts, I think the current receiver is sensitive to installation location and orientation, but I have been able to make adjustments to solve the issues.

-Ed B.

[XJet]

	Quote: Originally Posted by Flyfast1
	XJet, Are you saying that there is no way to make the XBee modules change channels once a channel has been initially selected and is being used? If so, that is indeed disappointing.

No, the XBeePro modules *can* be told to change their operating channel by the user's firmware.

The problem arises because both ends will have to change to the same channel or they won't hear each other.

So how do you determine *where* to hop if the channel you're currently using has been hit by a very strong noise and the other end can't hear you?

JD's hopping strategy (as he's explained it) was to monitor the number of lost frames/retries that were being experienced on the current channel. If that number gradually rose (and kept rising) then it would be fair to assume that a channel-change is in order so before *all* contact was lost, both ends could agree on an alternative channel to use.

Indeed, that strategy should work in the event that the noise does rise gradually and the channel hop can be negotiated before all contact is lost.

Unfortunately that's not always the way it works on 2.4GHz. Quite often the noise comes out of nowhere with no warning. One second you've got zero packet losses, the next you've got 100% packet losses.

It might be possible to agree much earlier on (while there's no sign of interference) on an alternative channel to use in the event the current channel is unusable -- but because of the nature of interfering signals, there's no guarantee that the alternative channel won't also be so noisy as to be unusable once you hop to it.

In short, it's the very thing that aids XPS in working as well as it does with a single antenna that cripples it when it comes to frequency changes -- the reliable transport layer.

If I were JD, I would simply establish two operating channels with a sensible separation at boot-up.

If the link were lost on the primary channel, I'd fall back to the secondary one and *hope* that it wasn't also compromised by noise.

In theory, this would be no worse than the Spektrum setup but in practice there are still issues surrounding the synchronization of the fall-back hop.

For example, the transmitter may not get any acknowledgments that its packets were received by the receiver and so it would hop to the fallback channel.

Unfortunately, it could be that the receiver was receiving those packets and it was simply that the acknowledgements were lost. If this were the case, the receiver would see nothing wrong and stay where it was.

As a result we find that the transmitter is now on the fallback channel but the receiver is still on the primary.

Of course you could build a time-out into the receiver so that if it didn't get any more packets after a certain time, it too would hop to the fallback channel.

The difficulty in making this practical boils down to establishing parameters that will not trigger false hops but which will not introduce unnecessary periods of lock-out in the event that actual interference is experienced.

And what happens if the fallback frequency is being used and that also becomes too noisy? Where do you hop then? Back to the primary and hope it's now clear?

You could use three channels of course -- but then the synchronization issues become even more complex and the opportunities for disaster increase.

But hey -- I'm not here to design JD's hopping algorithms for him :-)

	Quote:
	I agree having other antenna options would be good, although I have not had any issues so far. As I have said on other posts, I think the current receiver is sensitive to installation location and orientation, but I have been able to make adjustments to solve the issues. -Ed B.

There are many issues associated with using a single antenna and it's not just the radiation pattern.

There's shielding, multipathing and cross-polarization to contend with - all of which can attenuate the signal to a degree where control may be compromised.

Under normal conditions the headroom to cope with these issues may be adequate but if the noise level on a channel has climbed and that headroom reduced, even the simple fact that the transmitter antenna is horizontally polarized but the receiver whip is vertical may be enough to trigger a failsafe hold.

This is why frequency agility is especially important on a single antenna system like XPS.

[Flyfast1]

XJet,

An excellent explanation! I now better understand some of the issues. Deciding which channel to change to is not an easy problem to solve.

When I met Jim at the AMA convention he said that both the transmitter and receiver build "good channel" tables and when interference is encountered change to one of the "good channels". I don't know how a "good channel" would be determined, other than occasionally sending data on the other channel and then measuring the performance. I didn't think to ask many follow on questions about how it actually is supposed to work.

As you suggested the simple way would be to find two good channels at startup and use the second channel as a backup, but as you described there are issues with making the change and the second channel may or may not still be "good".

Thanks,

-Ed B.

[BZFrank]

	Quote: Originally Posted by Flyfast1
	XJet, When I met Jim at the AMA convention he said that both the transmitter and receiver build "good channel" tables and when interference is encountered change to one of the "good channels". I don't know how a "good channel" would be determined, other than occasionally sending data on the other channel and then measuring the performance. I didn't think to ask many follow on questions about how it actually is supposed to work.

Well, there is a method to scan all channels for the XBee module and get a metric for each on the level of interference. There is only one problem - it takes time: 375ms During this scan the module cannot send or receive. So it is rather impossible for the modules to do such a scan at normal runtime as the lag would certainly impair any sensible use. It is possible to scan only single channels instead of the full set, but that would take also longer than a single PPM frame (32ms vs. 20ms).

A channel switch (without scanning) takes 15ms, so it is not possible to switch to another channel, send/receive a test frame and switch back during a single PPM frame. And there would be a high pile of synchronisation problems associated with this scheme.

XJet: Very good summary of the issues!

Frank

[Daemon]

My guess is that JD will approach the total channel saturation problem one of two ways.
1. A fallback channel determined at startup as suggested above.
If the Rx loses the link long enough to trigger failsafe, it immediately hops to fallback channel.
If the Tx loses ACKs for some interval (Tx module isn't programmable, so who knows
if it'll match the failsafe interval), it hops to backup.
Let's say for the sake of argument failsafe interval and Tx hop interval were both 1 second.
Then after one second of loss of link by the Rx, it would hop, and since it wasn't
sending ACKs for that prior 1 second, the Tx would hop almost at the same time.
That's best case timing. 1 second loss of control, both hop near the same time.
Worse case, the Tx stops receiving ACKs but the Rx can still hear the Tx the whole
time. Tx hops after 1 second of no ACKs, Rx stops receiving packets, waits one
more second, and then hops to backup and they link. Two seconds total loss of control.

But that doesn't address the problem that interference may be on the backup channel now
as well, so only way to handle that is for Rx to scan.

2. Upon loss of link leading to failsafe, Rx scans for new good channel and hops to it.
Upon loss of ACKs for some interval, Tx goes and tries to find the Rx. So
let's try the same two scenarios as above.
Rx loses packets first, for 1 second, at onset of failsafe, it scans for a new open channel
(which if the number mentioned above is correct, takes 375ms).
Tx starts losing ACKs as soon as the Rx starts losing packets. After 1 second, it
starts scanning for the Rx. Assuming it takes the same time for Tx to scan for Rx
as it does Rx to scan for new channel, it'd find it 375ms later.. cept it's likely to
miss it on the first pass since Rx is still scanning, and Tx have to go around again so probably
375ms x 2 or.. maybe 375 (one full pass) + 375/2 (on average, find it halfway through
the channels. Let's say roughly 1.375-1.750 seconds time of loss of control, best case.
Worst case, Tx starts losing ACKs even though Rx could still hear Tx fine. After one second of
no ACKS, it starts searching for Rx (which has had no reason to move yet). One second after
that, Rx goes to failsafe and starts scanning for new good channel.. 375ms later it finds one,
and 0 to 375ms after that, the Tx finds the Rx again.
So worst case, 1 + 1 + 375ms + 375ms.. 2.750 seconds loss of control.

In either case, the Rx has to commit to hopping somewhere and staying there long
enough for the Tx to find it. It can't jump back to the original channel, "just in case",
because the Tx may at that moment be looking for it on the new channel
and they'd miss each other over and over.

ian

[XJet]

Unfortunately, no matter how you look at it, whatever JD does with XPS, from a frequency agility perspective he's trying to turn a sow's ear into a silk purse.

XBeePro modules just weren't designed to cope with this kind of hard-realtime environment in a potentially harsh RF environment and although they offer unequaled ease of use from a system-developer's perspective, you pay the price elsewhere.

There are many other factors to consider in the scenarios painted above that add further complexity and permutations that must be accounted for. It is perhaps easy to see why, despite the simplicity involved in doing so, nobody else has put an RC system based around the XBeePro modules on the market.