[Greg McKaskle]

What were results of the wifi? The difference between 150ms and 1500ms is huge. Did you fix the 1500 or did it just go away?

As for the field radio conditions. I have not seen evidence that the lag is typically there. I volunteer at a few events per season, so it could be that it happens when I'm not looking.

On the other hand, at every event, the situation plays out where a team blames the field and swears that fill-in-the-blank symptom has never happened before. Each time the issue has been debugged, typically on Thursday, and is caused by static discharge, a HW, or SW failure that just didn't show up until the rigors of competition.

The DS this year has a tab on the far right called Charts which displays and logs the packet loss, round trip time, cpu usage, and battery voltage. It also displays the tiny dots which show the state the field is asking the robot to be in and the state(s) that the robot code actually executed. This last feature only works if you insert, or don't remove, the instrumentation code that is in the framework. Program Files\FRC Driver Station\ also contains a Log File Viewer app to review and compare logs from shop and competition. If you run your code through the practice match, not just tele and auto separately, and you watch the last tab on Thursday, I think you are prepared. If the gremlin exists, I hope that the new tab helps to identify it sooner, whether it is a robot HW, SW, or field problem.

If you get to an event and decide to lower throughput on the field, I'd suggest lowering the resolution and upping compression to 60 or 70.

In testing I've run three cameras on a single robot in our eight story office -- a super wifi noisy wifi environment. The limiting factor was the old laptop's ability to decode and display. If you can reproduce the 1500ms or larger lag, please give details.

Greg McKaskle