Many thanks to Greg McKaskle from NI for looking into our log files and helping explain how to decipher what's in them and from Tom, Bryce, and Mr. Lim for suggestions re: WiFi. Their comments raised two branches of thoughts:
First, re: the log files:
Is there any documentation that explains the errors/warnings/logging system in more details? The "FRC Driver Station Errors/Warnings" on ScreenStepslive.com is helpful, but incomplete. In particular, it would be helpful to understand how status checking/logging works from a high-level point of view. Does everything come from the DS, or can the cRIO or DLink log events? Which components can log which events? Which components check on which other components? Where (DS, cRIO) does the Watchdog Expiration come from and what does it mean? How is it possible to have a Watchdog Expiration when you haven't had a 44004 "DS has lost comm with the robot" or any other warning/error?
Second, re: WiFi configuration:
Setting up, configuring, and debugging WiFi deployments is part of my day job, though I am by no means an expert – if I had been on my game, we wouldn’t have had the problems we did during the parade. That said, I’ll take what the guys above have suggested and add my own thoughts at a first stab at a concise list of best practices for “mission critical” demonstrations:
- Do a site survey ahead of time. While it won’t tell you the impact of 40k spectators or guarantee that the environment will be the same during your event, it will tell you what bands & channels are in use at that time. At the very least, do a survey using something like inSSIDer or a similar tool. If you have the means, scan for non-802.11 traffic using tools such as Wi-Spy, Channalyzer, etc.
- Use 5.8GHz, and unless you really know what you’re doing re: FCC channel allocation rules in that band, set the AP to auto-select the channel and/or use DFS. On the other hand, if you know what you’re doing and read the FCC rules very carefully, and depending on where you are located and the results of your site survey, it may be possible to find a channel that you are almost guaranteed to have all to yourself.
- Have a separate AP that the DS is hard-wired to, and setup the radio on the robot in bridge (aka client) mode to connect to the AP.
- Use a hidden/suppressed SSID w/ WPA2 Personal & AES.
- Use MAC filtering on the AP to restrict WiFi access to the client radios that you want to have access (the robot radio, possibly a backup DS). This may cut down on the work the AP has to do to reject attempts to associate.
- Don’t scrimp on the AP – Does anyone have any specific models they have had success with? I’d lean towards building a custom unit based on Mikrotik hardware & RouterOS, if only because that’s what I’m most familiar with.
- Hi gain antennas and high powered radios may do more harm than good! Yes, they may allow the AP to reach a mile away, but that’s not useful for our robots. They’re only necessary when the transmitter & receiver are “really far” apart. What constitutes “really far” is subject to interpretation, though I’d put it at 20-30+yds in open space. The problem is that hi gain antennas have a much narrower “beam”, and if the antenna isn’t aligned correctly (usually vertically), you may find that the signal strength 200yds away is higher than it is 30ft away. And even if it is aligned correctly, you don’t want to let the cell phones 200yds away know that you’re there – or to be able to pickup their signals if they attempt to associate.
- Use a directional/sector antenna on the AP – IF you can be sure that it will always be pointing in the direction of the robot.
- An AP that supports MIMO (multiple antennas) should help, especially indoors.
- I’m not sure I agree w/ Mr. Lim re: using 802.11n – Our robots don’t need the bandwidth that N-mode provides, and forcing the radio into N-mode means using a wider swath of the RF spectrum, which means that you’d be more likely to run into interference. I don’t have any hard evidence to back this up, though.
- In general, setup the AP & client to the most restrictive set of “advanced” WiFi settings that they can both agree no. The default settings of most APs allow compatibility with the widest variety of devices possible. For the fixed configurations we’re dealing with, that’s not necessary. For instance, use Long preamble only, disable WMM, disable “burst mode”, etc.
- Don’t use proprietary extensions that promise to boost throughput or range. They almost always rely on the AP and all clients being of the same brand (sometimes even specific models). Many are only useful for cases where there are a large number of associated client devices and/or extremely high bandwidth requirements – neither of which apply for a robot & DS.
- Always, always, always have a really long Ethernet patch cable as a fallback in case you can’t get the wireless to work!
Lastly, YMMV!!! Some of the above are my opinions/hunches based on non-FIRST experience, and my team will be testing them out at some point in the future. Don't take any of it as gospel - try it out on your own and report back the results. If something doesn't work or makes things worse, narrow it down to the specific thing that's causing the problem.