This hideous proof-of-concept lashup gathers a bunch of stuff I’ve been investigating into what’s definitely in the running for the most over-the-top LED blinky light ever:
The general idea:
- A large-area bike taillight (tiny, narrow-beam, intense LEDs aren’t visible at a distance or off-axis)
- Made from commodity 5 mm LEDs in series-parallel connection (cheap!)
- Powered by readily available replaceable Li-ion battery packs (simple off-bike recharging)
- Linear MOSFET LED current control (no switching EMI)
- Hall effect current sensing (low sensor resistance)
- Operates down to 6 V (low dropout voltage)
- Arduino Love closing the feedback loop (for programmatic blinkiness)
A closer look at the key analog parts:
The ferrite toroid near the middle surrounds that same “49E” Hall effect sensor. The ZVNL14 logic-level MOSFET in the lower right runs with about 2.4 V on the gate to put 120 mA through the LEDs. The cluster of parts just above it are the RC low-pass PWM filter, with the PWM running at 32 kHz. The snippet of perfboard near the top adapts a MAX4330 op amp to DIP pins. I used the twiddlepots to bring up the op amp and MOSFET circuitry by force-feeding bias and gate voltages.
The Arduino Pro Mini closes the feedback loop from current sensor to MOSFET gate. A knockoff Arduino Pro Mini is a $5 component, in onesies, delivered halfway around the planet. For low-volume stuff like this, you just build it right in and move on; there’s no reason to lay out a PCB with an ATmega328 chip and a handful of other parts. Unless you’re worried about power consumptions, as described below.
The schematic:
The MAX4330 removes the Hall effect sensor’s VCC/2 bias, but it turns out the offset varies by enough from part to part and over temperature that a single twiddlepot setting won’t suffice. The RC filter near the middle of the schematic converts an Arduino PWM output into a voltage between 2.0 and 3.0 V, which puts more PWM resolution where it matters; the default 0.4% PWM steps are just too coarse. I think 16 bit PWM resolution would be A Very Good Thing here.
The first-pass program nulls the offset once, during the startup routine, but nulling whenever the LEDs turn off would be a Good Idea. The offset steps are 8 mV, about what you’d expect from 2/5 of the nominal 20 mV PWM increments. It ramps the offset up from zero, but you’d probably want to use a binary search.
The op amp has a voltage gain of about 28 that scales the toroid-plus-Hall-sensor output so that 500 mA in the winding produces 5 V. That gain isn’t quite high enough for the 120 mA I’m using for this collection of LEDs , but it makes the coefficient a nice round 0.10. It’d be good to have a calibrated current load, something around 100 mA, that would allow auto-calibration.
A 50% voltage divider lets the Arduino measure the nominal 7.4 V battery voltage and decide when to lower the current or change the blink pattern or kvetch about imminent blackout or something. Knowing both the battery voltage and the resistance of the current calibration load would let the program calculate the actual current for calibration. Given two calibration loads, then you could derive both the gain and the remaining offset; that’s likely too much trouble.
The Pro Mini board has a voltage regulator that provides +5 V for everything else in the circuit, which means putting the microcontroller into sleep mode won’t save any battery power. I think a p-channel MOSFET switch and a suicide output from the Arduino will be in order. A vibration sensor would give you auto power on and off, which would be a nice touch; MEMS sensors seem to want 3.3-ish V for supply and logic.
The entire lashup runs at about 60 mA with the LEDs turned off, which is way too high and may include some breadboard screwups; considerable reduction will be in order before this circuit makes any sense. The Hall effect sensor costs about 4 mA all by itself, plus another milliamp in the load resistor. The microcontroller should be around 10 – 20 mA, but the datasheet makes some assumptions that aren’t true for the Arduino runtime.
The program brute-forces the pulse timing, just to get this thing working. The main loop stalls while the LEDs are on, which is obviously a Bad Thing. The ADC conversions do some averaging, but I’m not confident it works well enough. The PWM output routine includes an entirely empirical delay to cover the filter time constants.
The blink pattern should be in a table. Given linear current control, you can have variable brightness; a “night taillight” mode that isn’t so shatteringly bright would be a Good Idea. The table might contain gate voltages for each current level, updated during the last pulse, so that the output would be Pretty Close at the beginning; you’d measure those values during startup.
A button or two for mode selection might be in order. Sealing buttons is always a problem, but this thing might not be totally waterproof anyway.
But it blinks!
The Smell of Molten Projects in the Morning 