REV Blinkin lockups/resets

We’re using a REV Blinkin on the robot for the first time this year. It is really easy to use, but we’re seeing problems where it occasionally “locks up” and ceases to drive the LEDs. Often it comes back after a power cycle, but yesterday during practice it locked up so completely it would not even go into setup mode. A “factory reset” brought it back, but that is not a satisfactory answer; it shouldn’t get into this state under normal use. The behavior sounds similar to this problem from several years back, for which I didn’t see a satisfying resolution. Power is direct from PDH (which seems to be the recommended approach) and PWM is solidly connected to the Rio via a Swyft board, so I don’t think we’re losing signal.

The drive team really appreciates having the LEDs give feedback on actions, so having this unpredictably stop working mid-match is problematic. That is, since it’s being used for more than decoration, if it can’t be relied upon we’ll need to find alternatives.

Do others see this as well/is this a known problem with the device? We don’t currently have a spare to swap as a test, as this was one we’d bought just to try and then decided to use; naturally they are now out of stock.

Would putting a 12V regulator on its input make any difference, so it doesn’t see the voltage swings on the robot?

Thanks in advance for any suggestions.

Have you seen the Addressable LED support in WPILib? It is really simple to add programming support for LED strings using their example code. (Our programmers incorporated this into their code in about 10 minutes.) You just need to wire the data line to one of the RIO’s PWM ports, and make sure you feed the LEDs enough power.


Sorry, can’t help you on the hardware aspect. Ours got lost in the part reclamation from the 2020 bot and REV was out of stock so we ended up directly driving it off of the PWM and powering from the VRM.
In working with the WPILIB Addressable LED I decided it would be nice to have the ability for patterns to be objects and settable. So I coded up a library wrapper. It is new but seems to be working for us. I would like feedback if you have any.

We have plans in the future to add some decorator behavior and composition but those most likely will not be done soon.


Yes, we’re looking at this as a fallback if the Blinkin can’t be relied upon. It’s certainly possible to make it work. The Blinkin has the advantage of making it really simple even to get fancy patterns, and avoids having to spend any loop-cycle time updating pattern buffers. I was also looking at the CTRE CANdle but am having trouble finding any information on its APIs; the Phoenix docs acknowledge its existence but don’t seem to have any information on how to use it.

1 Like

I share your concerns about loading down the RIO to run a light show. We haven’t noticed any timing or performance problems, even though I suspect we are updating our LEDs every timeslice whether they need it or not.

We are local to you and I know we have a couple Blinkins kicking around our shop. If you need to borrow a spare, I am sure we can help you out.

This looks really cool. There is an Arduino Neopixel sample that has a lot of crazy light patterns you could add.

You might also consider adding support for breaking the string up into logical substrings. ie: A single LED string might be broken up into several segments mounted in different places on the robot. It could be useful to be able to run a different pattern on different parts of the total string.


We were definitely thinking of adding different patterns to different segments. It would just take a bit of rework and important bot work still needs done.

More important than a light show??!? Pfft.

I keep telling my team that I agree with Karthik that driving is first, but then it is led, game piece acquisition, game piece placement, autonomous, then climbing.

How can driving be first when coding always comes last?

Regarding the CANdle, we have API docs in our normal API documentation under the led namespace:
There’s also the examples repository that contains a Java and C++ example on CANdle:

We also have multiple animation support in a dev release

This allows up to 10 simultaneous animations running along the strip and fixes an issue where back-to-back calls to setLED doesn’t always send out the frame that updates the CANdle.
To use the dev release, take the Phoenix.json from this example and replace your project’s Phoenix.json with it. The example also demos how to use the multiple animations. You will also need the new CANdle firmware available on our Phoenix-Releases Repo.

The dev release is what would be a normal release, but hasn’t gone through our normal testing process. This means there is a higher likelihood of bugs. However, we were pretty diligent in testing the new features for CANdle, and there’s very few other changes so it’s unlikely there’s a major bug in it. We keep our dev releases public on our maven server, so everything should be fine to use the dev release in competition.

Hopefully this helps clear up some of the confusion with CANdle, and if you’ve got further questions you can reply here or shoot an email to our support!

1 Like

Thanks, @TytanRock for the links. I think I followed a pointer into the framework docs when I should have gone straight to the API. We’ll take a look at the CANdle as another possibility.

1 Like

What do the other LEDs (Status, 5V, 12V) on the Blinkin indicate when it locks up? This may help us determine what is going on, and hopefully get you back up and running quickly.

When the lockup that required a factory reset occurred, the Blinkin status LED was steady blue and would not change, including when attempting to enter Setup mode (where it would normally turn yellow). We tried pulling the PWM cable and saw no change then, either, when we’d expect it to start blinking due to loss of signal (and outputting the default LED pattern, which it did not do).

We have always run with 5V LED strips and I’m pretty sure that the 5V strip LED was on as well - honestly since we haven’t ever changed strip select from the default we didn’t pay much attention to it.

When we’ve lost LED output but had it come back after a power cycle without a factory reset, I think status prior to power cycle has also been blue, but we didn’t always pull the access panel off to verify. I will pay attention to this as well when we’re at the shop tonight.

If you are capable taking a video showing the status and strip select LEDs when the failure occurs, that would really help. I know you’ve said you haven’t actively ever switched the strip mode, but the LEDs can still give us information.

Understood, will tell the team that when we see the failure occur we need to stop and capture that information. Thanks!

We have the same problem with both of our REV Blinkins. It will require a factory reset to get them to work again.

Looking at this suggestion, is this available in Labview too? I only see Java or C examples in the link provided.

Look at “Installed Examples” under Resources from the starting window.
You’ll find an LED strip lights example for PWM controlled WS2812B LEDs under “Digital”.

1 Like

Thanks to everyone who followed up here. My electrical and software leads jumped on this last night, and we’ve converted our LEDs to use the WPILib support for our upcoming Week 1. We had a 5V 3A regulator on hand which we’re using for power, and we just bypassed the Blinkin to feed the PWM signal line into the strip. Software was able to stand up support in short order and the impact to loop cycle time is negligible, even with some nice patterns running.

We may do more investigating on the Blinkin when we don’t have an event looming. :slight_smile: It sounds like the problem is not unique to us, so for now we’re taking the cautious approach.

@Mark_McLeod tried the WPI LED Strip VI example and just tried to keep it simple by doing an Open and Set the colors, but was getting this error. Since there doesn’t seem much documentation on this, do you know what might be causing this error with the WPI LED VI?