Saturday, November 05, 2016

One bug: after using it for a few minutes, it seems to have swapped the red and green columns of colored buttons: red displays green and green displays red. The controller is nonvolatile: it remembers settings across powerdowns.

I set the controller to white (W button) full brightness and powered it with a bench supply. I went as high as 13.8V since that's typical for a running car, and they know people will put them in their cars. I briefly ran it upwards of 15V and it didn't immediately die, drawing about 3A.

The color temperature changes with applied voltage, going from yellow at lower voltages to very blue at high voltages.

The red LED first barely comes on at 5V 10mA. The blue LED is last to come on, at around 9V 0.85A (so looks like you could power the string from a 9V battery) . At 10V it draws 1.19A. At 11.0V, it draws 1.56A. At 12V it draws 1.96A. At 13V it draws 2.33A, and at 13.8V it draws 2.65A.

At 12V and max brightness with just one color lit, red draws 1.17A, green draws 0.95A and blue draws 0.87A.

The output of the controller has 4 pins: White, Green, Red, Blue. White connects to the positive rail (12V) and the three color channels are pulled down toward ground with PWM. Each PWM channel supports 8 brightness levels if you've pushed one of the colored buttons.

If you press one of the DIY buttons, though, you get 64 levels per color.

PWM period is 4.1ms (244Hz frequency).

Under the hood, the heavy lifting is done by a trio of 70T03GH MOSFETs. The microcontroller has no markings. The remaining IC is a 24C02 EEPROM.

Here's an amusing aside: observe the wire harness in the top right of the photo below, which feeds the LED strip. The LED strip's wires are colored white (12v), R, G, B, as expected. But in the cable coming from the board: 12v is black instead of white, the green channel is a red wire marked B (but ever since my controller glitched, it's actually red), the red channel is a red wire marked G (but is actually green), and the blue channel is a blue wire marked R (and is actually blue). So I bet the glitch I observed is part of a broader bug in which the controller flips around its channels, and which the manufacturer kept trying to fix by changing the order of wires in the harness.

The IR signal from the remote is received by an integrated IR receiver that produces serial for the microcontroller. Normally high (5V), it pulls low for about 9ms for a start bit, back to high for 4ms, then sends data bits. The data bits look to me like an RTZ code: high 600us, then high or low for 600us (depending on the data bit), then high 600us, then low 600us. Looks like about 24 data bits.