Hi everyone (and in particular Kristoff). Sorry to fragment this thread further, but...
Firstly - I agree that "older" small block codes are going to be more practical in the short-term than more advanced modern codes, if only because things like LDPC codes use enormous block lengths to get their efficiency up, and so they would add to the encode-decode latency so much as to make voice communications at these very low bitrates very cumbersome. Secondly - Having only looked briefly at the Golay code you're advocating, it does look like a good option - there is a guaranteed Hamming distance of 3 for every transmitted data bit (i.e. one bit change in the original code-word results in 3 bits changing in the transmitted codeword), which is really quite high. I agree that a better option for a "strangled" Golay code to reduce it from being a 1/2-rate code (i.e. 12 extra bits added to the original 12 data bits) to being a 2/3-rate code (i.e. 6 extra bits per 12 originals) would be to reduce the Hamming distance to 2, which I'm hoping you can achieve by careful removal of 6 of the "added" ECC bits. This would then, as you say, lead to all the payload bits having some ECC, rather than half having ECC, and half having none, which has to be a better overall solution, especially since there is no real redundancy in the original datastream to allow errors to be "concealed". Finally - When it comes to interleaving, most existing systems use fixed block interleaving structures, with the interleaving table size being as large as the latency will allow - i.e. the incoming datastream is written (bit by bit after ECC) into a table in one orientation (say left-to-right, from top-to-bottom), and then read-out in the opposite orientation (top-to-bottom, from left-to-right). This then ensures that, so long as the original bits from any particular group get spread-out as evenly as possible in the 2D table, the average time separation between them (and so their tolerance of burst errors) is maximised. In a scenario like this where you have an interleaving structure for data from several blocks being grouped-together (several Golay-ECCed blocks as well as several Hamming-ECCed blocks) for transmission in one bigger chunk, it would seem most sensible to pre-interleve the data from each of the parent blocks, so that bits from each ECC block end-up as spaced-out from each other as possible in that interleaving table, so that the time difference between their transmission is maximised. Graham -----Original Message----- From: Kristoff Bonne [mailto:[email protected]] Sent: 24 October 2012 15:32 To: [email protected] Subject: Re: [Freetel-codec2] 2400 bps gmsk modem: FEC Hi, On 24-10-12 14:10, Bruce wrote: >> In the list I got, the VQ (used by the 1200 bps codec) where at the same place of the LSPs for the 1400 bps codec. Would you place them higher? > My (very imperfect) understanding is that corrupting an LSP is like > distorting one filter tap while corrupting VQ can effect more than one. > Also, David noted that the first VQ index is the most sensitive. I'm sorry. It looks like some of our messages crossed eachother. (I sometimes write my email offline on the train which means they get posted a couple of hours later). Concerning the order of what to protect first, This is what would apply for the 1200 bps codec: - voicing bits (4 bits) - energy+Wo bits (16 bits) - VQ (27 bits) - spare bit (1 bit) (there are no LSPs on the 1200 bps codec, only VQ bits). The voice-bits clearly have top priority; so the remaining 20 bits that can be given FEC protection would then have to be chosen from either the Energy+Wo or VQ group. For me, it does does have to be "all or nothing". Perhaps we can protect some part of the Energy+Wo bits and part of the VQ bits. It this makes more sence, no problem. Perhaps a stupid question, would it make sence to use a different sceme for voiced or unvoiced frames? But, how do you then handle timeslots where there are both voiced and unvoiced 10-ms frames? > > Now, for the 1200 bps codec, the situation is relative simple: - if > there is no sync pattern, there is 48 bits of data and 48 bits of FEC, > so that is easy. - if there is a sync pattern, it's only possible to > protect up to 24 bits. > > Maybe I don't understand. Are you laboring under the misconception that > FEC must duplicate the data? Convolutional codes, even such old things > as CRC, will expand the data at less than a 1:1 ratio. I think you can > assume that we're using a more modern code like LDPC or turbo codes. Remember that we are using golay and hamming, because of the availability of open source code and we are pretty sure there are no patents applied here. Bill can probably elaburate better on that. If you take the example of golay, I have sofar only seen implementation of golay(12,24), i.e. a FEC of 1/2. If you take the example of D-STAR, they apply FEC on the voice part with a rate of 2/3 (per 20 ms frame: 48 bits become 72 bits), they just do a FEC 1/2 on two out of four of the 12-bit blocks: 2 * (12+12) + 2 * (12) = 72 bits. (At least, this is how I read it from the DTMF decoding software for the D-STAR repeaters). If my impression is right, this is actually pretty logical: If you would use a trick to reduce a (12,24) golay code to (12,18) (e.g. something simular to puncturing); this would impact the ability to decode errors on the FEC system, this equality for all bits in the golay block. So, if you would do (say) four times (12,18) (i.e. protect 48 bits with a 2/3 FEC and create 72 bits), you would apply FEC protection on all the bits; but with a limited protective power. If you do golay(12,24) on the first two blocks and no FEC on the latter two; you apply FEC on only half the information and no FEC on the other half. For codec2; this approach does make sence as certain information is simply more important then other. But, again, this is based on how I understand FEC. Anybody, feel free to correct me if I am wrong! > Thanks > Bruce Chééééério! 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
