Hi Bill
thanks for the info. I've used LDPC for about 7 years, mostly based on
David Mackays's work. Written all my own generators /decoders etc. I
did a little with turbo block codes. Very easy to explain to people the
method of TBC decoding is like solving a crossword !
Certainly an iteratively decodable code like LDPC is useful in any sort
of equaliser/interference mitigation where the decoder can provide a
metric to direct the effort. And of course you(almost) get a really good
CRC for free.... As for long and short codes and the gains...well no
free lunch there . I have been interested to read about your work with
shortened LDPC codes. There are many of those in block code world of
course, but they dont easily lend themselves it iterative decoding apart
from bit flip etc.
cheers
On 09/07/2020 16:10, Bill Cowley wrote:
Hi Glen,
A couple of general points re FEC: For digital voice, a few bit
errors may not cause too many problems, especially if the speech
decoder includes checks for weird parameter values. As some of the
current work covers digital sources (such as telemetry applications),
bit errors may be much less desirable. Secondly, FEC has improved
over the years -- the iterative codes in use now (LDPC, turbo codes
etc) offer better performance. They can also be used sometimes for
other benefits eg interference cancellation. Third, we now have
options that may offer attractive Eb/N0 performance over HF channels -
such 16FSK with LDPC. Agreed that we need to pick the code length and
rate carefully to avoid too much latency, but still give good
performance.
Cheers, Bill
On 9/7/20 11:57 am, Glen English wrote:
Hi David and group
I want to discuss "to FEC or not to FEC"
years ago, david and I had a conversation, I has asked David how he
felt about adding FEC.
David's comment was that he'd spent alot of work gettign the bit rate
down (IE the low bit rate speech codec)
and that he did not see the point or advantage of adding the bits
back in (with FEC).
I thought that was a very reasonable statement, and if using CODEC2
at the rock bottom of the modem, that would be true.
I was looking at the LLRs and other that Bill Cowley and David have
produced, and I wondered about our conversation.
Given that at BER=0.05 (5% raw BER) , the 'cost ' of FEC was a full
dB, I was wondering was the newer 700 mode usable at that high error
rate---Since the codec we were discussing (David and I) years ago was
1400 bps. and now at 700 bps losing a bit or two can hurt more.
An answer to this might be- try and find another 1.5dB and life
inside an FEC regime will be much better.
I'd be hesitant to stretch the code length out more than half a
second of speech, since latency is an issue when we are havign
conversations.
There might be a application for long code lengths for things like
WIA broadcasts, where very long blocks would provide some gain
-glen
On 09/07/2020 11:59, David Rowe wrote:
Hello List,
I've just merged some fine work by Bill, VK5DSP that has shown us how to
generate LLRs for 4FSK, in order to use LDPC codes with 4FSK. Bill has
summarised the Octave simulations he has developed in the GitHub PR:
https://github.com/drowe67/codec2/pull/129#issuecomment-653557681
At the top of the PR is a "Further Work" list. I would welcome new PRs
from anyone who would like to push these changes through to the C
version of the FSK modem.
Cheers,
David
On 8/7/20 8:01 am, Steve wrote:
On Tue, Jul 7, 2020 at 5:05 PM Al Beard <[email protected]
<mailto:[email protected]>> wrote:
There is a broken link to a document in: README_ofdm.txt:
https://svn.code.sf.net/p/freetel/code/codec2-dev/octave/modem_codec_frame_design.ods
Here you go:
https://github.com/drowe67/codec2/blob/master/README_ofdm.md
The stuff on sourceforge is an archive. GIT is the new development area.
Steve
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
--
Glen English
RF Communications and Electronics Engineer
CORTEX RF
&
Pacific Media Technologies Pty Ltd
ABN 40 075 532 008
PO Box 5231 Lyneham ACT 2602, Australia.
au mobile : +61 (0)418 975077
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
--
Glen English
RF Communications and Electronics Engineer
CORTEX RF
&
Pacific Media Technologies Pty Ltd
ABN 40 075 532 008
PO Box 5231 Lyneham ACT 2602, Australia.
au mobile : +61 (0)418 975077
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
