Rhino LED Lights
Whip lights sit on the back of a vehicle where other drivers look for brake lights, turn signals and reverse lights. We wrote the on-device software that makes those signals behave the way a driver expects, and that keeps working when several things happen at once.
Whip lights started life as a decorative product. Customers wanted them to also carry real vehicle signalling - brake, turn and reverse - because that is where a following driver is already looking. The moment a decorative product starts communicating driver intent, the software behind it stops being a nice-to-have and starts being something that has to behave correctly every time.
The hard part is not the animation, it is what happens when several inputs arrive together. A driver can be braking, signalling a turn and shifting into reverse within the same second. Early firmware approaches waited out each animation before handling the next input, which meant a signal could be missed or delayed at exactly the moment it mattered most.
If your hardware has to make the right decision without a phone, a network or a person watching, tell us what those decisions are and we'll tell you what belongs in the device.
Vehicle whip lights (decorative LED strips on vehicle antennas) lacked automotive safety lighting functionality. Owners wanted to add turn signals, brake lights, and reverse lights to these decorative systems while maintaining smooth animations that integrate with existing vehicle electrical systems.
Production embedded firmware built on a non-blocking state machine architecture with three concurrent state machines (reverse, brake, turn signals), a priority-based mode system for safety-critical operation, and smooth LED animations supporting 550 addressable pixels per channel. No blocking delays anywhere in the main loop, so vehicle inputs are always serviced.
Implemented non-blocking state machine architecture with three concurrent state machines operating simultaneously. Replaced blocking delays with millis-based timing for fully responsive system that never misses vehicle signals.
Developed smooth animation algorithms with linear interpolation for fade effects, supporting 550 addressable LEDs per channel with 25 FPS frame rate control. Implemented dual-channel independent control for left/right LED strips.
Integrated with standard vehicle signals (brake, turn signals, reverse) using GPIO configuration with pull-up resistors and active LOW signal processing. Implemented dual-mode turn signal support for flexible vehicle integration.
Implemented priority hierarchy: Reverse (highest) → Turn Signals → Brake → Nominal. Ensures safety-critical reverse lights are always visible while allowing turn signals to override brake lights for clarity.
Designed clean separation between hardware I/O and application logic with modular function design. Comprehensive pin definition system with comments for hardware revisions and maintainable architecture.
Iterative refinement from early blocking implementations to non-blocking state machines. Memory-efficient state representation with minimal CPU overhead and efficient LED update batching.
Non-Blocking Design: Replaced blocking delay() calls with state machine-based timing using millis() timestamps. This maintains system responsiveness and allows concurrent animations while preventing missed vehicle signals.
Concurrent Operations: Three independent state machines (reverse, brake, turn signals) operating simultaneously with proper state persistence during transitions and clean state transitions with appropriate cleanup.
Smooth Algorithms: Linear interpolation for smooth fade effects, non-blocking blink sequences with configurable timing, and 25 FPS frame rate control (40ms frame timer) for smooth visual performance.
Dual-Mode Support: External trigger mode (for vehicles with external turn signal kits) and auto-blink mode (internal timing control) providing flexibility for different vehicle integration scenarios.
Safety-Critical Hierarchy: Reverse (highest) → Turn Signals → Brake → Nominal. Ensures safety-critical reverse lights are always visible while allowing turn signals to override brake lights for clarity.
Timeout Handling: 500ms threshold to distinguish between brief off-periods (during blinking) and actual turn signal completion for external signal integration.
Vehicle Signals: GPIO configuration for vehicle signal inputs (active LOW, pull-up resistors), NeoPixel LED strip control (GRB color order, up to 550 pixels per channel), and output switch control for external relay/device integration.
Development Tools: Cross-compilation toolchain (ARM GCC), Atmel Studio project configuration, debugging infrastructure (Atmel-ICE, SWD interface), and build system configuration for Debug/Release targets.
No blocking delays anywhere in the main loop, so a vehicle signal is never missed while an animation is running.
Dual-channel independent control supporting 1,100 total addressable pixels with smooth animations.
The priority system means reverse lighting is always visible, and turn signals read clearly over brake behavior.
Modes hand over to each other with state preserved, so overlapping signals do not leave the strip in a strange state.
If any of that sounded like your business, this is the service it falls under.
Tell us what your product has to do, what it has to talk to, and what must never be allowed to fail. We'll tell you what that takes to build.