Most Gumstix devices I’ve encounter (Basix and Verdex Pro) come with a built-in Web server known as Boa. If you’ve ever watch the Gumstix boot from a console, you’ll see an error about gethostbyname. Once the Gumstix is up and running, you’ll find no Web server active. And any attempt to issue an /etc/init.d/boa start only results in the same gethostbyname error.

Here’s a simple fix.

Go to the boa.conf file located in /etc/boa/ directory and find the line with ServerName. Simply change what’s there to a name of your choosing, like this example:

# ServerName: the name of this server that should be sent back to
# clients if different than that returned by gethostname + gethostbyname

ServerName www.mygumstix.net

Once the change is made, start the server with: /etc/init.d/boa start

If all goes well, navigate with your browser to the IP address of your Gumstix and you should see the default Gumstix web page!

I needed to implement a reliable network connection into my Verdex Pro once it was attached to the GPSstix since the USB networking is hosed. Here was my solution to this wireless networking issue.

Step 1. Enable only necessary options
As you’ll see from my config from /etc/default/bluetooth, I disable most Bluetooth options. The key parts are at the end dealing with PAND (Personal Area Network daemon).

# Bluetooth configuraton file

# Attach to the onboard bluetooth adapter  (allowed values are "true" and "false")
HCIATTACH_ENABLE=true

# Start of hcid (allowed values are "true" and "false")
HCID_ENABLE=false

# Config file for hcid
HCID_CONFIG="/etc/bluetooth/hcid.conf"

# Start sdpd (allowed values are "true" and "false")
SDPD_ENABLE=false

# Start hidd (allowed values are "true" and "false")
HIDD_ENABLE=false

# Arguments to hidd
#HIDD_OPTIONS=""

# Run hid2hci (allowed values are "true" and "false")
HID2HCI_ENABLE=false

# Bind rfcomm devices (allowed values are "true" and "false")
RFCOMM_ENABLE=false

# Config file for rfcomm
RFCOMM_CONFIG="/etc/bluetooth/rfcomm.conf"

# Start dund (allowed values are "true" and "false")
DUND_ENABLE=false

# Arguments to dund
DUND_OPTIONS="--listen --persist"

# Start pand (allowed values are "true" and "false")
PAND_ENABLE=true

# Arguments to pand
PAND_OPTIONS="--role GN --listen"

Step 2 Add the bnep0 interface
Assign your Gumstix a static IP address so you can connect. Here’s a snippet of my /etc/network/interfaces file.

iface bnep0 inet static
      address 10.10.10.1
      netmask 255.255.255.252
      network 10.10.10.0
      broadcast 10.10.10.3

The netmask above defines a two-host network. Your outside connection (laptop, desktop, mobile device) must use 10.10.10.2 as its IP address as well as the netmask above. Sure, I could have installed a small DHCP server to issue IPs automatically, but since the same device will connect to the Gumstix, I didn’t see the need.

Anyone wishing to use sox for audio file conversions on the Gumstix may be interested in this information.

While you could simply cross-compile sox using the OE environment for Gumstix, you’ll quickly learn that a number of additional dependencies are required. Here they are in the order they need to be installed (all in the OE environment):

• libogg0 >=1.1
• libvorbis >= 1.0.1
• libmad0 >= 0.15.16

I used sox-13.0.0 for my app. A few flags have changed between the various versions, but here is what I used to convert a directory full of .raw audio files to .wav files:

for i in /media/card/*.raw
do
    sox -2 -s -r 8000 -c2 $i ${i%.*}.wav
done

The flags indicate the following:

-2 sample size in bytes
-s signed-integer
-r 8000 is the sample rate
-c2 is the number of channels

Good luck! Hope it helps.

The Problem

I’ve come to notice a quirk in the USB networking capabilities between my basix Gumstix mobo and my Ubuntu laptop. And I’m not the only one who has noticed this quirk. It has also appeared to manifest iteself on the connex boards as well. Maybe we’re not doing something right. But we simply want to have USB networking up and running at boot while a USB cable remains connected between the Gumstix and the laptop. Sure, we could simply pull the USB cable out and reinsert then all is fine. But shoud we really have to do this?

The Solution

The solution is to run /etc/init.d/networking force-reload once the system is finally up and running. Here’s how I implemented it for automation:

Step 1) Modify /etc/network/interfaces to contain the following (use your own IP addresses):

auto usb0
iface usb0 inet static
     address x.x.x.x
     netmask x.x.x.x
     network x.x.x.x
     pre-up /sbin/modprobe g_ether
     post-down /sbin/rmmod g_ether

Step 2) Add the following to /etc/rc.local:

/etc/init.d/networking force-reload

Note: Make sure rc.local is executable!

Step 3) Add a symlink in /etc/rc5.d to point to /etc/rc.local:

ln -s /etc/rc.local /etc/rc5.d/S95ReloadUSB

That should solve it even if you power your Gumstix over USB. If anyone can explain why we don’t need this workaround, I would be very interested in hearing what you have to say.

The following are instructions on how I was able to get audio working on the Gumstix basix mobo with a 400MHz PXA255 and Bluetooth. It runs the most recent version of Gumstix OpenEmbedded.

A few assumptions about your skills:

1. You can log into the Gumstix (either SSH or console)
2. You can gain access to the Internet from the Gumstix (either via Bluetooth or bridging usb0 to eth0)
3. You have a sound source (mic) and speakers or headphones

Log into your Gumstix. We need a tool that will allow us to record and play audio. Assuming you have that Internet connection, then from the Gumstix command line:

ipkg install alsa-utils-aplay

Next we need to configure the ALSA mixer for sound. From the command line:

alsamixer

An ncurses GUI pops up. Configure as follows:

1. Press the TAB key until [ALL] is highlighted at the top left in the row labeled “View:”
2. Use the up arrow to increase the Master Volume to a desired level (I set it at 76)
3. Press the “M” key (mute) to unmute the Master Volume
4. Use the right arrow to highlight “Capture”
5. Use the up arrow to set the capture volume (I use 73)
6. Press ESC to exit the ALSA mixer

Let’s save these mixer settings so we don’t have to configure the ALSA mixer every time the Gumstix boots:

alsactl store

Now issue the following commands to list your CAPTURE and PLAYBACK devices:

arecord -l
aplay -l

You should get some output along the lines of:

**** List of CAPTURE Hardware Devices ****
card 0: Gumstix [Gumstix], device 0: UCB1400 AC97 HiFi-AC97-0 []
Subdevice: 1/1
Subdevice #0: subdevice #0

And almost the same output with aplay, but CAPTURE is replaced with PLAYBACK.

Now let’s record something. You will have many choices and control over the quality of your recording. However, for our test we will record with some standard settings. Run the following on the command line:

arecord -d 5 -f cd test.wav

This says, “record for a duration of five seconds in CD quality (44100 HZ & stereo) then save it to test.wav”. NOTE: Failure to save this simple test to an external storage medium will fill up your root file system!

To hear what you recorded, simply type:

aplay test.wav

Congratulations! I hope you were successful in getting your audio recorded and played back.

The sample file above weighs in (for me) at 861.4k. If size is a concern, you can drop the stereo to mono and reduce the bit rate. Here’s one last example to illustrate the space savings at the expense of perfect stereo sound:

arecord -c 1 -d 5 -f S16_LE test.wav

This says, “record only one channel for five seconds in a signed 16-bit little endian format then save it to test.wav”. The result will be an audio file recorded in mono at 8000 HZ. Now my file only weights in at 78.2k vs. 861.4k. Wow! However, you will surely notice a difference in quality.

Now go do good things!

On Wednesday, May 9th I was invited to speak at the Columbia-Area Linux User’s Group on my trials and tribulations of building and running an embedded Asterisk server at home. You can click on the Embedded Asterisk Talk to grab a copy of the presentation. As I told the group, this is an on-going project that I tinker with when I have spare time — which seems to be dwindling the older I get.

Thanks to Christopher for getting John and me on the group’s calendar to speak, and thanks to CALUG for all the great questions, participation and overall great turn out! I had a blast and look forward to running a VoIP workshop if the group decides to hold one.