-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for sending callsigns using RADE #783
Conversation
@drowe67, so I'm pretty sure the TX side is correct based on the logs below. I'm not fully sure about the RX side, though. For instance, this run supposedly decoded with low BER but the decoded callsign is obviously not correct:
(Amplitude calculation is basically Test procedure:
Maybe you'll be able to see something obvious that I missed? |
Try:
Should be sqrt(sum(|v|^2))/N), RMS = root - mean - square, for for complex numbers (assuming s[] is populated)
|
@tmiw - I fixed an error in (3) and added some C code to the comment ☝️ |
1. Add RadeTextTest to rule out any issues with freedv-gui. 2. Calculate RMS magnitude across all EOO bits, not just the ones used by RADE text.
I ended up creating a Execute using the following:
Original (pre-rotation): After rotation: (Note: I used
After tweaking, it seems to match up with what Octave generates now, anyway:
vs.
Generated symbol files if you want to analyze further: syms.f32.zip |
I looked at the RADE code a bit more closely this morning and it looks like it was a problem with the TX side after all. The test application/ctest is now properly decoding, including with interleaving:
I'll probably do some code cleanup and then do testing with the full freedv-gui stack. |
@tmiw that seems better, suggest you also try the other AWGN suggestion above (edited):
|
I dropped
Across multiple runs, the highest raw BER I was able to get was 0.036:
The other runs for reference:
So yeah, it looks like we're able to correct down to ~4% as you mentioned. |
Was there anything else still pending for this PR? We can open another one if we need to make code changes for @Tyrbiter's observation. |
Oops, forgot to tag @drowe67 for the above question. |
It appears to work OK, so don't hold fire on my account, not actually sure what is happening and if there really is a buffering problem. |
@tmiw - there's still some pretty obvious errors above, e.g.
|
I added some logic in 20a9c9e to output the TX and RX floats to files, which I've been passing to
For coded BER, is that always going to be lower than raw BER, or do those have no correlation with each other? FWIW the current coded BER calculation is as follows: // Calculate coded BER.
int bitsCoded = 0;
int errorsCoded = 0;
for (int index = 0; index < LDPC_TOTAL_SIZE_BITS / 2; index++)
{
bitsCoded++;
int err = LastLDPCAsBits[index] != output[index];
if (err)
{
errorsCoded++;
}
} with memcpy(&tmpbits[0], &ibits[0], LDPC_TOTAL_SIZE_BITS / 2);
memcpy(&tmpbits[LDPC_TOTAL_SIZE_BITS / 2], &pbits[0], LDPC_TOTAL_SIZE_BITS / 2);
memcpy(LastLDPCAsBits, tmpbits, LDPC_TOTAL_SIZE_BITS); |
The idea of FEC is to correct errors, not introduce them. So beneath a certain threshold (around 8% for a rate 0.5 LPDC code), the coded BER < uncoded BER. Getting coded errors when there are no uncoded errors should be impossible. Not sure what all those arrays are doing in your code. There are many examples of BER tests with LDPC in libcodec2. You compare the tx bits to the rx bits. I usually start with a fixed test frame known to both the Tx and Rx. |
OK, I think I figured out the discrepancy. With the following AWGN setup:
I got the following runs:
(I added an additional BER calculation for the entire EOO--not just the 112 bits that are actually used--to at least make sure "raw" errors isn't higher than the EOO errors.)
Seems to at least be doing that now. I'm guessing there was a calculation error somewhere along the line before that got fixed with today's commits.
The arrays are mainly to store the generated LDPC bits/floats for later comparison. There is indeed a known sequence (the bits needed to encode the "callsign" ZZ0ZZZ, the latter of which is injected by the test framework). |
@drowe67, here's some additional testing with -14 passed to
Most runs don't decode a callsign but the number of error bits for coded BER is consistently lower than raw BER:
Let me know if there's any additional testing you'd like me to do or if we can go ahead and close this PR out. |
@tmiw look like it's headed in the right direction, but it's unusual (very low probability), that the FEC code will work at 17% raw errors. To get a feel for the expected performance try:
I'm guessing you are using Just to confirm:
|
Correct, we're using
What's done for encoding ( flowchart TB
step1["Encode callsign into 6 bit character set"]
step2["Calculate CRC8"]
step3["LDPC encode"]
step3["Concatenate ibits and pbits together"]
step4["Interleave bits"]
step5["Convert bits to symbols"]
step6["Concatenate additional symbols to fill EOO block"]
step1 --> step2
step2 --> step3
step3 --> step4
step4 --> step5
step5 --> step6
The interleaved bits are converted to symbols as follows (based on what I found in codec2
And to fill out the EOO block, we send repeated
On the decode side ( flowchart TB
step1["Deinterleave symbols"]
step2["Calculate RMS magnitude of received symbols"]
step3["Convert symbols to LLRs"]
step4["LDPC decode"]
step5{"Estimated BER from LDPC decoder < 0.2?"}
step6["Drop received callsign"]
step5a["Calculate CRC8 of received callsign"]
step5b{"Calculated CRC8 == received CRC8?"}
step5b1["Convert callsign to ASCII"]
step5b2["Pass callsign to higher level code"]
step5c["Drop received callsign"]
step1 --> step2
step2 --> step3
step3 --> step4
step4 --> step5
step5 -- Yes -->step5a
step5a --> step5b
step5b-- Yes --> step5b1
step5b1 --> step5b2
step5b-- No --> step5c
step5-- No -->step6
Correct (
Correct ( Note on the BER calculation: it appears that the formula for BER calculation is basically BTW I ran the AWGN test 30 times with |
@tmiw - thanks for that detailed explanation. The val.csv values make sense, just the occasional decode at at such a high raw BER. So I'm good to merge this and will merge drowe67/radae#35. I'm not sure how useful the LDPC based BER estimate is, it's probably based on the # of parity checks that match. |
WIP PR to bring over the
reliable_text
library from codec2 and adapt it for RADE.NOTE: requires #780 to be merged first. I merged that branch in here to make sure we're not also fighting bugs with EOO TX while implementing this PR.