You are backing a trailer down a ramp at night. Your foot is on the brake, you have the turn signal on because you are about to swing left out of the lot, the reverse gear is engaged, and your rock lights are three minutes into a slow colour fade you set up an hour ago. Four different things want the same LEDs at the same instant. Something has to decide which one gets them — and if nothing does, you get whichever command arrived most recently, flickering.
The short version
RhinoLink settles it with a priority number. Every action carries a rank, the higher rank takes the zone, and only the contested zone changes. Reverse holds the highest floor, then turn and hazard, then brake, then everything decorative. When the signal clears, the zone goes back to what it was running. This is a firmware feature and it works with no phone connected.
RhinoLink is in BETA pre-order — first production units are preparing to ship. It runs the Rhino RGB system.
Why this is a real problem and not a hypothetical one
A simple Bluetooth RGB controller has one job: run the pattern you picked. There is only ever one thing asking, so there is nothing to resolve.
The moment lighting is wired into the vehicle, that stops being true. A turn circuit, a brake circuit, a reverse circuit, a switch on the dash and whatever pattern was already running are five independent sources of intent, and they overlap constantly — braking while indicating is not an edge case, it is a left turn. Without a rule, the LEDs get told to do two things, and the visible result is either the last command winning at random or the two patterns tearing at each other frame by frame.
That is not a cosmetic problem. If a whip is acting as your turn indicator, "sometimes the brake animation wins" is a safety behaviour, not a rendering glitch.
How RhinoLink resolves it
Zones, not lights
The first half of the answer is that RhinoLink does not think in lights. It thinks in five zones, and you decide what is in each one — a typical layout is left whip, right whip, rock lights, pod rings and halos, but they are your names and your groupings.
When you map a vehicle input, you also choose which zones answer it. A left turn input might take the left whip, the left-side rock lights and the left pod rings. Everything you left out is not part of the argument at all and carries on doing exactly what it was doing.
Priority, per action
The second half is a number. Every action carries a priority, configurable from 5 to 150. When two actions want the same zone, the higher number takes it. The defaults are floors — the rank an action starts at — and you can raise one if your build wants a different order.
The default ladder
- 100
- ReverseBacking up outranks everything. Nothing below it can take a zone away from the reverse pattern.
- WhyReversing is the moment you most need the lights to do one predictable thing.
- 80
- Turn / hazardOutranks braking and everything under it.
- WhySignalling the move wins over showing the stop.
- 70
- BrakeOutranks Street Only and every decorative pattern on the machine.
- WhyA stop signal beats a show, and loses to a direction signal.
- 65
- Street OnlyA driving-oriented base mode that parks the decoration.
- WhyIt sits under the three driving signals and above everything else.
- 60
- PatriotA dedicated action with its own floor.
- WhyAbove the standard actions, below Street Only.
- 55
- SOSA repeating signalling pattern you can map to a trigger.
- WhyAbove the standard actions, below every driving signal.
- 40
- Standard actionsThemes, colours and show patterns.
- WhyEverything decorative starts here.
Two things in that ladder are worth arguing about, so here is the reasoning.
Turn outranks brake. Both are real signals, and this is the one genuine judgement call in the list. A brake tells somebody behind you that you are slowing. A turn tells them where you are about to go, which is the more perishable piece of information and the one they need to act on. So a turn takes the zone from a brake.
SOS is not the top. It is a pattern you chose to map, and it sits below every driving signal, because a machine that will not show reverse while an SOS pattern is running is a machine behaving worse under load.
Only the contested zone changes
This is the part that makes the whole thing usable. Priority is settled per zone, not per machine. A brake trigger winning the rear zones does not disturb a whip zone nobody assigned to it. Your left turn can be taking the left side while the right side is still four minutes into the fade.
What happens when the signal releases
A trigger borrows a zone; it does not reset your build. When the signal clears:
- The zone's pattern, colours, brightness and speed come back.
- If another zone is still running that same animated pattern, the returning zone re-joins that live animation where it is now — so the two do not come back out of step.
- With no matching zone still running it, an animation may start again from the beginning.
- A solid colour restores directly.
We are specific about the third point because an earlier version of our own marketing claimed a returning zone resumed at the exact frame it left. It does not, and saying so is worth more than the sentence was.
This is trigger restore, and it is a different feature from a Startup Profile. Trigger restore is what happens when a brake pedal lets go. A Startup Profile is what the machine looks like the moment it powers on.
Debounce: deciding when a signal has even happened
Before priority can settle anything, the board has to agree that a signal arrived. Mechanical contacts bounce — a door pin or a switch makes and breaks several times in a few milliseconds before settling — and firmware that trusts the first edge sees four events instead of one.
So every input carries its own debounce setting, from 0 to 1000 ms. A brake circuit wants a short one so the response is instant. A door pin wants a longer one so the puddle lighting does not stutter. Per input, because they are not the same problem.
The same trigger can switch hardware too
A trigger is not limited to changing lighting. The same input can also fire any of the eight relay-driving outputs, so one signal moves the RGB zones and switches something at the same instant. Reverse can take the rear zones to white and bring up backup lighting through an external relay in the same moment.
Those outputs switch external relay coils; they do not power a high-current accessory directly. They run in solid, pulse or strobe, with a configurable rate.
This matters for pods specifically: a pod's RGB ring is RGB-system hardware and joins a zone like any other light, but a pod's high-output main beam is not an addressable zone. It is switched through an appropriately wired external relay off one of those outputs.
Worked example: the trailer ramp
Back to the opening. Assume you have mapped left turn, brake and reverse, and each one takes the zones you chose.
- Reverse engaged. Floor 100. The zones you assigned to reverse go to your chosen reverse pattern and hold it. The relay output on the same trigger brings up your backup lighting.
- Brake applied. Floor 70. It loses to reverse on any zone reverse already holds. On zones you assigned to brake but not to reverse, the brake pattern runs.
- Left turn on. Floor 80. It beats brake, so on any shared zone the turn pattern takes over. It still loses to reverse.
- The colour fade. Floor 40. It keeps every zone none of the above asked for, uninterrupted.
- Out of reverse, off the brake, signal cancelled. Each zone returns to the fade as the signal that borrowed it clears — and the zones that never left keep it in step.
No frame is ever ambiguous, because at every instant each zone has exactly one owner.
Why this needs to be in firmware
Every decision above is made on the board, tens of times a second, with no phone in the loop. Your automotive pattern choices are stored on the controller, not in the app: pick your brake variant once and the vehicle brakes that way on a dead phone, a different phone, or no phone at all. The app is how you set it up and how you drive the show by hand.
Priority resolution that depended on a Bluetooth link would fail exactly when it mattered. That is the argument for writing the firmware rather than buying a module.
More on what firmware does in a light.
Scope, stated plainly
RhinoLink runs the Rhino RGB system: Diamond RGB rock lights, Rhino 2.0 and 2.5 Fattie whips, Rhino RGB halos, RGB strip and Rhino pod RGB rings. Axion RGB+W rock lights and Rhino 3.0 RGB+W whips are a separate architecture with its own controller, and the two do not sync.
RhinoLink controls auxiliary and accent lighting. It is not a replacement for required factory vehicle lighting. Lighting regulations vary — check local requirements before public-road use.