Archive for the ‘Hardware’ Category

Accessing status and diagnostic information for a Motorola Surfboard cable modem

Wednesday, May 28th, 2014

My ISP (to protect its identity, let’s call it Flomflast) drops my internet connection frequently. During the latest occurrence, I noticed from my router’s status page that the WAN address had been assigned to I was surprised to see this since I believed there was no connection to the ISP via the cable line. How could the ISP DHCP server assigned an ip address to the router? And why the private network address?

I guessed that if the DHCP server was assigning addresses in the 192.168.100.x range then itself or another server (the gateway?) might be located at I typed the address in the address bar of my favorite web browser and was greeted with a web page being served by my Motorola Surfboard cable modem.

Screenshot - 05282014 - 11:14:33 PM

On the configuration page I found information that the cable modem has a built-in DHCP server that takes over when the internet connection is dropped. As configured, it begins assigning addresses at Since my router is the only device on that side of the network with the cable modem, it was assigned the first ip address in the range.

The status page for the cable modem is especially handy. From the comfort of my chair I can see that the internet connection is indeed lost without the usual process of several rounds of pinging followed by a walk to another room to check the modem lights. Even with the internet connected, the modem is still accessible at

Managing an iPod Shuffle (2nd gen.) in Linux

Monday, March 31st, 2014

I have an old second generation iPod Shuffle (model A1204). When I dug it out of storage it wouldn’t play any songs. I plugged it in to my mobile desktop running Debian and verified the file system could still be read. I transferred all of the existing songs off of the shuffle using Thunar and its handy renaming feature. In order to manage the tracks (i.e. add and remove songs) I needed a piece of Linux software with that capability. Unfortunately, the popular options, Banshee, Rhythmbox, and Amarok would all require that I update a significant amount of my system (mostly gnome and everything that depends on it). The best lite application I could find was gtkPod.

I first tried adding and removing tracks with gtkPod but kept getting errors. The process for adding songs was not straightforward and I couldn’t figure out how to fix those errors. Even when I got songs transferred to the device, it refused to play. It would only flash alternating green and orange indicating it couldn’t find any music. The database file wasn’t being written properly. So, gtkPod alone would not suffice (I may have an unsupported model, I couldn’t find it in the list of devices).

The solution relies on a python script “iPod shuffle database builder” which can be found on sourceforge. I used version 1.0-rc1. My process for adding tunes to the shuffle is now this (starting from scratch):

  1. Use file manager (Thunar) to permanently delete all files from the shuffle.
  2. Open gtkPod and use it to recreate the iPod Shuffle directories only.
  3. Use file manager to copy songs from desktop to Shuffle. Songs are stored in device root or under any arbitrary file hierarchy, just not in the normal /iPod_control/Music directory that iTunes uses.
  4. The python script mentioned above, named “” is copied to the root folder of the device.
  5. The python script is executed from the root folder of the device.

That’s it. Once the script rebuilds the Shuffle’s database it can be ejected and used as normal. Easy. Apple take notice.

An improved key-reader library for the SainSmart LCD Keypad Shield (for Arduino)

Monday, August 5th, 2013

The LCD Keypad shield from SainSmart is a bargain. For ~$8 (and free shipping, at the time of this post) you get 32 character (16×2) blue/white LCD panel with a built-in keypad with 5 momentary switches. This provides a quick solution for interaction with Arduino projects. To control the LCD part of the shield, one can use the Arduino supplied LiquidCrystal library (included with Arduino IDE). In the Key_Grab demo (v. 0.2) on the SainSmart website is included a library, DFR_Key, for reading which keys are pressed on the keypad. However, the library is not written well. This post describes both the problem and the solution.

First, a little background is necessary about how the keypad signals a key is pressed. Only a single analog-in pin is used and the shield uses a voltage divider to send a voltage that corresponds to a given key. To detect a key, one has only to read the voltage at the analog pin and determine if it falls within a certain range. For example, a voltage of 0 to 0.7 V signals the UP key was pressed. The DFR_Key library contains a getKey() function that does this and returns an integer from 0 to 5 that represents the key pressed (0 is supposed to mean no key, but as written means the last key was just released).

You’d expect that when you call getKey() it would read the voltage at the pin, figure out what key that represented, and send back the integer representing the particular key. So really, it should just be translating the voltage to an integer from 0 to 5 (none, select, left, up, down, right, respectively). But, there is some “extra functionality” the library provides that is the problem. Here’s how the logic of the getKey() function works:

Has a minimum time passed since the last time I checked for a key press?

If not, do nothing – return no value at all!

If so, read the voltage at the pin. Is this voltage different than the voltage I read the last time I checked for a keypress?

If not, return -1.

If they’re different, it means a key was pressed right? Determine which key was pressed and return an integer from 0 to 5 representing that key.

The first bit of “extra functionality” is what the library refers to as the refreshRate. The idea is that you don’t want to check for a key press too quickly, else the function might return that the key is being held down when in fact it’s just a normal press. This makes some sense if you simply dump a getKey() call in your Arduino sketch’s loop() function. You would then check the returned value to see if it actually did a key press. If it decided enough time hadn’t pass it would return….oh wait! It doesn’t return anything in this case. That’s not appropriate behavior. When the program says getKey(), it should expect a key code sent back. Therefore, it should be the job of the programmer to only call getKey() at appropriate intervals (say every 100 ms).

That brings up the next problem. There are five keys on the keypad. Add in an extra code for “no key being pressed” and you get the six integers from 0 to 5. Perfectly reasonable. So what’s this -1 return value for? The library defines the alias SAMPLE_WAIT for this value (as opposed to NO_KEY, and UP_KEY, etc.). I’m not sure what the meaning was supposed to be, but this value is returned when the getKey() function determines that the key being pressed is the same as the key that was detected upon the last call to getKey(). At first, it would seem to be letting you know that the last key pressed is being held down. But 1: you don’t know what the last key pressed was, unless you’re tracking it yourself. And 2: that may not even be true – if you make two getKey() calls 60 s apart, whose to say whether the key was being held the whole time; all we know is that the same key was pressed as last time. So it’s telling us the same key was pressed as before and according to point 1, I’m keeping track of what that key was. If it had just returned the actual key code, I could have figured this out for myself by comparing it to my stored value of the last key pressed.

Now to the final problem. If you follow the logic stated above carefully, you’ll see that to determine if the same key was pressed, the getKey() function compares the voltage read at the analog pin to the voltage it read last time it detected a key was pressed. But the voltage does not directly correspond to a given key – a key press can be signaled by a range of voltages. For example, assume on the first call to getKey() it reads a value of 200 mV. That corresponds to the UP_KEY and it returns 3. On the next call to getKey() assume it reads a value of 205 mV. The user is pressing the up key again (or holding it down) but the voltage is slightly different. The getKey() function compares the new value, 205 mV, to the old value, 200 mV, and thinks a new key is being pressed. So instead of returning -1 for “same key is being pressed” it returns 3 for “up key is being pressed”.

Actually, this should be the behavior! Upon every call, the getKey() function should just return an integer representing the key that is being pressed at the time the call is made. But because the authors meant for it to return -1 when there was no change in the key being pressed, and meant for it to be called on every loop() iteration, the Key_Grab demo flickers the screen like crazy. Actually, it works fine when the UNO board is removed from all sources of noise and interference. But put it next to a piece of electronics (e.g. your computer) and the noise causes the voltage supplied to the analog pin to fluctuate, new key presses to be registered, and the demo to update the screen on every loop() iteration. It’s the constant updating that causes the flicker which makes it appear as though you got ripped off $10.

How can we fix this mess? Actually, the fixes are simple and actually reduce the code in the library.

  1. Remove all of the logic relating to the “refreshRate”. The programmer will be forced to decide how often to call getKey().
  2. Remove the comparison of the current key press to the previous key press. The programmer can decide if the user is pressing the same key by recording the last pressed key.

Here is the derived library which I’ve called LCD_Keypad_Reader.cpp (feel free to rename). The original SainSmart DFR_Key library didn’t come with a license so I’m not putting one on this derived work either. I don’t really care what you do with this code, but it’s possible that SainSmart could impose some kind of limitations.

#include "Arduino.h" 
#include "LCD_Keypad_Reader.h" 

static int DEFAULT_KEY_PIN = 0;  
static int DEFAULT_THRESHOLD = 5; 

// The Sainsmart keypad uses a voltage divider to deliver a voltage  
// between 0 and 5 V that corresponds to the key being pressed in  
// order to use only a single input pin. The values below are from 0 to  
// 1023 because the Arduino uses a 10 bit resolution. 
static int UPKEY_ARV = 144; // 0.720 V, that's read "analogue read value" 
static int DOWNKEY_ARV = 329; // 1.645 V 
static int LEFTKEY_ARV = 505; // 2.525 V 
static int RIGHTKEY_ARV = 0; // 0 V 
static int SELKEY_ARV = 742; // 3.710 V 
static int NOKEY_ARV = 1023; // 5.115 V 

  _keyPin = DEFAULT_KEY_PIN; 
  _threshold = DEFAULT_THRESHOLD; 
  _curInput = NO_KEY; 
  _curKey = NO_KEY; 

int LCD_Keypad_Reader::getKey() 
  _curInput =  analogRead(_keyPin); 
  _curKey = categorizeKey(_curInput); 
  return _curKey; 

int LCD_Keypad_Reader::categorizeKey(int analogKeyValue){ 
  int categorizedKeyValue = 0; 

  if (analogKeyValue > UPKEY_ARV - _threshold && analogKeyValue < UPKEY_ARV + _threshold ){ 
      categorizedKeyValue = UP_KEY; 
  else if (analogKeyValue > DOWNKEY_ARV - _threshold && analogKeyValue < DOWNKEY_ARV + _threshold ){ 
      categorizedKeyValue = DOWN_KEY; 
  else if (analogKeyValue > RIGHTKEY_ARV - _threshold && analogKeyValue < RIGHTKEY_ARV + _threshold ){ 
      categorizedKeyValue = RIGHT_KEY; 
  else if (analogKeyValue > LEFTKEY_ARV - _threshold && analogKeyValue < LEFTKEY_ARV + _threshold ){  
      categorizedKeyValue = LEFT_KEY; 
  else if (analogKeyValue > SELKEY_ARV - _threshold && analogKeyValue < SELKEY_ARV + _threshold ){ 
      categorizedKeyValue = SELECT_KEY; 
    categorizedKeyValue = NO_KEY; 

  return categorizedKeyValue; 

And here is the header file, LCD_Keypad_Reader.h

#ifndef LCD_Keypad_Reader_h 
#define LCD_Keypad_Reader_h 

#include "Arduino.h" 

#define SAMPLE_WAIT -1 
#define NO_KEY 0 
#define UP_KEY 3 
#define DOWN_KEY 4 
#define LEFT_KEY 2 
#define RIGHT_KEY 5 
#define SELECT_KEY 1 

class LCD_Keypad_Reader 
    int getKey(); 
    int categorizeKey(int); 
    int _keyPin; 
    int _threshold; 
    int _curInput; 
    int _curKey; 


Automatically mount USB drives in Linux without a GUI

Monday, June 3rd, 2013

The helloNULL web server is a headless system, i.e. it does not run a windowing/desktop environment. One feature that is therefore lacking is the automatic mounting of USB flash drives upon plugging them in. For example, in the Debian/XFCE environment of my mobile desktop, a flash drive will be mounted to /media/label upon plugging in to the port, where ‘label’ is the drive label. This post will show you how to duplicate that functionality on a terminal-only system using udev rules and a simple script.

When a USB drive is plugged in udev handles initiating the device and by using udev rules, it is possible to specify a script to be run whenever this event occurs. In Debian, udev rules are written in text files under /etc/udev/rules.d/. Each file in that directory is parsed by order of filename. Rules that run scripts should begin with a  number in the 80′s. Our script can be called /etc/udev/rules.d/81-custom.rules and should contain the following code:

# Custom udev rules. Note that udev rules are run in order based
# on the filename. Rules in filenames that start with numbers
# are run before this one.
# This rule detects USB drives that are added to the system so
# that they can be mounted automagically by the script.
# It is based off of the replies to a question on
ENV{ID_FS_USAGE}=="filesystem", SUBSYSTEMS=="usb", ACTION=="add", RUN+="/root/ mount %k"
ENV{ID_FS_USAGE}=="filesystem", SUBSYSTEMS=="usb", ACTION=="remove", RUN+="/root/ cleanup %k"

The first rule will trigger whenever a usb device (SUBSYSTEMS) is added (ACTION) and the device contains a filesystem (ENV{ID_FS_USAGE}). The second rule is similar but triggers upon a ‘remove’ event. In either case, udev will add the script (RUN) specified to the list of scripts to be run for that event. Our script has two functions, mount and cleanup, depending on the event. In the former case, our script will need to know the kernel name of the device (e.g. sda1) to use for the mount command. The script looks like this:

# This script is called by a udev rule whenever a usb drive is
# plugged into the system or removed from the system.
# Usage:
# where MODE is either mount or cleanup
# and DEVICE is the device basename, i.e. /dev/DEVICE

if [ "$1" = "mount" ]; then
    # The ID_FS_LABEL enviroment variable is only available
    # When this script is caleld by udev
    mkdir -p "/media/$ID_FS_LABEL"
    $(mount | grep -q "/media/$ID_FS_LABEL") || mount /dev/$2 "/media/$ID_FS_LABEL"
elif [ "$1" = "cleanup" ]; then
    rmdir "/media/$ID_FS_LABEL"
    echo "ERROR: Mode $1 should be 'mount' or 'cleanup'."

This is pretty straight-forward. In the case of mounting a usb drive, the device name is created from the passed argument while the mount point is generated from the disk label taken from an environment variable. The same environment variable is used to remove the mount point when the disk is removed. The proper way to remove the drive is with the eject command, like this:

That’s it! This is perhaps not the most robust solution but should work for most cases. Put the 81-custom.rules file in your /etc/udev/rules.d/ directory and the script in your /root directory (or wherever you want). Don’t forget to give the script execute permissions.

Edit 06/03/2013: I changed my mount line to give read-write permissions to the plugdev group. The plugdev group is for users who are allowed to mount and unmount removable devices. On my system, all people-users (as opposed to system accounts) are members of the plugdev group. This means that any real person logged in can access the mounted USB drive. The new mount line looks like this:

$(mount | grep -q "/medial/$ID_FS_LABEL") || mount -o gid=plugdev,dmask=007,fmask=117 /dev/$2 "/media/$ID_FS_LABEL"

Edit 12/16/2013: I discovered that my mount command from the 06/03/2013 change only works right for file systems of type vfat and would fail if the usb drive connected was formatted as ext3, for example. The problem is the options specified (gid, etc.) which aren’t valid for ext3 and ext4 filesystems which preserve permissions. The solution I decided on was to specify two different udev rules, one for each type of file system. Different mount options will be set in an environment variable depending on the file system detected. Then in my script, this environment variable is put directly into the mount call.

New udev lines:

# the mount options are different depending on the file system type
ENV{ID_FS_USAGE}=="filesystem", ENV{ID_FS_TYPE}=="vfat", SUBSYSTEMS=="usb", ACTION=="add", ENV{MOUNT_OPTIONS}="-o gid=plugdev,dmask=007,fmask=117", RUN+="/root/ mount %k"
ENV{ID_FS_USAGE}=="filesystem", ENV{ID_FS_TYPE}=="ext?", SUBSYSTEMS=="usb", ACTION=="add", ENV{MOUNT_OPTIONS}="", RUN+="/root/ mount %k"

New lines:

$(mount | grep -q "/media/$ID_FS_LABEL") || mount $MOUNT_OPTIONS /dev/$2 "/media/$ID_FS_LABEL"

Rebuilding a Raid 1 array: Using mdadm to add the new drive back to the array

Friday, May 31st, 2013

Because of frequent disk failures that occur in my Mobile Desktop for reasons I’ve yet to conclusively identify, I decided early on to run two drives in a Raid 1 array. In this way, a single drive failure was easily overcome. A week or so ago one of my current drives started producing read errors and it was removed from the array by mdadm (linux’s multi-disk administrator). Today I’m adding the failed drive back to the array (currently only 1 active drive) and decided to post the commands I use so I can find them easily in the future. For more information on creating, administering, and repairing Raid arrays in linux, I suggest an article on by Falco Timme.

As of right now, my Raid 1 array (md0) has one connected drive (really partition), /dev/sda1. The drive (partition) that I want to add back to the array is /dev/sdb1. Both drives are from Western Digital but sda is a 250 GB disk while sdb is a 320 GB disk. Because sdb was previously in the array, there’s nothing special that I’ll need to do to use it, but I will be limited to using only 250 GB of the space on that drive. Here is the output from some mdadm commands to clarify the picture:

ecellingsworth@MD1-LMDE ~ $ cat /proc/mdstat
 Personalities : [raid1]
 md0 : active raid1 sda1[3]
 244194841 blocks super 1.2 [2/1] [_U]
 ecellingsworth@MD1-LMDE ~ $ sudo mdadm --detail /dev/md0
 [sudo] password for ecellingsworth:
 Version : 1.2
 Creation Time : Thu Sep 15 10:36:29 2011
 Raid Level : raid1
 Array Size : 244194841 (232.88 GiB 250.06 GB)
 Used Dev Size : 244194841 (232.88 GiB 250.06 GB)
 Raid Devices : 2
 Total Devices : 1
 Persistence : Superblock is persistent
Update Time : Fri May 31 11:41:27 2013
 State : active, degraded
 Active Devices : 1
 Working Devices : 1
 Failed Devices : 0
 Spare Devices : 0
Name : MD1-Ubuntu:0
 UUID : 7d0d271d:04fdd2c1:de65ca3f:4c375489
 Events : 1279820
Number   Major   Minor   RaidDevice State
 0       0        0        0      removed
 3       8        1        1      active sync   /dev/sda1

First I copy the partition table from the good drive to the failed drive. If you use any of these commands yourself, be sure you use the right drive identifier. If you switch sda and sdb, you will destroy the good drive.

ecellingsworth@MD1-LMDE ~ $ sudo sfdisk -d /dev/sda | sudo sfdisk --force /dev/sdb
 Checking that no-one is using this disk right now ...
Disk /dev/sdb: 38913 cylinders, 255 heads, 63 sectors/track
 Old situation:
 Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start     End   #cyls    #blocks   Id  System
 /dev/sdb1   *      0+  30400   30401- 244196001   fd  Linux raid autodetect
 /dev/sdb2          0       -       0          0    0  Empty
 /dev/sdb3          0       -       0          0    0  Empty
 /dev/sdb4          0       -       0          0    0  Empty
 New situation:
 Units = sectors of 512 bytes, counting from 0
Device Boot    Start       End   #sectors  Id  System
 /dev/sdb1   *        63 488392064  488392002  fd  Linux raid autodetect
 /dev/sdb2             0         -          0   0  Empty
 /dev/sdb3             0         -          0   0  Empty
 /dev/sdb4             0         -          0   0  Empty
 Successfully wrote the new partition table
Re-reading the partition table ...
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
 to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
 (See fdisk(8).)

Now I remove any traces of the previous Raid information from the failed drive (partition).

ecellingsworth@MD1-LMDE ~ $ sudo mdadm --zero-superblock /dev/sdb1

All that’s left to do is put /dev/sdb1 back into the array.

ecellingsworth@MD1-LMDE ~ $ sudo mdadm -a /dev/md0 /dev/sdb1
 mdadm: added /dev/sdb1

Mdadm will then resync the two drives by copying everything from /dev/sda1 to /dev/sdb1. This process takes three to four hours for my 250 GB drives and will be longer for larger drives. You can monitor the rebuilding process using the following ‘cat /proc/mdstat’. I like to run this command with ‘watch’ every few seconds to see the rebuilding progress in real time.

ecellingsworth@MD1-LMDE ~ $ watch -n 5 'cat /proc/mdstat'
Every 5.0s: cat /proc/mdstat                            Fri May 31 11:51:17 2013
Personalities : [raid1]
 md0 : active raid1 sdb1[2] sda1[3]
 244194841 blocks super 1.2 [2/1] [_U]
 [>....................]  recovery =  2.6% (6465024/244194841) finish=124.7
 min speed=31746K/sec
unused devices: <none>

Don’t trust the estimated time. The rebuilding process will run in the background, but if you are using the PC at the time, the rebuilding has to pause every time you need access to the file system. And, for some reason, rebuilding tends to slow way down near the end.

Edit 12/17/14:

I’ve used the above process to add back to the array a failing drive several times now. However, in my case, since I’m adding back the same drive that was previously in the array, it’s not necessary to copy the the partition table from the good drive nor is it necessary to zero the superblock on the failed drive. Instead, I use one command “mdadm -a” to add the drive back to the array and it rebuilds fine. This has the advantage that it’s much less risky. There’s no chance of destroying the good drive by wiping it’s partition table or superblock. And, I doubt anything would happen if you told mdadm to add a drive that’s already in the array, though I’m not going to test this theory myself.