Good news folks: I have had my remote controlled IC-706 on the air and it works! So far I have only tested the receiver and on the LAN, but I still consider it to be a significant milestone because it was the first time I had the controls and the audio work together with a good antenna connected to the radio.
I have recorded this video so you can get a feeling about how it works.
I wrote in my previous post that this first version of the audio server and client is implemented using gstreamer. Since then I have also found an easy way to install gstreamer 1.4.3 on a Beaglebone running Debian stable, which as of writing is the official image. I have updated my wiki page to include the info about upgrading the debian system from stable to testing and installing gstreamer 1.4.
Once we have gstreamer 1.4 on the Beaglebone, my client and server scripts will run out of the box.
If you look at the audio server script you will notice that the encoder is set to:
- Narrow band
- Bit rate: 24 kbps
- Frame length 60 ms
- Complexity 3.
As you can hear on the video the performance is very good. The CPU load with these settings is around 20-25 % on a Beaglebone White, which is slower than a Beaglebone Black.
We should be able to go further down in bit rate, actually I estimate that even 8 kbps will give sufficiently good audio quality for SSB and CW. However, it will take some effort to tune the parameters for such low bit rates and the result will probably also depend on the background noise level..
The frame length lets us estimate the minimum latency in audio. 60 ms for the encoder + 60 ms for the decoder gives at least 120 ms. The frame length can be set all the way down to 5 ms; I just chose the largest frame length to see how it feels with long latency.
The complexity has impact on the audio quality and the CPU load. Higher complexity (max 9) give better audio and consumes more CPU.
As you can see there are many parameters to play with. For now I m sticking with the settings I listed above because I think it is more important to implement some caching of the event-based control traffic. Right now, data is transmitted every time a knob gets a new value, so turning e.g. the tuning dial very fast generates a lots of traffic. It will be more efficient to collect these events locally and only send updates say 5 times per second.
I will also start mounting the boards into enclosures and install the client in my car 🙂