AENSbox V2
From CSL Wiki
Based on initial experience with the Acoustic ENSbox, we are collecting together a wishlist of changes to make to the software and the hardware, along with a plan of how to get there and in what stages.
Contents |
Software Wishlist
- Web interface to configure a particular node as the Master. In Master mode, the following is true:
- Enables the master to be the gsync broadcaster
- Turns off gsync bcast on any other node
- Allows the sample rate for all nodes to be configured dynamically
- Allows synchronized recordings to be made
- Reports on disk space usage
- Ability to control the sample rate at runtime
- Localization subsystem needs to temporarily reset it to 48K
- Web interface to control local sample rate
- Ability to retrieve recorded data back to a sink node over multiple hops
- Ability to record data locally and perhaps to view it or play it back from the web interface
- Ability to view localization from laptop
- Additions to web interface
- view localization
- view network connectivity
- control sample rate
- record data
- view data
- configure master mode, control SR, recording on all nodes
- mixer settings and real-time level meter
- speed of sound calculation (temp, humid, pressure)
- result should get used for localization calculations
Hardware Wishlist
- Array (aka sensor head)
- Power array from main battery
- Array geometry from corners of cube (Shadnaz's design)
- Improved audio amp
- Improved mic mounts.. no more huge pvc tubes
- Weatherproofing
- Better connector
- Respin pcb, integrate into single pcb, integrate power filtering and audio power amp
- ??Ability to adjust location of mics?
- Accelerometer to measure tilt
- Box
- Smaller, lighter
- Hot-swappable Li+ battery packs?
- Battery condition monitoring... "laptop style" smart batteries?
- Mass storage capability
- Indicator LEDs
- Weatherproof..
- all connectors (ethernet, serial, power, USB) in sealed area
- Speaker amp volume knob more accessible (accessible if case is open at least)
Crazy Ideas
- Add a tiny additional computer, connected by ethernet, to handle mass storage. (gumstix?)
- Use intel-based embedded platform? (pentium M?) .. provides mass storage, FPU .. power?
Near Term Goals
By Colorado Trip (mid July)
- Move antennas off the box (mount on sensor heads?)
- Improve sample rate that can be recorded for sustained periods (This is the hard one!)
By Mexico Trip (Oct)
- Weatherproof (at least some)
- Note: Date has been pushed back to October (probably)
Laptop ENSBox
We want to get an acoustic ENSbox functionality on commodity hardware for two reasons:
1. lower cost, more processing power from commodity intel hardware
2. more readily available
Design considerations
One of the biggest problems with the current system is the PCMCIA sound card. There is only one such device on the market and it is both expensive and causes a heavy processor load.
Professional multichannel audio cards are typically PCI or Firewire, with a few offerings in USB audio. PCI options are not preferred because they can't readily be made portable. Among portable systems, Firewire is by far the most common interface, with a few USB 1.1 multichannel cards and a very few (but perhaps growing) number of USB 2.0 systems. USB 1.1 is very popular for low cost sound add-ons, but it is barely fast enough to support 4 or more channels.
FireWire Support. Linux support for professional audio in general is reasonably good. However, there is currently no ALSA support for any Firewire-based system. However, the FreeBoB project appears to have some support for Firewire interfaces, including a number of good multichannel systems. This support is somewhat bleeding-edge and requires kernel patches and module patches in order to work. In addition, there doesn't currently appear to be any ALSA support, although this is not necessarily a problem as the direct FreeBoB API provides straightforward access. In fact, this lower-level interface may actually be easier for us to access than the at times overly-complex and over-general ALSA API.
USB Support. Linux and ALSA seems to have good support for most USB sound hardware that conforms to the USB sound standards. There are a few USB-based systems that claim support on the ALSA site:
- Lexicon Omega
- Tascam US-428
- Roland/Edirol UA-101 (usb2.0) is marked 'may work, untested'.
- M-Audio Quattro USB (apparently works, but is discontinued)
In addition, the MOTU 828-mk2 is a USB 2.0 system, but does not appear to have a linux driver. The Roland device also has a FireWire version with the same model number. It is unclear whether any other Roland system based on USB 2.0 is known to be supported by Linux.
Tradeoffs. There is clearly almost 10x as many pro-audio products based on FireWire as on USB. Whether this trend will continue with USB 2.0 is unclear; increasing numbers of products today feature both interfaces. As far as laptops are concerned, USB 2.0 and FireWire are interchangeable. However it is unclear what impact this has on porting this system to an embedded platform. Some embedded platforms support host USB or USB-on-the-go. The ENSBox currently includes a USB-OTG 2.0 chipset, although there is currently no Linux driver supporting this chip. For an embedded system there also the possibility of designing a custom audio board, which would unquestionably also cost less, apart from NRE costs. We can also remain with our present PCMCIA-based solution, so long as that product remains on the market.
Driver Issues. Until we try some of these systems we won't know the extent of Linux driver issues. FireWire appears to require some bleeding edge modifications, although most information on the FreeBob page was as of kernel 2.6.12. However, this introduces many dependencies re. porting changes forward, etc. It is unclear whether USB support exists for some of these possible systems. ALSA support is sometimes flaky; for example Digigram support was broken in 2.6.11 and may still be broken. However, patched drivers may simply be a fact of life, and may be required anyway for synchronization support.
Synchronization
Arranging for synchronization of the sampling process with the CPU clock is as-yet undetermined. We have solved this with our PCMCIA solution, by arranging for a firmware patch and making driver modifications. With faster and more deterministic hardware such as FireWire and USB 2.0, synchronization may be easier to attain. In addition, FireWire-based pro-audio may have improved synchronziation support built-in. There are several possible avenues for handling synchronization.
Interrupt Timestamping. A method that we have used successfully in the past is based on timestamping interrupt arrival times and using linear regression to estimate a rate and offset relationship, with an additional unknown constant pipeline latency. If the hardware is fast and deterministic, this technique should work well. This typically requires hacking the driver to maintain and report arrival timestamps.
Channel Sacrifice. If an additional channel can be used for a sync signal, it may be possible to inject a signal into that channel that is used to read back the timestamp signal. One clever trick is to feed the serial output of a GPS into a spare channel. GPIO pulses can also be used to achieve this result. These solutions have the advantage that they mark the timeseries uniquely without requiring any further system coordination. However, they waste a channel. However, with 10 channel FireWire sampling units, this may be a reasonable solution. Note, we at one point attempted to mux the input channel with a fixed voltage, triggered by a GPIO. We also tried blanking the signal by using a GPIO to shut down the mic preamps at a particular time. Neither solution worked well; the resulting spikes and blanks were very difficult to distinguish from normal signals.
Built-in timecode support?. Some pro-audio systems may support some kind of useful timing signals or special timing channels.
Embedded Acoustic ENSBox V2
There are several possible approaches to the V2 version of the Embedded AENSBox. The point of the "embedded" version is that it will have better energy properties and be packaged for long-term deployments.
Several Possible Strategies
Extend Aevena ENSBox. The Aevena ENSBox is a packaged, self-contained unit based on the Slauson with a daughtercard supporting an MSP430. One strategy is to modify this device to add a custom or off-the-shelf sampling interface.
Slauson2. The Slauson2 is a smaller form-factor device based on the PXA270, and supporting mini-pci wireless. The new version of the AENSBox might start with the Slauson2 and add a daughtercard that supports a 4 channel codec, as well as other components needed for packaging (similar to the Aevena ENSBox).
Some Parts
- Schematic for "battery-or" circuit. Useful for allowing hot-swappable battery packs. [1]
- Battery vendor [3]
- Weatherproof connectors (Bulgin Buccaneer series) [4]
- Circuit diagram for a simple LED battery meter (lots of other potentially useful circtus at this site too) [5]
![[5]](http://ourworld.compuserve.com/homepages/Bill_Bowden/page11.htm#meter.gif){kind=link}