Kiwi's XPS test results are up.

[XJet]

	Quote: Originally Posted by tadawson
	Actually, no, it isn't logical at all . . . if the channel is busy, transmitting anyhow will be useless.

Not necessarily. What you (and many others) forget is that the noise levels seen by the receiver and those seen by the transmitter may be significantly different (perhaps because of another transmitter on the flight-line, a blue-tooth mobile or whatever).

Although the transmitter may see a very high noise level on its chosen channel, the receiver may not see the same noise. So, if the transmitter sends a packet, the receiver may still get it, even though the noise level at the transmitter end is very high.

HOWEVER -- since the Zigbee/XBee networking protocol relies on CSMA to avoid collisions, JD's claims of 120 concurrent users may be less than accurate since he has disabled this critical feature.

Without CSMA the chances of packet collisions between mutliple XPS systems increases significantly and may become an issue if you've got more than 2-3 users per operating channel. Not an issue at most fields -- but something to consider if you are under the illusion that 120 XPS systems can operate concurrently without problems.

It's also worth nothing that regardless of the CSMA setting on the XBeePro modules, there is never any CSMA for the ACK packets.

[Julez]

	Quote: Originally Posted by tadawson
	Actually, no, it isn't logical at all . . . if the channel is busy, transmitting anyhow will be useless. Waiting for a free "time slot" is far more logical, since it is a very small wait-time involved. Allowing free for all transmission, with all the subsequent retries will simply load the channel more, *decreasing* the chance of a good packet getting through . . . - Tim

Well, Jim stated that XPS will retransmit up to 3 times, when the module does not get the acknowledgement from the reciever, right?
So, how can it happen, that the ack is not recieved? Certainly by interference: Either the reciever did not get the information due to interference, or the module does not recieve the ack due to interference.
The result is: Upon the encounter of other signals (interference), XPS will not stop transmitting. It will do the opposite: Retransmitting packs as often as possible.

	Quote:
	Julez Have you read the article in RC Elektronik "2.4 GHz und die Geheimnisse einer neuen Technologie" ?

No, I have not. It sounds like a magazine, or do you have a link?

[seattle_helo]

Thanks, Kiwi, and everyone else that has posted technical info in this thread. Fascinating stuff!

All I want is the safest system possible- so I'm looking forward to your upcoming tests with the Spektrum and FASST systems.

nick

[tadawson]

	Quote:
	Well, Jim stated that XPS will retransmit up to 3 times, when the module does not get the acknowledgement from the reciever, right?

But that in no way implies that the module does not do the check/wait/transmit test for each of the attempts . . . or at least that is what the XBeePro manuals are telling me . . . the channel busy test and backoff is at a pretty low level, and appears to affect any attempt to transmit. This has nothing to do whatsoever with whether an ack is received or not - that is being done in an higher level protocol layer.

- Tim

[gareth.ky]

	Quote: Originally Posted by tadawson
	But that in no way implies that the module does not do the check/wait/transmit test for each of the attempts . . . or at least that is what the XBeePro manuals are telling me . . . the channel busy test and backoff is at a pretty low level, and appears to affect any attempt to transmit. This has nothing to do whatsoever with whether an ack is received or not - that is being done in an higher level protocol layer. - Tim

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.

[XJet]

	Quote: Originally Posted by gareth.ky
	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.

Not quite -- the raw data-rate of the XBeePro modules is quite high (250Kbps?) and the ACK timeout is pretty short which means that several retries can *easily* be squeezed in between transmitter frames.

Also, if you're in an environment that is severely compromised by noise, it would not be a good idea to just wait for the next transmitter frame to re-send, since that could also be blocked. The machine-gun approach at least offers *some* chance that the data will get through.

Of course hopping to a new channel with a lower-noise floor would be a far *better* option but, as we've seen, that doesn't seem to be an option for XPS.

	Quote:
	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.

I gather the XPS just keeps transmitting which means it comes closer to saturating the channel on which it's running with a much higher number of packets than it should. If several other XPS transmitters are also on that channel -- well who knows what the outcome will be -- especially once their ACK packets start being clobbered by the retries, causing them to also start sending extra retry packets.

I've previously voiced concerns that the simple act of someone turning off their receiver but leaving their transmitter on with XPS might be an issue at a busy field because of this constant re-transmitting (at several-times the normal density on the timeline).

[gareth.ky]

I guess my point above was that I don't believe that XPS is a 2 way system. Nor are any of the radios. It just doesn't make sense for the application. Nor does using a backoff. You wouldn't want your radio to repeatedly stop transmitting, would you?

By the time you get enough people on 1 channel that the Spread Spectrum encoding stops being effective nothing is really going to help. You have to hop.

I don't think though that XPS lets you transmit on the same channel as someone else? I know spectrum wont do that.

[XJet]

	Quote: Originally Posted by gareth.ky
	I guess my point above was that I don't believe that XPS is a 2 way system. Nor are any of the radios. It just doesn't make sense for the application. Nor does using a backoff. You wouldn't want your radio to repeatedly stop transmitting, would you?

Actually, the only reason that XPS works well enough at all to control a model is because it has a "reliable transport" layer that retries when packets are lost.

Without this, the lack of antenna/receiver diversity would cause unacceptable levels of data loss between transmitter and receiver due to multi-pathing, shadowing and several other propagation effects that are quite significant on 2.4GHz.

	Quote:
	By the time you get enough people on 1 channel that the Spread Spectrum encoding stops being effective nothing is really going to help. You have to hop.

That is true.

	Quote:
	I don't think though that XPS lets you transmit on the same channel as someone else? I know spectrum wont do that.

Yes, because the transmission is also subject to time-division multiplexing with about a 10% duty-cycle, it is possible to have multiple systems on the same channel. However, if XPS has disabled the CSMA then the practical number of simultaneous users on a channel will fall significantly and never come even close to the theoretical maximum of 10.

[cluster-buster]

	Quote: Originally Posted by gareth.ky
	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.

Currently, the manual claerly states, that only PPM modulation is possible. PCM will eventually be possible with a future firmware upgrade. As far as I know from studying my product manual.

[JKos]

We know via multiple independent tests that the XPS system is indeed a two way system. We know that it will retransmit a PPM frame's data up to three times. Those retransmissions occur relatively rapidly and well before the next PPM frame comes from the transmitter. If the system gets all the way to four total transmissions, it waits until the next PPM frame occurs and tries again.

> I don't think though that XPS lets you transmit on the
> same channel as someone else?

Sure it does. That's the only way to have more than 12 simultaneous XPS users.

> However, if XPS has disabled the CSMA

It would be easy to test this if one has two XPS systems, a two-channel oscilloscope, and can get them to both come up on the same channel (this is possible). All one would have to do is monitor the transmissions of both transmitters and see if they ever overlap. Monitoring for transmissions is extremely easy as the voltage clearly drops at the power in of the module during a transmission.

It would be very interesting to feed both transmitter modules the same PPM stream. That would clearly and immediately indicate if CSMA is on or off.

Unfortunately, I have only one XPS system so I can't do this test myself.

- John

[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.

[Daemon]

Here is my style of testing, using a powerful 2.4Ghz wireless video Tx.
The video clip is mostly self explanatory, but it's interesting to see how much information
can be discovered with this simple test.
Link to the video http://www.vimeo.com/793881
The second part of the video is recorded from the point of view of the wireless camera itself
and it shows the XPS signal on top of the video signal visually.
The two places I held the XPS Tx were equidistant from the Video Rx, so the noise didn't
come from being closer.
The video shows:
1. When XPS is linked normally, there's only about 1-1.5 XPS packet per video frame (PPM frames
are what.. 20ms.. 1 video frame at 30fps is about 33ms, so that's consistent.
2. When XPS is turned off, the noise goes away.
3. When the XPS Tx is moved around to behind the video Tx the powerful video Tx blocks
the signal, and pushes XPS into failsafe.
4. When the Tx has lost the link to the Rx, the XPS Tx starts retransmitting furiously
and you see somewhere around 4 transmissions per video frame
5. While the XPS Tx can't see the XPS Rx, and is only 12 inches behind the video Tx
it's still retransmitting, even though the powerful noise is on its channel. That's how we
know that the "look before you transmit" feature (CSMA) of XBeePro is turned off.
6. This is more subtle, but if you look at the actual shape and characteristics of the XPS
noise you can see that the normal packet + ACK from the Rx look a little
different than each packet when the Tx is retransmitting and there's no ACK.


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