Your take on CAN...

[techhelpbb]

Originally Posted by Levansic

In another thread in the electrical forum, there were complaints about the field system. We didn't have problems on the practice field, but many teams had on-field failures of the radio links. Quite a few came back to the practice field trying to diagnose their problems. Some were genuine power supply issues, but not one team noticed or mentioned that there were over a dozen active Wi-fi networks in the half of the arena where the competition field was.

My point is that the cause of failures is many and varried. Often convenience and relying on hearsay causes the finger of blame to point to one component or technology, when a more thorough examination without preconceptions will unearth the true cause of problems.

I totally agree about the number of WiFi networks at the events. It's really crazy compared to the normal density of networks even in a place like downtown Manhattan. There are easy ways to get a feel for it, given the number of 'smart phones' available, there are Android and iOS apps that can show you the networks and their respective strengths. Many are free.

During the one event we had trouble at last year there were at least 10 networks sitting on the default channel according to my Android copy of WiFi analyzer. Not sure how or why that was allowed to happen. There was a time when a person with a Agilent spectrum analyzer would sit right near the field to watch for stuff like this.

Additionally you are absolutely right, an open mind is the best policy in the absence of quantifiable evidence of an issue.

[mjcoss]

Originally Posted by Levansic

In another thread in the electrical forum, there were complaints about the field system. We didn't have problems on the practice field, but many teams had on-field failures of the radio links. Quite a few came back to the practice field trying to diagnose their problems. Some were genuine power supply issues, but not one team noticed or mentioned that there were over a dozen active Wi-fi networks in the half of the arena where the competition field was.

My point is that the cause of failures is many and varried. Often convenience and relying on hearsay causes the finger of blame to point to one component or technology, when a more thorough examination without preconceptions will unearth the true cause of problems.

In my opinion, the field issues has little to due with the other networks, although it will make the problem worse. FIRST has set it up such that teams can inadvertently saturate the field network. The camera can, and on the newer cRIO must be, connected to the DLINK, and the driver station can access the camera directly, bypassing the cRIO. This allows for streaming video from the camera with no compression, and at its highest rate, i.e. 640x480 @ 30 frames a second. It only takes a couple of robots stream video this way to saturate the field. Add to it that you can send data back and froth from the driver station to the cRIO via open unregulated ports, and you have a recipe for bad field behavior. In addition, 802.11n is susceptible to interference from other networks notably 802.11g, and this will reduce the overall data rates achieved. Also, the default code locks the periodic loops to the arrival time of driver station packets. If the network is congested, the jitter and latency of packet arrivals will be awful causing stuttering and unresponsive robots. While on the practice field or at your build site things will be fine. We have toned down our usage of the back channels to try a minimize our impact on the field, but this is a real issue and hopefully at some point FIRST will try to do something about it.

[Alan Anderson]

Originally Posted by mjcoss

FIRST has set it up such that teams can inadvertently saturate the field network. The camera can, and on the newer cRIO must be, connected to the DLINK, and the driver station can access the camera directly, bypassing the cRIO. This allows for streaming video from the camera with no compression, and at its highest rate, i.e. 640x480 @ 30 frames a second. It only takes a couple of robots stream video this way to saturate the field. Add to it that you can send data back and froth from the driver station to the cRIO via open unregulated ports, and you have a recipe for bad field behavior.

You might not be aware that the field access point creates six independent wireless networks, one for each team. One robot's network usage is not at the expense of the other robots' bandwidth. Too much streaming video from a robot can bog down its team's Driver Station, but it won't mess with other teams.

In addition, 802.11n is susceptible to interference from other networks notably 802.11g, and this will reduce the overall data rates achieved.

Doesn't the field wireless use 802.11n on 5 GHz? 802.11g is on 2.4 GHz and shouldn't interfere with that.

[mjcoss]

You're right that if they are running at 5 Ghz (which they should be), then they should be isolated from other networks running at 2.4 Ghz, but not other 5 Ghz networks in use. And while they may be running each team on a separate channel, there *appears* to be an issue that is correlated to the number of camera feeds streaming on the field.

I noticed this phenomenon last year, and it seems to be worse this year. I may have jumped to the wrong conclusion but I think that someone should be looking with a network analyzer to see what is really happening on the field during matches with various compositions of streamers, and/or robots making use of the open channels from/to the cRIO, the dashboard, and the driver station.

[techhelpbb]

http://www.chiefdelphi.com/forums/sh...69#post1137769

There was a discussion about the field issues and connectivity in this topic as well, I'm providing it for reference because troubleshooting tools were discussed that didn't exist last year.

See Greg McKaskle's post at the bottom of the first page.