You are mixing up separate issues.
radio disconnects, smart cable being removed from the controller etc. all should have been logged in the FC andTM logs (and visible to TM operator).
What Levi and I have never seen before is an apparent power loss of two controllers simultaneously (or close to that, hard to see on the playback). A cable disconnect should not be able to cause that, some other type of damage to the cable, perhaps, we will do some investigation next week.
Speaking of radio disconnects, what exactly does “Radio Disconnect” mean on the V5 smart controller? Is that 100% on the team or is that a field issue - or could it mean either?
Technically, the field has no radio running the fields. What the Field Control does is control the state of Pause, Autonomous, Driver mode signaling. With VEXnet Field Control it was signal sent through one of the leads to the Joystick controller (V5 or Cortex in the day). V5 Field Control App does a lot more communication between the field controller and robot’s V5 Brain, which allows logging of events, such as the Robot’s brain signaling a disconnect. The Robot’s V5 Brain will use having something plugged into the RJ45 plug on the controller as a signal to the brain to switch from pit radio frequencies to competition frequencies (to reduce interference from other robots). V5 Field Controller will signal to switch to competition frequencies once you plug the V5 Smart Cable on the driver station to your V5 Joystick Controller immediately or when the field status switches from “Standby” to “Ready”. This latter behavior is setup on the fields V5 Brain settings for the event.
So in this environment, the Radio disconnect logged is likely due to an event on your robot - it can be a loose V5 smart cable, it could be because your radio is buried deep inside a mishmash of metal, or a momentary glitch when your robot take a hard hit on the field (like crashing in the perimeter or other robots).
Do bring these event logs to the attention of the Event operations team - they might not have a strong answer right away, but certainly can help diagnose possible causes and later allow them to look at event logs later…
Be thankful that the VEXnet communication protocol has been much improved since early days when you had to ask pretty much everyone to turn off their phones, even in the audience, and you still had that one person who had to have their MiFi hotspot device running 
Thanks Pascal. That is the common sense answer, but I’ve got to believe there is more to it than that. For example, can a faulty cable running to the controller cause a “radio disconnect”? Can they be caused by too many robots on the competition channels?
So too many robots on same channel is a concern that they contend with at Worlds and had skills fields that had a high concentration of fields run bluetooth communication. By design the competition fields run on different channels reserved only for robots running on active fields. @jpearman has posted how this all works on the forum. I am sure he can chime in to correct my misconceptions.
We’re not really sure. There is no generally understood mechanism by which the field control, old or now, would be able to spontaneously cause a disconnect during a match.
However, throughout my 9 years in this competition I have seen too many simultaneous alliance disconnects or even whole field simultaneous disconnects to believe that there is no way for the field to cause one.
You can check out this thread for a great explanation of the older field control hardware by @jpearman himself, as well as a discussion about potential field faults in the 2017-2018 season:
As a ref my rule of thumb is that if no other teams were simultaneously affected, then it was probably an isolated incident to that robot from bad radio mounting, damaged wires, or plain bad luck. Am I 100% sure that the field wasn’t involved? No, but since I have no way to actually verify either way, I have to choose the most likely outcome. If multiple teams on the same field were affected simultaneously and it arguably changed the outcome of the match however, then that’s worth looking into a replay for.
I’m pretty sure. The most likely causes of radio disconnect are either poor radio placement, damaged hardware or some environmental condition (don’t run microwave ovens at events).
Dude, you are killing me! our volunteers depend on the non-stop appetizers we serve them fresh from our 1950s Radar Range!
(sorry - humor-ish)
My favorite Aunt had this and it was amazing, popcorn in moments, bagel bites, hot chocolate chip cookies, etc. So are you saying that when she pressed start and the lights dimmed and Uncle Chazz grabbed his chest, it was all related?
A Raytheon Radarange microwave oven aboard NS Savannah, installed circa 1961.
1
The galley has an early generation of microwave oven so the ship’s cooks could “nuke” food long before that shortcut became commonplace in American homes. 2
ok, let’s make that the last microwave post and get this topic back on subject.
@jpearman apologies - channels crossed - skills control disruption issue from other thread - trying to debug that one…
A post was merged into an existing topic: Field controllers disconnecting at skills competition
I understand the most likely causes, but what is it exactly that triggers the “Radio drops” counter on the V5 Smart Field Controller? I’m guessing that the V5 Smart Field Controller is just polling the V5 brain on the robot and that V5 brain reported a radio drop/disconnect?
The majority of status that the FC system has comes from the controller either directly as internal controller status or status the brain has returned as part of the normal radio communication. One very fundamental piece of information that the controller has is VEXnet radio status, either the controller has a good link to the brain or no link to the brain. If the controller to brain radio link is lost during either the autonomous or driver control periods we record that as a “radio drop” on the team status page. The V5 robot brain will also log a radio disconnect.
Are both “disconnects”? if not, what is difference from FCA that a Radio Drop vs a Brain recording Disconnect?
I think this is confusing teams - is this a symptom of flaw in robot or field control?
When I have discussions with teams it is important they understand what is happening - is it a problem they need to solve? or a problem for EP to fix and in questionable situations, replay match?
It’s the same thing, lost of radio link, I probably used “drop” on the FC team status as the word “disconnect” wouldn’t fit. I don’t remember.
why would it be a flaw in field control ? It’s the same thing we have always had to deal with, radio comms is disrupted for whatever reason, VEXnet radio usually turns from green to red on the robot. changing from the legacy control to new FC system should make no difference.
sometimes, if the radio is buried in the middle of the robot the radio should probably be moved.
the $64k question, over the years the general approach is no replay unless all robots disconnect simultaneously for significant amount of time.
Is it just me or does all robots DCing seem much less important to replay than all from 1 alliance?
certainly you could argue that both alliances were equally inconvenienced.
So one bug I witnessed is that a team had to unplug and plug in to a smart match controller cable several times before we could start the match. Each time they plugged in, their controller would disconnect and go “searching” for the paired robot, but so long as the controller was plugged in, could not find it.
If I understand you correctly, the paired controller likely swapped to a competition channel, and for some reason the robot brain did not… also know to do that? So is this likely a radio issue, a controller issue, or a brain issue? Also, it did eventually work, and could not be replicated.
This was one of several weird events we observed. I had to play whack-a-mole with the Match Control Brain ports. Suddenly one would no longer connect, and I would just move it along to the next port in the quadrant, and the next one, and the next one until it works.