Hi Jim,
On 28-10-12 08:32, Jimmy Carter wrote: >> Just wondering: >> >> Is there a difference in the format of the codec2 frames for voiced and >> unvoiced frames? >> As far as I understand the theory, voice and unvoiced frames have very >> different characteristics; so I guess, the format of the codec2 frame >> will also be different. >> >> Do the bits have a different means when used for a voiced or a unvoice >> frame. And what if the 20 or 40 ms timeslot contains both voiced and >> unvoiced (10 ms) frames? >> >> Does it make sence to do Jimmys exercise again, once for only voiced >> framed and once for only unvoiced frames? > Hey just took a look at the code in the codec2.c and it seems to be > using the same function to find the voiced bits within the frame. I > imagine they'd have a similar effect across the data rates. It's very > easy to run the tests again though. I'm going to get code going for log > spectral distance and then do some tests over the bit rates. I am still a bit confused about this; but I probably need to dive into the code a bit more to really understand this. > Separating the important bits and smearing them on the data stream will > be good for burst errors. If the log spectral distance readings agree > with subjective judgements we could base the interleaver on its > measurements. I have been making some drawings on paper this weekend to get an idea on how to do the interleaving; at least for the 1400 bps codec. In the end, I settled for this: - try to order the information in segments of 24 bits This can be: . 12 databits + 12 golay FEC bits . 20 databits + 4 hamming FEC bits (protecting bits 0 to 3 of the databits) . 24 databits without FEC - A frame that contains a sync pattern carries 72 databits: so 3 segments of 24 bits - A frame that does not contain a sync pattern carries 96 databits: 4 segments of 24 bits - The 3 or 4 segments are then interleaved: (1,1) (1,2) (1,3) (2,1) (2,2) (2,3) (3,1) ... This means that adjecent bits in the same segment are 3 or 4 bits appart in the transmission-stream. So, data that is related should be put in the same segment. - However, additional care should be taken that bits in same position of adject segments are not related neither. So, bit1 of segment 2 should not be related to bit 1 of segment 1, nor of bit1 of segment 3. (as -after interleaving- they will end up next to eachother). What will be protected? - for frames that contain a sync pattern (56 databits, 72 bits available in total). 12 bits protected in one golay block: 8 Wo+E bits of frame 0 and frame 1 + 2 '"voiced" bits for frames 1 and 2 + 2 MSBs of LSPs 4 bits protected in one hamming block: 4 MSBs of LSPs 40 databits unprotected: all information specific for frames 3 and 4 + rest of LSP information As there is no protection of the 3th and 4th frame of the 20 ms codec2 timeslot, some special care must be taken by the decoder. If the golay decoding process noticed a lot of bit-errors; the decoder can descide to copy frames 1 and 2 into frames 3 and 4 as this will mean that frames 3 and 4 will probably be also heavily corrupted. - for the frames that no not contain a syn pattern (56 databits, 96 bits available in total). 36 bits protected in three golay blocks: all "Wo+E" bits, all "voiced" bits + 2 MSBs of every LSP 4 bits protected in one hamming block: next MSBs of LSPs 16 databits unprotected: rest of LSP information > By the way its awesome to hear that you've contacted ka9q about FEC. > Found his website at the beginning of my interest in DSP and > convolutional codes around a year ago. He's got some really nice work! His work will for sure be really usefull. This weekend, I wanted to work on the codec2 stuff, but I was realy distracted by my transceiver tuned to the 10 meter band. :-) I did a number of QSOs this weekend some of them over 5000 km into VE3-country, using FM and AM on 29 Mhz! (59+ on both sides for almost 6000 km on FM!!! :-) ) But, concidering the QSB on some of these QSOs, if we want to make a DV-system that beats that; we are going to need a lot more then just FEC and interleaving in a 40 ms timeframe. Also syncronisation is going to be an issue that will require a lot of attention!!! But, first things first. First the "low complexity" modem! > KG4SGP - Jim Chééééééério! Kr. Bonne ------------------------------------------------------------------------------ WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
