Independent tests prove lack of frequency hopping with XPS

[klhoard]

	Quote: Originally Posted by XJet
	...<snip>. . -- it wouldn't have hopped out of the way of the oncoming vehicle anyway:-)...<snip>..

.
.
Now THAT's funny!!
.
.

[ss40]

Quote KrisW:We also have many cases of total loss of control of the aircraft, and the plane then crashing, instead of recovering control through the XPS unit regaining a data link. . again proving that on an all too frequent basis XPS somehow loses link, does not regain it, and the result is a lost aircraft EVERY TIME.

We do have the same comments regarding Spectrum setups here and there. I believe this is not really a fair statement. Just MHO of course.

[KrisW]

	Quote: Originally Posted by ss40
	We do have the same comments regarding Spectrum setups here and there. I believe this is not really a fair statement. Just MHO of course.

Ahem. . . the reasons for the Spektrum problems are documented. . usually battery voltages too low. Spektrum has addressed most of the issue, and also has a quick re-link firmware upgrade as well. Spektrum is also dual path, not single channel like XPS, making the likelihood of total signal loss almost impossible. I do not recall any incidents of Spektrum locking out, and I've searched back 6 months on all of the forums to see if any such total lockouts were reported on Spektrum with DSM2. Someone was trying to say one of the Park Flyer receivers losing link at long range was the same as one of the larger DSM2 modules losing link, but that's grapes versus watermelons, and an inaccuratte analogy.

Has anyone ever seen a Spektrum DSM2 go into failsafe that was NOT associated with low battery voltages? Has anyone ever seen an XPS go into lockout, not re-link, and crash the plane??

You will find the latter occurence to be well documented . . and the former to be literally nonexistent.

[ricoalonso]

	Quote: Originally Posted by ricoalonso
	... <snipped>... Edit: BTW, here the link http://www.rcgroups.com/forums/showt...816984&page=36 check post #535

Hey guys, I apologize for posting the link above here in FG. It turn out that it was a hoax or a bad joke from the original poster as he had admitted in RCG.

So sorry...

^R^

[Foamaholic]

That's okay, faked me out too. Mine didn't seem to fake anyone out.

[ricoalonso]

LOL! yeah, your video was at least very clear that it was all just for fun.

[Flyfast1]

	Quote: Originally Posted by KrisW
	Has anyone ever seen a Spektrum DSM2 go into failsafe that was NOT associated with low battery voltages? Has anyone ever seen an XPS go into lockout, not re-link, and crash the plane?? You will find the latter occurence to be well documented . . and the former to be literally nonexistent.

Chris,

How does the lockout mode of the XPS system work? Is this a mode where the receiver stops processing received data until some criteria are satisfied? I have been an XPS user for about 8 months and use the system in several quarter scale warbirds (100"+) and am always interested in learning more about the system. I have reviewed the documentation provided by XPS and the information on the XPS user group and cannot find anything that describes the lockout mode.

My system has been working quite well, but I am very careful about receiver installation and my electrical power system. I also conduct thorough range testing on the ground.

Thanks,

-Ed B.

[BZFrank]

	Quote: Originally Posted by Flyfast1
	Chris, How does the lockout mode of the XPS system work? .

A 'lockout' is a situtation when the RX does not respond to the TX anymore for a substantial time duration. There is no special mode for that in a XPS system (at least it would not make any sense to implement such), it is believed an error condition of the XPS due to various causes - low voltage, bad reception, channel swamping or triggered by other external events. 'Lockouts' in XPS are reported both be transitory when control could be regained after some seconds and permanent when control could not be regained until crash.

Here is a video example of a transistory XPS lockout (German narration, however its easy to tell when its happens: 'kein Empfang' means 'No reception', 'Empfang' means 'reception', its was not a low voltage issue as a logger was running during flight):

YouTube - rc jet Kangaroo 2007-12-23 XPS LockOut ?

Frank

[XJet]

Just as a matter of interest, here are some quotes from posts JD has made to various forms in respect to XPS. I don't think I have to add anything:

"MaxStream has patents pending for the spherical technology (I would love to say I invented it, but that is not the case)"

"As part of the normal operation, the frequency changes on the fly (hopping) using a patent-pending technique"

"Everything stated on our website for the product description is 100% true. It may not be worded the way you like it, but that is marketing"

"Being prepared for the possibility of an issue when fully enclosing the antenna, both the transmitter modules and receiver are designed to accept remotely mounted "rubber ducky" (stubby) antennas"

"Their [the AMA] biggest concern is the affects of metal and carbon fiber. Considering that we can fully incase the receiver in either carbon fiber or steel, and it still works, we are not concerned about these affects"

"I won't explain the technology, that is what we consider trade secrets - and magic"

"I can tell you that just watching a specktrum [sic] analyzer with our system running and other 2.4GHz devices going, definitely shows that we have a much superior system for preventing any type of potential problem"

"If you flew your plane over a school with a huge 14dbi external 802.xx antenna, that would likely be cause for switching to a new frequency (away from whatever channel that 802.xx was on)"

"Even 2.4GHz cameras are not a problem as we can move around their frequency, even with huge drift that occurs in the cheap overseas versions"

"now if anyone had bi-directional communication, telemetry support, and about 1/2 the price that would be impressive! ... oh wait, that's us! "

[Kiwi]

Gents.

I wrote to Maxstream asking some questions on the XBPRO module as I have a potential use for that type of device for data streaming information off mobile mining equipment. Unfortunately my mail server has quit tonight for some reason but as soon as it comes back on line I will copy and post the reply.

I asked the question from them as to what happens if the data stream is interfered with to the point that I start to get data errors. The application is dependent on a 100% secure data link. Currently done with cables but I want wireless.

I wont comment other than to say the information I received says the system cannot hop frequencies but the answer is over my head and I would like someone who does this for a living to decipher the reply.

As for my testing being non scientific I always and will continue to say I tested it in a modellers application. That is in a noisy environment with other systems operating in close vicinity. To me if the system has to go into failsafe to prompt a channel hop then how can the receiver tell the Tx where it is waiting if the two have no pre programmed idea of where in the heck to go. Fail safe has to be the last option, it cannot be a wait or hold alternative while the Rx and TX go there own seperate ways. The time it takes to relink even if it is only a second or two is way too long. To my mind any system that claims to be able to dodge noise and find a cleaner channel to maintain the link on must happen before the fail safe option comes into play.

I´m not bashing XPS, I just cannot make it hop by slowly raising the noise all around it or rasing the noise rapidly.

FUTABA FASST absolutely does what they claim and you can see that on the scanner.
SPEKTRUM does absolutely what they say it does. It runs on two spaced channels.
ASSAN does exactly what they say. It runs on one pre selected channel, it does not hop, they dont claim it can either.

But I got my Spektrum setup this week so I now have nearly all the available systems. They will all get the same treatment. Tested in a RC model friendly environment.

I have no pre conceived ideas or answers on how they will perform. Time will be the judge of that.

[Four Stroker]

Don't forget the Airtronics RDS8000 !

[XJet]

	Quote: Originally Posted by Kiwi
	Gents. I wont comment other than to say the information I received says the system cannot hop frequencies but the answer is over my head and I would like someone who does this for a living to decipher the reply.

I'm pretty sure their reply will be that the XBeePro modules will not hop by themselves but that the operating channel can be changed by the user's own software (firmware) if suitably written.

The problem with this is that we're trying to perform a transport-level reconfiguration at an application-level. In effect, it's a bit like trying to drive your car from the back seat -- the amount of control you've got is rather severely constrained.

	Quote:
	As for my testing being non scientific I always and will continue to say I tested it in a modellers application. That is in a noisy environment with other systems operating in close vicinity. To me if the system has to go into failsafe to prompt a channel hop then how can the receiver tell the Tx where it is waiting if the two have no pre programmed idea of where in the heck to go.

Yes, this is the biggest problem with hopping as implmented (or not) by XPS.

You can't negotiate where to hop if you can't talk to the other party.

JD bases his hopping algorithm on the assumption that an interfering signal will always appear at a low level and very gradually increase in intensity -- allowing plenty of time for his transmitter and receiver to detect the rising noise and renegotiate an alternative channel before all communications between them is lost.

It's been my experience however, that some of the worst interference on 2.4GHz simply appears out of nowhere and gives no warning of its arrival.

Remember that we're dealing with solid-state devices here. When someone turns on their video sender, leaky microwave or other 2.4GHz noise source then, just as when you turn on your LED flashlight -- the signal is there instantly and at full intensity. XPS can't cope with this kind of interference at all because there's no chance to renegotiate the channel in use -- it's a limitation of the XBee technology provided by MaxStream and there's nothing JD can do to change it.

JD says that the only time you get this "sudden" appearance of high noise levels is when the entire band is saturated -- which is patently untrue and I've got plenty of SA logs to show otherwise. Around where I do my UAV testing it's not at all uncommon for very high levels of noise to come and go in an instant on various segments of the 2.4GHz spectrum -- but I've *never* seen the entire band saturated.

I suspect the reason that JD has simple proffered an inadequate explanation and won't provide any format for a reproducable test scenario that proves XPS hopping is that he's hog-tied by the limitations of the RF modules he's using and can't.

It should be remembered that the XBeePro modules aren't designed for hard-realtime or RC model applications -- hence the fixed-frequency operation and absence of any diversity capabilities.

JD has taken some off-the-shelf modules, crafted up some relatively simple microcontroller code and grafted the two together into a module-based 2.4GHz system. It works for many people but is hardly the pinnacle of robustness from an RF or realtime perspective.

If it were, you'd have already seen a raft of other systems launched using the very same concept. In fact, I was doing some documentation for another company who was planning to do just this but they decided to cancel the project at a late stage when their testing showed issues created by the MaxStream XBeePro modules that could not be adequately addressed to their satisfaction.