Driving WS2812/NeoPixels RGB LEDS over CAT5 Ethernet Cable

I was recently working on a project using Adafruit NeoPixels (WS2812) RGB LED strips where a single controller was supposed to drive five strings of 30 pixels that were physically located several feet apart. I knew right away that there was going to be a couple of problems trying to drive the strings over more than 20 feet of cable. First off there is the voltage drop issue - these strings can draw several amps, and could easily drop around 1 volt or more, depending on the cabling and connectors. The other issue is the integrity of the data signal being sent to the string. The pixels are very timing sensitive, and noise or ringing caused by a long wire run could easily introduce errors, or even result in a completely non-functioning string. This last issue was made even worse by my choice of controller, the Teensy 3.0 which is a 3.3V part, while the pixels require a 5V input. (By the way, the Teensy 3.0/3.1 + the OctoWS2811 library is an awesome choice for driving dozen to hundreds of RGB pixels!)

While it seems that many people have successfully driven NeoPixel/WS2812 strings directly from the Teensy using a small resister to reduce ringing, I was pretty sure that wouldn't work over any appreciable distance. It also appears that the newer WS2812B pixels won't work at all with just a 3.3V signal. It didn't take me too long to come up with the solution for the data issue - RS-422/485 drivers and receivers! Since the pixel data is really just serial data, I figured using RS-485 balanced transmission lines to send the data would work perfectly. The data signal is well within the bandwidth these chips are capable of, and as a bonus, the SN75174 Quad Differential Line Driver IC inputs will easily accept the 3.3V outputs from the controller! On the receiving end, I went with SN75176 Differential Bus Transciever chips because I had several of those on hand in my parts bin. I just needed the receiver part of the chip, and it was quite easy to disable the transmitter portion.

Next up was the power-drop issue. Right about the same time I was dealing with this I discovered these LM2596 DC-DC Buck Converters on Amazon - they were perfect! Their low cost, small size, high efficiency and wide input voltage range made them a snap to integrate into my project. (Just make sure you check/adjust the output voltage on these before you use them!). Now I could feed 12V into my long cables feeding the remote strings, and use these power supplies on the receiving side to drop it down to the needed 5V. Since I was only driving about 30 pixels on each line, the 3A output was more than enough to drive each string.

With all the pieces in place, it was time to test out my ideas. First, I wanted to test out driving the data signal using the differential converts, so I wired up a transmitter and receiver on each end of 100 feet of CAT5 cable, connected up my controller to the transmitter and 5 meters (150 pixels) on the receiving end. For now, I just connected up a beefy 5V/10A power supply at the receiving end to power the string. After connecting everything up, it worked like a charm! Every pixel was responding as though it was sitting right next to the controller.

Next up, I cut the string up into 5 lengths of 30 pixels each, and wired them up as shown below, using the differential transmitters/receivers and the DC/DC converters (again making sure they were adjusted to provide 5V output!), powering everything with a large 12V power supply. Everything worked as expected, the pixels were changing colors as commanded, with no color shift or dimming caused by voltage drops.

Notice that I am calling out the color codes for the CAT5 wiring - it is important that at least the data wires are on twisted pair of conductors (blue/blue-white in this case). I also like to have the power wires paired as well, with all the +V connections on the solid wires and the -V connections on the white-striped wires, which helps with noise immunity on the power lines. In my project, I used 4 position connectors and just tied all the +V wires together on one terminal and all the -V wires on another (with the data on the remaining two terminals). Using all the extra wires in the cable for power helps reduce the resistance, and thus the power drop on the cables.

In the end, my project worked well, with the strips connected via 15 - 25 foot lengths of CAT5 cable all connecting back to my central controller. If you have a project where you need to have several remote RGB pixel strips all controlled from a single controller, hopefully by using this approach you can make your pixels work just like they were connected directly to the controller. As usual, your feedback is always appreciated, and if you have any questions please feel free to leave a comment.

UPDATE: I've just added a new post that goes into more detail about using the SN75176A chip in this design, for those of you who have asked about variations of the above circuit.

Read More......

Low-Voltage Controlled AC Power Strip

NOTE:  This hack involves working with dangerous voltage levels, which can result in property damage, injury, or death!  Proceed at your own risk.  If you are not comfortable working with power circuits and wiring, you may want to consider using something like the PowerSwitch Tail II from Adafruit instead.

As part of a larger project I'm working on, I needed a way to control five AC powered devices from a small microcontroller.  At work, we use Opto 22 G4 Solid State Relays in our industrial control systems.  They are small and convenient to work with, but I was looking for something more compact.  Searching around the web, I noticed that many hobbyist were working with Sharp S108T02 Solid State Relays, but doing a little research at Digikey I decided to use the similar Sharp S201S06V instead.

S201S06V Solid State Relay Diagram

Next, I needed to find a way to provide outlets to plug the controlled devices into.  I thought about using a project box and mounting three standard dual outlet wall sockets on it, then using a standard outlet cover on those.  That would work, but it would still be on the large side.  I then considered using a standard six outlet power strip.  I headed down to my local Home Depot to see what options I had there, and returned with a nice, metal cased power strip.  I removed the four screws holding the bottom on and checked to see if my relays would fit:

Ready for surgery

It looked like everything would fit!  As a bonus, mounting the relays flat against the bottom would allow the metal to act like a heat sink.  I measured to get them evenly spaced, drilled the mounting holes, and attached the relays using a bit of thermal compound for good heat transfer.  (I thought I would be able to attach the wires after the relays were mounted, but it turned out to be easier to do with them unmounted, so next time I would wait on the thermal compound).

Power and control bus wiring

I started by soldering the common buses for the AC power and DC control lines, covering all the exposed wiring with heat shrink as I went.  Once I had the common wiring done, I added the individual AC output wiring using different colors for each – I picked colors that matched the low-voltage cable's colors.  For the low-voltage cable I just used the cable from an old PS/2 mouse that had a 6 pin DIN connector, which gave me 5 lines for control signals and 1 for ground.  The mouse cable works nicely here because it is long and flexible.  Before you start wiring the DC cable,  drill a hole in the upper part of the case near the power cable, big enough for an appropriate strain-relief.  Then run the cable through that hole, before you begin soldering it!  I also made sure to write down the sequence of wire colors on the DC cable that corresponded to the pin numbers on the DIN connector, so that I could attach the AC control wire colors in the same sequence.

Added power control wiring

After getting all the AC and DC wiring attached to the solid state relays, I mounted everything to the bottom plate of the power strip, and routed the wires, with the inputs coming from the side where the power cable comes in, and the outputs at the opposite end.  As you can see, I also added some cable tie points to make sure the wires did not get pulled out or shorted.

Solid state relays wired and mounted

Next, I removed the black “hot” bus from all but the outlet closest to the power cord, and broke the jumpers on the hot side between the top and bottom outlet of each outlet pair that connected them together.  I am leaving the outlet closest to the power cord always hot, so I have some place to plug in the project's controller.  I can still turn the entire thing on and off using the existing power switch.  Now that that the remaining five outlet's hot sides are disconnected, it's time to start wiring them up.

Since these outlets use “slide in” connections intended for lower gauge solid core wire, and I am using smaller gauge stranded wire, I soldered the ends of the stranded wire to form a stiff end that would easily slide into the outlet connections.  You can sort of see the soldered end of the red wire in the next photo.

Connecting the power wiring

Now I attach each of the AC control wires to the corresponding outlet, making sure to keep them in the same order as the relay (and DIN connector) wiring.  I cut each wire to the proper length, so that I wouldn't have a lot of extra wire to try and tuck inside.  Here it is all wired up:

Ready to close

And now all assembled and ready to go with its new “tail”:

Ready for work

Now I should note that the solid state relay inputs are simply LEDs, and require a current limiting resistor in series or you will destroy the devices.  In this design, those resistors are located on the controller board, but you could easily include them inside the power strip by soldering them inline with the DC control wires.  If you are going to use this with multiple projects, I would suggest including the resistors in the power strip to help protect the relays from damage.

This hack worked out very nicely, and it's been working for several months without any issues.  Once again, since this project involves dangerous voltages, you should exercise extreme caution when building and using this hack.  I am not responsible if you decide to duplicate this project and you electrocute yourself, set your house on fire, or encounter some other mishap.  You have been warned.

Update

Several of the commenters over at Hack a Day noted that I didn't mention the solid state relays I'm using are only rated for 3 amps (and you would likely need a heat sink for that).  Although that is fine for my project, you probably shouldn't try to control your air conditioner using these devices!  You could do a similar hack using a larger power strip with more internal room and beefier solid state relays, and along the way provide either fusing or circuit breaker protection for the individual outlets.

Read More......

Let There Be Music

I needed to be able to play MP3 files as part of a larger project I'm working on.  I did a quick search on the Internet for embeddable MP3 player chips and circuits, but everything seemed a bit too expensive or too much work.  It was around then I saw Hack a Day's post pointing me to Gadget Gangster's Instructables article Adding MP3 to your project for $3.00.  Being the cheapskate that I am, $3 sounds great to me!

A quick trip to eBay and I had two of these “mini-clip” players on the way.  I figured I should get an extra just in case I damage one while fooling around.   Before I began hacking the player, I tested it out to make sure it was operational and get an idea of how it behaves.  One of the things I discovered is that the USB interface is pretty flaky (at least when connected to a Linux system), so it was much easier and faster to transfer files onto it by writing directly to the MicroSD card using a card reader.

Player liberated from its case

I cracked one open and took a look to see what it would take to hook into it.  One of the things I wanted to do is to be able to move this from prototype to finished product, or between projects.  The Instructables article showed discrete wires soldered to the board, which I could have brought out to some kind of connector.  After a bit of thought, I realized I could use a small 10 pin IDC connector and ribbon cable to allow me to plug it into a nice wire-wrappable header.  And with the extra pins, I could also supply power, and even pick off the audio!

After some minor surgery

First, I removed the power wires and also carefully removed the surface mount audio connector.  Somewhere in my lab I have the parts to build the IDC/ribbon cable assembly, but I found a pre-made one in my parts bin so I just cut it in half and started peeling back a few of the wires.

IDC cable ready for action

 I started by connecting to the power pads (mostly because they were big and easy to get to).  This also conveniently allowed me to set the amount of overhang from the connector to the board.  I then cut and stripped the remaining three wires for that side and landed them onto the pads where the audio connector used to be.  Next, I flipped over the board and cut each of the wires to length and soldered them to the center of each button pad.

Wires landed on board

Now with all the wires hooked up, it's time to test it out and see if I fried anything.  I wired up a 2x10 header on my main project (more about that in a future post) and wrote some quick code to “push” the buttons.

At home in the new project

I'm using a PIC18F4550 in this project, and using my favorite language – assembly. I love the challenge of hand-tuning code to make it as small and fast as possible, and that's not so easy with the PIC18F's!  Anyway, I wanted to drive the switch outputs open collector style, so for the switch outputs I initialize the ports by setting the switch TRIS bits and clearing the LAT output bits.  Then when I want to “press” a switch, I clear the the corresponding TRIS bit which drives the output low, and set a tick countdown timer.  When that timer expires about 200ms later, I set all the TRIS bits again to “float” the outputs and release all the switches.

After checking to make sure the software was doing as I expected, I connected the MP3 player to the main project, powered it up, and out came music!  I then tested each of the switch functions, and the player responded as expected, pausing, playing, skipping forward and back, etc.  To my surprise, everything worked as expected.  The player has been working without any hiccups for several months, despite powering it with 5v instead of it's expected 3.7v battery, and shorting the switch inputs to ground instead of the other contact (although I expect that is the way it is wired anyway).

I would like to thank Gadget Gangster for sharing his cool tip to re-purpose cheap MP3 players for use in embedded projects, and Hack a Day for bringing it to my attention.

Read More......

Hacking WebRunner to work with Firefox 6.0

I have come to depend on Salsita Software's WebRunner extension for Firefox that let's me create “applications” out of web sites. It comes in especially handy when I want to be logged in with multiple identities on the same web site, as well has keeping an always open window on my Zoneminder cameras.

When Firefox 6.0 was pushed out in Ubuntu, I was quite dismayed to find that when it checked add-ons and extensions for compatibility, WebRunner was not compatible, and furthermore, an updated version was not available. I waited for around two weeks for Salsita to update their software, but so far there's been nothing. So I dug around in the .xpi file and came up with this hack to make the current version work with Firefox 6. These instructions are for Ubuntu/Linux (since that is all I have running now), but the changes should be very similar for Windows as well.

First download (but don't install/run) the latest .xpi file from here. Then open the file with an archive manager (.xpi files are really just jar/zip files) and edit the file install.rdf, changing the value of /RDF/Description/version from 5.0 to 5.1, and the value of /RDF/targetApplication/maxVersion from 5.* to 6.*. Next, edit the file stub/application.ini, changing the value for MaxVersion from 5.0.* to 6.0.*. You may want to rename the .xpi file at this point to make it easier to keep track of it.

Now update to Firefox 6.0 (if you haven't done so already) and remove the old WebRunner 5.0 extension, in Tools|Add-ons on the Extensions tab. Close that dialog, and go to File|Open File... in Firefox and select your modified .xpi file. It should install without complaint, indicating it is version 5.1 (hopefully Salsita will version their next release higher than this).

At this point, you can either re-create your web application shortcuts, or hack the existing ones to work with the updated extension. To fix the current shortcuts and applications, modify the command for the shortcuts to point to firefox-6.0 instead of firefox-5.0. Then for each application in your ~/.webapps directory, edit the appname@webrunner/stub/application.ini file and change MaxVersion from 5.0.* to 6.0.* and change GRE_HOME to /usr/lib/firefox-6.0. Now try to launch your web application shortcuts and you should be good-to-go!

As with most hacks, I make no guarantees that this won't in some way hose your Firefox installation or your entire computer, so attempt this at your own risk! On the other hand, if you are like me and depend on the excellent WebRunner extension, this hack is a quick way to get it back in Firefox 6. Make sure to leave comments if you have tried this under Windows and get it to work.

Read More......

MonoDevelop Custom Color Schemes

I have been playing with MonoDevelop 2.0 on Ubuntu on and off for a while now, but one of the things I find most annoying (other than not having ReSharper) is there is no easy way to modify the colors used for syntax highlighting. Sure, it has several pre-defined schemes you can choose from (Using Edit | Prefrences > Text Editor > Syntax Highlighting), but changing individual syntax element colors using the GUI is not possible.


The reason I find this issue annoying is that I like to have comments and strings really stand out – in our shop we avoid comments as much as possible, and string constants are kept to a minimum, so I like to be able to see them easily in the code. A few years ago, I started using “highlighter” background colors for comments and strings, and have become quite attached to them ever since.


After many attempts to find a solution on the web, I finally found all the pieces I needed to make it happen. The basic problem is that although MonoDevelop allows you to add new color schemes, the format of the scheme file is not well documented, and there are a few tricks you need to know to make it work correctly. The existing schemes are embedded resources and not stand alone files, so they can't be easily viewed for reference. Finally, I discovered this Ubuntu Forum thread that helped me find the solution. The first piece of the puzzle was discovering the color scheme XML source files in MonoDevelop's SVN tree. Now I had some samples to go by. Another useful tidbit from that thread was that the file name must end in "Style.xml" in order to work correctly. I did not actually verify that this was required, but I did it just to be safe. The rest came from a MonoDevelop Developer's Article page I stumbled across shortly thereafter. One of the important things mentioned on that page is that you need to put the color scheme XML file in the ~/.config/syntaxmodes directory (although in my Ubuntu installation it is actually ~/.config/MonoDevelop/syntaxmodes). Now I had everything I needed to start tweaking colors!

The first thing I did was download the VisualStudioStyle.xml file and renamed it to TeknynjaStyle.xml. Next I edited the file to change the name and _description attributes of the EditorStyle tag so they would not clash with the existing styles in the GUI. Finally, using the information from the MonoDevelop article and the existing examples, I modified the colors for comments and strings to get the highlighting I was looking for:

   <Style name="comment" color="black" bgColor="#ffff80"/>
   <Style name="comment.doc" color="black" bgColor="#ff8040"/>
   <Style name="comment.tag.doc" color="black" bgColor="#ff8040"/>

   <Style name="text.preprocessor" color="purple"/>
   <Style name="text.markup" color="skyblue"/>
  
   <Style name="constant" color="black"/>
   <Style name="constant.language" color="keyword-blue"/>

   <Style name="string" color="black" bgColor="#80ff80"/>
   <Style name="string.single" color="black" bgColor="#80ff80"/>
   <Style name="string.double" color="black" bgColor="#80ff80"/>
   <Style name="string.other" color="black" bgColor="#80ff80"/>
  
   <Style name="keyword" color="keyword-blue">
       <Style name="type" color="#004080"/>
   </Style>

I found the "bgColor" attribute by looking in one of the other color scheme files. Then I copied my customized color scheme file to ~/.config/MonoDevelop/syntaxmodes, restarted MonoDevelop, and selected my color scheme. I was able to tweak the colors by editing the XML file and restarting MonoDevelop until I achieved the scheme I was looking for. Finally I had the highlighting I was used to in Visual Studio, and along with modifying some of my commonly used key bindings, I was able to make MonoDevelop feel a little more like "home".

Read More......

Ubuntu Photo Frame

About two years ago I converted an old laptop into a photo frame for the living room. There are plenty of examples of how to do this floating around on the web these days, so I am not going to cover that here. What I am going to talk about are the software aspects of this project, and my recent upgrade of my photo frame.

The frame had been working fine for almost two years, but a few months ago I upgraded my WiFi network at the house to WPA (finally), but that meant that I could no longer transfer files to the frame because the WiFi card I was using in it only supported WEP. Shortly after that, the frame started acting strangely, turning itself off about once a day, then finally not booting at all with the infamous “missing file” messages you get when Windows can't read the hard drive correctly.

The original software setup for this project was Windows 2000 with a small .NET application I wrote to scan a directory and display pictures from it. When it was time to display the next photo, the program would scan the directory and pick a new picture at random to display. The laptop hardware did not have enough “horsepower” to handle any kind of transitions or fades between photos, so the program just displayed the next photo on the screen without any transitions.

I brought the frame back to my cave, where I confirmed that the hard drive had indeed given out. I ordered a SYBA SY-IDE2CF-NB25 Ultra IDE to Compact Flash Adapter from StarSurplus, and with a 4GB Compact Flash card I had laying around, I now had a solid state hard drive for the frame. I also ordered a EDIMAX EW-7108PCg 802.11g/b Wireless LAN PC Card from NewEgg to allow WiFi access to the frame again. I selected this card because it is well supported under Linux and it is very inexpensive. Now that I had all the hardware ready, time to re-install the software.

I wanted to use Ubuntu for this project, because I am familiar with it, and this would give me an opportunity to learn about doing a very minimal installation. My goal was to use as little space on the flash drive as possible for the OS and supporting programs to leave room for photos. After a few practice runs setting up the system and trying different programs, I came up with the following recipe.

First, I installed Ubuntu Server, with the OpenSSH and Samba options. The server edition of Ubuntu doesn't install any kind of GUI (just a command prompt) and none of the heavy applications like OpenOffice, Evolution, etc. Then I got the Wifi card working (it wasn't detected during setup) and performed an upgrade to make sure I had the latest security patches. I setup Samba to allow access to the folder containing the pictures to be displayed. Next I apt-get installed xorg, dnotify, and feh. feh is a small, lightweight image display program for X. While playing around with different configurations, I discovered that even under Ubuntu, this laptop just didn't have what it takes to display transitions between photos, and so feh fit the bill almost perfectly.

I tweaked the xorg.conf file to prevent it from blanking the screen (I think it defaults to blank after 10 minutes), copied some photos to the frame, and fired off feh using xinit. And my photo slide show started up! The only problem with feh is that it only reads the files in the directory when it starts up, so if I add pictures to the directory later, I would have to restart the program in order for them to be shown. So I created the following script using dnotify to restart the program whenever any files in the folder have changed.

#!/bin/bash
export HOME=/home/teknynja
while true; do
  killall -q feh
  sleep 1
  xinit /usr/bin/feh -rzFZD180 --hide-pointer /home/teknynja/Pictures &
  dnotify -MCDRro /home/teknynja/Pictures
done

I made the script executable, and added a line to invoke the script from inside /etc/rc.local so that it would run when the system started up. After a couple of days of testing in the cave, I put everything back together and it is now back in the living room, displaying our family photos once again. It also has the added bonus of being completely silent, due to the solid state hard drive. The total space budget on the flash drive was 645MB for the OS and supporting programs, leaving around 3GB for photos, which is more than enough for now.

Once again I warn the readers that I still have a lot to learn about Linux, so any constructive comments are appreciated. If you have any questions or would like more details about this project, feel free to leave a comment and I will try to help you if I can.

Read More......

Obscure Ubuntu Tip: CRON User account has expired

No, I haven't forgotten that I have a blog. I've just been keeping busy with a lot going on at work, and a backlog of “projects” at home after finishing up the kitchen project. Some of those projects have involved getting down-and-dirty with Ubuntu, and I thought I would share a quick tip I discovered yesterday.

I was looking through the system log (/var/log/syslog) on one of my servers and I noticed it was full of “CRON[xxxx]: User account has expired” messages. A little searching on the web pointed to the fact that the root account had been locked. While setting up this server, I had followed some instructions I found on the web that required me to unlock the root account, then re-lock it when I was done with the

sudo passwd -l root

command. Locking an account this way also causes the password to be expired, one of the results of which is the above mentioned log entries. Most of the solutions I found on the web involved either unlocking the root again and giving it a long, random password, or manually editing the password files. I think I've found the correct way to fix this though, by using the

sudo chage -E-1 root

command, which sets the root's password to never expire. (Note that the -1 is negative one, not dash L). After using the above command, the system log showed normal CRON log entries, and the root account remained locked.

I hope someone else will find this information to be of use. That's it for my very obscure Ubuntu tip. Join me again soon for another exciting post. I actually have a good sized list of topics to cover on the blog, so hopefully things will settle down and you will hear more from me soon. Thanks for stopping by!

Read More......

Video Sedation

During one of Woot's last “Woot-Offs”, I picked up a couple of Sansa E250 media players for the kids to watch videos on when we need them to be calm and quite (like during visits to Ikea). They each already have a Sansa Shaker loaded with their favorite songs (Tucker seems very fond of his blue “radio”), but video is a much more effective way to keep them “sedated”. In the past, I used my T-Mobile MDA with several hours of their favorite movies loaded on it to keep them occupied – but they both had to share the screen and I didn't like the idea of them fondling my phone and possibly dropping or otherwise injuring it.

For $30 bucks each during the woot-off, I figured I couldn't go wrong, so I ordered two of them. I quickly discovered that the built-in firmware for these players could only handle video encoded using Apple Quicktime DLLs that I have so far managed to keep off my system. Plus, the compression of the supported format was so bad that I could have only put a few minutes of video in the limited 2Gb of memory the devices contain.




Here's were Rockbox saves the day. Before I pressed the shiny “I Want One” button on Woot, I did a little research and discovered this project and found it supports the players I was about to purchase. I went ahead an placed my order for two, then within hours of their arrival, I had the Rockbox firmware installed on them. I played with the software, tweaking the many settings and options the firmware provides.

Finally it was time to put some videos on the devices. It took a while to figure out the optimal encoding options for these devices, but after playing around for a few hours I arrived at the following settings:

Video Encoding Format	MPEG2 (RockBox only supports this for now)
Video Resolution	224x176
Video Bitrate	192 kbps
Video Frame Rate	25 fps
Audio Encoding Format	MPEG-1 Layer 2
Audio Samping Rate	44100 Hz (other samping rates break mpeg 2 compatibility)
Audio Bitrate	64 kb/s, Monophonic

Although this results in some serious visual artifacts, this is perfectly fine for the kids to watch (they haven't complained yet!). These settings allow me to cram several hours of video onto the players. The only thing I haven't figured out yet is how long the batteries last during video playback – the longest stretch of time the kids have watched the devices is about 90 minutes during a drive back from Grandma's House.

I figured I should share this little tip in case anyone else needs to administer some “video sedation” of their own while out in the world. As always, any tips and suggestions are always appreciated in the comments.

Read More......