Hello Bruce, The current VQ design has three tables or 9 bits each. The indexes of the first table are the most important. Yes, if any one bit is wrong, then the VQ entry will be wildly different from intended. Jean-Marc has suggested the VQ tables be "sorted" to improve robustness to single bit errors.
I started playing with interleavers a few months back: https://freetel.svn.sourceforge.net/svnroot/freetel/codec2-dev/src/fdmdv_interleave.c One other issue with interleavers is sync, for example if your interleave over 200ms you need to know which of the 5 40ms frames is the start. It can also mean a big chunk of data lost of frame sync is lost. The interleaver above is just single frame, as I didn't have a simple solution for multi-frame interleaver sync on the HF FDMDV modem. Thanks, David On Tue, 2012-10-23 at 09:03 -0700, Bruce wrote: > Hi Kristoff, > > I am back where I have a keyboard now :-) > > I would like to hear from David regarding whether any bits of VQ are > "more sensitive" than others, or if it is the case that if we get an > index off by one bit we go arbitrarily far from the intended signal. > That was my suspicion but maybe I'm wrong. > > I propose to code a system that makes it easy to insert an arbitrary > interleave and/or FEC function. The system itself is rather more fancy > than you might have planned, but it will make it dead simple to > experiment with FEC and interleave. > > So, I propose to provide: > A coroutine interface that makes it as simple as possible to insert a > chain of arbitrary functions that transform the bitstream. > For each transformation, a function is provided for transmit and a > second function for receive, and an initialization and tear-down > function are provided for transmit and for receive separately. So, that > is 6 functions per transformation. > A pre-defined C struct is used to pass in all 6 functions, and their > name, as one argument. > Each initialization function takes its input frame size and input data > rate as an argument at initialization time. > Each transformation function accepts a number of bits which is its > "local frame size". This can be as small as 1 bit. From time to time the > function emits some number of bits, but it does not have to emit bits > every time it is called. > Each initialization function will allocate all memory resources that > will be used by the transformation function, except for the calling stack. > Each initialization function multiplies the data rate by Y, and that is > passed to the next initialization function in the chain. Functions may > assemble frames into some larger packet, or disassemble packets into frames. > Given the chain of functions, the exact output data rate for a > particular input data rate can be determined, and remains constant after > initialization time. This can be used to choose a modem rate for an > arbitrary codec rate and transformation chaiin. > Sloppy concatenation of too many frame-size-transforming functions will > result in unacceptable delay. > The tear-down functions deallocate all memory resources that were > allocated by the initialization functions. > For efficiency in small-memory environments, transformation functions > are expected to refrain from allocating stack data. > For shared-memory efficiency, nothing in the system should define any > BSS data. Pre-defined data expected to be const so that it is placed in > text space. > > Thanks > > Bruce > > On 10/23/2012 12:08 AM, Kristoff Bonne wrote: > > Hi all, > > > > > > > > One of the elements needed for implementation of the the 2400 bps modem > > is something called "interleaving". > > > > As this element is just "bit-processing" which does not really need > > knowledge of FEC, DSP, voice-encoding or the other "low-level" stuff; > > this might be an interesting project to develop by itself. > > > > If somebody is interested in this, do let me know; either via the list > > of offlist. If you always wanted to get your name in the official > > documentation as cool as an open source voice codec; this is your > > chance. :-) > > > > > > What is this about: > > * Interleaving is a simple but genious trick used to beat burst-errors. > > Burst-errors is a senario where interference of a radio-signal takes > > that long it modfies not one bit, but multiple bits after other. This is > > an issue for two reasons: > > - some FEC systems operate on a relative small group of bits or a number > > of bits located after eachother. > > - certain bits in a voice stream are more important then others. The > > audiable effect of having certain bits modified is much larger then > > having some other bits changed. It is therefor important that not all > > "important" bits are wiped out by one single bursterror. > > > > * Interleaving is as simple as effective: it simply changes the order of > > the bits transmitted so that bits that are important or "related" are > > not transmitted after eachother. To do this, > > - the bits order it changed before transmitting > > - the stream is transmitted > > - on the receiving end, the order of the bits is corrected again. > > > > > > > > So, this is the senario; as taking from the 2400 c2_gmsk spec: > >> 2/ for the 1400 bps voice codec: > > (...) > >> 2b/ For a timeslot WITH sync/type-of-frame pattern: > >> - 24 bits sync/type-of-frame > >> - 56 bits codec2 voice > >> - 16 bits FEC > >> > >> In this senario, > >> - once golay(24,12,8) is applied, with the ability to protect 12 bits > >> - in addition, one hamming(8,4,4) is applied, with the ability to > >> protect 4 bits. > >> > >> Firstly, the golay(24,12,8) is applied to the following bits: > >> - all 4 voiced bits > >> - the 8 energy/wo bits that apply to the first two codec2 frames of > >> the (4 frame) codec2 timeslot > >> > >> For the 4 remaing FEC bits (the hamming(8,4,4) block), I would like to > >> propose this: > >> The hamming(8,4,4) is applied NOT 4 of the other eight energy+wo bits > >> (for the 3th and 4th frame), but 4 of the MSBs of the LSPs. > > Also important to know: > > > > > * A codec2 frame is based on a 40 ms timeslot, containing information > > about four 10 ms frames. It has the following structure: > > >1/ For the 1400 bps voice codec > > > - 1 "voiced" bit for frame 0 > > > - 1 "voiced" bit for frame 1 > > > - 8 "energy or WoE" bits for frames 0 and 1 > > > - 1 "voiced" bit for frame 2 > > > - 1 "voiced" bit for frame 3 > > > - 8 "energy or WoE" bits for frames 2 and 3 > > > - 36 "LSP" bits for frames 0 up to 3 > > > Total: 56 bits > > > The 36 LSP bits represent 10 values, using between 2 and 4 bits for > > every values. > > > > > > And: > > > > > Not all information in the codec2 voice frame is equaly important. > > Corrupting certain bits produces more audiable error then other bits. > > The importance of the different > > > groups of bits is as follows (in descending order): > > > - voicing bits > > > - energy+Wo bits > > > - MSB part of the LSPs > > > - remaining part of the LSPs > > > > > > > > What is needed: > > A interleaving matrix which modifies the order of the bits as stored in > > the 72 bits of the to-be transmitted frame, into an order less > > vulnerable for burst errors: > > > > The rules are as follows: > > - bits with a high importance (like the voice-bits and energy+wo bits) > > should NOT be located close other bits with a high priority. > > > > - bits that are related should also not be located close to eachother. > > "related" bits are all bits that are part of the same FEC block: both > > the databits and the error-correction bits of the FEC block. > > In this case, there are two FEC blocks: > > . one 24 bit "golay(12,24)" block: containting the 4 voice bits, the 8 > > "energy.wo" bits of the first frame + the 12 error-correction bits for > > that block > > . one 8 "hamming(4;8)" block: containing 4 of the MSBbits of the LSPs + > > 4 error-correction bit for that block > > > > > > Who takes up the challence to give this a try. > > > > One way to do this is write an application that compaires possible > > interleaving-matrices giving them all a score how well they based on the > > requirement (it they end up with some of the important bits located next > > to eachother, it should have a bad score). > > This would allow us to compair different matrices. > > > > > > Anybody interested? > > > > Feel free to reply via the list or offlist. > > > > > > > > 73 > > Kristoff - ON1ARF > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > > Freetel-codec2 mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
