Packet Loss when Drive Station window is moved

I recently made a post for what I thought was an issue with a wifi adapter on our drive station computer.

There is massive packet spike when either the wifi menu is open or the drive station window is moved somewhere else on the screen. Simply clicking and dragging… bam, packet loss is near 100% for a solid 2-3 seconds! Pictures attached illustrate the issue in simple terms.

However, after more debugging, we found the issue to not be specifc to:

  • Computer hardware
  • Windows version
  • Physical locations
  • Robot hardware (inc. radio and powering types)
  • The Java code loaded on the roboRIO(s) (or no code)
  • The dashboard type loaded up
  • Battery voltage or draw

We also experience these losses at random times in addition to the triggers seen above. Occasionally the robot completely disconnects for a split second. We have no idea the cause and are desperate for a solution.

Thanks in advance for any help!

Edit: Logs from a disconnection that happened randomly.

1 Like

I tried it and me, too.
I’m running tethered and little else running on my PC. Looks like moving/refreshing the DS window occupies much of the DS so it misses some roboRIO communications.

Both computers we used are nowhere near underpowered. Maybe I will try downgrading FRC Game Tools from NI

Also, when you open the WiFi menu at the same time, does a spike happen? (When wirelessly connected)

It wouldn’t surprise me that both opening other windows and moving the DS window causes packet loss. To hit the determinism that is wanted to hit a consistent 20ms timer, iirc its basically treated like a game would be. Which means it needs to be the main focused window, and not moving.

Some of this might be able to be worked around by moving windows to high performance mode. The default balanced mode will take away power from any window not currently the main window.

1 Like

The WiFi menu thing is definitely not a surprise. What Windows does when you open that menu includes scanning for wireless networks, which means it needs to not be talking to the wireless network you’re currently connected to for a period of time. Best action there is simple to avoid doing that.

That didn’t turn out at all well. Did figure out how to create the High Performance profile and used it. The DS log stopped updating - no records are being written to the file (according to the record counter on the log display window; maybe that window is not updating)! The cpu utilization of the PC also went down appreciably. Back to balance for me; I never had a need to move the DS window around much so it’s not a problem for my team.

1 Like

Is this the problem you care about? If so, the issues you mentioned are likely to be unrelated. If you can reproduce the problem and upload driver station logs, we can likely help.

If they are unrelated, then reproducing the random issue will take some time. I don’t have any way to cause the high ping without the two triggers outlined. When it does happen I will upload such logs from the viewer. Thanks for the suggestion.

1 Like

Turns out it happened quicker than I thought. Linked are two logs, it spawned a new log on disconnection. I do not see anything of interest, but I am not knowledgeable in this respect.

So, things look pretty normal (I assume the robot was just sitting there?) and there is a loss of communications which lasts ~8 seconds. This is consistent with something going on with the WiFi on the DS computer. Is this something that happens periodically (say, every 5 minutes or at whatever regular interval)? Is there anything going on with the robot at the time? This is a fairly strange set of symptoms, so getting as much information and as many clues as possible should help here. If you tether via Ethernet, to the radio, does this make the problem go away?

You’ve tried swapping out many things to make the problem go away. Can you describe the WiFi environment (is this a school, does this happen in different places, etc.)? I’m sorry to have so many questions, but this is an odd one. If you have only used school-issued computers, it’s also worth trying with a non-school one.

It’s worth looking in the Windows event log right around the time of this occurring (https://www.howtogeek.com/123646/htg-explains-what-the-windows-event-viewer-is-and-how-you-can-use-it/). You are especially looking for anything to do with networking.

I’ve not had an occasion to do a deep dive on Windows networking in quite some time, but this tool might help: Windows 10 quietly got a built-in network sniffer, how to use. It sounds as though you’ve been chasing this for a while, so it’s probably worth trying to use this, or a similar, tool to really drill down into what is happening at a low level.

Thanks very much for uploading the logs – sorry to not have anything beyond more questions!

EDIT: You might try some of these steps, if you have not already done so: https://windowsreport.com/wifi-connection-drops-every-few-seconds/. I wouldn’t download anything, and certainly not pay for anything that claims it will fix such issues. Also, what WiFi adaptor are you using – especially if this has been the same type throughout?

My team’s mysterious radio disconnects at competitions and at home dropped to essentially 0 when we started using static IP addressing for all devices associated with the robot.

1 Like

fwiw I experience a similar issue with many programs on Windows, where moving the window around lags the program. Minecraft is the first example that comes to mind, the game completely freezes when moving the window around.

No, thank you for responding. It hasn’t happened tethered, as far as we know.

Since it is becoming obvious that the WiFi menu and window move thing is separate, I will make a new post with the answers to these questions. It happens infrequently, so I cannot be certain if and when I will figure out whether it is per robot. Thanks for the suggestions! I will ping you if I find these answers out.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.