view timing window? And next time it happens i will. But it is what i said, 44004 Driver Station Lost Communication with the robot
When you say the same problem, what exactly do you mean?
This is how you get to the “View Timing” window:
The robot losing connection repeatedly, used to be the whole internal issue with print and error messages thing, then after the patch its 44004
This was during one of the disconnects? If so it isn’t related to DS timing
nah, just resting, not doing anything but being connected to the robot
Thanks for your comments.
Our switch is powered from a VRM (one of the old voltage regulator models).
We’ve looked at the voltage trend on the drivers station and it doesn’t ever seem to drop below about 10v.
One of our diagnostic tests was to power the switch from an isolated 12 v battery and we still saw failures in that case. In that case there was no way that its 12v supply saw a voltage drop.
We should have a new switch to test either today or tomorrow.
When the disconnect occurs, do the LEDs of the switch give any indication of what is happening? There should be overall power status and link status for each device plugged in.
Greg McKaskle
We installed a gigabit switch and the problem seems to have gone away. Strange as I would not think we were pushing 10MB let along 100MB
We appear to be having the same issues as many before. We are getting the same warning 44004 and 44000. When it happens the robot disconnects from driverstaion and immediately reconnects within 1s.
The issue is also very repeatable. Our shooter is currently a 2x neo v1.1 double flywheel and when a note is fired through it the moment the voltage drops seems to disconnect it. We have tried causing a voltage drop with aggressive driving, intaking while driving. Nothing else causes the issue.
We tried removing our network switch (brainboxes sw-005) and the problem went away. It’s worth mentioning this issue seems to have become more of an issue (or at least repeatable enough that we are paying attention to the issue) since we attached a limelight. Nothing has been done with it yet though (still last years photon vision).
Nope, the switch looks fine and we even powered with a separate 12V battery to no avail. BUT we installed a gigabit switch and the problem is gone.
This is so crazy, yet EXACTLY what we were seeing. Only losing communications while shooting even though the shooter was barely causing a voltage drop. We could stall the drivetrain into a wall and cause a much larger voltage drop and never lose comms.
Two D-Link switches we’ve used successfully through entire previous seasons were failing 100% of the time when shooting this season’s robot.
We just put in a TP-Link LS1005G today and the problem is gone.
¯_(ツ)_/¯
1 Like
Any chance Ethernet and cables for the shooter motors are bundled together for a long run?
Not in 4020’s case. They are about as separate as can be. Ethernet is all in the base in the front of the robot. Shooter power originates in the PDH at the rear of the robot and goes up an arm structure.
1 Like
My guess is the impulse of the motor stalling against the note is resulting in a much larger drop, but is of such short duration that it’s not showing up in logs (which only sample at about a 20 ms rate). If you have access to an oscilloscope, it might be insightful to get a higher sampling rate capture of the voltage at various points in the chain. My guess is that some of these devices either have less input capacitance or an input-side undervoltage detector that is triggering on the very short drop, resulting in a hiccup or reboot. It might be worth trying adding some input capacitance at the input of the switch to decouple it (it’s a custom circuit, so this is perfectly legal to do).
2 Likes
Another discovery. We can only reproduce the issue on carpet.
Does that suggest a rapid generation of electrostatic charge when the shooter wheels rub against the note?
So at first we thought it might be our battery mount pictured below which is super close to the ground. That wouldn’t explain why it happens while shooting.
Temporarily we added a grounding wire from the frame and the problem went away.
We’ve been able to make driverstation connect by killing random processes that are using the network from task manager. Not recommend, but you know