Quote:
Originally Posted by NCollins
OK, after numerous calculations here is the data for 802.11 channel interference. Although it is true that only 1,6,and 11 have no crosstalk AT ALL does not mean that there are only three channels with low enough interference to work.
|
Sorry - not OK. First, the non-overlapping channels 1, 6, 11 are not totally free from adjacent channel interference. They are called non-overlapping because you have three channels with nominal channel widths of 22mhz spaced 25 mhz apart. When transmitting on 6 for example, most of the signal energy will be in 4 - 8. But there will still be signal energy in channels 3 and 9 that can interfere with channels centered on 1 and 11. While the adjacent out of band signals are typically -20db - 35db below the peak signal, this is still sufficient to cause interference. This is because the signal in the adjacent channel, while 20 - 35 db lower than the the peak signal, can still be nearly as strong in absolute level as a signal you are trying to receive that is ten times father away. Adjacent channel interference is a particular problem when the interfering transmitter is very much closer than the transmitter you are trying to listen to. This is exactly the case if you try to operate several robots in close proximity with the robots relatively far from the stations they are talking to.
Quote:
Originally Posted by NCollins
Cisco tested a 4 channel system using 1,4,8, and 11. In their test they found an only 1% interference overlap. With such little crossover they only found problems when using a large amount of the bandwidth at one time.
|
Even when operating on the exact same channel, two networks interfere only when they occupy the channel at the same time. Very lightly loaded networks, even on the same channel, have little noticeable interference consequences due to link layer retransmission. You won't see the effects until you have larger amounts of data on one or the other network or you are running an application that is sensitive to packet delay. Teleop control is such an application where you do not want such delays. You won' care about a 400ms delay surfing the web. You will when controlling your robot.
I suspect the Cisco example showed access points spread apart by some tens of meters. This is enough to reduce the interference seen at the access points. However, two laptops close together operating on different networks will experience lots of mutual interference. In the normal office operating environment wireless nodes are normally several meters apart or operating on the same network.
Quote:
Originally Posted by NCollins
Using similar calculation I extrapolated the crosstalk with the system I described above (1,3,5,7,9,11). I found a crosstalk interference of only 5.47% outside 802.11 guidelines. Also at a distance of only 12.45 inches there is a drop in power enough to lessen the crosstalk below guidelines as well.
We also need to remember that the robots this year are only running at 19.2 Kbps. 802.11 provides up to 11000Kbps.
The guidelines for 802.11 require a 30dB drop for no interference.
|
I have no idea what 5.47% crosstalk interference means. I would expect that the total combined throughput of the 6 networks you suggest would be well below that of a single network. Operating 6 robots on 1, 3, 5, 7, 9, 11 would probably not be too pretty, especially with synchronous traffic. When the robots are in close proximity, they will overwhelm the signals from the much more distant stations they are communicating with. The traffic would have to be extremely low for this to be workable. Bluetooth would probably a much better solution for multiple independent networks in close proximity. Or 802.11a where there are many more channels. Or a channelized system like we have now (operating on other than 2.4 GHZ).
Operating a single access point per field with 6 robot stations and using wired LAN from the Operator Stations to the field controller is IMHO the way to achieve the best performance. The single access point can employ 802.11e to provide QoS for teleop control packets (and possibly telemetry) and the beacon rate and other network parameters can be tuned for optimum system performance. The Field controller can also shape the traffic to equalize the access for the six teams or even for the two alliances. Adjacent field would operator on non-overlapping channels. All of this off-the-shelf stuff. There would be very few re-transmissions or holdoffs in such a scenario - mostly from outside interferences. If FIRST is planning on 802.11b/g, I do hope this is what they are planning. Personally, I'd like to see 802.11 a/b/g radios in Linux capable boxes all around for maximum flexibility.