Kiwi's XPS test results are up.

[JKos]

> One of the primary features of the wireless stuff is that is does
> **not** blindly transmit and step on itself

This is simply not true. There is no FCC requirement for collision avoidance, i.e. listen before transmit. This is a widely held myth that seems difficult to squash.

> - that's how multiple devices can exist on the same channel cleanly!

No, it's called spread spectrum. In a network situation in which multiple devices are attempting to share the same "pipe", if you will, collision avoidance makes sense. It is even used in wired networks like Ethernet. But for our application, it does not make sense nor are any of our RC 2.4 GHz products using it.

- John

[Four Stroker]

Julez

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

While we are myth busting:

There is absolutely no requirement to listen to a channel before transmitting on it in the 2.4GHz ISM band. That is, there is no collision avoidance requirement whatsoever.

Download for free and read part 15 section 247

http://www.fcc.gov/oet/info/rules/

If you can't find it in part 15, it's not a requirement (unlicensed equipment).

[tadawson]

	Quote: Originally Posted by Julez
	This appears to be the only logic solution. After all, one does not want one's system to stop transmitting, when interference is encountered, does one?

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

[gareth.ky]

"Spread Spectrum" means smearing your signal across the channel your transmitting on. If you'll read the post above or the wikipedia article you will see how several devices on the same "channel" can co-exist.

The big reason that systems like the XPS and Spektrum look for an empty channel is swamping. You don't want to place two emitters on the same channel in the same physical place.

People imagine that its some sort of time devision multiplexing. Each device transmits in the clear on its own time slice. Its actually far more clever and robust than that.

Its actually more like this. The device is transmitting on a continuous range of frequencies (a channel). Its sending a sine wave. That wave is modulated or distorted by a known value. Positive distortion indicates a 1 and negative distortion indicated a 0. This is called a chip. The radios send several chips for each bit.

For each chip the radio knows that it should be receiving on one of two possible very precise frequencies. like 2.4508 or 2.45016. Other chips being sent by other devices on the same channel wont land on those two frequencies and they can be ignored.

Seeing neither or both of those frequencies lit up causes the chip to be discarded. The send several chips per bit. So you might only need 2 good chips out of 8 to know you got a 1.

It's pretty slick stuff.

[Flyfast1]

	Quote: Originally Posted by JKos
	> One of the primary features of the wireless stuff is that is does > **not** blindly transmit and step on itself This is simply not true. There is no FCC requirement for collision avoidance, i.e. listen before transmit. This is a widely held myth that seems difficult to squash. - John

John,

While you're at it, would you please quash the myth about "lockout"!

-Ed B.

[JKos]

Ed,
I'm really not sure what you mean.

- John

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