LED light up bicycle

The city of Round Rock, Texas has an annual night time bike ride event at the end of July. It starts at 9pm with a ride through the downtown area to a city park where they have music, free hotdogs and free shaved ice. After the event everyone rides back to the starting point. It sounded like fun to me so I decided I wanted to participate along with my two older kids. As the event approached I started to think it would be fun to decorate my bike for the event. I didn't want to spend much money because this was going to be a pretty temporary thing. I started scrounging my plastic storage bins of electronics for parts. I found a 12 volt LED light strip that had originally been purchased to be used as under cabinet lighting (which I never installed). I had an old unused UPS battery backup that came with our AT&T Uverse service. I tore that UPS open and found a nice 12 amp hour SLA battery. I also had four extra TIP120 transistors and an Arduino Uno. Seemed like enough ingredients to make something cool.

I started by measuring how many amps the full strip of LED's drew at full brightness. It measured 1.3 amps so the battery should give me about 9 hours of run time between charges which is obviously more than enough for a long night ride.

The spool had just enough LED's to light up each of the tubes of the frame on both sides of the bike. The LED strips have a cut line every three LED's. I cut the LED strips into sections that would fit each of the tubes on the frame of my bike.


Then I soldered power and ground leads onto each of the strips and covered the connections with heat shrink.

I attached the LED strips to my bike using zip ties and black electrical tape.

Next I wired up the TIP120 transistors on some scrap proto board. I soldered on a row of right angle headers so I could plug the Arduino right onto the board. Please keep in mind I was just throwing this together at the last minute so it isn't very pretty. The only real goal was to make it fit on top of the battery and stay out of my way while pedaling the bike. I used a scrap barrel connector pigtail for the main power to the board and another to power the Arduino. I added a 12 volt regulator to the Arduino power circuit because the battery was putting out a little over 13 volts and I didn't want to damage the voltage regulator on the Arduino. The transistors connect to four different LED segments and are controlled by four PWM digital pins on the Arduino. I used a different color wire for each transistor and LED segment so I could keep track of them when I wrote the software for animating the segments.

The transistor circuit is very simple. The TIP120 isn't the best way to do this but I had them laying around. A N-channel Power MOSFET is better for this because it can handle high amperage without generating heat. 

Example of TIP120 used with an Arduino.
Image taken from here

I couldn't wait anymore to see what the bike looked like in action so I just taped the battery to the frame and took it out for a quick test ride. At this point the Arduino software just faded the LED's to full brightness and didn't do anything else.

Now I turned my attention to making a proper mount for the battery. I wanted to make sure the battery was mounted solidly so it didn't fall off the bike when I hit a bump. I started with an old L bracket I had laying around the garage and drilled some holes in it so it matched up with the water bottle mounts on the seat post tube of the bike. I bent the L bracket down a bit so the battery would sit level on the bike. Next I took a piece of scrap sheet metal and created a short metal box for the battery to sit in. I made another tab out of sheet metal so the battery box could also bolt to the other water bottle mount on the down tube. I spot welded everything together and ground down the welds on the battery box so it didn't scratch or cut my legs while pedaling.


After the welding and grinding was all done I mounted the battery box on the bike.

I did a test fit of the battery and it was a little loose in the box but I had planned on putting something on the top edge of the sheet metal to cover any sharp edges.

I scrounged around the garage a bit more and found some extra automotive vacuum tubing. I made a slit down the entire length of the vacuum tubing and then pushed it on the top edge of the battery box.

Now the battery fit very snug in the box.

Next I made two velcro straps out of 1" webbing. I cut the webbing to length and sewed on some velcro with the sewing machine. These straps will hold the battery in box.


Here is the battery with the straps in place and then the control board installed on top of the battery.


Here is how the overall bike looks with everything installed.

The last thing I needed was some way to charge the battery. I searched around on Amazon and found this SLA battery charger. I paid about $18 US dollars for it. It has an automatic shutoff once the charging is complete. It only comes with screw terminals so I had to make my own cable. I used yet another barrel connector and some 18 gauge wire to make a cable. (seriously how many barrel connectors can one person have? I may have used up my stockpile on this project.) I triple checked the polarity of the connecters on my charger and my battery with the voltmeter and then charged up the battery.


I finished writing the code for the Arduino the night before the event. Here is a video showing the animations. Since I only had four TIP120 transistors I could only control four sections of the LED's. The fork and the seat tube just stay on full brightness.

Here are my kiddos at the starting line a few hours before the event.

The night ride event was really fun and my kids enjoyed the ride. I'll go ahead say I had the coolest bike at the night ride. This bike has inspired me to get some exercise and I have been riding about 4 miles every night since the event. Maybe for next year's event I will step up to some Adafruit NeoPixels.

Ubuntu 14.04 init scripts fail and throw errors

I recently built out my first couple Ubuntu 14.04 servers at work and when my chef scripts tried to run they blew up all over the place. Chef was getting errors when trying to start or restart services like ssh and rsyslog. Looking a little deeper at the errors, Chef was executing init scripts directly and getting back an exit status of 1. For example when Chef tried to restart ssh it was running '/etc/init.d/ssh restart'

That script on Ubuntu 14.04 has no output and exits with a status of 1. I attempted to run the same thing manually from the command line on one of the servers and had the same result, no output and an exit status of 1. I did some searching and found other people are running into this same issue with various other services. I did find the command 'service ssh restart' would do the right thing and not throw an error. Since it seemed like this is an Ubuntu or Debian bug with the start scripts I decided to just modify my Chef scripts to use the service command instead.

By default Chef attempts run the scripts in /etc/init.d when starting and stopping services. The service resource in Chef has some attributes that let you modify how services are started. The attributes start_command, stop_command, restart_command and reload_command let you define an alternate command for these actions. Here are the changes I made to get my Chef scripts working again on Ubuntu 14.04.

Before

service "rsyslog" do
    supports :restart => true
    action [:enable,:start]
end

After

service "rsyslog" do
    restart_command "service rsyslog restart"
    start_command "service rsyslog start"
    supports :restart => true
    action [:enable,:start]
end

This change is backwards compatible with older versions of Ubuntu so I don't have to worry about special casing this just for 14.04 boxes.


[Update 1]
After reading a bit more I'm starting to suspect Ubuntu and/or Debian has purposely deprecated running the scripts in /etc/init.d to force people to use Upstart. Apparently these init scripts have been broken since Ubuntu 13.10.


[Update 2]
@retr0h gave me a cleaner way of accomplishing this:

service "rsyslog" do
  provider Chef::Provider::Service::Upstart
  supports :restart => true
  action [:enable,:start]
end

This does the same thing without having to define each command individually.


[Update 3]
@jtimberman informed me that this problem will be fixed in Chef 11.14. In that version Chef will automatically use Upstart for Ubuntu 13.10 and higher. (Chef support ticket) (Git commit)

Gmail messages labeled as sent 'via eigbox.net'

At work I had a user who suddenly started having all her outbound Gmail messages labeled as being sent 'via eigbox.net'. My thoughts immediately jumped to virus or malware. A google search of 'via eigbox.net' returned a bunch forum posts where people were having the exact same problem but I didn't find any info on what could be causing this to happen. The next thing I did was try and find info about the domain name eigbox.net. The whois information showed the owner of the domain name is a company called Endurance International Group. They are the parent company of several different hosting providers including HostGator. The domain eigbox.net doesn't have a website but it appeared the domain is used for a hosted e-mail service. At this point I couldn't rule out a virus but there wasn't anything necessarily suspicious about eigbox.net.

Screenshot showing how messages appeared to recipients.

This person primarily used the native Mac Mail application so the next thing I tested was sending a test message from the Mail application and another test message using the Gmail web interface. I examined the message headers in both messages using the 'Show Original' option in Gmail.

Examination of the headers showed that messages sent from the Mac Mail app were definitely being routed through smtp servers at eigbox.net. Messages sent through the Gmail web interface stayed within Google's network. This information let me focus on the Mail app as the source of the problem. I started combing through the settings in Mail.app. I discovered the user had two e-mail accounts configured. One personal account and another for the company Gmail. Under the Gmail settings (Mail > Preferences > Accounts) I noticed the Gmail smtp server said 'Offline' and the check box labeled 'Use only this server' was not checked.

At this point I audibly exclaimed "Aha!".  What I realized is going on is outbound Gmail messages can't reach Google's SMTP server for some reason and Mail.app is failing back to the SMTP server for the the user's personal e-mail account. Surprisingly the e-mail servers for the personal account allows sending of e-mail with any domain in the from address. Checking the 'Use only this server' box and saving the setting causes mail to get stuck in the outbox. In the end the reason the Gmail SMTP server was offline was because the user changed Gmail passwords. Having 'Use only this server' unchecked allowed Mail.app to seek out another SMTP server. It appears Mac Mail stores the IMAP and SMTP passwords separately. When she changed her Gmail password she updated the IMAP password which allowed her to continue to receive mail but it wasn't very obvious that the SMTP password also needed to be changed. 

To change the SMTP password go to Mail > Preferences > Accounts. Click on the 'Outgoing Mail Server (SMTP)' drop down and select 'Edit SMTP Server List...'

Select 'Edit SMTP Server List...' from the drop down.

Click on the 'Advanced' button and enter the password for the SMTP server.

The user's personal e-mail account is hosted by a company called iPage which does web page and e-mail hosting. iPage uses the eigbox.net domain for it's e-mail. iPage is also part of Endurance International Group. Mystery solved.

Arduino - Using digital potentiometers part 2 (MCP4251)

This is part two in a series of posts about using digital potentiometers with Arduino boards. Part one covered the AD8403 digital pot. This post will go over the MCP4251 from Microchip. The MCP4251 is a dual pot chip with the capability to individually disconnect the terminals of each wiper through software and a hardware shutdown pin that shuts down both wipers simultaneously. Communication with the chip is done over SPI. The chip is available in DIP and surface mount configurations. I bought the DIP version so I could use them on a breadboard. The specific part number I bought is MCP4251-103E/P which is a 10k ohm model with an 8 bit resistor network. The 8 bit versions have 256 possible positions for the wiper which works out to approximately 39 ohms increase in resistance for each wiper position on a 10k ohm model.

Two MCP4251 chips

I began searching for an Arduino software library for these pots. I found two but neither of them fit my needs. They didn't implement any of the TCON functionality which was the main reason I was interested in these pots. Here are links to those libraries if you are interested in trying them out:
   https://github.com/jmalloc/arduino-mcp4xxx and https://github.com/teabot/McpDigitalPot

Since there wasn't a preexisting library that would work for me I began figuring out how to talk to this chip. I started with the Arduino example in File > Examples > SPI > DigitalPotControl. The AD840x and AD520x series pots work right out of the box with this example but the MCP4xxx pots use different memory addresses so I started tweaking the example.

Understanding how to talk to the MCP4251

So lets start with the very basics of how to talk to these pots. Sending a command over SPI requires four steps:
1. Take the slave select pin LOW. This tells the chip to listen for commands.
2. Send the memory address for the item we want to change using SPI. This is the memory address for a wiper or terminal connections. This tells the chip what we want to change.
3. Send the new value for the item we specified in step 2. Wipers on the MCP4251 have 256 possible positions so this would be a decimal number between 0-255 or binary B00000000 - B11111111.
4. Take the slave select pin HIGH. This tells the chip to execute the changes.

The AD8406 covered in part 1 used decimal numbers 0-5 as memory addresses for each of the wipers which was very easy to understand. The MCP4251 doesn't use sequential values so I had to go digging in the data sheet to find the right values. Here is the memory map table from the data sheet:

Looking at the data sheet you can see the memory address and the data is made up of a total of 16 bits. The sheet says the data is 10 bits and the memory address is 6 bits but in practice you can send the data in two 8 bit chunks which allows you to use the 'B' binary formatter. The maximum possible value for a wiper is 255 which would be B11111111 in binary. So here is the list of memory addresses and tcon values I was able to determine:

wiper0writeAddr = B00000000;
wiper1writeAddr = B00010000;
  tconwriteAddr = B01000000;
  tcon_0off_1on = B11110000;
  tcon_0on_1off = B00001111;
 tcon_0off_1off = B00000000;
   tcon_0on_1on = B11111111;

The Wiring

Now that I had memory addresses figured out I wired up the digital pot on a breadboard with some LED's. I'm using LED's in this example because it's a good way to visualize the pots changing resistance values. I wired the shutdown pin to a 4.7k pull down resistor so the pot would go into shutdown mode if digital pin 7 wasn't HIGH. My example code also uses the software disconnects (TCON) to turn the LED's off and on.

The connections are:
* All A pins of MCP4251 connected to +5V
* All B pins of MCP4251 connected to ground
* An LED and a 220-ohm resistor in series connected from each W pin to ground
* VSS - to GND
* VDD - to +5v
* SHDN - to digital pin 7 and a 4.7k pull down resistor
* CS - to digital pin 10 (SS pin)
* SDI - to digital pin 11 (MOSI pin)
* SDO - to digital pin 12 (MISO pin)
* CLK - to digital pin 13 (SCK pin)

You can download the fritzing file here:
https://github.com/matt448/arduino/raw/master/MCP4251_tcon/MCP4251_tcon.fzz

and you can download the MCP4251 fritzing part I made here:
https://github.com/matt448/arduino/raw/master/MCP4251_tcon/MCP4251.fzpz

The code

Here is a Gist with the example code. The most recent version will be my the github repo here:
https://github.com/matt448/arduino/tree/master/MCP4251_tcon

Up next

Part 3 in my series of digital potentiometer posts will cover reading data from the MCP4251 to determine the wiper positions and the tcon status. Part 4 will cover using multiple SPI digital potentiometers. I will add a links here as I complete those posts.

Adding MOLLE / PALS webbing to a backpack

I really like my North Face Surge backpack but I have never found the vertical daisy chain loops on the back panel to be very useful. I guess you can clip on small items with a carabiner but I never do that. I do have a few items that use the MOLLE or PALS attachment system and I would like to attach those to the back panel of my pack. So I decided to try and modify my backpack.

Here is a how the pack looked before I modified it.


The loops down the center of the flap are what I want to change. These vertical loops are usually referred to as a daisy chain. MOLLE, or more specifically PALS, is method of attaching pouches and equipment to a bag. It is used by the military and law enforcement personnel to attach things like radios, ammo clips, knives, first aid kits, etc to bags and vests. There are quite a few handy generic pouches as well. The PALS system uses one inch webbing spaced in horizontal rows one inch apart and sewn at one and half inch intervals. Most people seem to use the term MOLLE and PALS interchangeably but really MOLLE is a line of military gear that uses the PALS attachment system. Equipment that is attached using PALS webbing uses straps that are woven in and out of the rows and secured with a snap or velcro. Some equipment uses plastic clips that hook into the rows.

Here is a diagram of how to sew PALS / MOLLE.

Before I modified my backpack I first tried sewing some PALS webbing onto scrap fabric.


It went pretty well on the scrap fabric. The ends of the webbing were a little difficult because had melted them a little too much. When cutting the webbing you need to use a flame to melt the ends to keep it from fraying but it only needs to be melted very lightly. If you melt it too much it will cause big lumps which are difficult to sew. I did a test fit of my Leatherman sheath and it fit perfectly so I moved on to modifying my backpack.

The first step was to run a zigzag stitch across the rubbery material to hold it in place and to reinforce the strap before I shortened it. Then I used a seam ripper to remove all the stitching below the zigzag stitch. After that I used some scissors to cut off the strap and rubbery material from the area I want to place rows of PALS webbing.



Next I laid out the rows of webbing. I started out with laying pieces of webbing on the bag and measuring but it was difficult to visualize where the loops would end up. I made a paper diagram which made it easier to see how many full loops I could get. Because the flap tapers up I was only able to get three loops but that would be perfect for attaching my Leatherman and a flash light. Next I used a water soluble marking pencil to lay out the webbing and sewing line locations.



I trimmed the ends of the webbing to the same taper as the flap and lightly melted the ends. Then I pinned the webbing in place.



Next up was the sewing. The top piece of webbing wasn't too bad but the lower piece took some acrobatics to get all the lines sewn. I ran a straight stitch first and then a zigzag stitch over top of it for strength.



Sewing is complete. The stitching is visible on the inside of the flap but it doesn't look too terrible and the flap is usually closed. Quick test fit of my Leatherman and then all that's left is to clean up the white pencil lines with a washcloth and some water.


And here is the finished product. It turned out exactly like wanted. :-)


[UPDATE 2014-07-31]

Just a small update. I sewed my own MOLLE flashlight holder out of some 2" webbing and added that to my pack. My buddy bought me a 'tactical' pen which fits nicely on the center loops.