[Tutorial] Programmable RGB Lights With VEX V5

Note from mods (specifically @jpearman)
Before attempting to attach an led strip using this technique, please be aware that there are some potential problems that could be caused by driving the MC29 controllers incorrectly. Read the whole thread, there will be an explanation of some of the issues further down.


This is a tutorial on how you can make custom RGB lights that can be controlled with a V5 Brain.

This is the code used in the video.

Feel free to ask any questions you might have.


What is the legality of this during official match play? I am guessing only legal if colors are static/rainbow and give zero user feedback.

1 Like

As it is decoration, there’s no issue regarding non-vex components being used. I would assume your second point to be correct, but there is currently a Q&A question waiting for an answer regarding that.

On my bots I just have it do the rainbow constantly.


I haven’t watched the video, and while this is a fun idea, I doubt many teams would utilize it unless the have those triport expander things whose names I have forgotten. I assume many teams will have already used up all their triports [legacy ports] plus (if lucky) optical or distance sensors.

Regardless, cool!

Luckily for me, I have a triport expander.


You could probably also use heat shrink tubing to insulate the connection points. It’s cheap, replaceable, and arguably cleaner. Nice job though


Yes, but it’s easier to put on electrical tape, and I didn’t have a heat gun handy.


Blow dryer!


1 Like

What parts did you use?

Taran, there are multiple safety issues with the way you do this project!


If you don’t program it correctly - the consequences could range from smoking MC29 controllers to frying ADI ports power rail, all the way to permanently damaging V5 brain or even setting the battery on fire!

I will leave it up to you all as an exercise (for now) to figure out why it is the case before giving my explanations later in this topic.

@DRow or @jpearman could you, please, edit the OP to put “DANGER - DO NOT DO IT THIS WAY” in the title and a warning that RGB lighting should never be implemented this way and the reasons why will be discussed later in the topic.

Also, Taran, you will need to edit your video with proper warnings before anyone followed your tutorial.


Please elaborate on this. The only risk I can think of is shorting the mc29 outputs together.
This happened fairly frequently in cortex days including in my own club, and, on cortex at least, it appears to rarely (if ever) kill the cortex port - it just kills the mc29. The is because the mc29 has a PTC which prevents it from drawing too much current from the ADI/3wire ports.
In addition to this, this page specifies a maximum current of 2A, which makes me think that there probably is an internal PTC (i.e. in the brain). This should prevent an overcurrent/short from killing the ADI power rail as you suggest may be a possible consequence.

I highly doubt a short/overcurrent even on a (hypothetically) unprotected ADI power rail would cause the battery to catch fire. This page specifies a maximum battery current of 20A, again implying a fuse. Also, not having a current limiter on a lithium battery is just plain stupid, and while the V5 system has some issues I seriously doubt the designers forgot about basic battery safety.

While soldering anything always carries a risk of shorting something, it is certainly possible to do it right and mitigate risk. It is good practice to cut the stripped (copper exposed) lengths of wires as short as possible to reduce the chance of them touching. In Taran’s video he makes them very long which isn’t ideal (see 6:00 mins).
It’s also a good idea to make sure that each wire is secured to the LED strip’s copper pad by giving it a tug after soldering.
Encasing the whole thing in hot glue and tape and mounting it securely to prevent excess force on the soldered joints should mitigate most of the risk.

Therefore, I think the only likely consequence of doing it wrong and shorting the mc29 outputs together would be a melted mc29. I think the mc29’s and internal ADI power rail’s PTCs would prevent the ADI power rail from being damaged. I highly doubt that any short circuit on any power rail would cause a battery fire, just because it is such an obvious risk with easy mitigations that will be in place.

Its also worth pointing out that this will only work on 5v LED strips since that is the voltage output by the ADI power rail. You could maybe use a boost converter to up the voltage of the power line of each mc29 to 12v but this might not work, probably wouldn’t be competition-legal, and would be a bit more dangerous as you would be bypassing the short protection offered by the mc29s if a short were to occur in the boost convertor.

@technik3k is short-circuiting the danger you were talking about? If there’s some other issue then I’d love to hear about it.

tldr; I doubt that a short-circuit would cause any more damage than melted mc29s. You should learn to solder well before attempting this to mitigate the risk of shorting. This will only work on a 5v LED strip.


I can’t comment more right now, but later when I write something out it will basically agree with @matthewb and provide some more details about what happens to this hardware when shorted.

Just re-read @technik3k’s comment and noticed you said software. You do raise a good point - since mc29s are H-bridges, it would be possible to connect the positive of one h-bridge via common ground to the negative of another - basically causing a short through software. This would happen if one MC29 was fed a negative number, while another was fed a positive.

This consequences of this shouldn’t be any different to if you shorted the physical wires together as only one PTC would trip (not 2 in series which may increase the trip current or not trip at all, though would probably still be fine). Please see this picture on how that would work. I’ve omitted one of the mc29s since only 2 are needed to show the effect.
vex led strips

There are a couple of promising solutions to prevent a short being possible in hardware.

One (solution A in below picture) would be to put a diode in series with the black wire output of each MC29. This would prevent current flowing forward through the black wire, so no short could happen if you accidentally reversed the polarity. The disadvantage with this is that the diode will drop about 0.6V, so the LEDs might be ever so slightly dimmer.

Solution B is to disconnect the black wire from each MC29 completely and run a 3-wire extension from another (4th) ADI port. Snip the female end and connect only the ground (black, probably) wire to the LED strip’s ground. Since the ground now runs directly to the ADI ground rail, it won’t short out regardless of how badly you screw up your programming. The disadvantage of this is that it uses up another ADI port. Instead of getting a ground from a new ADI port you could also just splice it into the ground wire on the 3-wire end of one of the MC29s, saving a port. That might be even less legal than the rest of this idea.

Simplified diagram of H-bridges with Taran’s initial circuit and solutions A and B:
(Note MC29#1 on the right is reversed like it would be if it was given a negative power, which would, in the first diagram, cause a short)
vex hbridge elds

I think the easiest solution would just be to change the function lights() to this to ensure you can’t mess it up and not bother with the extra hardware.

void lights(int _red, int _green, int _blue) {
    red.set_value(abs(_red / 2));
    green.set_value(abs(_green / 2));
    blue.set_value(abs(_blue / 2));

@Sylvie, you said this was legal. However, wouldn’t this violate R13.D? “VEX electronics may not be used as non-functional decorations”. Might be worth a QnA perhaps.
Also, I’m not sure about the legality of diodes since the vex people always seem to be a bit frightened by electronics but I suppose they’re part of the decoration.

Let me know what you all think about my solutions.
For this I’m assuming that the PTCs are on the positive rail input or the red output. If they aren’t then my solutions may be bypassing them. This isn’t ideal as a physical short may essentially cause a short between the ADI power rails - defeating one of the layers of defense (see my above post).

Anyway, @technik3k , you have a point but its solvable and doesn’t seem as major as you were thinking. Next time please explain first rather than scream bloody murder immediately.


Huh, never saw that one before. I guess you could say that it’s not VEX electronics from the control system that I’m using. No one would use an MC29 on a V5 robot for non-this purposes.

I do currently have a Q&A out about lights, but this could be worth another one. @Nathan_Rossi is the main head ref around here, and he’s never had an issue with it.

The GDC has previously ruled that light as decorations powered by the brain are legal, and idk how they expect us to make that work without VEX electronics and modifying them.

I think that the smartest way to avoid these issues would be to connect the ground channel on the lights directly to the ground rail on the brain, like your solution B.

This is copied from my DM with @technik3k about this:

I’ll be honest, I don’t know much about how the electronics in the brain and the motor controllers work. I do understand that they can take the value I give them and output a certain amount of power. I also understand that if I connect the ends of the motor controller to the contact pads on my light strip that it will complete the circuit, and the lights will light up.

From my experiments with this a long time ago, I do know that if connected to a 7V power supply (Cortex motor ports), if the leads on the 2 wire end of the mc29 touch while power is running through them, it will short out the mc29 and the port on the brain.

I have tried replicating this on the V5, and no matter how badly I abuse the motor controllers, I cannot get anything to break.

One final question about these for @jpearman. In competition, I’ve noticed that whenever the lights are on and the controller gets put into disabled mode via a competition controller, my lights go crazy. Like, a restart of the program fixes it, but immediately once disabled the lights start flashing random colors at what I assume is the refresh rate of the MC29’s. It look likes if static from an old television was condensed into RGB strip form. Do you know what causes this? There’s nothing special in the lights, so I’d assume that there’s something funky with the signal channel on the 3 wire ports when the robot gets put into disabled.


Here in California it’s still Christmas eve, for some of you it’s already Christmas day, I don’t have time to comment in depth on this, however, I will add the following.

The battery is not going to catch fire.

The V5 does not have any PTCs on the three wire ports, however, there is current limiting on the 5V output.

The MC29s do not have any PTCs, they have been known to self destruct in the past when used with the cortex, I doubt that would happen with the V5 due to current limiting.

Long term effects of shorting the 5V output on the three wire ports is unknown, it’s not something I would recommend.


I have found that powering the LED’s on the 5V outputs can possibly mess with the sensor accuracies, and sometimes cause encoders/potentiometers from being recognized. I would possibly advise making the LED power be external.


Well, me not doing that initially, lead to the excellent explanations by @matthewb with much better illustrations than I could do, so…

Seriously though, I’ve been watching quite a few Chernobyl documentaries lately and it only reinforced my belief that engineers need to get used to understanding and planning for the worst case scenario no matter how unlikely that might be.

While the worst case scenario that could happen here is a loss of an expensive V5 brain in the middle of the Worlds qualifying eliminations, my assumption is that some of the students reading this will be designing systems in the future that may have serious catastrophic failure consequences and it is important for them to learn how to properly think about the worst case scenarios. It is called “culture of safety” and only works when all: design engineers, operators, managers, and regulators are on the same page.

We already identified the first mistake when Taran (and I guess majority of people who watched the tutorial) must have subconsciously assumed that black wire going out of MC29 is synonymous with electrical ground and didn’t see anything wrong with joining them together.

@matthewb gave us a very good illustration how this could lead to the electrical short and, while some could argue that they will program it correctly, I am convinced that you must never underestimate how easy it is for someone to make a programming mistake or a typo in the middle of the competition.

Hardware solutions like protective diodes or connecting LED’s common negative to the V5 electrical ground is always a better option.

I am sorry if it sounded all gloom and doom, but the key point here is that there are way too many unknowns to conclude that accidental shorting of the ADI 5v power rail is not going to be a problem in all cases.

VEX didn’t publish 5v power regulator schematics and part numbers for us to lookup and read the specs, as well as do an online search for any reported issues.

There are two ways power regulators implement protection: thermal shutdown and current limiting. Thermal shutdown is designed to protect from the long term slow heating by currents well below those that would trigger current limiting protection in case of the short.

In top of the line parts those two protections are tightly integrated, but in the cheaper designs they are not necessary integrated or tested together (because they want to sell parts advertised with max specs for the given size of the power drivers, which are the most expensive part).

Such parts will shutdown correctly when you test current limiting by shorting the cold part and then correctly thermal shutdown after the steady load slowly heats the part.

However, in the real life, you may have the long period of steady load that will “preheat” the part to the temperature just below that of triggering thermal protection and then hit it with the burst of high current just below the current limiting threshold. By the time the heat wave arrives to the temperature sensing element - the power driver could release the magic smoke and turn into a blob of the molten metal.

In the best case scenario, you will end up with a permanently damaged part that doesn’t conduct any current and, in the worst case, you may end up with high input voltage shorted to the regulator output or even to the ground. Well designed parts will have an additional integrated piece of thin wire that acts as the last resort fuse to break the circuit, but you never know what corners have been cut in the cheaper part, since they don’t report those specs.

The bottom line is: without looking up specs of the parts inside the V5 brain and running variety of tests on them, you cannot rule out the possibility of 5v power rail regulator being permanently damaged or even (although unlikely) melting down and passing the short to the next circuit level.


Thanks @technik3k. Jpearman did say “there is current limiting on the 5V output” (of the brain), so I think the hardware would forgive a non-prolonged short while testing. I totally agree, however, that shorting should be avoided by using a circuit where software cannot cause one especially since this tutorial is aimed towards the wider vex student group who are probably less careful and knowledgeable about the risks.

My previous comments had a few errors. One of those is my assumption that the MC29s have PTCs, which, as jpearman said, is not the case. This makes a lot of sense given how often they melt from shorts. Therefore, to anyone reading this thread in the future, please ignore what I said above about PTCs in the mc29s. The actual mechanism of how the short comes about is (I think) still correct.

Another thing that nobody seems to have talked about is the connections on almost all RGB led strips (including Taran’s). These strips have a common positive and switch the negative of each colour channel, rather than the common ground and switched positive that we generally expect. You can read more about why this is here.

The (seemingly) strange thing is that Taran connected the black wire from the MC29 to the common positive of the LED strip. It turns out that a positive number/forward input in both pros’s ADIMotor and VexCode’s motor29 classes make the MC29’s black wire positive and red wire negative. This is not what I (and I presume others) would expect but it explains why Taran’s circuit works. This means that the R, G, and B pins on the LED strip are the switched negatives (connected to the red wires from each MC29) and the + pin on the strip is the common positive (black wires).

I’m not too sure why positive number resulting in black being positive would be the case, I guess to make anticlockwise (looking into the shaft) positive as is convention in maths.

The upshot of all this is that instead of running a common ground via a 3-wire extension or splicing into the 3-wire in the MC29, we need to get a common +5v. This is easy enough to do in the same way by using the orange wire instead of black.

I have drawn upon the full extent of my artistic ability to produce diagrams on how to wire up your own LED strip which are attached to this post. The first option uses 4 ADI ports but requires a bit less soldering, while the second option uses 3 and requires a bit more soldering. I’m no expert on the legality of any of this but I’d guess that the first option is less illegal.

@Sylvie, perhaps you should update your tutorial or put a notice about how there is a better way in the title/description so people don’t blow their things up then blame you? I don’t have any rgb led strips at the moment but when I get some I might make a video of my own if you haven’t already done one.

@Connor that’s very strange. The only reasons for that that I can think of would be drawing so much current that the voltage starts to drop (unlikey), or the relatively high-current pwm signal causing electromagnetic interference (also unlikely but maybe less so?).
Does this also occur when powering 393 motors instead of LED strips? What about when the strips/motors are at full power (so the duty cycle is 100%, meaning no AC component)? Or when the MC29s, LED strips, and all wires related to those are as far away from the sensors and sensor wires as possible? 3-wire sensors like encoders aren’t ‘recognized’ in the same way that a v5 motor or sensor is, so it is possible that EM interference is sufficiently messing up the signals that they aren’t detected by the digital input. Though that theory doesn’t really stack up for potentiometers since they output a voltage level (rather than pulses) which should at least be detected.
I would be quite interested in learning what other people think the cause of this is.

Method 1, using 4 ADI pins.
vex led strip option 1
Method 2, using 3 ADI pins.
vex led strip option 2


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.