Current project developments are discussed on the Beagleboard Project page.
A personal annotated bibliography of Beagleboard Resources.
- There is lots of Beagleboard documentation out there, including an excellent hardware writeup. There is lots of software information, but it is scattered and fragmentary. Some relates to the earlier (and less expensive) Beagleboard and some to the Beagleboard XM. There is no single how-to manual that tells you how to get going with software development. It depends on your choice of OS, obviously, and your preferred toolchain. I am still looking.
- Alas, there are Beagleboard sites that try to be helpful by reprinting information from other sites. That can compound the confusion for a newbie (like me!). I will try not to do that here. These pages, I repeat, are a record of my own travels through the Beagle world. I hope they're useful and provide some clues, but they may not apply to your configuration and needs.
- If a mouse and keyboard are attached, and you are drawing power from the USB port (the micro USB connector), you may not have enough current available. I found I could not get reliable booting when using one of my laptop's USB ports for power. Supplying +5V power with a good quality switching "wall wart" (5V 2A) cured the problem. Some 'net documents recommend connecting the mouse and keyboard to a powered USB hub and then to the Beagleboard. This may be more important for a non-XM board.
- The lack of a VGA-style video connector is somewhat problematic. You need to find a monitor capable of accepting HDMI (or DVI-D) and/or S-Video inputs. You probably can't use the cheapest monitors because of this.
- The system will apparently boot with any or all of the following connections: Serial I/O (console), Ethernet, keyboard, mouse, and monitor. It boots up an Ångström gnome/gdm (X windows) environment reminiscent of the Ubuntu desktop. There are few applications, but the web browser Midori is present. There is also Python.
- People were impressed with the nice big screen-saver pictures coming out of that little board!
- The evaluation system distributed on the SD card ("xMTEST beta 4-25") allows some persistent configuration, but provides a single password-less user account: root. You can add your preferred accounts and passwords, of course.
Choosing an OS environment
Should we continue with a "full" installation of Ångström Linux or switch to the (experimental?) version of Ubuntu? Real Ubuntu is more familiar, but the Ubuntu-on-Beagleboard may or may not be well enough along for my taste. Can we work with a "canned" rootfs/kernel distribution, or will we need to customize? Hopefully, the former.
Our application target for now would use the audio in and out ports, along with serial I/O and Ethernet -- all pretty standard. No custom peripherals or drivers.
I tried to load the "Canonical/Ubuntu Image" link, but with my XM board, the mouse and keyboard were not activated. The install/configure process started but hung waiting for mouse/kb input.
Then, I successfully loaded the "Demo Image" from rcn-ee.net eLinux link. This is a basic Ubuntu without, e.g., a GUI system. We will try working with this image to see what further "interesting" features develop. The usual repositories work, and I am able to install a Gnome desktop (with XFCE as well) and Firefox. There are few if any extensions available for the browser. No Flash. Installation of lots of packages is pretty slow, probably due to relatively slow I/O to SD card. It is not CPU or network limited. But eventually there is success.
The Ubuntu system uses the "eth0" device, while other parts of the Beagle ecosystem use "usb0", i.e. Ethernet over USB. This leads to some confusion, e.g., with the MAC address. The BBXM assigns a random MAC address at boot time for both usb0 and eth0. This is rather awkward in a DHCP environment that wants to store information (IP address, etc.) for devices based on their MAC addresses. Procedures are documented (on the Google list) for setting this as a boot parameter, but I could only make it work for the usb0 device. Life is short, so I have given up for now and configured the /etc/network/interfaces for eth0, specifying the desired MAC address. This screws up Ubuntu's Network Manager, but I don't care at this point!
Audio Subsystem (Ubuntu)
The audio hardware interface is through the TI TPS35950 chip.
The audio device is recognized in Ubuntu as "omap3beagle analog stereo duplex" in the sound properties. However there was no sound output with the speaker test function. Installed alsa packages. Alsamixer shows all the weird controls provided. (Carkit? Really?) I fiddled with all of them and finally found some settings that allowed output to go to the jack. Unfortunately, this is typical of how complex sound hardware and drivers are supported or not supported by the desktop environment! (More info to come.)
Installed mplayer and I'm now able to listen to sounds on web pages (via Firefox) and to play most sound files. BUT the Ubuntu "speaker test" function still makes no sound. Is there a package missing?
Part of our project involves audio transmission over the Internet, for example, from a remotely located radio to a local computer sound system. Some design goals:
- Low bandwidth utilization
- Insensitivity to network latency
- Single channel voice, e.g. < 4 kHz, 16 bit
- Minimal processing delay (to allow reasonably responsive remote tuning of a rig)
- Option for up to 48 kb/s stereo (I/Q) data
- Not dependent on X desktop
There are network options built in to common Linux systems, for example PulseAudio in Ubuntu. PulseAudio and other "high fidelity" oriented network audio options (such as jackd) are aimed at local area networks with low latency and high data rates. There has been some work using netjack1 in high-latency, restricted bandwidth situations.
I have a very simple Python network transmit/receive built with PyAudio. It works, but PyAudio does not provide true realtime capability. It uses blocking I/O which leads to audio gaps. This is a limitation of PyAudio, and seems to reflect the non-realtime character of Python, alas. This is surprisingly tolerable for communications voice work, but sounds miserable when you listen to carrier tones or CW. Working with 8 kHz 16 bit sampling, uncompressed, with TCP/IP protocols, I see 17-18 kB/s data flow on my local network in one direction, with about 10% reverse flow because of TCP/IP ACKs. (A UDP solution would be somewhat better.) I did not measure the end-to-end delay, but it sounds like it's in the low 10s of msec. when listening to both the direct receiver output and the computer output.
Are there any end-to-end solutions that we could use? I am evaluating VOIP options, such as Ekiga. Ekiga provides good quality (for voice) and will even do two-way audio and video, if you like. A simple setup required about 11 kB/s bandwidth forward with the PCMU codec and video suppressed. Delay was considerably greater than I saw with the direct transmission test above, maybe double.
For simple voice work, the VOIP solution looks promising at the moment, but it will probably not support the wideband I/Q application. Alas, Ekiga is a Gnome application and would need to be adapted for a command line interface in our remote Beagleboard environment.
I looked at OPAL, which is a VOIP environment. Their simpleopal demo program is surprisingly close to what we need. It's a command line program, where you can place an IAX2 "call" to a listening client at a known IP address, and they will (optionally) automatically start a call session. You can choose from many codecs at many bit rates. One issue is that normal telephony is bidirectional. We only want oneway transmission. It may be possible to suppress the reverse flow (by muting that audio channel?), but this is not a normal option. Of course, it's all open source, and we can adapt the simpleopal program if we have to. (But OPAL, like all VOIP systems (?) is really complicated...) Our needs are very much a subset of what VOIP offers.
Tentative conclusions: Python is not real-time enough, "streaming" (as in Icecast et al) has too much latency, and VOIP software (as in OPAL) is encumbered with too many telephony and video telephony complications. So we are back to homegrown code - a "transmitter" program afxmit I wrote in C, along with an afrecv program in Python. With 8 kHz sampling, mono, and 16 bit samples, we need about 17 kB/s of network download using either UDP or TCP. TCP uses about 2 kB/s upstream for acknowledgements. Adding an appropriate codec may reduce the load by 50% or so.
For now we will write our own C code using the PortAudio API and the Speex modem.