Conrad MS-35 LED controller revisited

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.

EZL-70 and MS-35Finding 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?

EZL-70 settings

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 (0x00) 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 0x00 0x00 0x00 0x00 0x00 0x00’ (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 0x01 0x00, the 3 values for R, G and B and 0x00 0x00. So for red in full brightness this would be:ย 0x01 0x00 0xff 0x00 0x00 0x00 0x00 (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’ (0x65) 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 (0x00…). 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!

Tagged . Bookmark the permalink.

8 Responses to Conrad MS-35 LED controller revisited

  1. Pingback: The invisible kill-joy - Digits Domotica Blog

  2. Pingback: Building a cheap Wifi LED controller - Digits Domotica Blog

  3. Miko Kuijn says:

    It’s not game over ๐Ÿ™‚ The controller reads fixed-length packets of 9 bytes. If you get out of sync, even valid packets will not parse. You can “reset parsing” by tapping a key into a terminal emulator until a new “e” appears. The controller will then accept new valid packets.

    • Funny that you mention this now ๐Ÿ™‚
      Last weekend I visited a friend who didn’t get his MS35 working from a Node.JS script he was working on. We coincidentally found out that sending 0xfd until an ‘e’ was returned, made the controller accept new packets. What we didn’t know was that ‘any key’ would have the same result ๐Ÿ˜‰
      Thanks for the info!

  4. Paul says:

    Hello,

    Is this possible to do with a direct usb connection? So can i send directly packaged to a usb port (with linux)?

    • I really don’t know, never tried that.
      What I do know is that I had to install a Silicon Labs CP210x USB to UART Bridge driver on my Win7 PC for the programming cable.
      That’s all I can tell…

  5. Hi all,

    Based uppon the information explained above, I created a C# program to control RGB intensity (and more). Above that, I did check out some more commands lik start-program, program user-defined programs 8 and 9, etc.

    I have placed a download link on my website: http://www.tec-v.nl/downloads

Leave a Reply

Your email address will not be published. Required fields are marked *