Tag Archives: LED

Yesterday I finished the new Wifi LED controller. One day later as expected, because while cutting the last wire to the correct length, I accidentily also cut 2 other wires that were already soldered.. Well, if those things happen and it’s already getting late, it’s better to just stop and clean up the mess the next day – so I did.

Putting it all together

While testing all the components together on a breadboard, I decided to use a different 3.3V voltage regulator, cause the original choice led to a very hot regulator which is something I don’t like, so I chose the following components:

• Conrad MS-35 LED controller, EUR 20,89;
• TTL to Wifi converter, EUR 21;
• Hammond enclosure, EUR 6,83;
• IPEX/SMA antenna adapter, EUR 4,99;
• 2×5, 2mm pitch female connector, EUR 0,90;
• Standard Wifi antenna, from an old Wifi access point;
• 3.3V voltage regulator, EUR 12,64;
• 12V DC power adapter, found in the garage.

I started with drilling a hole of  Ø 6.5 mm for the antenna adapter and an opening for the LED wires with a fretsaw. The wires for the 12V that would go to the 3.3V regulator were soldered to the connectors for the LED wires at the bottom of the MS35 PCB, like so:

I took a piece of perfboard, cut it to the right size so that it would fit inside the enclosure and screwed the Wifi module to the perfboard with the help of spacers and 2 tiny screws. The voltage regulator was soldered onto the perfboard as well and now all I needed to do is connect all these components with some wires and a resistor.

The pins of the Wifi module that will be used are 3.3V, GND, UART_TXD, UART_RXD and nReload, so a 5×2 2 mm pitch connector will suffice.

The connections are pretty straightforward; the voltage regulator connects to the 12V DC from the MS35 connector and the Wifi module is connected to both the voltage regulator and the MS35.

To the right you see the pinout for the R-78B3.3-1.5. This is the first time I’m using this type of voltage regulator and I’m very happy with it actually. There is no temperature increase noticable, it’s small enough to replace a TO-220 sized regulator, it can take a voltage from 4.75-18V and can deliver as much as 1500 mA.

I think I’ll be using this regulator more from now on, even though the price is a lot higher; now I don’t have to wonder how long the cheaper LD33V will stand the heat… it’s worth the higher price.

So, to conclude all the wires needed:

1. +12V DC to VR (Voltage regulator) Pin 1;
2. GND to VR pin 2;
3. Wifi GND to VR pin 2;
4. Wifi 3.3V to VR pin 3;
5. Wifi UART_TXD to MS-35 RX;
6. Wifi UART_RXD to MS-35 TX;
7. Wifi nReload to VR pin 3.

The nReload pin can be used to reset the Wifi module to factory default settings, which is something I don’t think I’ll ever use. To prevent this from happening, this pin can be kept high with a resistor of 4.7kΩ..10kΩ – at least, that’s how I’ve interpreted the manual.

This concludes all that’s needed to build your own Wifi LED controller. Some standard components, a few wires and you’re done! No wait, the software… For that all you need to do is read a previous post which provides some additional information on the do’s and don’ts regarding communication with the MS-35 and here’s how I do it:

Making contact

When connecting to the LED controller (i.e. opening a TCP/IP connection to it) you’ll have to send the following byte sequence:

oxfd ox00 ox00 ox00 ox00 ox00 ox00 oxcf ox2c

Think of it as a ‘Hi there’ message, to which the MS-35 should respond with:

0x61 0x5f 0x43 0x5f 0x52 0x47 0x42 0x5f 0x31

Yep, part of it is human readable  From now on, the MS-35 accepts commands to set the R-, G- and B-levels.

Setting the RGB levels

Setting the levels is quite easy, the format is as follows:

0x01 0x00 RR GG BB 0x00 0x00 xx xx

where RR is the byte value for the R channel, GG the byte value for the G channel and BB for the B channel. “xx xx” is the CRC16 of all previous 7 bytes.

Here some images of the end result (click to get the original size):

Have fun!

Today I started building the Wifi LED controller I wrote about 2 days ago. Not all parts have arrived yet, but all the essential ones are already here, so I could start testing. Let’s see if the I can change the brightness of 3 small pieces of warm white LED strips on a piece of cardboard over Wifi.

I mounted the Wifi module and the stripped MS-35 to a breadboard, connected the two with some wires, added a 3.3V voltage regulator for the Wifi module and waited for the Wifi module to come online.

I already tested the Wifi module ‘standalone’ about a week ago and changed all the settings so that the module would operate like I wanted it to with the built-in Webinterface of the Wifi module; the UART on the Wifi module can work in Transparent or Agreement Transmission mode, the module can act as an Access Point (AP mode) or work in so-called STA mode (like a wireless network card), etcetera. I had already configured all those things, so after power-up the Wifi module was online in a matter of seconds:

Reply from 192.168.10.11: Destination host unreachable.
Reply from 192.168.10.11: Destination host unreachable.
Reply from 192.168.10.11: Destination host unreachable.
Reply from 192.168.10.151: bytes=32 time=2744ms TTL=255
Reply from 192.168.10.151: bytes=32 time=1ms TTL=255
Reply from 192.168.10.151: bytes=32 time=1ms TTL=255
Reply from 192.168.10.151: bytes=32 time=4ms TTL=255
Reply from 192.168.10.151: bytes=32 time=1ms TTL=255

Cool, that’s working again; now let’s see if the UART of the Wifi module is able to communicate with the MS-35. So I added 2 additional wires: one from Wifi-UART_TXD to MS35-RX and another one from Wifi-UART_RXD to MS35-TX. I added a 2nd MS35 LED controller to the database of my Domotica system, started a dev-instance of my system and sent 3 random values for R(ed), G(reen) and B(lue) to the newly added MS-35.

Everything worked as expected – the default program that starts when the MS-35 is powered ended and the brightness of all 3 LED strips changed according to the values I sent. Yep, it’s working

It’s my intention to use a single 12V DC adapter for this LED controller, so just like before I wanted to use a linear voltage regulator to power the Wifi module (3.3V). That means that the 3.3V regulator would have to dissipate (12-3.3) * 0.300 = 2.61W; that’s a lot I guess and I was right – the LD33V regulator I used for testing became too hot to touch, even briefly.

For the sake of ‘learning on the job’ I put a L7805CV I had laying around between the 12V and the LD33V; now the power dissipation was spread over 2 regulators – both still became warm, but not as hot as in the previous single-regulator setup. Another approach I tried was using the 7805 (with heatsink) on the MS-35 PCB but that also led to hot regulators – maybe within specs, but I just don’t like those high temperatures.

So I searched for an alternative, remembered Kyle Gordons comment and decided to give this regulator a try – no need for heatsinks it says! So now I’ll have to wait 2-3 days for this regulator to arrive – which gives me some time to spend time on my solar panel project….never a dull moment!

This is a logical follow-up on a previous post about the Conrad MS-35 RGB LED controller. I’m using this controller for 3 warm white LED strips for a few weeks now and it’s working perfectly – everybody is very happy with how it worked out. So it didn’t take long before I got the question if it was possible to install even more LED strips – in the living-room this time. That should be doable, however, the ideal location for the LED controller is in a corner of the living-room where it’s hard to get Ethernet.. ok, lets try something different. I’ve already got 3 Chromoflex controllers connected to Zigbee modules in the kitchen and garage, I’ve got an MS-35 connected to Ethernet in the hallway – lets try Wifi this time! Don’t wanna do mass-production, every piece of hardware is unique over here!

So I’ve started buying the parts I need, which are:

• Conrad MS-35 LED controller, EUR 20,89;
• TTL to Wifi converter, EUR 21;
• Hammond enclosure, EUR 6,83;
• IPEX/SMA antenna adapter, EUR 4,99;
• 2×5, 2mm pitch female connector, EUR 0,90;
• Standard Wifi antenna, from an old Wifi access point;
• 3.3V voltage regulator, EUR 1,10;
• 12V power adapter, found in the garage.

Total cost: EUR 55,71 (and some spare time). And this could have been even less than 50 Euro, if Conrad hadn’t suddenly raised the price of the MS-35 with almost 40%! Despite that, a Wifi RGB LED controller for less than 55 Euro…try to beat that if you can!

I decided not to use the antenna that comes with the TTL to Wifi converter, cause it’s a bit hard  to mount; I would probably have to drill a large hole in the enclosure and use a lot of glue to make the construction robust enough, so I decided to buy an additional IPEX/SMA adapter for that. This will give the end result a more “pro” look. The 2mm pitch connector isn’t essential either, but this connector will fit on the headers of the TTL to Wifi converter (I think) so that I don’t have to solder any wires directly onto the converter PCB headers – I don’t like doing that, a connector just looks and feels better.

And the enclosure I chose has nice ‘ribs’ on the inside so I can put a piece of perfboard between those ribs and solder the voltage regulator on the perfboard and mount the Wifi module to it.

Ok, I think I’ve got all things covered; I ordered the parts I didn’t have yet and they will be here real soon. Let’s see how this LED controller turns out!

This post is a follow-up on a previous post where I had a look at a very cheap RGB LED controller. I have 10 meters of white LED strip just waiting to be used, so after finding out what to send to this LED controller, I searched for a way to connect it to my system. This time I took the easy road. The plans are to use 3 LED strips in the hallway: one above the door, one where the coat rack is and one above the door to the living room. And 3 is also the number of LED strips you can control with one MS-35. So the best location for this controller was easy – in the hallway, under the stairs, where we have a small space of 0,75 m² with heating pipes and a lot of domotica hardware -stuff like a RFXCOM receiver, Opentherm Gateway, Plugwise stick, ELV MAX Cube already found a place there.

I’ve also got an Ethernet switch nearby, so I didn’t have to think very long – this first MS-35 will be Ethernet-enabled by connecting the 5V TTL of the MS-35 to a EZL-70 I bought some time ago but which didn’t have a purpose yet. So I tried to get the MS-35 working with the EZL-70. I started on a breadboard.

From left to right: blue patch cable, EZL-70, MS-35, 3 white LED strips.

Finding out what the 4 pins for the programmer cable were for was not that hard – the manual for the programmer cable contains an image that shows what is RX, TX, GND and 5V. So the 4 wires between EZL and MS-35 were connected within a minute.

So how to connect the EZL-70 to the MS-35?

These are the settings for the EZL-70 TTL to Ethernet converter. Not much to talk about, actually..

JP13 on the EZL-70 was set to TTL mode. JP17 on the EZL-70 is the TTL port, so I soldered a bunch of headers there; the EZL-70 manual shows which pin is what, so no surprises there either. For the record: you’ll need pins 1..4; pin 1=+5V, pin 2(RXD) and pin 3(TXD) go to the MS-35 and pin 4 to GND.

With the MS-35 in front of you like in the picture above, the wiring is as follows:

• top left goes to EZL-70.TXD;
• top right goes to EZL-70.RXD;
• bottom left goes to +5V;
• bottom right goes to GND.

Now the software side, the ‘protocol’; this took a bit longer.

At startup, the “RGB Controller MS-35″ software that’s on the Mini-CD sends a lot of bytes to the MS-35; about 10 times 0xfd, some zeroes (0×00) and a checksum. The way the first couple of 0xfd’s were sent, the Rx buffer being purged by the software and another sequence of bytes being sent including a valid CRC, made me think the first single-byte transmissions of 0xfd were not necessary and I was right. Then why are those first 0xfd’s being sent? Keine Ahnung… it works without those too.

After I sent ’0xfd 0×00 0×00 0×00 0×00 0×00 0×00′ (and the CRC-16 of those bytes) to the MS-35, it responded with an ‘a’, immediately followed by (as in: in the same TCP/IP frame)  ’_C_RGB_1′. The ‘a’ is also used as an ACK as I discovered earlier, so the second part must be some sort of identification for what you’re talking to – an RGB controller

After that, setting the color and brightness (or, with white strips, the brightness of those 3) is very easy. Just send 0×01 0×00, the 3 values for R, G and B and 0×00 0×00. So for red in full brightness this would be: 0×01 0×00 0xff 0×00 0×00 0×00 0×00 (and the CRC-16 of course). That’s it!

One nasty habit of the MS-35 is that when you send it something it doesn’t understand, the whole thing just stops working – you won’t get an ACK (‘a’) but an ‘e’ (0×65) instead and it’s game over – nothing seemed to help to get communication going again, everything gets an ‘e’ reply and nothing happens with the LED strips; the only thing that helped to get on speaking terms with the MS-35 again, was power-cycling it. Very annoying when you’re trying to find out how to communicate with it…. Maybe those first 0xfd’s do something ‘special’? A software reset perhaps? I don’t know and I didn’t bother to find out; just make sure your own software is OK and you’ll never get an ‘e’, right?

I wrote a small test that changes the brightness of the 3 white LED strips I’ve got attached to this LED controller and it has been running fine for an hour or so:

while true do
begin
  RGB:=inttohex(random(255),2)+inttohex(random(255),2)+inttohex(random(255),2);
  s:=HexToStr('0100'+RGB+'0000');
  crc16:=StringCrC(s);
  s:=s+chr(Hi(crc16))+chr(Lo(crc16));
  Net.Socket.SendText(s);
  delay(100);
end;

Nice… now it’s time to find a nice enclosure and put 3 white LED strips in the hallway…

Oh, there’s one last ‘gotcha’ to the MS-35. On the PCB there are 2 ‘things’ that have a heatsink; those heatsinks are very close to the 3 IRFZ44N MOSFETs – for one of them, close enough to make contact.  In that case, the LED strips will light up very dim, even when you don’t want them to (0×00…). Just gently bend the rightmost heatsink away from the MOSFETs and the problem will be gone. Have fun with this 15 euro LED controller – I know I will

Merry Christmas!

LED strips are nice, I like them a lot. Especially the (warm) white ones. We use them in the kitchen and behind the TV; in both cases as a replacement for light bulbs and/or fluorescent tubes. Looks very nice.

So when I could get my hands on some cheap white LED-strip, I didn’t hesitate and bought 10 meters. Those LED strips (which haven’t even arrived yet) come with a 12V adapter and a small ‘box’ with IR receiver and a small credit-card sized IR remote. That’s OK for RGB LED strips in the child bedrooms, but not when those LED strips are going to be used in the living room, entrance or anywhere else. So I needed a simple LED controller; not too expensive, and that has just the stuff I need – the controller and a way to send commands to control the strips individually. And last week I found the Conrad MS-35 RGB LED controller: cheap and no unneeded accessories. If you want you can even add buttons to the controller or an IR receiver (both connected to the controller by means of the headers on the PCB) but I don’t need all that – just this small controller for 15 euro, that’s all I need. Cheap and the user reviews weren’t bad either, so why not try it.

I added the P522J USB programming cable to the shopping basket and today those goodies arrived.

Time for some good-old serial port sniffing… The USB programming cable uses the Silicon Labs CP210x USB to UART Bridge driver (which is on the mini driver CD that comes with the cable). Now let’s see what happens when I try to program a so-called user sequence with the software that came with the controller:

First only the red channel goes on, next only green and after that blue. And I added some variations to the time values, so it’s easier to find them back in the communication between the software and the controller. The software has a ‘Send program’ button for that so after I started a Serial port sniffer, I clicked that button and had a look at what was sent to the controller:

> 02 03 00 00 00 00 00 f3 23
< 61
> 03 00 ff 00 00 04 01 14 e4
< 61
> 03 01 00 ff 00 05 02 54 80
< 61
> 03 02 00 00 ff 06 03 73 41
< 61
> 0a 01 08 00 00 00 00 10 4a
< 61

OK; 61 must be the ACK.  The 02 on line 1 must be some ‘start programming’ id, the 03 is the number of colour transitions. Line 3 contains the first transition, line 5 the 2nd transition and line 7 the 3rd transition. And it’s obvious that the transition line contains a sequence id (pos 2), the R value (ff), G value (00), B value (00), cross-fade time (04) and the hold-time (01). And the last 2 bytes are the CRC16. Byte value 0a on line 9 must be some end programming id, followed by the User sequence id (01) ?? Don’t know what the 08 on line 9 is for…

Although this is nice, all I really need is a very simple command to set the R,G and B values – nothing more.

Lets see what more the MS-35 software has to offer.

There’s an Edit button in the User-sequence programming dialog; let’s see what happens there.. hey that’s a WYSIWYS (what you set is what you see) dialog with 3 sliders and some buttons to quickly select some colors. I changed 1 of the sliders and immediately the LED strip responded..

Let’s fire up the sniffer once more! With every change of either the R-, G- or B- value I saw the sniffer capturing a packet, so that should contain what I was looking for:

> 01 00 f6 6d 92 00 00 94 65
< 61
> 01 00 f6 6e 92 00 00 d0 65
< 61

Here, the G value was changed from 109 (decimal) to 110.

Done, I know what I need to know!