Kiwi's XPS test results are up.

[Daemon]

Attached are some vid caps from the video in the previous post, showing
1, 2 - normal XPS link's effect on video. Typically 1 XPS packet per video frame
3, 4 - XPS Tx retransmit effect on video. Typically 4 XPS packets per video frame
5 - comparison of normal link and retransmit, and where the ACK would normally show in the transmission
6 - Just for grins.. Airtronics FHSS link's effect on video frame. It works the whole 2.4Ghz band so there's a lot of frames with no noise from FHSS signal, but this is what it looks like when it overlaps with the video transmission's channel.

At 30fps, it's roughly 33msper frame of video, while PPM frames are about 20ms, so one
frame of video usually captures about 1.6 PPM frames. It looks pretty chaotic viewed
live, but play it frame by frame, and it's pretty clear.

I don't have a Spektrum or FASST system on hand to show them, but this test isn't exactly
rocket science, if anyone else wants to post up an example.

ian

[KrisW]

	Quote: Originally Posted by Daemon
	BTW, this style of noise of a 2.4Ghz RC system overlayed on the 2.4Ghz video image is common to all of the 2.4Ghz RC systems. XPS, Spektrum, FASST, Airtronics FHSS all spew noise on overlapping channels at times (each system looks different), and it's a real pain for us FPV fliers. If I'm flying my plane say 1000 feet away, and a Spektrum guy walks up and turns his Tx on, my plane and its transmitter are too far away for it to notice so it'll go ahead and pick an overlapping channel (or even both of them), and my sensitive video Rx, only a couple feet away from his RC Tx is immediately swamped with noise and I can't see anything through my FPV goggles. They'll generally not have any control issues unless my video Tx is very close to their plane, and that's usually only on the ground. It's why I'm switching to 900Mhz video gear. ian

Ian, I found your videos of the park flyer 6100 losing link and then not regaining it to be interesting. Have you tried this test with any of the non-park flyer DSM2 modules? And, have you asked Horizon to examine the receiver and TX to see if there is an issue with either of them?

[Daemon]

DSM2, not yet. But I did test DX6 + AR6000 combo and it was considerably more robust.
Many people related problems with the AR6100, but the AR6000 with its two
receivers always seems to relink within 2 seconds when going from full loss of link
back to being able to see its signal. I don't know if the pilot who's DX7/6100 system
I tested has sent anything back to Horizon yet, but there were so many people relating
"normal" poor performance for the 6100 that I generally wouldn't trust em.

One theory tossed around with respect to the AR6100 is that since it only has one
receiver, it's only listening on one of Spektrum's two channels (some theorize
that it rapidly switches back and forth between them, but I don't think there's any
evidence to support that). My suspicion is that all the dual receiver Spektrum systems
are able to continue to listen to the original channel, even while they're
scanning for the Tx on its new channel, which accounts for the faster re-link,
while the AR6100 on its one channel (or one receiver), can either listen or scan, but not both
and it's more easily blocked, which of course is a major
criticism of XPS. The difference between the AR6100 and XPS though, is that XPS will
hot-link instantly once the signal is visible again, while the AR6100 may lock you out for
5-15 seconds while it rescans.

[edit] More info on this since last night.
Here's a quote of a post on RCG in my thread regarding this issue

	Quote: Originally Posted by Rob Hair
	From a post made by Paul Beard (one of the designers of the Spectrum system): AR6000 (DSM1): 2 radios (monopole antennas), 2 paths. 1 freq per radio 2 copies / frame AR6100 (DSM2): 1 radio (dipole antenna), 1 path, 2 freqs per radio 2 copies / frame AR7000 (DSM2): 2 radios (dipole antennas), 2 paths, 2 freqs per radio 4 copies / frame Paul

ian

[Daemon]

5 whole views of the video. Oh well, I learned a lot, even if nobody else finds it interesting.

I switched to a 10mW video Tx so XPS wouldn't have to fight so hard to see through
the video transmission and I could better see the XPS signals themselves.
Attached is an image showing 4 modes of the XPS Rx and Tx pair.
Turned Rx on first, powerful burst transmission for about 1 second, which appears
to be on the last known "good link" channel, and then if it doesn't immediately find
the Tx, it searches for a clean channel and about a second later goes into a mode where it
keeps retransmitting small pulses. Basically the "I'm here, come find me" mode.
Turn the Tx on, it finds the Rx and links, can see normal transmission frame
followed by the shorter ACK from the Rx.
Then turned the Rx off, and watched the Tx retransmit 4 packets per frame,
and can see the lack of Rx ACK.

ian

[gareth.ky]

Actually linking to the video might help that.

[Daemon]

	Quote: Originally Posted by gareth.ky
	Actually linking to the video might help that.

The video *is linked* in the last post on the previous page of this thread, along with the relevant discussion of what it shows. here


ian

[gareth.ky]

	Quote: Originally Posted by Daemon
	The video *is linked* in the last post on the previous page of this thread, along with the relevant discussion of what it shows. here ian

My bad I missed the link.

----[strike]Did I see right, when the Tx was turned on and the self diagnostic was off the noise stopped? As in the XPS system only transmits when some servo position has changed?[/strike]----

never mind, it was when you picked up the Tx and the orientation changed

[sweetpea]

	Quote: Originally Posted by Kiwi
	Phew, Away for a few days and it took me an hour to catch up. Gents I´m glad this is still a gentlemans discussion despite the odd feeling or two being thrown in. I´m sort of back on deck this week but away from home so dont expect too much please. Next week I will be in a position to get really serious and start doing tests across all the brands. What I am sure of so far is that its positively positive that XPS does not hop under favourable or unfavourable circumstances that I as a green horn modeller would expect it too. I´m sure there are thousands out here who know more of the techy inside stuff than I ever will and I have seen some very clued up guys try to make XPS hop. All without a succesful result. Does that make XPS bad, unusable, etc etc. That6s up to the individual and the use he has the devices intended for. Nothing is 100% perfect but you can sure reduce the odds. Thats my only point so far. Lets see what goes with all the others.

I know the original intent was to make XPS hop.......and you couldn't do that.

I do hope you intend to layout the same parameters (i.e. test conditions) to all the other systems and show that their method of transmission (be it 2 channels or continous hopping or 1 channel only) either passes or fails the exact same test for comparison basis.

Once that has been accomplished then we can look at what it really takes to take out each system individually and try to relate that to a "real world" power source.

[Daemon]

	Quote: Originally Posted by gareth.ky
	never mind, it was when you picked up the Tx and the orientation changed

Yep. With the high power video Tx nearby, the XPS signal as seen by the video Rx was
very sensitive to XPS Tx antenna orientation. I tried to keep everything pretty much
the same distance and orientation away from each other.

Here's another screen cap from today.
This is Airtronics FHSS signal with XPS signal on top of it. They're transparent to each other
XPS didn't lose a packet and retransmit, and while the FHSS Rx light blinks any time it loses a
packet (which it does do around the video Tx) it didn't affect the servo response at all. Only
happens for a frame or two every second or so. FHSS definitely has a cycle though.
The sequence it uses to run through the channels may be pseudo-random, but it's not infinite.
It cycles back around every 1.2 seconds. I'd love to see an FASST signal at this timescale
to see if it does the same.

ian

[Daemon]

	Quote: Originally Posted by sweetpea
	I do hope you intend to layout the same parameters (i.e. test conditions) to all the other systems and show that their method of transmission (be it 2 channels or continous hopping or 1 channel only) either passes or fails the exact same test for comparison basis.

The other systems can't pass or fail this specific test. He was only testing to see if XPS would
hop, not whether it was still responsive, or needed to hop. Spektrum and Assan never hop.
FASST and Airtronics FHSS hop constantly. Subjected to the same test, the former
will continue to not hop, and the latter will continue to hop constantly. I guess that'd
be a "pass" but it's pointless since there's no reason to expect them to do anything else.

	Quote:
	Once that has been accomplished then we can look at what it really takes to take out each system individually and try to relate that to a "real world" power source.

And that I'd be interested to see, and have asked for before. Basically bring
the noise level up directly on the channels that each system uses (including on both of Spektrum's
channels) to the point that one system starts to show noticeable loss of response,
then see if the other systems are more or less responsive at the same noise level.

ian

[sweetpea]

	Quote: Originally Posted by Daemon
	The other systems can't pass or fail this specific test. He was only testing to see if XPS would hop, not whether it was still responsive, or needed to hop. Spektrum and Assan never hop. FASST and Airtronics FHSS hop constantly. Subjected to the same test, the former will continue to not hop, and the latter will continue to hop constantly. I guess that'd be a "pass" but it's pointless since there's no reason to expect them to do anything else. ian

Understood. But in his hop test the system also failed (i.e. locked out).

Would like to see how the other systems perform under the same exact test to see if their method of dealing with noise is effective in the exact same scenario. That would be useful information.

[zoomer260]

	Quote: Originally Posted by gareth.ky
	That is correct, an ACK 'packet' is at the protocol layer and the backoff is happening at the physical layer. In tcp at least an ACK packet is a packet thats dozens of bits long with a single bit set to 1 to indicate the ACK. Did Jim actually say that XPS was a 2 way protocol? Seems pretty silly to have the Tx sending things over and over again because it didn't get an ACK. After all its a stream, old data is useless anyhow. Might as well send current stick position data. Why wait for an ACK? I mean, what do you do if you don't get an ACK for an extended period, stop transmitting, get stuck in an infinite loop??!! You would never want that in an RC application. Maybe it just sends the current stick positions 3 times per PCM frame. Since a PCM frame is kind of long you could pack a few transmissions in there. The redundancy wont hurt.

"Might as well send current stick position" makes a whole lot of sense. Why it would wait for a reply would only makes sense if it intended to do something about it if it did not get a reply. Which if it did Jim would be all over these threads. Which he isn't.
So since a laymen such as myself can only make use of information at hand would decide XPS just is not the way to go 2.4.

I have no intention to bash anyone but the proof is in the pudding. He would settle this matter quickly if it was possible.

Since for me XPS is a dead horse I am WAY more interested in how they all stack up to interferance before "lockout".

Very patiently waiting on those results should the testing get that far.

Thanks KIWI