I haven’t seen a device behave like that. Can you try a new USB cable and see if that helps? Does the USB-C connector feel loose or anything? Are you using multiple controllers and is this the only controller behaving like that?

I agree that this is a sensor error, (e.g. controller is in Brushless mode, but no sensor plugged in?).


I was testing a Spark MAX motor controller connected to a Spark Neo in a gearbox. While operating the Spark Neo with a joystick plugged in to a custom arduino box to simulate PWM signals, it sent voltage back into Cross The Road’s power distribution panel and to other connected components: three Spark motor controllers, Spike relay, arduino, and Cross The Road’s voltage regulator module. That voltage combined with the 12V from a power supply plugged into a wall outlet (steps down 120V to 12V) managed to fry the arduino, voltage regulator module, and the radio. When we did some testing using the Spark Neo plugged into a gearbox (tying a cord around a gear and quickly pulling it) we found that the Neo was generating up to 40V on its own. We theorized that the frying of the components was due to the power supply being plugged into the wall and not holding the voltage at 12V while receiving generated voltage so we switch it out for a 12V battery and found that the excess voltage was not distributed to other components when we did the same test. Our base worry is people pushing their robots and generating enough voltage to kill their electronics. We are speculating the use of zener diodes to prevent this problem in the future, but we know the legal use of them is yet to be posed to FIRST. If there are any other theories to why the components were fried along with solutions, we are open to hearing them.


Nick, we received pictures of your setup from another member of your team and it was unclear to us exactly what was going on based on the pictures.

We were about to ask for more information when I noticed your post here on CD. From the information you provided both through email and in this post, this is our theory of what happened:

Many AC to DC power supplies are not very good at maintaining steady voltages when experiencing rapidly changing conditions (transient loading). Additionally, these types of power supplies are not good at absorbing current flowing back into them.

For example, if you were running a motor off of one of these supplies and you stopped it suddenly, the built-up electrical energy in the motor still needs to flow somewhere, and on an FRC robot, some will flow back into the bus capacitors within the SPARK MAX, and the rest will flow back into the battery. Unless you have a power supply designed to absorb this back flow (a four-quadrant supply), the voltage across a less advanced power supply may spike significantly.

We believe this is what damaged the other components on your test setup.

We recommend only running motors, including NEOs (connected to MAXs of course), off of a battery. Make sure the battery is appropriately sized and fused for the application you are testing.

This should not be a concern. You would need to push the robot at over 3 times the maximum speed of the robot in order for the NEOs to generate anywhere close to 40V. We have tested pushing robots at many different gear ratios and have not measured any voltages significantly higher than 12V.


We have the basic drive train set up using CAN with the FRC components with 4 SPARK MAX controllers. One controller was giving us the alternating error lighting until about the 5th time we pushed the firmware. We attached two to the left side of the drive train NEOs and all functioned as expected amid high fives and cheers. When we connected the other two MAX to the same NEOs, it ran for about 5 seconds then the problem controller started flashing the error signal again and movement stopped. I believe the colors were orange and magenta, but will recheck in the AM.



This error code indicates there was an issue with the encoder input into the MAX. Double check that your NEO encoder cable is fully seated in the Encoder Port on the MAX.

Also, double check that you haven’t inadvertently switched the Sensor Type to “Encoder” on the Advanced tab of the SPARK MAX Client (or in your code). When using the NEO, you must set the Sensor Type to “Hall Effect”.


Is there a particular license the Java artifacts are under? I noticed the C++ artifacts are under the BSD-3-Clause license, but couldn’t find a license file in the jars.


We recently got our spark maxes / neos and have been successful in configuring them (with the quick config, 40A limit). We can drive around in teleoperation and it seems to drive fine except for the following problems:

We get the following error repeatedly:

  • Loop time of 0.02s overrun

  • Warning at edu.wpi.first.wpilibj.IterativeRobotBase.printLoopOverrunMessage( Loop time of 0.02s overrun:

I used System.currentTimeMillis() to measure how much time the teleopPeriodic function is taking, it ranges from 8ms to 40ms when all it contains is the following:
public void teleopPeriodic() {

long starttime = System.currentTimeMillis();

drive.arcadeDrive(pilot.getY(Hand.kLeft), -pilot.getX(Hand.kRight));

System.out.println(System.currentTimeMillis() - starttime);


In addition, when we attempt to access the integrated encoder through
leftEncoder1 = new CANEncoder (left1);
the values keep on jumping between 0 and the actual measurement

Also we double checked that the encoder cable is fully seated, and we couldn’t push it any further.

Do you have any ideas for how to fix these problems?


We are also seeing the encoder occasionally throw a zero. We have switched several Neos and Spark Controllers and the issue persists.


+1. Ive noticed that as well.


We are working on this now, I expect the fix will be with the roboRIO SDK, we are tracking this here


I’m also confused about the units of the encoder. I noticed it says RPM for velocity and Rotations for position. Is RPM ticks per minute or actual rotations of the motor? And is position just ticks or a fraction of a rotation?


It is actual rotations of the motor. We are working on a method to scale this to a desired unit on the controller side, we are tracking this feature here


We were looking at performance differences between using our own controller versus using the built in SPARK MAX feedforward and PID. I’ve seen multiple applications feedforward gain in control loops in the past. Is there a block diagram or anything that could give us insight to the integrated SPARK MAX controller? :guitar:


Block diagram and firmware implementation can now be found in the SPARK MAX User’s Manual here.


We’ve traced this issue to being a timeout on the CAN bus due to the way the CAN API works. To fix this we’ve added time for the data to be considered ‘valid’, and can be adjusted using the setCANTimeout API. The default timeout is 20ms, plus 2 times the frame rate. We’re released this as an optional update here:

In addition we have added a card to our near-term roadmap to add a function call which includes a timestamp with every reading.


Thank you for tackling the problem so quickly, just have a few follow up questions:

So my understanding is that we were receiving old packets from before the motors started moving and they were the ones with the 0s? If that’s right, does that mean that the encoder value won’t be updated as often because some of the packets won’t arrive in time? If so, do you think there could be a scenario where the encoder position won’t be updated for more than one loop (20ms)?

Also, have you been able to figure out this problem as well?


Please help. Our Spark Max Motor Controllers keep switching to brake mode while we are running them. Has anyone else encountered this issue?


I haven’t noticed the controller changing to brake mode when connecting to the GUI (after running them). However, I have noticed something weird: while driving (and the Sparks configured at Coast) the wheels stopped very quickly—corresponding to brake mode. What programming language are you using (we’re using java)? Also, how’d you notice that it switches to Brake?

Could it be that during run time the Java API is setting the controller to brake mode (similar to how you define the motor type when initializing at run time)?


Just started testing my NEO’s and I have the same thing happening. It’s not going into brake mode. But the motion of the motor is choppy. It is switch into brake mode it is super choppy on coast it is less but still there. It feels like turning on and off, like the hall effect sensor isn’t keeping up or something. I get this when running in the spark client and via Labview.


We have had a similar issue. Occasionally, the motor controllers will stop sending a motor command and stay a solid cyan even though the Java code is still sending the command. It seems to only work again after cycling power.