Close

Mockup

A project log for Remote controlled GU-24 bulb

x

lion-mclionheadlion mclionhead 09/03/2022 at 09:580 Comments

The mane problems with this are condensation in winter & unstable current.  Without PWM, the 15W ones rise from 10W cold to 15W as they heat up.  The 9W ones rise from 5 to 6W.  They don't have much of a current regulator & brightness highly depends on temperature.  There's using a single 15W at full power, 2 9W at full power, or PWM with 2 15W.  It might be good enough to add active cooling to lights running at full power.  The idea with 2 lights is more coverage than a single light.

There's no way to use the 15W on anything else but manes voltage.  

Along came a full mockup without properly trimmed wires, to see if it blew up.  It was decided to use 2x9W at full power.  They burned 8W cold.  It turned out the bulb on the right wasn't a 9W as rated.  It burned 3.6W when the bulb on the left burned 5.8W.  A 2nd bulb on the right with the same number of LEDs still burned 3.6W.  There's not much consistency in the ratings.  There will be many discarded bulbs.

Manes voltage is star distributed from the phone charger's prongs.  The phone charger's 5V powers the receiver.  The phone charger's GND can be tied to the LED return path without drawing any current.  The MOSFETS turn off the LED return path.  No thyrister is required.  The 5V side burns 400mA with the fans on.

The transmitter is a simple 3V thing which transmits a repeating 16 byte key when it's on.  4 bytes in the key contain a PWM value.  The PWM value isn't saved on the receiver.  It always starts at full power until the 1st remote control packet.

The debounce on the receiver is 1 second.  The receiver toggles the MOSFETs if it gets a packet after the debounce period.  The lion kingdom has only needed faster responsiveness when accidentally toggling the light.  Debounce is a compromise between expected packet loss & desired responsiveness.

A more robust system might be to transmit packets for only 1/4 second & set the debounce to 1/4 second.  If it transmits forever, it always eventually toggles the light twice when packets are lost for more than the debounce.   The shorter transmit time decreases the chance of a dropped packet misfiring it  but increases the chance of it never being received.  The shorter debounce increases responsiveness but also the chance of a dropped packet misfiring it.  The transmit time & debounce time have to be the same to eliminate any chance of a misfire.

Firmware updates are going to require dismantling the light.

Discussions