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
