Recently we announced the SPLear™, a module that integrates a PDM microphone along with a small ARM CPU to act as a sensor that measures Sound Pressure Level or SPL. Today I want to show how easy it is to use the SPLear as a sensor for a Raspberry Pi. This is part of our series of articles on the general subject of audio signal processing from air to information.

See the announcement for a more complete description of the board. The key components are the bottom port microphone and the NXP LPC812 ARM CPU. The basic firmware implements an analog output driven by a PWM, an LED controlled by PWM to flicker when the room is louder than about 30 dB, along with a logic level UART, and access to most pins of the mic and the CPU.

Much of the firmware has been discussed and published in past posts on this blog, and the source code is available from a public repository. The firmware discussed here and running the demo seen in the video is checked in as [3b4f54236e].

Raspberry Pi

The Raspberry Pi (or RPi for short) is a very inexpensive single board computer that can run Linux, and supports USB, ethernet, and HDMI for both video and audio output. It also has a GPIO expansion connector which provides access to individual pins configurable as single-bit input and output, as well as I2C, SPI, and a UART.

The RPi I’m using for this demonstration is configured to boot without a display, keyboard or mouse (a so-called “headless” configuration), and is booting the Raspbian distribution.

My RPi is named treepi, and since I have mDNS configured for my Windows PC, I can reach it via the name treepi.local. For this demo, I’ve simplified life by using a wired network connection, but WiFi will work as well.

RPi UART

The RPi has a single UART that is readily accessible from the GPIO header and known to Linux as /dev/ttyAMA0. The Broadcom SOC that implements most of the RPi has a second UART, but it is not clear whether or not it is possible to use it in the RPi with commonly available Linux configurations.

The available UART is configured out of the box as the system console port. This has several side effects. First, the boot loader will chatter on the port as it finds and loads the Linux kernel. Second, the kernel will chatter as it boots up. And third, once booted it will prompt for a username and password, allowing a user to log in on the console.

We cannot trivially prevent the boot loader from chattering, but fortunately it doesn’t have very much to say. We can, however, prevent the kernel from chattering and the system from supporting a login prompt. As described by Adafruit here, the easiest way to get that effect from a Raspbian distribution is to use raspi-config and turn off the console serial port. In the version of raspi-config I have, this control is in the Advanced Configuration menu, under Serial, which differs slightly from Adafruit’s description.

After doing that and rebooting the RPi, the UART is untouched by the kernel and system. From observation, the boot loader chatter consists primarily of a single line of text emitted at 115200 baud:

Uncompressing Linux... done, booting the kernel.

Logging in over ssh to the freshly rebooted system we find…

Last login: Wed Apr 29 23:05:21 2015 from 192.168.1.26
pi@treepi ~ $ uname -a
Linux treepi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux
pi@treepi ~ $ stty -F /dev/ttyAMA0
speed 9600 baud; line = 0;
-brkint -imaxbel
pi@treepi ~ $ 

The SPLear is configured for 115200 baud, so we want to change that. I suspect it would be possible to adjust the kernel command line to get this effect by default, but it is easy enough to do directly from the stty command. There are likely other features of the serial port configuration that ought to be adjusted, but getting the baud rate right will allow us to use simple commands to verify that the SPLear is operating.

pi@treepi ~ $ stty -F /dev/ttyAMA0 ospeed 115200 ispeed 115200
pi@treepi ~ $ stty -F /dev/ttyAMA0
speed 115200 baud; line = 0;
-brkint -imaxbel
pi@treepi ~ $ 

Connecting the SPLear

The SPLear has been designed to be easily connected to a logic level serial port such as the UART provided by the RPi. Both the SPLear and the RPi use 3.3V logic levels, so we simply need to wire the port straight over.

The SPLear will directly plug in to a solderless breadboard, but the RPi requires an adapter (such as the Pi Cobbler or Pi T-Cobbler). Alternatively, with a few socketed jumper wires you can wire the RPi directly to the SPLear. Either way, connect them as follows:

RPi GPIO header  SPLear J1
---------------  -----------
 2 (5V)          J1.2 (VCC)
 6 (GND)         J1.1 (GND)
 8 (UART0_TxD)   J1.6 (RXD)
10 (UART0_RxD)   J1.7 (TXD)

With the SPLear wired to the RPi GPIO header, we can observe the default output on the UART which consists of raw codes for peak and instantaneous SPL. The version of the firmware used here also includes two forms of mean sample value as a leftover of testing DC offset removal, these values can simply be ignored.

pi@treepi ~ $ cat /dev/ttyAMA0
27 24 0 0
26 24 0 0
51 26 -2 0
27 25 0 0
^C
pi@treepi ~ $

In a nutshell, this output indicates that a program running in the RPi (in this case cat) can receive the SPL data as provided by the SPLear. We know this data has some connection to reality because I deliberately made a noise after the first two lines printed, which is evident in the jump from a peak of 26 to a peak of 51, which is 25 counts or about 19 dB SPL louder than the recent ambient level.

What Now?

The next step is to actually use that SPL level to do something, which will certainly be the subject of future posts. Watch this space!

---

Let us know what you think!

---

(Written with StackEdit.)