Hello Matthias,

My understanding is that iterative coding schemes need large block sizes
to be effective. Fine for 1Gbit Ethernet, but Codec 2 has just 48
bits/frame, so a large block size would lead to intolerable delay.

- David

On Sun, 2012-07-15 at 14:49 -0500, Matthias Granberry wrote:
> Is there a reason that the amateur radio community doesn't use
> iterative coding schemes for FEC and instead relies on Golay or
> Reed-Solomon error correction?  Is it that LDPC codes are (usually)
> non systematic, somewhat more complex to implement, or something else
> entirely that I'm missing?
> 
> Thanks,
> Matthias Granberry - KD5PFT
> 
> On Jul 14, 2012 5:23 PM, "Kristoff Bonne" <[email protected]> wrote:
>         Hi,
>         
>         
>         We are two weeks since the last software-update of the
>         gmskmodem; so ... I just pushed a new version onto github:
>         
>         
>         Changes:
>         - some additional error-checking for ALSA
>         
>         - There is now an option "-id" which enables the modem to play
>         out a wav-file after every "n" transmissions. The reason is
>         that all transmissions of hams have to be "in the clear" and
>         hams have to give their callsign every "x" overs.
>         As we are dealing with developing a new protocol -which cannot
>         be understood by other hams- it might be usefull to add a
>         small audio-fragment with your callsign in plain audio or CW
>         after a transmission so that people are able to identify the
>         source of "this strange broadcast".
>         
>         - I've also changed the Makefile so that the code can be
>         compiled with floating-points instead of integer operations.
>         This may sound a bit strange; but this is the result of
>         helping out some people to port the "WSPR" application to the
>         raspbery pie.
>         It turns out that -on some devices, like the RasPi-
>         calculating a filter in DSP is faster when using
>         floating-point operations. The ARM1176 in the Pie seams needs
>         more CPU cycles to do a 32 bit * 32 bit integer operations;
>         then doing the calculation using the onboard VFP unit.
>         
>         By modifying a flag in the Makefile, one can now select if the
>         code is compiled using integer or floating-point math.
>         
>         As usual, the code can be found at github:
>         https://github.com/on1arf/gmsk/tree/master/gmskmodem_codec2 
>         
>         
>         Planned for the next releases: 
>         - implement the header. (who knows where I can find code for
>         implementing golay FEC encoding)?
>         
>         - do some further experimenting with optimizing the integer
>         math.
>         After doing some research on the assembler-code generated by
>         gcc when doing code-optimalisation of the integer math; it
>         turns out that on a ARM9 and a ARM11, every 32 * 16
>         multiplication in C is actually translated into three
>         multiplications on assembler level: two "MUL" (multiply) and
>         one "MLA" (Multiply-and-add) instructions.
>         
>         As some devices (like almost all  D-STAR gmskmodems out there)
>         actually operate with audio using only 10 bits (instead of
>         16), I want to experiment if it not possible to reduce the
>         resolution of the audio and of the filter FIR coefficients; so
>         that this 16*32 bit multiplication will be limited to an
>         instruction that fits in 32 bit; hopefully reducing the
>         CPU-power needed on certain devices without a FPU.
>         
>         
>         
>         73
>         Kristoff - ON1ARF
>         
>         
>         
>         
> ------------------------------------------------------------------------------
>         Live Security Virtual Conference
>         Exclusive live event will cover all the ways today's security
>         and
>         threat landscape has changed and how IT managers can respond.
>         Discussions
>         will include endpoint security, mobile security and the latest
>         in malware
>         threats.
>         http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>         _______________________________________________
>         Freetel-codec2 mailing list
>         [email protected]
>         https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>         
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________ Freetel-codec2 mailing list 
> [email protected] 
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to