Reoccurring field control disconnect issues

Looking for some help trying to figure out why our robots keep disconnecting. Cross posting here as I’m hoping @jpearman can offer some advice.

Some background, all of the JHAWK electronics are relatively new, with the oldest items being from late 2023; however, we have bought some items as recently as late 2025. Additionally, we did have some similar issues on the 24 inch robot last year DCing (not the 15 inch robot). This robot had 12 motor drive (15 motors total), and based on the suggestions of a couple people, we swapped it to 8 motor drive. This solved the issue and not sure if it’s relevant but I’m including it anyway. This season, we started off without any DC issues at the first tournament of the season. This was running the legacy field control. We did not add any electronics after this event before our next event.

At our second event of the season, we began having major DC issues. Our first match of the day went without issue. During our 2nd match of the day, our 15 inch robot collided with another robot wrestling in both robots DCing (video: https://youtube.com/shorts/WfHyhCq_BcQ). By resetting the controller, I was able to reconnect to the robot. Beginning in our 3rd match of the day, the 15 inch robot began not starting autonomous correctly. Every time that the autonomous program started, the 15 inch robot would DC and reconnect without needing to reset the controller after roughly 7 seconds. Notably, the field log did not report this as a radio drop.

Additionally, the robot also DCed regularly throughout the event at a rate of roughly once every other match and required a controller reset to begin driving again. Interestingly, we did not DC only the skills field the entire event, only the match field. Multiple other teams also reported DC issues on the match field as well. The event was also very dry and cold (approximately -20C). At this event, we swapped out the basic items such as controller, radio, and radio cord with no noticeable difference. We did not swap out the brain as we didn’t have time between matches.This event was using smart field control at both fields.

After this event, we tested our 15 inch robot using field control at our workspace. We ran the smart field control off of a brain connected to a windows laptop running TM. We were no longer immediately disconnecting at the start of auton. This led us to the conclusion that there was an issue with the field control at the 2nd event we attended as our robot appeared to be working well for us now and we had no issues at the skills field at the event. At this event, we did not have issues with the 24 inch robot DCing. For reasons unrelated to the DCing, we swapped out all but one of the motors on the 15 inch robot and added 2 additional motors onto the 24 inch robot.

At our 3rd event of the season, we continued to experience DC issues. At this event, both robots would regularly disconnect from field control, both in matches and in skills. This required the controller to be reset in order to reconnect to the robots. This happened roughly every other match for each robot. Sometimes we would go multiple matches in a row without a DC, in our semifinals match our 15 inch robot disconnected twice and our 24 inch robot disconnected once during the match. They were showing up in the field logs as a radio drop now. The disconnects were not the result of robot-robot interaction or collisions, as we disconnected while driving without any robot interaction (video: https://youtube.com/shorts/cjEsfkVUzJM )

During the event, we swapped out the brains, controllers, radios, radio cables, radio mounts, and start order. We tried mounting our radio statically off of the main chassis, on standoffs well above the height of the rest of the robot, and electrically isolated on polycarbonate. We tried plugging into field control then turning on the robots and starting the programs as well as starting the programs before connecting to field control.

Since coming back for the 3rd competition, we have done extensive testing trying to find the issue. We ran 10 matches using smart field control as described earlier on our 15 inch robot and did not disconnect once. At the suggestion of another, we tried running matches with multiple robots connected to the field. We only have 4 brains so we could only have 3 robots running off of smart field control. Out of the 5 matches we ran, the 15 inch robot disconnected a single time, requiring the control to be reset. We did have the robots driving around on the anti static tiles during the tests to try and be as accurate as possible to a real competition environment. We did not disconnect on the 24 inch robot once despite this occurring multiple times at the competition we attended last weekend.

I am currently hesitant to make any changes to our electrical systems and code, as I am unable to currently replicate the issue we have been experiencing at events. Given we can’t replicate the issues, we won’t have any way to know if the changes we make will actually result in less disconnects. If anybody has any information on why we aren’t disconnecting at home compared to a competition, that would be greatly appreciated.

Here is one of the brain logs from when we repeatedly disconnected mid match at our 3rd competition of the season:

03:23.212 ,Field ,Match End ,201 ,0
02:52.433 ,Field ,Drive Start ,225 ,0
02:52.403 ,9 ,connected ,81 ,0
02:52.382 ,Field ,Lost radio connection ,225 ,0
02:52.372 ,Field ,Disabled ,225 ,0
02:52.362 ,9 ,connected ,58 ,255
02:40.937 ,Field ,Lost radio connection ,0 ,0
02:38.615 ,Field ,Drive Start ,225 ,0
02:38.595 ,Field ,Disabled ,225 ,0
02:38.585 ,9 ,connected ,81 ,0
02:28.558 ,Field ,Lost radio connection ,0 ,0
01:53.875 ,Field ,Drive Start ,225 ,0
01:17.642 ,Field ,Disabled ,201 ,0
00:47.682 ,Field ,Auton Start ,209 ,0

Using the v5 firmware utility I was able to gather the versions of all of the electronics

date : Wed Feb 11 2026 16:16:14 GMT-0600 (Central Standard Time)
version :
vexos : 1,1,5,0
Serial : VEX V5 Communications Port:COM11
CPU0 : 1.1.0b6
CPU1 : 1.1.5b18
Assets : ok

Devices :
port 2 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 4 : V5 IMU (Type 6) version: 1.0.0.b15 boot: 1.0.1
port 5 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 6 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 8 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 9 : V5 Rangefinder (Type 7) version: 1.0.0.b2 boot: 1.0.0
port 10 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 11 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 13 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 15 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 16 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 18 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 19 : V5 Motor (Type 2) version: 1.0.0.b31 boot: 1.0.4
port 21 : V5 Radio (Type 8) version: 1.0.0.b48 boot: 1.0.2
port 22 : V5 Tri Port (Type 12) version: 1.0.0.b11 boot: 1.0.1
port 23 : V5 Battery (Type 14) version: 1.0.1.b25 boot: 1.0.6

Everything here firmware wise appears to be up to date. We are currently coding using vexcode pro and I would be willing to share code or the full brain logs if needed.

Here are some of the potential problems that I have identified (which again I am hesitant to try changing given we can’t replicate the issues).

A motor is causing a current spike. Based on this discord post this could be an issue: (Discord) This would explain why we have gone to comps without any DC issues yet at others we have had multiple. However, I do not know how to correctly replicate the issue and cannot test which motor is causing the issue and we are not finding anything about a motor trying to say it is connecting in logs.

Printing to the controller and rumbling. Based on these VF posts: (Eccentric Robot disconnects - #3 by jpearman and V5 Disconnecting and not Reconnecting - #5 by jpearman ) rumbling the controller and printing values to the screen could cause DC issues in older firmware versions. However, this code is the same as I have used in years past and at our first competition this season where we didn’t experience any disconnects. Additionally, in one of our matches at our 3rd competition I accidentally ran the wrong program that doesn’t rumble the controller at all and we still DCed that match.

Persisting tasks. Based on this post: Competition code and user created tasks we could have issues, as we continuously run a printing stats to the brain screen and controller task. However, this code is the same as I have used in years past and at our first competition this season where we didn’t experience any disconnects and I believe this isn’t an issue if you turn on your robots after connecting to field control (which we usually do and are still disconnected while doing).

Again, if anybody has any ideas or other resources, these would be greatly appreciated.

We had DC’s at Worlds last year and the help desk did some signal strength testing. One of the tests was to drive away in a straight line. Typical robot should get like 50ft away before losing connection. We only made it 10-15 ft. New controller fixed the issue.

Sorry for the late responce but didn’t have the space until recently to test. The robot was capable off driving over 400ft before we ran out of room to drive it further. I beleive this is not the issue.

@jpearman do you have ideas of what could be causing this or insight on best practices for radio mount, order to plug into field control, ect.

not really

Could you elaborate on what the reccomended mounting point for the radio is? Connected to the rest of the robot via metal or ellectircally isolated? Also, when you did these tests, V5 Disconnecting and not Reconnecting - #5 by jpearman , did you turn on the robots then have them connect to field control or connect to field control then turn on?

same advise we have used for years, from kb.vex.com

Mounting the V5 Robot Radio Best Practices

  • Do not wrap the V5 Robot Radio in metal foil.
  • The higher the mount location on the build, the better.
  • Do not mount the V5 Robot Radio in a steel box.
  • Keep the thinner part of the V5 Robot Radio away from other metal.

so that was 4 years ago, do I remember ? nope.

It’s a bit complicated for worlds as whenever you connect the controller to field control (before or after starting code) it’s not going to be placed onto a competition channel until the field activates when it’s time for the match to begin (meaning if another field is running you will still be on a pit channel). That means that there’s a good chance the radio will be disconnecting while you wait.

once on a competition channel, the connection should remain stable, this will happen 1 - 2 minutes before the match starts while the MC introduces you etc.

If I were competing, I would avoid sending text to the controller so field control has the best chance of reading the vexos version and other data it requires on an initial connection with your controller (it does this once only on connection) and probably start my program after switching to a competition channel, this may annoy the field techs trying to get your team ready, but I think a VexU team can politely explain to them that you know what you are doing.

Having said that, every year at worlds we get connection issues that we cannot explain and this year, in a new venue, will be no different.

Replying back to this so that if anyone else runs into these issues they can hopefully also resolve them. Over the course of JHAWK’s last 2 compeitions of the season (both smart field control) and a couple of scrimmages (some legacy some smart), we did not disconnect a single time. We made multiple changes all at the same time, and clearly one of them worked.

  • Removing controller prints. For our last 2 events, we did not have any information print to the controller.
  • Ending tasks early. In order to prevent tasks from running in driver controller, we ended all tasks (such as odom) right at then end of auton (29.95 seconds into auto). The tasks were then restarted at the beggining of driver controller.
  • Different motors. 2 of the motors on the 15 inch robot were swapped out and the entire 24 inch robot was rebuilt.

Again, no clue which of these fixed it, but if anyone else runs into these issuese I would reccomend trying these things as they worked for us.