When we try to test code on our robot communications cut in and out randomly while using the wireless bridge. When we connect via USB, or via Ethernet (both directly to the roboRIO, and through the OpenMesh) we get constant communication, but not if we connect through WiFi. Every couple of seconds while connected through WiFi we loose the connection for about a second. The driver station reports no communication to the radio at this point, and then it returns. If we are running code while this happens, it will still be running when communications returns, so nothing is crashing as far as we can tell. We have examined the electrical wiring and found nothing out of the ordinary. 
Are the power lights to all the robot components staying on?
Just the radio cutting out?
Yeah, all the lights are on when communications cut out.
We had something similar happen and found that our CAD software had an update program running in the background that liked to eat wifi alive. Do you happen to have CAD software on said equipment?
No CAD software, or anything similar. But while looking through task manager I noticed that a lot of CPU and RAM were being used, so maybe the driver station can’t keep up? I’ll try another computer and see.
I tried running the driver station on a new computer, with no other apps running, and it helped quite a bit, however there are still moments when it cuts out. It’s almost unnoticeable unless you look at the graphs, but I assume this is not intended behavior. Also, the packets get dropped at regular intervals, for about the same time, so I don’t think it’s just random interference. But for now, I think our problem is solved. I would like to know what was causing it to drop packets though.
Make sure to check all of the power connections through to the radio. Start from the battery and trace through the PDP and VRM to the radio. Check to see that all power connectors are very tight. Wireless comms are the first thing to go if the battery hiccups for a second, so this is most likely the cause.
Are you running any large bandwidth features like video? The 7mbit bandwidth allocation per robot is being done on the radio now (although I do not know how that is affected when not going through the FMS…but I will ask that tomorrow/tonight when I have access to people that should know that answer). Regardless, the dropped packets are QOS’d to be the user generated type and not control traffic…but who knows.
The home version of the Radio Configuration Utility emulates the competition field conditions by setting the limit in the OpenMesh. That’s also where it will be enforced during competition.
You can browse to the OpenMesh and see the limit setting.
We were having a similar problem today. It was with a new Windows 10 laptop we bought this year. When we connected with the DS laptop from last year (Windows 7 with this year’s new dashboard), it connected fine.
We did not have any time to diagnose it further.
That’s interesting. I didn’t consider Windows 10 vs Windows 7 having an impact. I was using my own laptop at first (with Windows 10), and later tested it on our team laptop (Windows 7) when it started working. I thought that it was processing power (my laptop is quite slow, but our team laptop has some decent specs), but maybe there’s a bug with how the driver station program works on Windows 10?
Also, for the other replies, I don’t have access to our robot or workshop right now, but I will have access on Monday. I’ll be sure to check the wiring, and the settings for the OpenMesh. I don’t think we’re going over the 7mbit limit, but maybe the camera stream is taking up more bandwith than I thought?
Is the Win 10 task bar crashing when it disconnects?
First…Open up the rear of the laptop, make sure both the white & black antenna wires are still attached to your wireless NIC card properly…some need to be white to white labeled nub/black to black. Just had a customers unit that had intermittent wireless…sure enough the unit was fine when it was on my desk near my router (About 1’ away), put it (laptop), on my lap, no connections avail. at all…Someone had been inside it recently, neither wire was connected, both were sitting 2" away from the card itself. (1 of your antenna wires may be connected/1 disconnected from the Wireless adapter).
Is the Win 10 task bar crashing when it disconnects? (Have someone closely watch the taskbar for it to disapper and re-start or re-appear, and see if both that and your disconnection issue is related). If so, that points to a simple hardware driver issue (with the MS Win 10 Native Installed Drivers usually). Easy fix is usually track down which driver is causing the issue, and see if Hardware MFG Win 10 Driver(s) are avail…If not, try Win 7 or 8, or 8.1 drivers for that hardware item, see if the problem disappears).
Do you have AVG Free installed as an AV? (I upgraded a Win 8.1 laptop we have as a driver’s Station -2015’s, and a Win 7 Laptop we have as a backup Driver’s station -2014 both to Win 10 to get them both simply matching in OS’s, and they both already had all the 2016 NI software and all the updates installed on them before the upgrades). Both said all apps/programs, etc. were fully compatible except spybot S&D Ver. 1.62 of course…I always re-install that anyway.
The newest one - the Win 8.1 unit, had a hardware driver issue of some kind after the upgrade to Win 10 and the native Win 10 native OS drivers were installed, that I did not currently have the time to fully isolate…appeared to be graphics related though to me, and it was crashing & restarting explorer - It would crash explorer about once every 5-10 Minutes.
Then I installed AVG Free on it, restarted it, updated the AV, and went to sleep…finally. (I was going to figure out from the reporting system exactly what driver was causing the issue when I woke up later…But, I never actually got that far).
When I woke up later, and there were 7 NI files removed & in the AVG Free Virus Vault…AVG was so proud of itself saying “LOOK WHAT WE CLEANED OUT FOR YOU!”
I have never actually been furious of a working AV before…Usually they are my absolute best friends. (Later I figured out they were false positives, as I had previously run Malwarebytes, Spybot S&D, and Hitman Pro, and Windows Defender after the Upgrade to Win 10 and each found absolutely nothing).
I rolled that unit back to Win 8.1 immediately (only takes about 30 minutes), as it is done using the Windows.old folder created at the beginning of the upgrade, and uses a simple System Restore snapshot prior the upgrade…End of issues, the NI software was fully restored and unaffected, all 7 files that were in the virus vault were back in their proper places. No more explorer crashes (no taskbar restarts)…I’ll deal w/ upgrading that unit to win 10 after the current FRC season ends.
Currently, we are now running the programming test bot (drivetrain w/ CAN, compressor and 1 air tank storage, etc.), on either laptop -Win 8.1 & 10 (Tethered USB or Ethernet, or wireless), now that all of the firmware (RoboRIO, OM5P-AN Radio, and PCM has been all finally flashed & properly configured, and the roboRIO was formatted (ran the self tests), and test code was finally deployed -Using Labview. (We faced numerous repeated mDNS connection issues w/ both laptops occasionally on that path, and had to switch back and forth between laptops to get all of that successfully done though).
Seems like that is a problem with the new mDNS auto IP feature…We are still investigating what is causing that situation to develop occasionally - connecting to begin with usually via USB, not disconnections, as it just assigns each device an IP, and when we switch from tethered USB to Ethernet cable or back on the Laptop NIC, it won’t simply release and assign a new IP or return to automatic reassigning of IP’s to devices switching between USB, tethered or wireless…even with a laptop restart). It says missing a necessary network setting…but, does not specify what network setting is missing upon running the network troubleshooter -states problem is not fixed!
Simply switch laptops…And immediately we are back in business.
Weird science!
I doubt it. It is cycling too fast. We have an LED attached to a camera. The LED lights up for approximately 5 seconds, shuts off for about a second, turns on for a few seconds, and repeats.
If the task bar was crashing, I would think it would take more than 1 second to reload.
At first, I thought it was the LED drawing too much current from the roborio (driving the LED directly, and not through a relay), and the cycling was related to power or heat. But, when it worked fine with the old DS, that idea went out the window.
It could be a packet limiting issue. I will check the network utilization (task manager). Maybe windows 10 is doing something funky. I know FMS prioritizes packets, so maybe it won’t be a problem with the field system (but then we may have choppy video).
Interesting comment about the code on the RIO running ok. If our code was running, the LED wouldn’t cut out (I don’t think).
I’m not sure where you are doing your testing but we are (un)fortunate in that our host school has a no-wireless-APs policy that is strictly enforced by broadcasting de-auth packets to everything around it that is not in a whitelist that the administrator maintains.
It has lead to some serious problems for us in the past, and it sounds remarkably similar to what you posted in the first post, but we’ve come up with several solutions and workarounds and honestly, the best one has been to just talk with the admins and get our particular APs on the whitelist for the school.
Hope that helps.
We didn’t notice it crashing at all, in fact everything seemed completely fine, except for the whole loosing communication thing. It also seemed to be cycling too fast for the taskbar to crash, same as what rich2202 was noticing above.
The DS that was causing issues is running in boot camp on a mac, so… Can’t really check the card, and I really hope it’s all still working.
The trouble DS ran out of battery and shut down while we were updating the NI software… It appeared that everything installed properly, but maybe it messed up some files, and that’s causing an issue? Other than that, I don’t have anti-virus on the trouble DS (Oops! I need to get on that!)
I don’t think our school has any strict policy on it, but in the past they have gotten mad at us for our router we’ve set up in the shop so we can connect to the internet. I don’t know if they have the same de-auth packet thing going on, but if so that might explain some things. The building we are in doesn’t have any wifi, but the school admin building is next door, and their wifi just barely reaches us, so if they’re broadcasting de-auth packets from there maybe they cut in and out every once in a while. I can probably get in touch with the IT folks and ask about that.
Check that you are not on the same channel as one of the schools channels. Get a program called inSSIDer from http://www.metageek.com/ to find out.
If your robot network is on the same channel, then you may need to set your equipment to a non-used channel. We had this problem with symptoms you described.
-Hugh
We recently had a similar issue. It was cause my a brown out cause my high current draw from the motors. The issue came up when we added additional drive motors we change from 4 to 6. When driving from stop to full speed it would be fine. It would ocur when quickly changing direction from full forward to reverse or hard left turn to hard right. We corrected the issue added a delay to the code. Before it react immediately to changes in speed, it now takes about 5 cycles before it will reach the requested speed.