Views
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.)
The BBXM is delivered with a 4 GB microSD card holding a boot loader and an evaluation copy of Ångström Linux. (Also, see wikipedia:Ångström_distribution.)
Project Background
See Beagleboard Background for general information.
The AA6E BeagleBlog
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% |
| Protocol | TCP |
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.
Future developments:
- The software could be revised to use UDP rather than TCP. UDP would demand less network bandwidth and might operate better with more network latency, with somewhat less reliability.
- A two-way version would support transceive operation. Running simultaneous transmission ("full duplex") might be possible if bandwidth is adequate. Otherwise, rapid send/receive stream switching might be acceptable.
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.