CQ Codec2, Calling CQ Codec2

Over the holidays, I developed a bash script that allows to computers to communicate with codec2-encoded audio using UDP packets.

The script, called c2qso.sh, doesn't do any of the firewall-punching magic that Skype etc. perform. But it should be useful in testing lightweight linux contexts, especially those without a GUI, since it comprises pipelines built from pretty standard Unix tools.

Who'd like to arrange a QSO?


c2qso.sh works the following way. It pipes the audio-in through gstreamer to change the sample rate and format, pipes this through c2enc, and sends the resulting data out to the other machine as UDP packets, using a default port of 20002. Input is even simpler: a ncat process listens to the 20002 UDP port, and, if it gets a connection, opens a shell command that pipes the data through c2dec and pipes the resulting audio out through 'aplay'.

(I wasted a great amount of time trying to put the audio out through gstreamer, even writing gstreamer plugins for codec2. I kept getting choppy output, which was solved by using aplay. Unfortunately, although the rest of the toolkit is available for OS X, the OS X audio player doesn't seem to provide for streaming data in at 8000.)

There is no metadata or error correction in the streams.

Some helpful bits to get you started:
1. You need 'ncat', which is a souped-up version of 'nc'. ncat comes with nmap, so on a Fedora system do 'yum install nmap' and on a Debian system do 'apt-get install nma

2. Download and build codec2. This requires the 'svn' package installed. Then run 'svn co https://freetel.svn.sourceforge.net/svnroot/freetel/codec2 codec2' From a bare Fedora you'll need to do 'yum install gcc'.
Do 'cd codec2' then './configure' and 'sudo make install' (or su, then 'build all').

3. Configure your firewall to allow incoming UDP packets on port 20002. On Fedora, go to 'Administration/Firewall' and use the 'Other Ports' tab to make this exception. 

In any case, the philosophy here is to use extremely simple networking tools to get the job done, and as a result, it should be easy to port this approach (if not the code) to platforms like the iPhone and android.

Comments

  1. mvandewetteringJanuary 13, 2011 at 12:03 PM

    Very good Bruce, I'll have to give this a try. I'm currently swamped, but maybe next week we can try a QSO. I was working on my own client that simply used udp sockets and portaudio for portability: perhaps making that compatible with your setup would be fun.

    ReplyDelete
  2. Bruce Robertson VE9QRJanuary 13, 2011 at 1:18 PM

    Mark --

    That'd be great. I think Simon will be set up soon, too: pretty soon we'll have many opportunities for testing and playing with this.

    Your approach seems identical and should be interchangeable, since I'm just using the live data stream across UDP. My goal is to make this code work with various data radios, and especially UDP over 9600 baud packet (TH-D7, etc.) My feeling is that RTP would be overkill. (Moreover, this just works :-)

    I'd like to try making an iOS client for this approach, too. If it took its data in over wifi, we could use something like the Wifly to send serial data from a TH-D7 to the iPhone or iPod.

    ReplyDelete

Post a Comment

Popular posts from this blog

Building and Operating a Transmitter from the Roaring 20s

Image
Radio was booming in the 1920s: transmitters had started using the pure tone of 'continuous wave' signals, replacing signals sent with sparks, and increasingly selective and sensitive receiver circuits offered greater range seemingly by the month. Amateurs, not yet able to tame their simple transmitters with crystal-controlled oscillators, constructed them on simple wooden boards with heavy wiring and large inductor coils in order to keep heating from causing their signals to drift. These homebrew transmitters were ongoing experiments in electronics and engineering. The position of a coil might increase output power but cause the signal to sound like a buzzsaw. If you could find a higher voltage power supply, that too would raise its power, but the increased currents in the rig would add more drift: if the other guy can't find your signal wandering up and down the band, what use is that extra 3 watts? The 1929 QSO Party Every year the Antique Wireless Association holds a tw
Read more

Defining a 49:1 EFHW Transformer's Losses

Image
 End-fed halfwave antennas are so convenient, especially in rapidly deployed setups, and they're easy to build . But how much energy is lost in the 49:1 transformer that makes it possible? Because I operate mainly QRP, and I'm using a rather large core for 5w, I'm not concerned with losses that appear once the transformer's core reaches the Curie temperature. So I can use a nanoVNA, performing a S21 logmag trace on two cores back-to-back, to see how much power my transformer is eating up on the way to the antenna. I used the Fair-Rite 2643625002 core, inspired by excellent results MM0OPX reports in a generously shared spreadsheet of results. Could I get around 0.5 dB loss from 80m all the way to 10m if I used that core in 21:3 turns ratio?  My experience with more donut-shaped ones suggested that such broad-banded performance was a tough order: a 14:2 turns ratio works well on one end of the HF band; 21:3 works well on the other. In the end, Colin's accompanying vi
Read more