Showing posts with label LEDs. Show all posts
Showing posts with label LEDs. Show all posts

Monday, 23 December 2024

Christmas Lights 2024

It’s become something of a tradition at this point that each year I continue to build upon the interactive Christmas lights which I started in 2020.

Previous iterations:


Now that my kid is walking, the baby bouncer control I added last year is redundant, but is given me the idea of continuing to build upon the lights following his progress stages.
So this year I purchased a Playstation dance mat.


The single board computer that I have been using is pretty much tapped out in terms of resources – trying to add a USB hub in order to connect the controller pulled too much power, so in order to do that would mean having another powered USB socket (currently there are 3, which all powered from a single wall socket, 3 port USB charger)

However the way that I have developed the control software is that it is ultimately a small web server on the local network.


Therefore I can connect the dance mat to a different machine then just have it control the lights over the network. It’s perhaps not the most optimal way of doing things, but is ultimately a temporary installation for a couple of weeks.


To connect the dance mat, I am using a Playstation to USB adapter (it’s a PS2 dance mat).


This shows up under lsusb, and using the details taken from there I can connect it using udev, following the same method that I used in order to connect the treadmill from a different project.

 

Monday, 8 January 2024

Hardwood slim line LED panel light fitting with accent lights

I recently purchased a pair of low profile LED ceiling lights from a charity auction on Ebay.

It seemed like the kind of thing that I’d find a use for eventually, and it was for a good cause.

After buying I had a message from the seller to tell me that they only had one driver for the two panels – I went ahead with the purchase because at the end of the day I wasn’t expecting them to be new and pristine from a charity auction.

My curiosity was piqued when they arrived. I noticed another label sticking out from underneath the address label. I peeled it back, and revealed an Amazon delivery label to a different address.

Initially I figured perhaps it was an Amazon returned item – one of the drivers was missing, therefore the original purchaser returned it, and it was sold on to the charity as one of those wholesale return pallets that you see advertised.

I did also think that the wires on the mains side of the LED driver seemed a little bit thin. However I tested it with those panels and they actually seemed to work okay, so I didn’t think much more of it.

Losing faith

So, I started to put together a project plan to make a light fitting with them.

I wanted to add in a few extra accent lights but everything I had was 12v, and the light fittings driver was 18v. While I was mulling over options – adding in a separate transformer, the space and heat issues to work round, etc. I noticed a couple of other things.

The case of the driver seems to have fake screw heads stamped on them. Not in itself a problem, but kind of sketchy.

And the panels themselves are stamped with 18w, not 18v.

The output of the driver says 9-18v at 300ma.

W=V*A.

There’s no way that if those panels are 18w, the driver can provide enough power to them.

This made me rethink my theory on the background of these lights.

Having a look on Amazon I can see very similar products, with identical looking drivers – the only difference being that the outputs are rated differently.

My guess is that this set of lights came with incorrect drivers, and the original purchaser damaged one whilst trying it.

It’s only a theory and not enough to make a claim against, it ultimately is enough to destroy my faith in these lights and make me not want to use them as they are.

Rebuilding the electronics

I had built the design around the size of these panels, so I decided to rip out all of the electronics.

On doing so I realized that the panels were just flexible LED strip edge mounted to a diffuser.

I swapped out the LED strip that was there with some white 12v strip LEDs. I had to trim about a millimeter off the sides of the diffuser in order to account for the slightly larger LEDs.

In an initial test the LED light was quite patchy, so I took the diffuser from the second light and doubled up. This makes a notable difference.

To drive the strip I’m using a regular RGB LED control box.

Initially my choice of this was simply because it was available and had a small profile so would fit well in the fitting.

However this also gave me the idea I could run the accent lighting and the main light on different color channels, allowing them to be controlled separately. It would also allow me to dim the light.

The design

Because I don’t want to carve out my ceiling to flush fit the panel I planned to build a small mitred frame, with another frame mounted at forty five degrees behind it. The back frame would contain some accent lights, with the front frame housing the main light fitting.



the fitting needed to fit in with the of our lights in the room, so I disassembled the original fitting and spray painted it black.

For the wood frame I opted to use zebrano.

The frames are simple squares with 45 degree mitres, and a 2mm deep by 10mm wide rebate to fit the light fitting frame flush with the surface.

The back frame was turned at a 45 degree angle, and screwed to the front frame.

The back frame also had a pair of key hole plate mounted to the back, which will be used for connecting to the ceiling.

Accent Lighting

Rather than cut up the filters from the second light, I opted instead to use a stack of filters from an old PC monitor. It was simply a case of measuring out the triangles, cutting them and then gluing them in place with hot glue.

Each corner would have a single segment of white LED strip (3 LEDs per corner). These would be connected in series and then connected to the RGB LED control box, on a different color channel to the main light, allowing them to be used independently.

The rest of the electronics

The IR receiver from the control box sticks out behind the front frame, so it is not visible from ground level, but catches enough reflected light from the ceiling to function.

However, this didn't last long and soon found itself wrapped in black tape because what I didn't realise at the time was that the IR receiver worked on the same encoding as our TV remote and we soon bored of having the lights change as we scrolled through TV guide menus.

PSU

The power supply is provided by an AC-DC “wall-wart” – I had to be quite selective in which one I picked to fit within the frame. The one I opted for had a removable face plate which allowed me to remove the socket pins and wire directly into.

The end result

 



Saturday, 30 December 2023

Christmas Lights 2023 - Baby bouncer controlled lights

Back in 2020 I made some Christmas lights that could be controlled via Slack and WhatsApp so that Christmas spirit could cross the void created by Covid-19 and its lockdowns.

In subsequent years I added more features, such as morse code.

So now adding to my over-engineered Christmas lights has become something of its own tradition.

In early December this year, while setting up the decorations and mulling over what new silliness I was going to add to the lights, I was asked to fix my son's baby bouncer/cradle thing.

It's a Fisher Price Kick & Play Calming Vibrations bouncer, which has switches in the foot area which I believe are supposed to trigger lights and sounds.

This particular one was a hand-me-down which had been sat in storage, and the battery terminals are all corroded, making it non-functional.

Fixing it wouldn't really be a big deal, but I remembered that like most newborns, my son loves anything that's bright and shiny and blinky, like Christmas lights.

 

So obviously you can see where this is going...

The arch of the chair detaches, and you can see in one of the mounting points 4 pins.

A quick probe with the multimeter shows that these are two pins for each of the two 'pedal' switches.


To interface this with the existing light setup, I decided to again use the GPIO interface of the PCDuino.

Using the guide from before, I identified the GPIO identifier for two pins that I wanted to use, and enabled them as below. Pin 4 (232) is an input and pin 7 (233) is an output that is set to high simply provide a source, as I wanted to keep the main source pins (3v3 etc) free.

echo 232 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio232/direction
chown -R ant:ant /sys/class/gpio/gpio232
echo 233 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio233/direction
chown -R ant:ant /sys/class/gpio/gpio233/value
echo 1 > /sys/class/gpio/gpio233/value

The two pins were connected with a resistor to create a pull up effect. I had initially tried to have it as a pull down but it seemed to still have a lot of flicker in the output.

I picked the switch with the red foot as this tends to be more how Sam would sit. one side of the switch was connected to ground, and the other to pin 4.

The code

I added a thread to the main application which would read the value of the pin and change the lights accordingly.

Because of the way that /sys/class/gpio/gpio232/value is not actually a real file, it was not possible to hold the file open and continually read the input. Instead I had to create a loop which would constantly open the file and read the value. This does cause some overhead, but isn't too bad because the file is never more than one character long.

I had initially planned that when a change is detected, it would hook into the main code to change the lights, however I found this was causing a lot of deadlock issues. 

Instead, the new thread works very independently - it will pick one of the basic colors at random, and make a simple HTTP request to localhost to invoke the change.

The result

I'm not sure if he's aware of the causation between him moving and the lights changing, but like most babies there's twinkling, blinking and sparkly stuff, he's a fan, so he certainly seems to enjoy it.


Monday, 14 April 2014

Space Invaders alarm clock mod

I'm very conscious of the fact that the last two posts have been quite text-heavy, so here's a lighter weekend project.

I was once given a Space Invaders alarm clock. It's shaped like one of the aliens from the game, the 'pixels' of the LCD display are shaped the same, and when the alarm goes off it makes the aliens sound and moves from side to side as they did in the game.



Which is all well and good unless you have a small bedside table, and the clock just rolls off the edge every morning...

The lazy answer would be to just build a barricade, or some kind of stand that would stop the wheels turning.

Opening up the clock reveals a small PCB, with wires neatly labeled, and a small motor which operates a worm gear to move the wheels.

 

My plan is to replace the motor, and use it's wires to power some LEDs which I will place in the 'eyes' of the model.

Although labelled "M+" and "M-", the motor wires polarity changes - to allow the change of direction. This is great for motors, but reversing the polarity on an LED will likely result in the magic smoke escaping.

To get around this - and also provide a neat colour change effect - each eye will have 2 LEDs in parallel, and arranged in opposite directions. The LEDs of each colour for each eye will be in series (see below). Also don't forget a 100 Ohm resistor at one of the ends (doesn't match with one)

One green and one red LED per eye. As the current changes the LEDs will alternate


This means that when the current is flowing one way, it can't get through one LED, so moves through the other. When it changes direction, it can no longer get through that one, so it diverts to the other, effectively 'blinking' each LED in turn.

Then it's just a case of drilling eye holes, poking the LEDs through, and reassembling (I also used hot glue to act as a diffuser for the eyes)

Each stage of the end result. It doesn't roll off the table anymore, but I didn't count on it looking a lot more sinister.


Monday, 24 March 2014

Motion activated Pac-Man lamp


Version 2

Migrated the control over to an ATtiny25, using the ATtiny cores for Arduino.
I found a ported version of the IRRemote library on Github. It looks as though this port was for a specific purpose, and lacked the IR codes I needed, however it was easy enough to port the necessary parts from the orignal IRRemote library.

This is the revised code:

#include "IRremoteTiny.h"

IRsend irsend;

#define PIR PB2 // pin 7 on ATtiny

void setup(void) 
{
  DDRB &= ~(_BV(PIR)); // Set as input
  DDRB |= _BV(PB3);

}

void loop(void) {
  
  if (digitalRead(PIR) == HIGH) {
    digitalWrite(PB3, HIGH);
    for (int i = 0; i < 3; i++) {
      irsend.sendNEC(0xF7C03F, 32);
      delay(40);
    }
    delay(10000);
    for (int i = 0; i < 3; i++) {
      irsend.sendNEC(0xF740BF, 32);
      delay(40);
    }
  } else {
    digitalWrite(PB3, LOW);
  }
}


Version 1
I was given a Pac-Man lamp for Christmas.
It's a simple RGB colour changing lamp that is remote controlled.


In my flat the hallway can be quite dark, and when leaving, there can be a few seconds between turning the flat's hall light off, and the external hall light being triggered.

I was considering getting a simple plug-in 'night light' type thing, but I didn't want something that stayed on all the time. And besides, I wanted to put Pac-Man to good use.

As it was a Christmas gift, it didn't seem right pulling it apart straight away, so the plan is to create a motion-triggered device that mimics the remote.

The first thing is to find the remote protocol being used.
To do this use a IR receiver module (I scavenged one from a VCR that was on the junk pile), and hook it up to an Arduino, using Ken Shirriff's arduino IR library. Using the 'IRrecvDump' sample sketch you can find the details of the protocol in the serial monitor - it'll look something like

F7C03F
Decoded NEC: F7C03F (32 bits) Raw (68): 15538 8950 -4200 700 -400 700 -400 650 -450 700 -400 700 -400 650 -450 650 -450 650 -450 650 -1500 700 -1500 700 -1500 650 -1550 650 -450 650 -1500 700 -1500 700 -1500 700 -1500 700 -1500 650 -450 650 -450 650 -400 700 -400 700 -400 700 -400 700 -400 700 -400 650 -1550 650 -1500 700 -1500 700 -1500 700 -1500 700 -1500 650 F740BF

Decoded NEC: F740BF (32 bits) Raw (68): 26860 8950 -4200 700 -400 700 -400 650 -400 700 -400 700 -400 700 -400 700 -400 650 -450 650 -1550 650 -1500 700 -1500 650 -1550 650 -450 650 -1500 650 -1550 700 -1500 650 -400 700 -1500 700 -400 700 -400 650 -450 650 -400 700 -400 700 -400 700 -1500 650 -450 650 -1550 650 -1500 700 -1500 650 -1550 650 -1500 700 -1500 650

My first thought that the pacman remote looks very similar to the remotes that tend to get bundled with rolls of RGB leds, and I had a couple of those going spare, so perhaps one of them could've been sacrificed, however performing the same test with those showed that they use a different protocol, and so wouldn't work.

The second thought was to make use of an old Sky TV remote - they have a feature that allows the protocol to be programmed to control several makes of TV, but after a while trying various codes, it appeared that the one I was after wasn't one of them.

So the final option was to use the arduino itself for sending the signal. It seemed a bit overkill, but I can always migrate it to a smaller microcontroller when I have one spare. The IR led was taken from the old Sky remote.

The next stage is to wire in the PIR sensor (motion detector)

I used one of these:


They're a simple 3 pin setup - Vcc, Ground, and Data. Data simply goes high for a few seconds when motion is detected.
It can be easily wired in, just effectively like a simple button.


Here's the code I used - when motion is detected, turn the lamp on for 10 seconds, then off again.

#include <IRremote.h>

IRsend irsend;

void setup()
{
  pinMode(4,INPUT);
  pinMode(13, OUTPUT);
}

void loop() {
  if (digitalRead(4) == HIGH) {
    digitalWrite(13, HIGH);
    for (int i = 0; i < 3; i++) {
      irsend.sendNEC(0xF7C03F, 32);
      delay(40);
    }
    delay(10000);
    for (int i = 0; i < 3; i++) {
      irsend.sendNEC(0xF740BF, 32);
      delay(40);
    }
  } else {
    digitalWrite(13, LOW);
  }
}