Looking for an FEC coding scheme with variable coding bits
in [DSP]
|
Prev: How to compensate gravity if I only have 1 accelerometer and 1 magnetometer(magnetic field sensor)?
Next: FPGA Camp is tomorrow - 11/11 - silicon valley - Dinner provided
From: dudelmann on 9 Nov 2009 09:32 Background: I am currently writing a lossy LPC source coder for real time transmission over a wireless channel. This coder produces a stream with a fixed AVERAGE bit rate (that means it varies around that rate). To keep the MOMENTARY bit rate within certain limits, I reduce quality when the bit rate gets too high and I INSERT USELESS BITS, WHEN IT GETS TOO LOW (hint: this was the important part :). This way I can keep the overall bit rate within limits all the time. Now this stream is to be transmitted over a wireless simplex channel (meaning I don't get any feedback from the receiver). Thus I have to add forward error correction (FEC) bits to my stream. So far so good. Problem / Idea: The idea is to use the bits I add in order to keep the lower bit rate limit for forward error correction - instead of just adding nonsense. The problem is, that the number of bits that are added is not constant. Question(s): Does anyone know of an FEC coding scheme that can cope with a varying number of correction bits? Or can anyone propose a scheme? Something like: - for one bit, make it the checksum of the next two bits - for 2 bits, make it an FEC code for the next two bits - for 3 bits, make it an FEC code for the next three and so on... Any help, idea or suggestion is highly appreciated! Thx in advance Markus
From: Vladimir Vassilevsky on 9 Nov 2009 09:57 dudelmann wrote: > Background: > I am currently writing a lossy LPC source coder for real time transmission > over a wireless channel. This coder produces a stream with a fixed AVERAGE > bit rate (that means it varies around that rate). To keep the MOMENTARY bit > rate within certain limits, I reduce quality when the bit rate gets too > high and I INSERT USELESS BITS, WHEN IT GETS TOO LOW Why can't you just shut the transmitter down when there is nothing to transmit? > (hint: this was the > important part :). This way I can keep the overall bit rate within limits > all the time. Qualcomm employed variable bitrate codec (QCELP) in CDMA IS-95 standard. That provided for statistical multiplexing of the channel and some battery savings as well. > Now this stream is to be transmitted over a wireless simplex channel > (meaning I don't get any feedback from the receiver). Thus I have to add > forward error correction (FEC) bits to my stream. > So far so good. > > Problem / Idea: > The idea is to use the bits I add in order to keep the lower bit rate > limit for forward error correction - instead of just adding nonsense. The > problem is, that the number of bits that are added is not constant. This is likely to be inefficient as the low bitrate parts are perceptually unimportant. There is little advantage in adding better protection to the unimportant data. > Question(s): > Does anyone know of an FEC coding scheme that can cope with a varying > number of correction bits? > Or can anyone propose a scheme? Quick and dirty solution could be punctured convolutional code with the variable amount of puncturing. > Something like: > - for one bit, make it the checksum of the next two bits > - for 2 bits, make it an FEC code for the next two bits > - for 3 bits, make it an FEC code for the next three and so on... Depending on the bit rate, you have several different bit layouts of the vocoder frame. Develop the encoding scheme for each layout. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: dudelmann on 9 Nov 2009 10:18 >Why can't you just shut the transmitter down when there is nothing to >transmit? Usually this is just one, two or three bits in the middle of a lot of data. >> Now this stream is to be transmitted over a wireless simplex channel >> (meaning I don't get any feedback from the receiver). Thus I have to add >> forward error correction (FEC) bits to my stream. >> So far so good. >> >> Problem / Idea: >> The idea is to use the bits I add in order to keep the lower bit rate >> limit for forward error correction - instead of just adding nonsense. The >> problem is, that the number of bits that are added is not constant. > >This is likely to be inefficient as the low bitrate parts are >perceptually unimportant. There is little advantage in adding better >protection to the unimportant data. not quite true. i apply (modified) rice coding and the stream is not block based - it works on a sample by sample basis. if a bit drops, the coder an decoder might get out of step and thus create a total desaster. >> Question(s): >> Does anyone know of an FEC coding scheme that can cope with a varying >> number of correction bits? >> Or can anyone propose a scheme? > >Quick and dirty solution could be punctured convolutional code with the >variable amount of puncturing. good idea, thanks I will have a look at it. >> Something like: >> - for one bit, make it the checksum of the next two bits >> - for 2 bits, make it an FEC code for the next two bits >> - for 3 bits, make it an FEC code for the next three and so on... > >Depending on the bit rate, you have several different bit layouts of the >vocoder frame. Develop the encoding scheme for each layout. Currently i don't have frames. i operate on a per sample basis. if I had frames, things would be easier i admit, but this also increases overall delay. >Vladimir Vassilevsky >DSP and Mixed Signal Design Consultant >http://www.abvolt.com >
From: Eric Jacobsen on 9 Nov 2009 13:53 On 11/9/2009 8:18 AM, dudelmann wrote: >> Why can't you just shut the transmitter down when there is nothing to >> transmit? > > Usually this is just one, two or three bits in the middle of a lot of > data. > >>> Now this stream is to be transmitted over a wireless simplex channel >>> (meaning I don't get any feedback from the receiver). Thus I have to > add >>> forward error correction (FEC) bits to my stream. >>> So far so good. >>> >>> Problem / Idea: >>> The idea is to use the bits I add in order to keep the lower bit rate >>> limit for forward error correction - instead of just adding nonsense. > The >>> problem is, that the number of bits that are added is not constant. >> This is likely to be inefficient as the low bitrate parts are >> perceptually unimportant. There is little advantage in adding better >> protection to the unimportant data. > > not quite true. i apply (modified) rice coding and the stream is not block > based - it works on a sample by sample basis. if a bit drops, the coder an > decoder might get out of step and thus create a total desaster. This is important to accommodate, as bit slips do happen in practical systems, especially during a deep fade event. >>> Question(s): >>> Does anyone know of an FEC coding scheme that can cope with a varying >>> number of correction bits? >>> Or can anyone propose a scheme? >> Quick and dirty solution could be punctured convolutional code with the >> variable amount of puncturing. > > good idea, thanks I will have a look at it. I was going to suggest some simple code rate adaptation schemes, and varying the puncturing on a convolutional code is one of them. Regardless of what you do, however, you need to include some sort of signalling scheme so that the decoder knows what to do with the incoming stream, i.e., where the adaptation points are and what changed. >>> Something like: >>> - for one bit, make it the checksum of the next two bits >>> - for 2 bits, make it an FEC code for the next two bits >>> - for 3 bits, make it an FEC code for the next three and so on... >> Depending on the bit rate, you have several different bit layouts of the > >> vocoder frame. Develop the encoding scheme for each layout. > > Currently i don't have frames. i operate on a per sample basis. if I had > frames, things would be easier i admit, but this also increases overall > delay. The delay for framing (or some sort of configuration signalling) is one of the prices you pay for being to implement adaptation. Somehow you need to convey the coding scheme and relevant changes due to adaptation to the demodulator. Usually this means a framing scheme, since it's ultimately a pretty efficient way to do it. FWIW, framing will also help to mitigate your catastrophic bit-slip problem, since detecting the framing will limit the scope of a bit-slip event. -- Eric Jacobsen Minister of Algorithms Abineau Communications http://www.abineau.com
From: dudelmann on 10 Nov 2009 03:32
Hi thanks for all the helpful answers so far. Concerning the framing: In a bit error free scenario the codec does not need framing since all adaptive coefficients are updated depending on the already received data. Now I know of course that in practice I will have to send the coefficients from time to time since there will be errors and I also don't know when the receiver is going to start decoding. in other words: I am planning to have some sort of framing and also some sort of FEC in these frames. My idea was to additionally use the fill-up bits for FEC. But maybe it is wiser to merely add FEC after my codec and use the fill-up bits for additional data - like config, or names or time or whatever |