This is a brief log of my work with the Beagleboard single-board microprocessor system (Beagleboard XM, Revision C), aiming to develop a general platform mainly for Amateur Radio applications, such as remote control of radio equipment. The information here may assume considerable prior knowledge of Linux. Use Google or other resources to deal with unfamiliar terms.
The Beagleboard is an open-source hardware project described at beagleboard.org. A series of boards was developed around an ARM Cortex A8 processor (TI OMAP3 family). The Beagleboard XM (BBXM) shown above sports the DM3730 1 GHz processor with 800 MHz DSP, 512 MB RAM, 4 GB micro SD "disk", 4 USB ports, 10/100 Ethernet, HDMI video, audio in and out. Oh, and an old-fashioned serial port. It is about 3" square and draws 2.5 W on a 5 V power supply.
(The bare Beagleboard XM is currently available at Digi-Key for about $150 - 10/2011.)
Some of my software is available at the Software Projects area.
See Beagleboard Background for general information.
2/4/2012 - Multiplatform OK We finally have a single afrecv.cpp that will compile on Linux with Portaudio and on Windows with XAudio2. Speex decompression is available on both platforms. Remind me not to use C++ for further projects! A W1HQ remote help page is taking shape.
1/5/2013 - Windows audio Because we want to support the remote system on a Windows XP system at W1HQ, I have been working with the alien (to me) MS Visual Studio C++ system. Because PortAudio is not well supported (if it works at all) in the Windows environment, I cast around for an alternative audio method for the Windows implementation. I discovered DirectX XAudio2 API. Though aimed at gaming applications, it seems to be rather similar to PortAudio, at least for our application. As usual, the combination of UDP network functions (Winsock2 in Windows parlance) and real-time audio has its challenges.
The new software is beginning to work, but it needs to be integrated with the Python-based user control system.
We should end up with the UDP transmit program afxmit programmed in C running under Ubuntu Linux on the Beagleboard ARM processor at the remote site. This runs alongside rigctld, a version of the Hamlib rig control subsystem. At the local site, we will have the Python user interface program remote.py running together with the C++ afrecv under Windows XP (or Win 7). It's getting to be a zoo of software and hardware, but each piece has a clear rationale.
9/14/2012 - Testing at W1HQ The audio software seems to have stabilized. Using UDP transport solves a number of problems. We are now focusing more on the Python / wxWidgets control front-end. We've made a few actual contacts with the remote receiver in Branford CT, about 30 miles away. The tests highlighted some "usability" issues -- how to manage the T/R switching, for example.
6/16/2012 - The Saga Continues BB development continues. We are building a little remote control box for W1HQ, the ARRL staff club station, so that W1HQ can operate while W1AW is sending bulletins and code practice. The BB applications are mainly a low-latency network audio transmission link (PortAudio and Speex) and Hamlib's rigtctld network interface. There are other ways to do remote control of course, but the BeagleBoard and Ubuntu are the most fun!
12/13/2011 - Hot Chips Cooled We may never know what was wrong, but after loading a new version of Ubuntu (Oneiric) using the "method 1 preconfigured" image from the Elinux Ubuntu page, my boards run normally. So my problem was something to do my old Ubuntu configuration (but not the kernel). This episode set me back several days, but we now have 2 Beagleboards, so that's good.
12/12/2011 - The Hot Chip Problem We had a useful discussion of the problem on the Beagleboard Google group. The thought was that we might be having a known hardware problem. I tried out a second Beagleboard, which shows the same problem. Furthermore, if we use the demo SD card that is delivered with the board (Angstrom distro), the hot chip runs cool, as it should! So now it appears that there is something wrong with the Ubuntu Natty system that causes high power drain. It was suggested that I should upgrade to the latest stable kernel from Robert Nelson, version 3.1.5x6. But that made no improvement.
I wonder if other Ubuntu BB users have the same problem, but have not noticed the hot chip, or if there is something different about my Ubuntu configuration.
12/8/2011 - live Internet demo, overheating With the BB at the home QTH connected to a Ten-Tec Orion transceiver, we demonstrated remote operation and receiver audio at ARRL HQ in Newington, 30 miles away. We had to use SSH tunneling to overcome the ARRL and home (U-Verse) firewalls, but it did work fairly well. The extra network latency and reduced bandwidth pointed out some software issues that will need attention. SSH tunneling might be a good choice to provide security in an operational system. You would get nowhere without being a logged in user. No ports (other than port 22) would need to be exposed.
The "PMU" chip (TPS69590) appears to be overheating (>60 C by fingertip measurement). Consulting with the very active Beagleboard discussion group produced a number of helpful responses. Best guess: there is a board defect (chip soldering?) that leads to excess current draw - a known issue. We will return the board for repair, after a new board is delivered.
Posted info in blog.aa6e.net here.
12/5/2011 - grig / rigctld / hamlib For actual control of a remote radio, we are using Grig and rigctld (part of the Hamlib project.) Rigctld is a daemon that enables an Internet-based client to control an amateur receiver or transceiver. Grig provides a simplified control panel for the remote radio.
12/5/2011 - afxmit / afrecv These programs implement a low-latency voice-grade client-server system. They are written in C and and completely open source. They rely on the PortAudio API for audio input and the Speex Codec for audio compression. They were developed under Ubuntu Linux, but should be portable to many different operating systems. Source is available on request, and will eventually be provided on this site.
We are using the 8 kHz "narrowband" Speex mode, which is very adequate for amateur speech and CW applications. (We still need to evaluate its performance with digimodes like PSK31.) Our software will accommodate a "null" codec (linear transmission) or any other desired codec.
|Sample rate||8 kHz|
|Sample size||16 bits|
|Min. latency||80 msec.|
|Data Rate (null codec)||18 kB/s|
|BB CPU (null codec)||2.6%|
|Data Rate (Speex Default Settings)||2.9 kB/s|
|BB CPU (Speex default)||50%|
Minimum latency (using Speex) is 80 msec., when using the default buffering -- 4 buffers of 20 msec. Buffering higher results in better network efficiency (lower TCP overhead), but at the cost of more latency.
The Speex codec has two major parameters: "quality" (default 8) and "complexity" (default 3). A lower quality setting reduces the required network bandwidth at the cost of less natural audio. Higher complexity may improve fidelity for some audio signals (PSK31?), but requires more CPU time for encoding.
12/5/2011 - Starting the blog. This project needs a blog, to share interesting results and to serve as a sort of lab notebook for the project. I will welcome reader comments and will possibly post them in this space.