You might like this talk, which is available in audio and video 
formats:

> http://www.parc.com/cms/get_article.php?id=344

It covers Turbo, Tornado, and LDPC codes.  The focus is on a FEC 
mechanism for broadcast to receivers over a noisy channel. LDPC codes 
are supposedly close to the Shannon limit, though computationally 
expensive.  This talk brings up a lot of these interesting issues.

You can hear me ask the speaker if it's OK to use their patented 
technology for amateur radio and his response, which I interpreted to be 
"ok."

Leigh / WA5ZNU

        Using Powerful FEC Codes for File and Streaming Delivery to Mobile 
Receivers

        Michael Luby, Digital Fountain, Inc

        We describe Raptor codes, the most flexible and powerful FEC codes 
available for delivery of data over packet-based networks. We 
demonstrate that Raptor codes are crucial for both efficient delivery of 
files and for high-quality video streaming over emerging broadcast and 
multicast wireless networks. Example applications include delivery of 
navigational updates and point-of-interest data to automobiles and 
delivery of multimedia files and H.263 streaming video to 3G telephones 
and PDAs. Standardization of the general approach of using FEC codes for 
file and streaming delivery within the IETF and 3GPP will also be 
outlined.



        Dr. Michael Luby cofounded Digital Fountain, Inc. in 1998, where he 
currently holds the position of Chief Technology Officer. Michael is a 
world-renowned Theoretical Computer Scientist, and has made breakthrough 
research contributions in the areas of coding theory, randomized 
algorithm design and analysis, transport protocols and cryptography. He 
is actively leading the development of several transport standards 
within the Internet Engineering Task Force (IETF). After receiving his 
Ph.D. in Theoretical Computer Science from UC Berkeley in 1983 he was a 
Professor in Computer Science at the University of Toronto. In 1988 
Michael joined the International Computer Science Institute in Berkeley 
to become the Leader of the Theory Group and concurrently an Adjunct 
Professor at UC Berkeley. Michael is a recipient of the 2002 Information 
Theory Society Paper Award for some of his coding theory research and 
the 2003 SIAM Outstanding Paper Prize for some of his cryptography 
research.
>
> -----Original Message-----
> From: KV9U <[EMAIL PROTECTED]>
> To: digitalradio@yahoogroups.com
> Subject: Re: [digitalradio] Re: Another look at ALE
> Date: Fri, 17 Mar 2006 08:57:30 -0600
>
> I used to think that Viterbi coding worked better for ham applications.
> For example, Pactor modes (Viterbi) work better than Clover modes 
> (R-S).
> Other R-S modes include, SSTV RDFT and the Winlink 2000 initial attempt 
> to develop a sound card mode (SCAMP) which uses the same modulation 
> scheme as RDFT.
>
> Actually, many of the sound card modes use Viterbi:  QPSK31,  PSK63F, 
> PSK220F, MFSK16, MFSK8, and even the new DominoEX/FEC mode all use 
> Viterbi coding.
>
> Many of the Pactor "tricks" have been applied to sound card modes, 
> including Huffman compression which is really varicode from what I 
> understand.
>
> The use of DPSK is common for sound card modes since PSK31 is really 
> DPSK, is it not? In fact, the waveform is quite similar to Pactor using 
> a raised cosine form.
>
> But it still does not explain why Pactor 2 and 3 is so much faster than 
> the sound card modes. Even though many have determined that P2 and P3 
> can not work as deep into the noise as some sound card modes, other 
> tests seem to refute this. Rick, KN6KB has indicated that the SCS 
> product is tremendously more powerful than any desktop computer at this 
> time since it is a dedicated unit.
>
> One other way to increase the coding is to use concatenated codes that 
> include both R-S and Viterbi since we can do this with faster 
> processors. The technology trends seem to replace the concatenated 
> codes with Turbo code that is a more recent development. Is anyone 
> planning to use this for sound card applications?
>
> I wonder what would happen if a developer speeded up some of the very 
> weak signal approaches such as WOLF:
>
> http://www.scgroup.com/ham/wolf.html
>
> 73,
>
> Rick, KV9U
>
>
>
>
>
>
> Jose Amador wrote:
>
>>  Well, about what´s being done the wrong way, I think I better pass it
>>  to the codesmiths. I am not completely clear about how the soundcard
>>  modes do it, but the success if Pactor is wrapping all those tricks
>>  together.
>>
>>  Some of the modes use Reed Solomon codes, others use BCH, but I am not
>>  sure if any of them uses convolutional encoding with Viterbi decoding.
>>
>>  One important point. If my memory does not betray me, I think Pactor
>>  uses DPSK, which does better passing by the ionosphere. Seems to be
>>  easier to take account of the phase jumps than of the absolute phase.
>>
>>  I used at times packet at 1200 baud on 28, 21 and 14 MHz, and it
>>  worked in order of decreasing success on the lower frequencies....but
>>  it managed to work on 14MHz quite well at times. Multipath is the
>>  deciding factor in the link. If just one path is open, it may work, if
>>  there is multipath, better hold back to lower speeds.
>>
>>  What surprises me (and I have never been able to test it personally)
>>  is that in Indonesia, some hams have used 1200 baud DPSK satellite
>>  modes succesfully on 40 meters. Once again, DPSK does the trick.
>>
>>  It would be interesting to read about what and why the programmers
>>  have chosen their options while creating new sound card modes.
>>
>>  73 de Jose, CO2JA
>

Need a Digital mode QSO? Connect to  Telnet://cluster.dynalias.org

Other areas of interest:

The MixW Reflector : http://groups.yahoo.com/group/themixwgroup/
DigiPol: http://groups.yahoo.com/group/Digipol  (band plan policy discussion)

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/digitalradio/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



Reply via email to