The Austringer

Life has been a bit demanding lately, so it has been a while since I last worked on the Raspberry Pis. I had a notion that I might dragoon the Pis into serving as compute engines for a simulation I wrote in Python, and that got me motivated to get new Raspbian images and set up two Pis as headless units. It did not take long to disabuse me of the notion that the Pis represented a good alternative to workstation compute time: my simulation on the Pi ran at about 1/20th the speed it did on the workstation. So the simulation is running in background on the workstation, and I had two Pis hooked into the network, up and running.

So I spent a part of the weekend working on steps toward using a Pi as an acoustic monitoring platform. I bought two real-time clock (RTC) modules some time ago, so each of the Pis had one of those onboard. The critical piece of information I was missing in getting those running was that the process of establishing the Linux device corresponding to the I2C device had to be accomplished not merely using “sudo” in front of the command, but in a root-owned shell process because of redirection within the command. I found a web page that offered good advice, including putting the following lines into /etc/rc.local:

modprobe i2c-bcm2708

echo ds1307 0×68 > /sys/class/i2c-adapter/i2c-0/new_device

modprobe rtc-ds1307

hwclock -s

When we last visited this topic, I had a USB sound device that could be recognized by the RasPi and that I could take recordings from. There was just one problem: the Pi would not stably reboot with the USB sound device plugged in. Given that my use case is going to be using the system as an instrument that will only be attended maybe every two weeks or so, that problem was a sufficient discouragement to have me doing other things for a few months.

It turns out that time helps. With the most recent Raspbian image, the reboot problem has gone away. Now, everything is not completely rosy. It turns out that I needed to restrict the USB ports to USB 1.1 speed in order to get a clean recording from the mic input. That likely would interfere with using either a USB keyboard or mouse, but I was already aiming at headless operation.

This clears the way for actually getting the system put together and readied for deployment. I need to write some code to handle periodic acoustic samples (cron launching a Python script seems good to me). Having code to connect to a server to upload status updates and/or data would be good; several of the platforms have some sort of Internet service. There’s a chunk to do for hardware. I need to find out exactly what the power supply situation is. I do already have a pair of 4A 5V UBECs. I need to do some testing, though, to make sure that the UBEC does not add a significant amount of noise to acoustic recordings. Since the UBEC is a switched power regulation device, it is quite possible that power-line noise could get into recorded signals. Some sort of housing is needed. And I need to fabricate the hydrophone (a piezo disk soldered to a coax cable with some waterproof potting to cover it) and pair it with an amplifier circuit. Whatever power the amplifier will need I’ll have to figure out, too. Some testing would be good. It would be ideal to find someone with a boat who thinks this sort of thing is cool. I think I have several weekends worth of project to keep me busy.

I am looking forward to getting a Teensy++ 2.0 microcontroller board. Teensy is a low-cost, small microcontroller based on Atmel AVR technology that uses USB for the programming interface. USB can also be used by the device running the user’s programs in a variety of modes.

Teensy is something that I expect to solve a number of problems in deploying Raspberry Pi in embedded systems and instruments. The Raspberry Pi hardware exposes a number of GPIO pins, but that number is not large, and gets smaller as one uses special-purpose features like SPI and I2C, which are mapped to specific pins in the GPIO range. Raspberry Pi also has no built-in analog-to-digital capability. To protect the GPIO circuitry on the Raspberry Pi, one also has to do level-shifting to 3.3V. Attaching Teensy to a Raspberry Pi via USB does not risk the circuitry since nothing is going through the RasPi’s GPIO pins. I am intrigued by the USB HID mode, which looks like it may be amenable to a particularly flexible way of supporting two-way communication of commands and data between the two systems. Teensy also has several channels of analog-to-digital conversion built-in, as well as digital IO and PWM. With everything on and running at a full 16MHz, Teensy++ should draw less than 70 mA of 5V DC power. There is the potential for hooking up multiple Teensy systems to one RasPi via USB when using hubs.

I’ve also got multiple RasPis here, so I am in position to deploy a system and still be able to work on further development. The problem, as usual, is where to get the time.

I’ve moved on to the official Raspbian release. This OS image using the hardware floating-point capabilities on board the RasPi and is noticeably faster than the Debian “squeeze” image was. It allows me to reboot when I’m powering the RasPi from my USB hub, something I couldn’t do before.

I’ve also tested a total of five different sound devices with Raspbian and ALSA for recording a mono microphone input. I’ve gotten one recording by fluke on a “Virtual 7.1 Ch Sound” device, and consistently get the claim that there is no capture device associated with the Behringer UCA202. The only device that has worked consistently for recording is a Syba “USB Stereo Sound Adapter” CMedia CM119. I didn’t pay more than $9 for any of the non-Behringer devices.

The CMedia is recognized, the controls come up appropriately in alsamixer, and arecord works without complaint on it. My only problem in simply going with this adapter is that I cannot reliably reboot my RasPi with it plugged into the USB hub. If it is plugged in on boot, the network interface throws “kevent 4″ errors. If the network is not plugged in, but the CMedia device is, ALSA throws a lot of errors at boot. Given that I want to deploy my RasPi remotely for a couple of weeks at a time, this sort of behavior doesn’t give me confidence. Things have improved since the earliest firmware I was using, but there seems to be a ways to go.

Syba SD-CM-UAUD USB Stereo Audio Adapter, C-Media Chipset, RoHS ($8.08 from Amazon)

The currently non-recording adapters:

Virtual 5.1-surround USB 2.0 External Sound Card ($1.78 from Amazon)

7.1 Channel USB External Sound Card Audio Adapter ($2.38 from Amazon)

Behringer UCA202 ($29.99 from Amazon)

Intermittently working adapter (I can’t say exactly how I managed to get one recording done with this):

Syba USB2.0 7.1CH Sound Adapter Add Stereo Output Mono Input Led ($3.28 from Amazon)

I had the chance to work with my Raspberry Pi some more late last night and this morning. Quite a lot of stuff works, given that the board design is essentially at a state of “ready for the software developers to do their thing”. But some things are not quite there, or behave oddly.

My first boot-up that I talked about was on a bench without networking. That turns out to be significant. When I tried to run my RasPi with the full load of peripherals in the USB hub and also have the wired Ethernet on, I got a lot of “kevent 4 may have been dropped” error messages and no network connection. The canonical answer on the RasPi forum is that this is a power supply issue, where marginal power to the board means there isn’t enough to properly run the Ethernet circuitry. Some respondents have noted that their circumstances don’t fit into that neatly. I suspect that I may be joining them, but I have some more experimentation to do before saying so categorically. My get-it-working solution so far is to run the RasPi off a dedicated power supply and have all the peripherals on a powered hub. This isn’t ideal for something I hope to deploy remotely. I need to figure out really reliable, comes-up-on-power-on every time configurations.

I spent entirely too much time dealing with something that I should have caught early. The RasPi is a UK invention, and its default settings are convenient for people in the UK. I have a firewall here, and I set my RasPi to enable SSHD so I could login over the net. I logged in from an Ubuntu box and changed the “pi” user password to something approaching a strong password, you know, one with odd case, numbers, and symbols. That’s all to the good, but then I rebooted and ran into the network interface being offline. Fine, I thought, I’ll login directly. But I couldn’t, because no matter what I did, I could not generate one of the symbols in the new password from the directly-connected keyboard, not even with alt-codes. Stripping the RasPi down to just power and network allowed it to boot and establish the network interface, and I could login once again from a remote computer. I changed the password to avoid the bad symbol and worked on localization. The involves “dpkg-reconfigure” applied with three different targets, the keyboard, the locale, and the timezone.

I’ve been able to install a batch of additional software. I installed Cmake and libncurses5, then tried building Avida on the RasPi. The Avida build doesn’t get far. tcmalloc apparently is known to have build issues on ARMv6, plus multiple classes got an “out of virtual memory” error. That still holds with the boot switched to the 224MB main memory setting. But python-scipy and python-gps installed without issues. I even installed VLC to check if the final piece of a media center was anywhere close to done. While the VLC and its dependencies went on without complaint, plugging in a USB DVD drive and pointing VLC at it did not go much of anywhere. There was no continuous playback, and if I changed the media pointer, it would display a single frame. I think that the color rendition was off, but I had plugged in a movie that I hadn’t watched yet, so it is just possible that the cinematographer thought a strange palette would be a good thing.

I tried out my USB GPS dongle. I installed “gpsd-clients” and ran cgps, which reported … absolutely nothing. That was disappointing. I plugged the GPS into my Ubuntu box, and cgps happily displayed a fix and chatter from the dongle. I went back to the RasPi, stopped gpsd, then used gpsmon. That displayed a fix and messages from the dongle. So I’m not sure why gpsd on the RasPi is doing things differently than on the Ubuntu box.

For those pulling up “Geany” to do some Python scripting, you’ll need to change the preferences so that the terminal of choice is not “xterm”, but rather “lxterminal” (this is for Debian Squeeze).

That’s it for now. I’m expecting to have to repeat this process whenever a new version of the operating system is released, so a set of notes on what gets done seems in order.

Notes on RasPi

Adding nameservers:
sudo nano /etc/resolv.conf
nameserver 4.2.2.2
nameserver 4.1.1.1

Localization:
sudo dpkg-reconfigure keyboard-configuration
sudo dpkg-reconfigure locales
sudo dpkg-reconfigure tzdata

Additional python modules:
sudo apt-get install python-scipy
sudo apt-get install python-gps

WiFi dongle —————————————–
See http://elinux.org/RPi_Peripherals

Add to /etc/apt/sources.list:
deb http://ftp.us.debian.org/debian squeeze non-free

Then
sudo aptitude update
sudo aptitude install firmware-atheros

cd /lib/firmware
sudo wget http://wireless.kernel.org/download/htc_fw/1.3/htc_9271.fw
sudo wget http://wireless.kernel.org/download/htc_fw/1.3/htc_7010.fw