hi, all. I am a graduate student making research on LDPC. As we all know, LDPC with its good performance has attracted a lot of people to study on it. For the last few years, many aspects about LDPC has got to mature such as binary code design on many channels, density evolution analysis, irregular codes design .. I donot know whether there are some other problems to be resolved? And what is the future of LDPC? Anybody would like to exchane some ideas with me?? Best wishes..
what aspects we can do more about LDPC?
Started by ●April 6, 2007
Reply by ●April 6, 20072007-04-06
On 6 Apr 2007 06:46:48 -0700, "zaaamouse" <lm.zju.edu.cn@gmail.com> wrote:>hi, all. >I am a graduate student making research on LDPC. As we all know, LDPC >with its good performance has attracted a lot of people to study on >it. For the last few years, many aspects about LDPC has got to mature >such as binary code design on many channels, density evolution >analysis, irregular codes design .. >I donot know whether there are some other problems to be resolved? And >what is the future of LDPC? >Anybody would like to exchane some ideas with me?? > > >Best wishes..Efficient decoder implementations, and perhaps more work on code design to enable them, is still needed, IMHO. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Reply by ●April 6, 20072007-04-06
>On 6 Apr 2007 06:46:48 -0700, "zaaamouse" <lm.zju.edu.cn@gmail.com> >wrote: > >>hi, all. >>I am a graduate student making research on LDPC. As we all know, LDPC >>with its good performance has attracted a lot of people to study on >>it. For the last few years, many aspects about LDPC has got to mature >>such as binary code design on many channels, density evolution >>analysis, irregular codes design .. >>I donot know whether there are some other problems to be resolved? And >>what is the future of LDPC? >>Anybody would like to exchane some ideas with me?? >> >> >>Best wishes.. > >Efficient decoder implementations, and perhaps more work on code >design to enable them, is still needed, IMHO. > >Eric Jacobsen >Minister of Algorithms >Abineau Communications >http://www.ericjacobsen.org >I think the Encoding process is a real issue with LDPC codes. There is no succinct way of describing the encoding process, or making it scaleable. If you compare to product codes with generator polynomials, they can be represented/described quite neatly which also leads to very simple encoding functions. Sele http://signals.thingsconnect.com/ _____________________________________ Do you know a company who employs DSP engineers? Is it already listed at http://dsprelated.com/employers.php ?
Reply by ●April 6, 20072007-04-06
zaaamouse wrote:> hi, all. > I am a graduate student making research on LDPC. As we all know, LDPC > with its good performance has attracted a lot of people to study on > it. For the last few years, many aspects about LDPC has got to mature > such as binary code design on many channels, density evolution > analysis, irregular codes design .. > I donot know whether there are some other problems to be resolved? And > what is the future of LDPC? > Anybody would like to exchane some ideas with me??For many practical applications, it would be good to have a high performance code with a small block length (hundreds of bits). The theoretical bounds allow for that, however the quasi random structures do not perform well unless the block size is at the order of 10kbit or higher. If you can come up with the such code, that would be a breakthrough. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●April 7, 20072007-04-07
On 4=D4=C27=C8=D5, =C9=CF=CE=E76=CA=B123=B7=D6, "Sele" <s...@thingsconnect.= com> wrote:> >On 6 Apr 2007 06:46:48 -0700, "zaaamouse" <lm.zju.edu...@gmail.com> > >wrote: > > >>hi, all. > >>I am a graduate student making research on LDPC. As we all know, LDPC > >>with its good performance has attracted a lot of people to study on > >>it. For the last few years, many aspects about LDPC has got to mature > >>such as binary code design on many channels, density evolution > >>analysis, irregular codes design .. > >>I donot know whether there are some other problems to be resolved? And > >>what is the future of LDPC? > >>Anybody would like to exchane some ideas with me?? > > >>Best wishes.. > > >Efficient decoder implementations, and perhaps more work on code > >design to enable them, is still needed, IMHO. > > >Eric Jacobsen > >Minister of Algorithms > >Abineau Communications > >http://www.ericjacobsen.org > > I think the Encoding process is a real issue with LDPC codes. There is no > succinct way of describing the encoding process, or making it scaleable. > If you compare to product codes with generator polynomials, they can be > represented/described quite neatly which also leads to very simple > encoding functions. > > Selehttp://signals.thingsconnect.com/ > > _____________________________________ > Do you know a company who employs DSP engineers? =20 > Is it already listed athttp://dsprelated.com/employers.php?- =D2=FE=B2=D8==B1=BB=D2=FD=D3=C3=CE=C4=D7=D6 -> > - =CF=D4=CA=BE=D2=FD=D3=C3=B5=C4=CE=C4=D7=D6 -yes. Maybe the practical application of LDPC should attract more research. But I think it emphasizes more on industry contribution. For fundamental theory, it's hard to make a breakthrough. That's my personal opinion. BTW, a researcher recommends me to do something about rateless coding based LDPC. I do not whether this aspect is a good aspect?
Reply by ●April 8, 20072007-04-08
On Fri, 06 Apr 2007 17:41:18 -0500, Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:> > >zaaamouse wrote: >> hi, all. >> I am a graduate student making research on LDPC. As we all know, LDPC >> with its good performance has attracted a lot of people to study on >> it. For the last few years, many aspects about LDPC has got to mature >> such as binary code design on many channels, density evolution >> analysis, irregular codes design .. >> I donot know whether there are some other problems to be resolved? And >> what is the future of LDPC? >> Anybody would like to exchane some ideas with me?? > >For many practical applications, it would be good to have a high >performance code with a small block length (hundreds of bits). The >theoretical bounds allow for that, however the quasi random structures >do not perform well unless the block size is at the order of 10kbit or >higher. If you can come up with the such code, that would be a breakthrough. > >Vladimir Vassilevsky > >DSP and Mixed Signal Design Consultant > >http://www.abvolt.comBoth the IEEE 802.16e and 802.11n standard/draft contain such LDPC codes. I chaired efforts in both cases. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Reply by ●April 9, 20072007-04-09
Eric Jacobsen wrote:>>For many practical applications, it would be good to have a high >>performance code with a small block length (hundreds of bits). The >>theoretical bounds allow for that, however the quasi random structures >>do not perform well unless the block size is at the order of 10kbit or >>higher. If you can come up with the such code, that would be a breakthrough. >> > > Both the IEEE 802.16e and 802.11n standard/draft contain such LDPC > codes. I chaired efforts in both cases.Yes, the 802.16 includes Turbo and LDPC coding. However it is defined as the optional feature, which doesn't mean much good. Can you comment on the code performance vs block size, compared to the conventional RS + CC ? Last time I looked at this was in 2004, and my impression was there is no systematic procedure to generate a high performance code with a moderate block length. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●April 9, 20072007-04-09
On 4=D4=C29=C8=D5, =CF=C2=CE=E712=CA=B139=B7=D6, Vladimir Vassilevsky <anti= spam_bo...@hotmail.com> wrote:> Eric Jacobsen wrote: > >>For many practical applications, it would be good to have a high > >>performance code with a small block length (hundreds of bits). The > >>theoretical bounds allow for that, however the quasi random structures > >>do not perform well unless the block size is at the order of 10kbit or > >>higher. If you can come up with the such code, that would be a breakthr=ough.> > > Both the IEEE 802.16e and 802.11n standard/draft contain such LDPC > > codes. I chaired efforts in both cases. > > Yes, the 802.16 includes Turbo and LDPC coding. However it is defined as > the optional feature, which doesn't mean much good. > > Can you comment on the code performance vs block size, compared to the > conventional RS + CC ? > > Last time I looked at this was in 2004, and my impression was there is > no systematic procedure to generate a high performance code with a > moderate block length. > > Vladimir Vassilevsky > > DSP and Mixed Signal Design Consultant > > http://www.abvolt.comyes. Maybe the biggest difficulty to widely apply LDPC in indusry is how to deduce its implemetion complexity with little performance degradation. Moderate block length, fewer iteration numbers, good frame error performance and so on are all we have to consider. The result i have experimented on LDPC reveals that if not enough iteration numbers and not very long code applied, LDPC maybe beated by other coding schemes, such as RS + CC you mentioned.
Reply by ●April 10, 20072007-04-10
On Sun, 08 Apr 2007 23:39:09 -0500, Vladimir Vassilevsky <antispam_bogus@hotmail.com> wrote:>Eric Jacobsen wrote: > >>>For many practical applications, it would be good to have a high >>>performance code with a small block length (hundreds of bits). The >>>theoretical bounds allow for that, however the quasi random structures >>>do not perform well unless the block size is at the order of 10kbit or >>>higher. If you can come up with the such code, that would be a breakthrough. >>> >> >> Both the IEEE 802.16e and 802.11n standard/draft contain such LDPC >> codes. I chaired efforts in both cases. > >Yes, the 802.16 includes Turbo and LDPC coding. However it is defined as >the optional feature, which doesn't mean much good.Whether it's optional or not has no bearing on the performance or suitability of the code.>Can you comment on the code performance vs block size, compared to the >conventional RS + CC ?Our comparisons were to CC-only, which is legacy for 802.11, and TC, which is optional in 802.16 and the primary "competitor" to LDPC. In 802.16 the block lengths run according to what the MAC uses for packet partitioning, which results in block sizes from about 576 bits up to 2304 bits. In all of those cases the LDPC performance was pretty much on par or slightly better than the Turbo Code, so I think it'll be difficult to squeeze much more performance out of the system without a significant breakthrough in code design for either TC or LDPC. The differentiator is complexity and insensitivity to channel interleaving, where the LDPC has some advantages. In 802.11 codes of very similar structure and performance to the 802.16e codes were used (by intent), but the packet sizes in the 802.11 MAC can be anything from 1 byte to something huge (I don't remember the limit, but nobody is going to build a code that big). In that case we developed concatenation rules for stringing code blocks together efficiently in order to accomodate any given packet size. The code block sizes run from (IIRC) about 576 bits up to about 1728 or so. For any iterative block code the coding gain drops with the codeword size due to the loss in bit diversity, and that's true for both TC and LDPC. We found that the breakpoint was about 60 bytes where one was just as well (or better) off using the CC, which has nice properties for small blocks. So we didn't bother defining codeword sizes any smaller than that since they're not useful, anyway.>Last time I looked at this was in 2004, and my impression was there is >no systematic procedure to generate a high performance code with a >moderate block length.Yes, there is some art involved. The codes defined in 802.16e and 802.11n are quite practical and perform very well, though. There was competition within the committees to produce good codes, so what came out of the process was a good result, IMHO. Eric Jacobsen Minister of Algorithms Abineau Communications http://www.ericjacobsen.org
Reply by ●April 10, 20072007-04-10
On Apr 10, 1:21 pm, Eric Jacobsen <eric.jacob...@ieee.org> wrote:> Yes, there is some art involved. The codes defined in 802.16e and > 802.11n are quite practical and perform very well, though. There was > competition within the committees to produce good codes, so what came > out of the process was a good result, IMHO. > > Eric JacobsenHey Eric, this is interesting. Can you post the links to documentation on these codes, please? Thanks in advance, Julius
