Joystick code downloads - survey data

We have 15 teams and most of them use two joysticks (driver and operator).

I am seeing a number of failures where the second joystick stops operating the robot. Our current best fix is to reload the code in the primary joystick (the one with the VEXNET key).

I am trying to put together data on when this happens and why. I would like to see responses from you that has data:version of the joystick code you are running (and I’ll accept "RobotC or Easy C version numbers), what happened prior to the failure (threw the controller to the ground), and what the fix was (reloaded code in primary controller).

While I’m appreciative of moral support posts of “yes we see that too” but I’m interested in hard data. I’m not seeing a pattern yet, so I’m looking for hard data points to track this down.


are you using the old pic or cortex?
you use a tether to connect the 2nd joystick to the first (one with the vex net key) right?
this has never happened to us before, but the first thing i would do it to check the tether connecting the 2nd joystick from the first

They are cortex joysticks. First joystick all the lights are normal for a VEXNET connection. Second joystick - green robot light. Fix is to reload the code in the first joystick.

None of the teams I support have ever used paired joysticks, so I can’t help with the survey results.

Hypothesis1: (Murdomeek) tether cables have low quality connections.

Hypothesis2: Low battery;
If CortexJoystick code needs reload, then it seems likely that the EEmemory is getting corrupted somehow. This is already a known problem when batteries are low. The tether passes digital data from joystick to joystick, so they must at least have a common ground through the tether.
Is there a common power connection also.

The next step beyond generating hypotheses is to test them by deliberately trying to recreate the problem.
T1a. Pay more for a new higher quality cable.
T1b. Wiggle, disconnect/reconnect the tether.
T1c. Make a breakout box for the tether cable and break each signal one at a time.

T2a: pop batteries from secondary joystick, bounce either joystick in the direction that is most likely to despring the battery connections.
T2b: use weak batteries, let them run out

Just because you can re-create the same symptom with a deliberate act, does not insure that all such symptoms come from similar acts: ie “correlation does not imply causation”, (but it does waggle its eyebrows significantly and suggest looking in that direction, nudge, nudge)

We’ve had temporary drop outs from the 2nd controller, but none that we reprogrammed for. We might of had to turn the controller off and on.

Just a follow up.

We are using RobotC 2.30. The reloads seem to be around battery change, which on the surface seems to be wrong.

We have identified that it’s the SECOND controller that is having the problem, not the primary. So we now download the firmware to those joysticks first.

Thanks to all that replied.

we have had this issue a number of times with our second controller dropping. we are using the current version of easy cv4. the first time we had a bad tether cable and replacing that solved the issue (you may want to try that) but the other times we had to redownload the firmware in the secondary controller (it mysteriously wiped) and the problem was resolved

Why would battery change be wrong for eeprom wipe problems?
Battery changes are associated with low batteries, which are associated with low-power-glitch during eeprom updates, which leads to bad eeprom values, which require reloading.

Do you have a specific proceedural order for changing the batteries?
What order of ( OFF, untether, swap batteries)?
If you wrote up a DOE (Design of Experiment) and tried all orders, and leaving out various steps, you might find something repeatable, which would then point to an obvious (after the fact) explanation.