This is incredibly awesome, and I'm looking forward to testing this out
over the radio tonight :-)
However - The program gives me an error saying it can't open the sound
card, on Windows 7 (64-bit). This happens no matter what sound card I pick.
I might (finally) install Linux on my PC and see if I can get it going
there.
Cheers,
Mark VK5QI
On Thu, Feb 16, 2012 at 2:38 AM, Peter Lawrence <[email protected]> wrote:
> 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
>
------------------------------------------------------------------------------
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
