Raspberry Pi+Minibian: Adjusting the Locale and Time Zone

I really have enjoyed playing with the Raspberry Pi, but many of my projects don't require a GUI (for example OpenVPN and web servers). For projects like these, I usually install Minibian which is a great, small version of Raspbian with all the GUI goodness removed. It is a perfect starting point for my headless projects, except that out of the box, it comes setup with locale and timezones configured for Great Britian. This causes some strange characters to come up when typing on the keyboard, and the clock doesn't reflect my local time zone.

Fortunately, these issues are easy to address, and I will show you the steps I take to configure my system for my locale and time zone (us-EN & America/Los_Angeles). Just use your locale and time zone in the steps below to configure your system as desired.

1. Install Minibian on your SD card following the provided instructions. Insert the card into your Raspberry Pi, power it up, and log in. (The default username/password is root/raspberry). You may also want to change the name of your system from the default "raspberrypi" by editing the /etc/hostname file.
2. Change the keyboard locale. Run the following command:

   dpkg-reconfigure keyboard-configuration

   then
   • Set your "Keyboard model" to "Generic 105-key (Intl) PC".
   • Set the "Country of origin for the keyboard" and "Keyboard layout" both to "English (US).
   • Next for the "Key to function as AltGr" choose "The default for the keyboard layout".
   • For "Compose key" I chose "No compose key".
   • Finally, choose "No" for "Use Control+Alt+Backspace to terminate the X server".
   Once the command completes, reboot your Raspberry Pi to pickup the new keyboard layout.
3. Now change the system local. Run the command

   dpkg-reconfigure locales

   and de-select "en_GB.UTF-8 UTF-8" and select "en_US.UTF-8 UTF-8", then set the default locale to "en_US.UTF-8" on the next screen.
4. Edit the /etc/default/locale file and change/add the following lines:

   LANG=en_US.UTF-8
   LC_ALL=en_US.UTF-8
   LANGUAGE=en_US.UTF-8

   then log out and back in again to pick up the new locale.
5. Finally, run

   dpkg-reconfigure tzdata

   and select "America", then "Los_Angeles" to set the local time zone for your system.
6. Now that your system understands you a little better, it's probably a good time to update your system using

   apt-get update
   apt-get upgrade

   then reboot your system again.

Optional Tweaks

If you'd like to make your system a little more secure, you can enable sudo and disable the root login with the following steps:

1. Install sudo:

   apt-get install sudo

2. Create your new user. For example, to add the user "bob" run the command

   adduser bob

   and follow the prompts.
3. Add your new user to the sudoer's list. Run visudo then add the following line (changing the username to the user you just added) after the root ALL=(ALL:ALL) ALL line:

   bob ALL=(ALL:ALL) ALL

4. Now disable the root user with the command

   passwd -l root

   (note that is a lower-case L, not a one)
5. Now log out of your root session and log in as your new user.

Finally, it's a good idea to change the SSH server keys because the ones that come with the image file make it easy to impersonate your system (since everybody has access to those keys):

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server

Now you should have a headless Raspberry Pi system that you can use for various server projects that is customized for your locale and timezone! If you have any questions or comments on this procedure, please feel free to leave a comment.

Read More......

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......