Independent tests prove lack of frequency hopping with XPS

[jonkoppisch]

Tychoc, the guy who did the test and posted the results got this response....

	Quote: Originally Posted by tychoc
	My original thread got deleted. I re posted my original post and politely asked for clarification, it got deleted within 3 minutes of me posting it. Disappointing response. -tychoc

[sweetpea]

Here is a sticky from the RCgroups XPS vendor page.

	Quote: Originally Posted by JimDrew
	With all of the so-called experts doing some bench testing, it is time to shed some light on the subject of our frequency hopping. Does it hop? Yes, it does. Can you make it hop? Probably, but it is going to require some very specific situations for it to occur. The hopping is predictive, based on the noise floor over a period of time. When the noise increases at a particular rate and pattern, a new frequency can be selected. Can be? Yes, if there are no good frequencies to use, hopping can be more of a problem than not hopping. So, how did we determine the noise rate and pattern? By flight testing at various locations, including Las Vegas - which we believe has the highest noise floor in the U.S. Using a simple bench test to apply a high power signal (even slowly increased) is likely not going to make it hop. You will find that I stated this last year when we discovered an issue pertaining to having an on-board 2.4GHz video camera. If that camera is activated remotely and is on the same range of frequencies (occupying 4 of the 16 available frequencies) as the XtremeLink, there is no question that there will be a problem. The system will not hop in this case, even though there is a possibility of hopping to a frequency far enough away. But, if the video camera is high powered (500mw or more), it won't matter what you do as the entire noise floor is completely saturated. You will find that NO 2.4GHz radio system will work in this condition. Lower power video cameras can be made to work with our system by making a change to the hopping to include instant noise saturation, and *if* there is an open channel. In practical testing for the last 2 years, we have never seen this occur without it being an on-board 2.4GHz device. While in Germany, we discussed the frequency hopping issue along with Graupner in a meeting with the technical director of the German equiv. of our AMA. "Dieter" agreed that a simple single band noise saturation test is no where near the condition that we fly our aircraft in, and that unless you have a high power device sitting directly on the receiver, there is nothing available short of Nexrad radar that can cause the level of interference necessary to cause a lock out condition. In Dieter's test, it took a 20db, 100% duty cycle CW wave, using a 15db gain directional antenna nearly touching our receiver antenna, for a failsafe condition to occur. To get this power level while flying a model would require extremely high power levels. Wifi, baby monitors, etc. can not even come close to generating this type of power. We agreed with Dieter when he mentioned that the entire noise floor being elevated is the only real danger for 2.4GHz R/C, and that affects every 2.4GHz system made. Hopping to a non-existant frequency is not going to do you any good. If a 2.4GHz device supports spread spectrum technology, it could be high power and in close proximity. It is only carrier based devices that could every present a problem. A 500mw DX7 transmitter on the same frequency as our 100mw system play nicely together, even when the antennas are taped together and range checked. Although the noise floor goes up, there is no "noise" if the spread spectrum encoding is working. The data gets through with no problems. How fast can we hop? If you listen to the experts that would like to believe they know our proprietary product better than we do, we can't hop fast. Our system is capable of hopping every single frame, which is all that matters. But, in reality our hardware can change to a new frequency every 350us. However, FCC/ETSI/IC rules clearly state that unless you are hopping on 15 or more frequencies, your maximum hop rate can not be any faster than once every 400ms. We only have 12 channels available to us, so we are not allowed to hop any faster than once every 400ms. Some have been confused about the FASST's FCC ID being DSSS instead of FHSS. They simply hop within the specified time, making them legal. While in Germany, there was a lot of speculation about the Spektrum's hopping being illegal. The Spektrum supposedly does not really "lock on" to 2 frequencies, but rather transmits one time on each frequency separately with the single antenna, thus hopping on only 2 channels, and faster than once every 400ms. We have not really looked into this ourselves, so we don't know if it is true. So, our system does in fact do what it is advertised to do. Is it "bullet proof"? No way... NOTHING is bullet proof, not even a direct hard line to the aircraft. It is extremely arrogant to believe a system is infallible as these are electronic devices which can fail. We believe that we still have the best system available. We have the only system that actually knows what is going on during flight, knowing when data is not received and having that data re-transmitted when it isn't. We think that is a far cry from reporting a 'fade'. Our electronics are built by a company with every ISO certifiication available, and each piece is x-rayed, optically inspected and compared via computer, and hand tested prior to packaging... all in the U.S.A. What are our future plans? We will be changing our code to make the receiver boot-up less sensitive to the noise floor. This is why sometimes the LED flashes red on both the transmitter and receiver after powered up (requiring a power cycle of the receiver). Some equate this to losing the binding which really is not be possible. We will also be adding a new hop condition (when possible) for immediate saturation of 2.4GHz noise to accomodate the on-board remotely activated 2.4GHz video cameras. Some have asked about the ID system we use. We actually pay for IEEE certified "MAC" addresses, like you would see on the Internet. Each 64 bit address is unique (never repeating). This gives us 2^64 possible ID codes that are locked into protected flash ROM, guaranteeing that we will never have a case where two transmitters could control the same aircraft. Based on the number of systems sold to date and the average amount of flying done by a modeler on any given weekend, we now have millions of successful flights by our customers. Compared to the number of issues reported, we believe this number speaks volumes for the reliability of this system.

[Eflyer_75214]

Both Tychoc and Daemon have started new threads under the General topic and Radios. They have posted all of their info which is the meat of the threads that were deleted.

[XJet]

	Quote: Originally Posted by sweetpea
	A question for Xjet (since you are a pro on Xbee). Is it possible for XPS to change and transmit on 2 freqs vs 1 like spektrum or is that not possible? I'm just wondering.

Unfortunately it's not practical to do this.

The XBee modules can only transmit/receive on one channel at a time and although you might think it would be a simple task to just toggle back and forth between two frequencies, it's not.

The problem is the very thing that XPS claim as one of their strengths -- the reliable transport layer that the XBee modules provide.

When an XBee sends a packet of data, it doesn't just forget it and move on -- it waits until the other end sends back an acknowledgement (ACK) that the packet was received.

Now in a perfect environment, with no interference, no multi-pathing and where the receiver and transmitter could always hear each other with 100% reliability, such a system could be configured to toggle between two or more frequencies - but in such an environment you wouldn't need that capabilty anyway.

The problem arises when you have noise, multi-pathing and other factors which can cause either the original data packet or the corresponding ACK to get lost.

If the transmitter sends a packet on frequency 1, it will wait until it gets an ACK back before carrying out any other commands (such as "change channel"). If it gets that ACK then there are no problems, the receiver can change to the alternate frequency after it receives the packet (and returns the ACK) and the transmitter will also jump to the same frequency once the ACK is received.

But what happens if the ACK gets lost?

The transmitter is still on the original frequency (because it's waiting for an ACK that never arrives) whereas the receiver (which has sent the ACK) thinks it's okay to change channels an sits on the new channel waiting for the next data packet.

Suddenly we have a problem. Transmitter on channel 1, receiver on channel 2.

The transmitter will tire of waiting for the ACK and automatically resend the data packet that was never acknowledged -- but it's now sending on the wrong frequency so the receiver will never get it.

This will happen at least three times on a standard XBee module before the transmitter gives up and accepts that it's *never* going to receive an ACK. So what does it do then?

It could hop to the alternate frequency -- but then the other scenario comes into play...

Let's go back to the start and assume the transmitter sends a packet to the receiver (both on the same channel) but that packet never makes it to the receiver (noise, multi-pathing, wathever). The receiver doesn't send an ACK back because it hasn't received anything.

The transmitter tries a couple more times and if both those packets also get hit by interference it still won't get an ACK. So now the transmitter gives up trying and (if it's programmed as in the original scenario) jumps to the alternate frequency -- but the receiver is still waiting for a packet to arrive on the first frequency. Once again we now have the transmitter and receiver on different frequencies -- unable to hear each other.

Clearly the issue of maintaining synchronization becomes a major one -- mainly because the XBee modules are just too "clever" for their own good in such cases.

If the transmitter didn't wait for an ACK then we'd be a lot better off.

The transmitter could simply send each alternate frame of data on the alternate channel.

The receiver could start off listening for a frame of data one of the two channels and when it got it, switch to the other. If a frame was lost -- then the receiver wouldn't switch (but the transmitter still would) so you'd lose another frame -- but the third frame would again be on the right channel and synchronization could be re-established.

Yes, this could also be done with the XBee system but the automatic interference of the ACK traffic and resulting delays tends to start pushing latency times up and potentially making it much harder to re-establish synchronization between the transmitter and receiver.

Once again (in the case of XPS) it's trying to use a hammer on a screw -- it's not really the ideal tool for the job. You *can* use a hammer to drive a screw in, but the results will be neither pretty, nor robust, nor reliable -- and this is the case with XPS and the XBee modules. They were never designed for the applications that XPS is using them for and there is no easy way to work around their increasingly obvious limitations.

I am aware that other manufacturers took a good look at the XBee modules before opting for other chipsets on 2.4GHz. At first glance, the XBee modules look like a terrific idea, if only because they're so simple to interface to and implementing an RC system using them is child's-play. However, it seems that the others took a much deeper look and considered the performance disadvantages and limitations of the XBee modules in such an application greatly outweighed the extra cost and work involved in using other more flexible chipsets.

This may explain why JD prefers to baffle with BS rather than simply rely on the technical merits of his system. When examined closely, the XBee's inability to provide frequency agility or redundancy and diversity were probably well-known to XPS right from the start, hence all the talk about mythical spherical antennas, etc. If you've got some serious unfixable weaknesses -- just come up with some magical concept that seeks to negates the importance of issues that other manufacturers take extremely seriously.

I hate to be a cynic -- but we've seen absolutely no evidence to support many of JD's claims and they all seem to fly in the face of the facts and established scientific principles. He could re-assure all the doubters and nay-sayers by simply submitting the XPS system to a suitably accredited independent lab or university for testing. It may cost a few thousand dollars -- but surely all this doubt in respect to the claims made for the system is costing him a whole lot more right now.

And if his claims of having sold tens of thousands of units is accurate, this will represent far less than a dollar per unit in terms of cost.

If he doesn't take the step of having XPS independently tested and providing some irrefutable evidence to support his claims, then I think we can work out why.

[exeter_acres]

	Quote: Originally Posted by XJet
	-- but surely all this doubt in respect to the claims made for the system is costing him a whole lot more right now. .

You must be proud

[sweetpea]

	Quote: Originally Posted by XJet
	Unfortunately it's not practical to do this. The XBee modules can only transmit/receive on one channel at a time and although you might think it would be a simple task to just toggle back and forth between two frequencies, it's not. When an XBee sends a packet of data, it doesn't just forget it and move on -- it waits until the other end sends back an acknowledgement (ACK) that the packet was received. Now in a perfect environment, with no interference, no multi-pathing and where the receiver and transmitter could always hear each other with 100% reliability, such a system could be configured to toggle between two or more frequencies The problem arises when you have noise, multi-pathing and other factors which can cause either the original data packet or the corresponding ACK to get lost. If the transmitter sends a packet on frequency 1, it will wait until it gets an ACK back before carrying out any other commands (such as "change channel"). If it gets that ACK then there are no problems, the receiver can change to the alternate frequency after it receives the packet (and returns the ACK) and the transmitter will also jump to the same frequency once the ACK is received. But what happens if the ACK gets lost? The transmitter is still on the original frequency (because it's waiting for an ACK that never arrives) whereas the receiver (which has sent the ACK) thinks it's okay to change channels an sits on the new channel waiting for the next data packet. Suddenly we have a problem. Transmitter on channel 1, receiver on channel 2. The transmitter will tire of waiting for the ACK and automatically resend the data packet that was never acknowledged -- but it's now sending on the wrong frequency so the receiver will never get it. This will happen at least three times on a standard XBee module before the transmitter gives up and accepts that it's *never* going to receive an ACK. So what does it do then? It could hop to the alternate frequency -- but then the other scenario comes into play... Let's go back to the start and assume the transmitter sends a packet to the receiver (both on the same channel) but that packet never makes it to the receiver (noise, multi-pathing, wathever). The receiver doesn't send an ACK back because it hasn't received anything. The transmitter tries a couple more times and if both those packets also get hit by interference it still won't get an ACK. So now the transmitter gives up trying and (if it's programmed as in the original scenario) jumps to the alternate frequency -- but the receiver is still waiting for a packet to arrive on the first frequency. Once again we now have the transmitter and receiver on different frequencies -- unable to hear each other. The receiver could start off listening for a frame of data one of the two channels and when it got it, switch to the other. If a frame was lost -- then the receiver wouldn't switch (but the transmitter still would) so you'd lose another frame -- but the third frame would again be on the right channel and synchronization could be re-established. Yes, this could also be done with the XBee system but the automatic interference of the ACK traffic and resulting delays tends to start pushing latency times up and potentially making it much harder to re-establish synchronization between the transmitter and receiver.

So after reading through your post several times.......

XPS could chose 2 freqs and transmit back and forth on them. Of course it would need some "what if" clauses in the programming if a packet has not been confirmed to align the TX and RX. But it appears that it could be a viable option depending on what kind of delays are present.

(note: I edited the quote down to exactly what I asked and deleted the useless extra info that was in the original post as I wasn't asking what XPS could do, I was asking what an Xbee could do as it pertains to how XPS is currently using it. I also wasn't asking for your opinions on XPS....just the feasibilty of Xbee to perform this task)

[XJet]

	Quote: Originally Posted by sweetpea
	So after reading through your post several times....... XPS could chose 2 freqs and transmit back and forth on them. Of course it would need some "what if" clauses in the programming if a packet has not been confirmed to align the TX and RX. But it appears that it could be a viable option depending on what kind of delays are present.

Yes, but the big problem is that small bits of interference that would normally go unnoticed (without all this hopping overhead) could start to introduce some very real unwanted latency into the system's performance.

In effect, you'd be compromising the average performance (possibly to quite a large degree) in order to obtain a higher probability of not being shot down.

If folks want to lose that "locked in feeling" they talk about and accept some significant variability in the time between when a control input is given and the surface actually moves (possibly several frames worth) then it might be possible to get such a system to work - but it's still a nasty kludge.

[KrisW]

	Quote: Originally Posted by klhoard
	. . My guess is that he will announce that the R/C field is now "too crowded to be profitable" or something along those lines and announce he's going to produce electronic control systems for the quilting hobby. . . Either that or just take down his web site and disappear; leaving hundreds of heartbroken Fanboys posting tearful "Stop picking on JD" videos on YouTube. . .

Actually, the electronic quilting thingie proved a bust too. . I heard he was researching it over in Germany, since all the Haus Frau's like to do the quilting thing, and one of the local Unions for the current technology got wind of his ideas and when he came out of his hotel he was accosted by a mob of angry older women, wielding knitting needles, long quilting needles, and even some crochet hooks ! ! ! Kind of put the Kabosh on THAT idea. . .

Soo. . he'll probably stay with the RC thing for a while. .remember, he's already SAID that the 2.4g spectrum is kind of full and problematic, so he is going to come out with 900 mhz really soon as the REAL solution to all this inerference and lockout situation. I'm still very happy on 72 mhz. . . .

[buttface]

	Quote: Originally Posted by exeter_acres
	You must be proud

GO Xjet!!!!!!We are all proud of you!!!!!Keep up the good work Bro!JD needs to support his claims.Why shouldn't he, unless he is hiding something.

[XJet]

	Quote: Originally Posted by buttface
	GO Xjet!!!!!!We are all proud of you!!!!!Keep up the good work Bro!JD needs to support his claims.Why shouldn't he, unless he is hiding something.

Well I"m just trying