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
