All, I've written proof-of-concept PC software to demonstrate receiving Codec2-encoded speech over an audio/radio link using a soundcard.
It uses a 2500 bps OFDM implementation to convey raw Codec2 data in about 2.2kHz of audio. In the spirit of David's post, there is no FEC and the symbol period is the same as the Codec2 frame size. The classic 2500bps Codec2 code is used. It is a multi-platform tool (Windows and Linux) and source code and binaries are provided: http://code.google.com/p/codec2demo/ The suggested usage is to use one of the provided pre-encoded modem .wav files (see download section of web page) at the transmitter and use the tool at the receiver. Using the tool, the user picks one soundcard to listen for the modem signal and one soundcard to playback the speech. (These can be the same soundcard.) As with any soundcard software, some manual tweaking of the audio levels (both at the transmitter and at the receiver) is needed. I've provided some instructions in the wiki section on volume controls in Ubuntu and Windows. When the Linux version detects a modem signal, it turns green. On the Windows version, it displays the word "RECEIVING". I've been testing with a simple acoustical coupling of microphone to speaker. As I increase the distance between microphone and speaker, the voice quality becomes corrupted and eventually cuts out. It would be nice if someone could test it with a real radio link. I don't claim to know the entire history of Codec2 testing, but you might literally be the very first person in the world to use a Codec2 radio link! :) Note that because there is no FEC, there will be bit errors; the Codec2 decoder can misinterpret these errors as loud digital artifacts. So, please exercise some caution; an open loudspeaker to listen to the decoded speech seems preferable to using a headset/handset. On Mon, Feb 6, 2012 at 6:18 PM, David Rowe <[email protected]> wrote: > Hello Peter, > > Nice work, and thanks for the links to those resources. > > The 1400 bit/s mode is buggy and still under development, so the bit > stream (and even bit rate) might change. > > I've used Golay and Hamming codes in the past for Codec FEC. You won't > have any patent problems. I might be able to dig up some code - let me > know. To work out which bits to protect, try subjecting each bit in > turn it to some random BER and see which ones are the most sensitive. > Likely candidates for the 2500 bit/s codec are the MSB of pitch, > voicing, energy, and MSB of low order LSPs. > > On this topic, I have some thoughts for modems and Codec 2: > > 1/ I like the idea of making the symbol rate the same as the frame rate, > as it means no frame sync is required. So we might have 56 BPSK > carriers with 40ms symbol rate. > > 2/ What we really want to maximise is speech quality at a given SNR. > It's not about bit errors, but the perceptual effect of those bit > errors. Speech is not like data - we don't want to aim for zero bit > errors. Many Codecs can tolerate a 1% random bit error rate, data has > to be perfect. This means SNR can be quite low without FEC, and we will > still get our message through. > > 3/ A low bit rate gives us a narrower signal, which Mel has indicted > fights interference (QRM). This might be more important than SNR or bit > error performance on crowded Ham bands, where our signal sounds like > noise and SSB users on adjacent frequencies may be inclined to > accidentally splatter us. > > 4/ Halving the bit rate will give a 3dB increase in SNR, like doubling > your tx power. Small changes in bit rate won't affect the signal much, > e.g. 1600 bit/s compared to 1400 bit/s is only 10log(1600/1400) = 0.6dB. > This also means we can add small amounts of FEC without much penalty. > > 5/ The 1% BER regime is the "knee" in the BER versus SNR curve for many > modems. If the SNR drops much the modem falls over. If the power > increases a few dB the raw BER gets low quickly, and FEC is not reqd at > all. > > 6/ The HF DV channel might be characterised by fades where we either get > a great signal or lose complete packets. Assuming we cant interleave > much due to delay, then BER performance is not an issue, FEC is not > helpful, we just need to do our best with lost packets. Or, maybe as HF > DV is push-to-talk, we can tolerate 500ms of delay and can interleave > using FEC to ride over short fades. > > 7/ Jean-Marc recently asked me about the usefulness of variable bit > rate. After some thought I think that might be useful. For example > imagine if we could send unvoiced and silence frames at 700 bit/s. We > could do this by halving the number of carriers for that frame, if power > is constant we would be putting twice the energy into each carrier. So > during the pauses between words and consonants we would have a 3dB > better SNR for our data than voiced speech (vowels). Curiously this > would mean the listener would hear _less_ "channel" noise in the silence > between words - the opposite to analog modes like SSB. These sorts of > tricks are possible if we consider the speech coding and modulation > together. > > Guess once we get this thing on the air we will get some clarity around > the best way to handle HF DV. Right now I am working on integrating the > LSP work Jean-Marc showed me a few weeks ago into a 1400-ish bit/s mode. > Rather than make it perfect, I would like to get it to the point where > we can test OTA and start tuning - hopefully get an on-air demo up for > Dayton in May. > > My end-goal is to make HF DV work better than SSB for a given SNR. Not > sure if that's possible yet, but digital has overtaken analog in most > other areas of radio so it's worth a shot. > > Cheers, > > David > > On Mon, 2012-02-06 at 16:00 -0500, Peter Lawrence wrote: >> In my limited spare time, I've been working on adapting an OFDM >> implementation to convey the Codec2 1400bps bit stream. >> >> Functionally, it would operate like WinDRM, EasyPal, etc. (e.g. use a >> soundcard connection to a radio's existing audio in/out), but could be >> open-sourced and multi-platform. >> >> I took this packet modem implementation: >> >> http://www.arrl.org/q15x25 >> >> which is encapsulated into this open source library: >> >> http://www.baycom.org/~tom/ham/soundmodem/ >> >> and stripped out the FEC and data link layer (since these were suited >> to a packet modem implementation, but not a real-time audio link). >> >> I've also been adapting the modem parameters (number of carriers, >> symbol rate, etc.) to try to better suit Codec2, and have done testing >> over a lossy audio channel under both Windows and Linux. >> >> Codec2 in the 1400bps mode operates on audio in chunks of 40ms. >> However, the modem implementation uses powers-of-2 (a reasonable thing >> to do with FFTs), which results in a symbol period of 12ms. >> >> The least common multiple of these two quantities is a not too >> unreasonable 120ms ( 3 x 40ms = 10 x 12ms ). >> >> In my proposed implementation, there are 12 carriers, each with QPSK >> modulation. This results in a 2000 bps data stream ( (1sec / 12 ms) x >> 12 carriers x 2 bits/symbol = 2000 bps ). >> >> (FYI: the first carrier is at ~500 Hz, and the inter-carrier spacing >> is ~125 Hz. This makes the highest carrier at ~1875 Hz. This should >> fit comfortably into the audio bandwidth of most rigs and >> regulations.) >> >> Rather than fixating on bit rates, a more applicable viewpoint would >> be to view it as 168 bits of Codec2 data (3 x 56 bits/frame) that must >> map into 240 bits (24 bits x 10 symbol periods). >> >> This mapping must also provide framing alignment so that a receiver >> can align itself to the repeating blocks of 10 symbol periods. >> >> FEC is an art form, and rather than try to devise a (potentially >> faulty) scheme on my own, I'd like to solicit input from the >> knowledgeable readers on the mailing list. >> >> I'm looking for a specific suggestion on an implementation to map >> these 168 bits into ten x 24 bits, rather than an open-ended "why >> don't you try X?". Anyone can do a literature search on names of FEC >> techniques; it takes real skill to devise a technique suited to a >> channel (and quite frankly I don't have that experience yet). >> >> It also seems critically important to devise a technique not >> encumbered by patent protection. >> >> Thanks for your time. >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
