Rhino LED Lights

Keeping a Product Cool Enough to Ship

A high-power LED product had to protect itself from overheating once it was out in the world. We built that protection into firmware small enough to run on the controller already on the board, so nothing about the hardware or its cost had to change.

The Problem

A high-power LED runs hot. Heat that is left unmanaged shortens the life of the LED and the components around it, and in the worst case the product fails while a customer is using it. Anything that ships has to be able to look after itself in conditions nobody can predict from a bench.

The obvious fixes all cost money on every unit built. A larger controller, extra sensors, or a redesigned board would have raised the bill of materials on the entire production run and pushed the schedule back. The chip already specified for the board was an ATtiny5, one of the smallest microcontrollers made, with 512 bytes of program space and 32 bytes of RAM. Whatever protection the product got had to fit inside that.

What We Built

Firmware that measures temperature continuously and adjusts LED output to stay inside safe limits.
Staged protection: gradual dimming first, hard limits and emergency shutdown only if heat keeps climbing.
Smoothing so the light does not visibly flicker or hunt as temperature moves around.
A gentle startup ramp so the product does not jump straight to full power from cold.
A second temperature-sensing method for the case where the chip's analog input was not available.
The whole thing sized to run on the 512-byte controller already chosen for the board.

What Changed

  • The product manages its own heat in the field instead of relying on the customer to notice a problem.
  • No board redesign and no more expensive controller, so the per-unit cost of the product did not move.
  • Brightness stays as high as conditions safely allow, rather than being permanently capped to leave a safety margin.
  • Thermal behavior now lives in firmware, so adjusting it later is a code change rather than a hardware change.

What This Could Do in Your Business

Getting more out of hardware you have already committed to, instead of respecifying it mid-project.
Products that protect themselves in the field rather than depending on the person using them.
Control logic for products where per-unit cost matters and every added component multiplies across the run.
Behavior that can be re-tuned after launch without touching the physical product.

Have a product that has to look after itself?

Tell us what your hardware has to survive once it leaves the building, and what the parts budget looks like. We'll tell you what can be handled in firmware instead of on the board.

Under the Hood

For the technical evaluators: how the firmware actually works.
Rhino LED Lights 2025 Completed
512
Bytes Flash Memory
32
Bytes RAM
20Hz
Control Loop Frequency

Engineering Brief

Constraint and solution
The Constraint

Intelligent thermal management firmware for a high-power LED system running on the ATtiny5 microcontroller - one of the smallest AVR parts available, with 512 bytes of flash and 32 bytes of RAM. The system has to hold maximum usable brightness while preventing thermal damage, using real-time temperature monitoring and adaptive PWM control.

What We Delivered

Production firmware that operates inside that memory budget while providing adaptive thermal management, smooth control behavior and layered safety protection - all on the hardware that was already on the board.

How the Firmware Works

The main areas of the design
Resource-Constrained Programming

Optimized firmware to fit within 512 bytes of flash memory and 32 bytes of RAM. Implemented efficient algorithms, removed unnecessary overhead, and utilized bit-level operations to maximize functionality within extreme memory limitations.

  • Memory optimization techniques
  • Code size reduction strategies
  • Efficient data structure design
Real-Time Thermal Management

Designed and implemented a thermal control system that continuously monitors temperature and dynamically adjusts LED brightness to prevent overheating while maximizing light output.

  • Temperature-based control algorithms
  • Multi-threshold protection systems
  • Emergency thermal shutdown
Signal Processing & Filtering

Implemented exponential moving average (EMA) filtering to smooth noisy sensor readings and prevent erratic behavior. Applied dual-stage filtering for both sensor data and control targets.

  • EMA filter implementation
  • Noise reduction algorithms
  • Signal smoothing techniques
PWM Control Systems

Developed fast PWM (31.25 kHz) control for precise LED dimming with smooth transitions. Implemented slew rate limiting and deadband control to prevent oscillation and ensure stable operation.

  • Fast PWM mode configuration
  • Slew rate limiting
  • Deadband control implementation
Hardware Abstraction & ADC

Worked with both ADC-based and RC timing-based temperature sensing methods. Implemented alternative sensing techniques when hardware limitations required creative solutions.

  • ADC configuration and calibration
  • RC discharge timing methods
  • Hardware register manipulation
Safety & Protection Systems

Implemented multiple layers of safety protection including thermal limits, brightness clamping, emergency shutdown modes, and gradual startup ramping to protect hardware and ensure reliable operation.

  • Multi-level thermal protection
  • Safety clamping algorithms
  • Gradual startup sequences

Control Logic in Detail

How the behavior was implemented
Intelligent Control Algorithm

Dual-Stage Filtering: Implemented exponential moving average filtering at both the sensor input stage and control target stage to ensure smooth, stable operation even with noisy sensor readings.

Linear Interpolation: Developed temperature-to-brightness mapping using linear interpolation between thermal thresholds for precise control across the operating range.

Smooth Transitions

Slew Rate Limiting: Implemented ±1 per loop transition limiting to prevent sudden brightness changes that could cause visual flicker or hardware stress.

Deadband Control: Added deadband (±2 PWM units) to prevent oscillation around target values, ensuring stable operation without constant micro-adjustments.

Startup Behavior

Gradual Ramping: Implemented slow startup ramp (+1 brightness per second) to prevent thermal shock and allow the system to stabilize before reaching maximum output.

Initial Conditions: Configured safe startup brightness (75%) with immediate thermal monitoring to balance performance and protection.

Adaptive Control

Airflow Detection: Implemented enhanced brightness mode when very cool temperatures indicate active airflow, allowing up to 90% brightness in optimal conditions.

Dynamic Limits: System automatically adjusts maximum allowed brightness based on thermal conditions, maximizing performance while maintaining safety margins.

Engineering Outcomes

What the finished firmware does
Fits the Existing Part

Full functionality inside 512 bytes of flash and 32 bytes of RAM, so the controller on the board did not have to change.

Responds Fast Enough

20Hz control loop with sub-50ms response time for thermal events, so protection engages before damage accumulates.

Layered Protection

Dimming, clamping and shutdown stack on top of each other so a single failure mode does not put the product at risk.

Worked Around the Hardware

RC timing used for temperature sensing where the ADC was unavailable, avoiding a hardware change to solve a sensing problem.

Engineering Approach

How the constraints shaped the design
Working Within the Budget

When the standard approach does not fit, the alternatives have to be found rather than bought. Alternative sensing methods and heavily optimized algorithms kept the feature set intact inside the memory that was available.

Whole-System Design

Hardware limits, real-time requirements, safety behavior and how the product looks to a user were treated as one problem rather than four. Competing requirements were balanced instead of solved in isolation.

Built for the Field

Error handling, safety margins and protection behavior were written for real deployment conditions, not for a bench: gradual startup, thermal protection, and stable operation as conditions change.

Hardware Integration

Integrated with power management ICs, LED drivers, thermistors and protection components, working directly with low-level hardware registers and timing requirements.

Technologies & Tools

Technical stack used
ATtiny5 Microcontroller C/C++ (AVR) AVR Toolchain Embedded Systems PWM Control Signal Processing Thermal Management Memory Optimization Real-Time Systems Safety Systems Hardware Integration Microchip Studio

The Capability Behind This Project

If any of that sounded like your business, this is the service it falls under.

Got hardware that has to protect itself in the field?

Most thermal, power and safety problems can be solved in firmware for less than they cost in components. Tell us what the product has to survive and we'll tell you which side of that line it falls on.