Weird WiFi Router behavior?

Technical Programming
1

Hi,

Over the course of the past couple of weeks, I have had some annoying problems with our WiFi router. The annoying problem is that sometimes, our computers that are on a network bridge don’t show up on the network.

This doesn’t seem to be the network bridge itself because we switched from a normal 5 port unmanaged one to the old DLink routers and the problem still persists. When it happens, the dLink router doesn’t even show up let alone the computers. This issue shows up about 1/10 times of turning on the robot. We really need to connect to our coprocessors for vision processing.

So, if anyone has had a similar experience or any idea of what might be happening, we would love to know!

Thanks a bunch in advance!

2

seems like you are having an mDNS problem. The old dlinks do not handle mDNS.

If you give your computers a fixed IP address, and point your code to the correct IP addresses, that should solve your problems.

3

We actually have all static IPs. The same problem also happens for another network bridge we have laying around.

4

can you ping the other computers?

Could be a windows firewall setting on your Driver Station.

5

No, we can’t ping them. I run an IP scan on the network and the only things that show up is the WiFi router itself and the roboRIO. If the router works correctly, it should show the router, the Rio, the dLink, our mini-pc, and our Raspberry Pi.

6

You don’t mention it, so I have to ask:

  1. Are you trying to find the other computers from the Driver Station?
  2. Is the Driver Station connected to the RoboRio via Ethernet or USB?

Assuming that your Driver Station is connected via Ethernet (either tethered or Wifi) via the radio, and you can see the RoboRio, then your radio is likely working just fine.

Are the computers on the Robot?
What is the IP Address of your Driver Station?
What are the IP Addresses of the other computers?
I assume you have a hub/switch on your robot to connect the other computers (there are not enough ports on the Radio). Have you confirmed that the hub/switch is working correctly?
Can you tether to the roborio via the radio (that is to confirm that both ethernet ports are working on the radio)?
Did you disable DHCP server on the Hub/Switch, and anything else that might conflict with the Radio?

7
  1. Yes I am trying to find the computers via the Driver Station. However, when they don’t show up on the network, the RoboRio can’t find them either as our autonomous goes a little crazy when it comes to the vision part.

2)The Driver Station is just connected over WiFi.

-Yes, the computers are on the robot.
-IP of our Driver Station is dhcp. Do we need to set it as static?
-Mini-PC: 10.44.80.12, RPi: 10.44.80.13, RoboRIO: 10.44.80.2. All subnets are 255.255.255.0
-Yea, the dLink lights up and works. I suppose one thing I could try is connecting via ethernet to the network hub so I can make sure that it works. However, the setup is currently on the robot in a bag.
-I have not tried connecting to the main router and using the roboRio from it yet. Maybe something to try. Although, I did switch the ethernet ports on the router to see if that helped and it unfortunately didn’t.
-Yes, the dLink has disabled dhcp and the address it is set at is 10.44.80.3

It is just weird that it happens 1/10 times. So it doesn’t seem to be a hardware problem unless the WiFi router has an odd problem. We even used an unmanaged hub that we had lying around. That one had the same problem.

I really appreciate the help!

8

-IP of our Driver Station is dhcp. Do we need to set it as static?

It shouldn’t make a difference, but since everything else is static, you might as well, just in case: 10.44.80.5

-Yea, the dLink lights up and works. I suppose one thing I could try is connecting via ethernet to the network hub so I can make sure that it works.

Just because it lights up does not mean it works 100%. Might have a bad port.

-I have not tried connecting to the main router and using the roboRio from it yet. Maybe something to try. Although, I did switch the ethernet ports on the router to see if that helped and it unfortunately didn’t.

If you switched the roborio to the other port, and you could still connect to the DS, then both ports work.

Have you tried changing the ethernet cable that connects the radio to the dlink? Changed the port it is plugged into on the dlink?
I assume you have turned off the Dlink’s wifi.

If ping is successful to 10.44.80.2 (DS-Radio-RoboRio), but can’t reach 10.44.80.12 nor 10.44.80.13, then the problem is somewhere between the Radio and the computers. If you can’t reach both, then it is likely somewhere between the Radio and the Dlink.

It is just weird that it happens 1/10 times.

Make sure the DS has a static IP address for the wifi adapter and the Ethernet (hard wire) adapter. The next time it happens:

Ping the radio, roborio, dlink, and Pi while still connected to wifi. Record your results.

Disconnect the wifi (turn it off on the Driver Station), and tether to the Hub. Then retry your pings. Record your results.

If you get different results wifi vs tethered, then the results should tell you where to look.

Another thought: If your ethernet cables go near a motor, then the motor may be generating a lot of interference in the wire.

We even used an unmanaged hub that we had lying around. That one had the same problem.

unmanaged hub to replace the dlink or the radio? If it replaced the dlink, then i’m guessing you have a bad cable between the dlink and the radio. It could also be the radio. Do you have a spare radio you can swap out?

How are you powering the dlink? could it be flaky power to the dlink? Do the dlink lights look right during the problem times? Dlink should be off the 5v 2A connection of the VRM, with nothing else on the 5v2A connection. Are you overloading the VRM? I believe the Pi needs more than the 5v500ma of the other port on the VRM. Do you have a separate VRM for the Pi? Are you trying to power both the Pi and the Dlink off the same 5V2A connection? If so, that won’t work.

9

Really it won’t work? So both of those slots run off of one 2A breaker? We are running both on 5V 2A but I just assumed that each slot had its own 2A capacity.

10

2a/5v master rail
That’s 2a peak, it’s only 1.5a max steady load
for all four sets of 5v connections combined.
The 500ma connections are also part of that 1.5a power load-they just have an additional limit.

reference page 3 & 4 of: VRM User’s Guide.pdf

11

So we should probably add either another VRM or one of the old 12V to 5V converters?

12

I don’t know what your total power draw is, but that’s why in the past only the radio has been allowed on the 5v/2a or 12v/2a connections.\

With insufficient power the radio might appear to boot, but fail to initialize wireless transmissions.

13

If you put the dlink on the 5v2a rail, then nothing else should go in the other 5v2a connector.

If you are not using the 12v500ma rail, then something like this might work for additional 5v1a to power the Pi. Check to make sure your pi + devices don’t draw more than 1A.

https://www.amazon.com/SMAKN-Converter-Power-Supply-Module/dp/B00CXKBJI2

The old 12v to 5v converters work too. That would have to connect to the PDP.

That’s 2a peak, it’s only 1.5a max steady load for all four sets of 5v connections combined

It is my understanding that you can get 1.5a max steady from the 5v2a rail, and another 500ma max steady from the 5v500ma rail, for a total of 5v2a steady.

Limitations
● Current draw must not exceed 500mA on 500mA-channel.
● Continuous current draw must not exceed 1.5A on 2A-channel.
● Peak current draw must not exceed 2A on 2A-channel.

There is no limitation of “continuous current draw must not exceed 1.5A combined”

14

Since the VRM was redesigned in 2016 that’s probably true for the ones from last year forward. They got more robust.

For the older model from 2015, this is from our Beta testing in 2015.
Through limit testing on the 12v rail (not on the 5v) we were able to get it to fail through overheating by loading both outputs to their respective steady state load of 2a combined. A component upstream of both circuits would fail. Although, the failure would only occur after running the loads for a while and occasionally hitting peak to simulate startup load.

We repeated the test on the redesigned models in 2016 and they worked great. We forced the breaker with peak loads repeatedly, but no damage was suffered by the VRM.

15

Has this problem been resolved for you? We’ve been having similar issues with our robot network typically working from power-up, but sometimes (maybe 1/3 of the time) having our DS laptop be unable to communicate with either the RoboRIO (but still see our IP cameras) or the reverse of being able to see the IP cameras, but not the RoboRIO. I’m wondering if you found a resolution for your problem or not?

16

Assuming that you are using the AC radio, be sure to see team update 17.

17

Thanks, Joe! I’d missed seeing that information!

Yes, we are using the AC radio, rather than the AN radio. Sounds like we could instead connect our switch to the port nearest to the AC radio power connector, and plug the RoboRIO into the switch – at least that would probably result in an “all or nothing” situation which would prevent the match from being started before we have IP connections to all our devices.

Or, if the AN radio doesn’t have the problem, maybe we should just use the AN radio instead? Is anybody aware of any advantages to the AC radio as compared to the AN radio?

18

At the regional we spent time with a number of Orange Hats figuring out the radio issue… because it had become 50/50 on the system booting and working or not. But furthermore, our Robot was reporting odd variables to FIRST Through their system. Ultimately… Our robot was not showing up as enabled for them, or even on the field During Gameplay through data and signal… but yet we were still out there with communication to our drivers station and playing. So they wanted to see what was happening and how this variable was occurring.

With two hours of deliberation, we tried a number of items with no success, but ultimately boiled down to Two things that we ended up doing. On a whim our Radio from 2017 was one of our major culprits. We swapped to the 2016 Radio, and of 7 boots in the pit, consistently showed communication and data from our PC (7 times Booting perfectly - statistically eliminates the probability of it being “Chance”) The orange hats didn’t know what the main issue with the radio was but overall we finished the remainder of our semi finals rounds, and the elims with full vision and auto working.

I don’t recall what the second item we ran into was… I’ll talk with one of the students, but I believe it was something to do with Subnet Masking.

19

Thanks a lot for the above suggestion! We’ve only been seeing the problem on the competition robot at tournaments, but not on our practice robot. We had been presuming this was because of a difference in the radio configuration for home use and tournament use. However, after reading the suggestions here, the note in Team Update 17 on the radio, and talking with an engineer at FIRST, we think the problem may be instead related to the 2017 radio – in particular, we think the issue may be an intermittent ethernet configuration issue on the 2nd port at boot-time.

Accordingly, we’re taking our 2016 radio (OM5P-AN) to the tournament and will try using that instead of the 2017 radio (OM5P-AC) to see if the problem is resolved.

Thanks!

20

We have also had terrible luck with the 2017 radios. We have two of them and both fail regularly, although one seems slightly more reliable than the other. It is really unfortunate at competitions! We plug the roborio into the POE port and a D-Link switch into the other, which has our raspi and arduino, and driver-station/developer laptops as needed. When the radio decides to fail, none of them can communicate with the roborio. We have swapped ethernet cables and the secondary router and even tried different brands, but the problem still happens… not every time, but maybe 1/4 times or so. We have deduced that the radios are just buggy. This is with all static IP addresses configured on all devices.