A modern LED light is a small computer that happens to emit light. There is a microcontroller in it, and that microcontroller is running code somebody wrote. Which code, and who wrote it, turns out to explain a surprising amount about how a lighting system behaves on a vehicle — including several things most people assume are hardware.
The short version
Firmware is the software running on the light or the controller itself, with no phone involved. It decides how the product comes up at power-on, how it protects itself from heat, how a pattern is timed, what happens when two vehicle signals want the same LEDs, and what survives a battery disconnect. None of those are things you can add to a product later if you did not write the firmware.
Firmware is not the app
Worth separating, because they get conflated constantly.
- The app runs on your phone. It is how you configure things and how you drive the lights when you feel like having a phone in your hand.
- The firmware runs on the board, on the vehicle, all the time. It is what makes the lights work when your phone is in your pocket, or dead, or three miles away.
A product whose behaviour lives in the app is a product that stops behaving when the app is not there. Everything below is firmware, which is why it keeps working when the phone does not.
Six things the firmware decides
1. Thermal behaviour
LEDs get hot, heat shortens their life, and the only way to manage that in real time is to reduce the drive. Our pods use firmware-controlled thermal protection: the board watches temperature and manages output to protect the emitter.
We deliberately do not publish a temperature threshold or a derating curve, because nobody here has produced a thermal test for one and inventing the number would undo the point of publishing numbers at all. What we will say is the honest version: a light that manages output on temperature does not have unlimited sustained output, and any product claiming both is claiming two things that cannot both be true.
2. Current control
The LEDs in a colour-mixing light are not simply switched on. Brightness and colour come from pulse-width modulation — switching each channel on and off faster than the eye can follow and varying the ratio. The mix of red, green, blue and, on RGB+W products, a dedicated white channel is firmware arithmetic happening thousands of times a second.
This is also where a real difference between measurement and datasheet arithmetic lives. A component rating describes an emitter at a drive current in a laboratory. What the finished light actually does depends on what the firmware asks the driver for. Which is why our published figures come off a meter pointed at the assembled product.
3. How the vehicle comes up
Power-on behaviour is a firmware feature. On RhinoLink it is a Startup Profile: the pattern, colour, brightness and speed your zones come up with are stored on the controller, so the machine wakes up the way you left it without a phone in the loop. Brightness and speed survive a power cycle for the same reason.
4. Pattern timing across different lights
This one is invisible until you have both. A rock light and a four-foot whip hold very different numbers of LEDs, and for years that meant a pattern running across both never quite lined up: the same animation on a 24-pixel light and a 462-LED whip are not the same length. The fix was to rewrite the patterns so they scale across devices, and then put the automotive animations on a shared timing source so every zone assigned to a turn input runs the same variant and stays in step.
That is entirely a software problem. No amount of housing quality solves it.
5. What happens when two signals compete
Brake, turn, reverse, a show pattern and a plain colour can all want the same LEDs at the same moment. Something has to decide, and that something is firmware. On RhinoLink every action carries a priority, the higher one takes the zone, and only the contested zone changes — a brake trigger winning the rear zones does not disturb a whip zone nobody asked for. When the signal clears, that zone returns to the pattern, colours, brightness and speed it was running.
Reverse holds the top priority floor, at 100 out of a configurable 5 to 150 range, because backing up is the moment you most want the lights to do one predictable thing.
6. What survives a battery disconnect
The least exciting firmware work there is, and one of the most important on a vehicle. Configuration is written to the controller a few seconds after your last edit — roughly five seconds for trigger and input configuration, roughly ten after lighting adjustments stop — and force-saved if you disconnect first. Storage is written so that a battery pulled mid-save leaves the controller holding the old configuration or the new one, never half of each.
A controller that can be corrupted by an interrupted write is a controller that eventually gets pulled off a machine in a parking lot.
Debounce: a small example of why this is hard
A door pin switch is a mechanical contact, and mechanical contacts bounce — they make and break several times in a few milliseconds before settling. Firmware that trusts the first edge sees a door open four times. So each RhinoLink input carries a debounce setting from 0 to 1000 ms: long enough to ignore the chatter, short enough that a brake signal still feels instant.
You can set it per input, because a brake circuit and a door pin do not need the same number. That option only exists because somebody wrote the code and had a reason to expose the setting.
Firmware is why a product improves after you buy it
Hardware ships once. Firmware keeps being written. Long LED runs moved onto a new driver architecture inside the firmware in August 2026, and big builds animate more smoothly than they used to on the same boards that were already in the field. That is only possible for a company that wrote the firmware in the first place.
It is also why the control system took so long. We started engineering an upgraded Bluetooth module in February 2023 specifically so we could write our own app and our own firmware instead of building around somebody else's. That decision cost years. It is also the reason there is anything to write about here.
What we do not claim
- No temperature limits or derating curves. Thermal protection is real and unquantified; there is no test on file, so there is no number.
- No LED capacity figure. How many pixels a controller will drive is not something anyone here has established with a test, so we sell the architecture rather than a load.
- No source code details. Everything above describes behaviour, which is what affects you.