PSK Reporter encoding/decoding improvements

[tmiw]

Alternate implementation of PSK Reporter improvements:

• Uses codec2's reliable_text API (which uses LDPC(112,56) with a max of 8 characters)
• Supports manual frequency entry for those without Hamlib enabled.

This obsoletes PR #98. Note that this PR will break compatibility for PSK Reporter with previous versions.

[Tyrbiter]

There are some places with 7 character callsigns, VK#Fxyz are Australian foundation licences I believe.

I don't think there is any reason for supporting prefixes, suffixes and special event callsigns, but this case is one that is a normal everyday callsign. Not sure if there are (m)any others.

[tmiw]

@Tyrbiter, thanks for that. I bumped up the limit to 8 characters, which should still be good if we go LDPC.

[drowe67]

Hi @tmiw - a good way to develop this protocol is to break it out as a separate module, so it can be tested on the command line, just like the recent stm32 700E tests. It's very easy for subtle issues to slip in that will be difficult to debug or test using a GUI application and over the air testing.

Design wise, libcodec2 might be a better place for it.

One interesting "unit test" for the protocol would be to see how it stands up to typical simulated channels. For example it should have a low packet error rate at SNRs where the voice quality is fair.

Gut feel is a block code like Golay should be sufficient, LDPC isn't that much better.

[drowe67]

Just thinking about requirements:

1. How many bits (bytes) would you like in a payload?
2. How often do we need an update? (e.g. once every 10s, once an over)?
3. What PER is acceptable at a given SNR for AWGN and fading channels?

Also wondering if there are other ways to send the info that a few bits/frame - like a RSID type frame we inject at the start or end of an over, or periodically into the speech data stream.

[Tyrbiter]

Tried running the PSK reporter improvements and I get a crash after some amount of time. Sometimes nearly instant, sometimes takes a little while. Only happens with PSK reporting enabled in Options.

gdb backtrace attached.

gdb_output_freedv.txt

[tmiw]

@Tyrbiter, I checked in a change that might help. Give that a shot?

@drowe67, yeah, I think moving the bulk of this logic to codec2 would be a good idea. To answer your questions:

How many bits (bytes) would you like in a payload?

I think enough to hold about 95% of callsigns (+ ideally any prosigns) would be good. That seems to be about 7-8 bytes at the moment but could change.

How often do we need an update? (e.g. once every 10s, once an over)?

I'd say once per transmission is adequate. However, this also means that someone listening in might miss the report that happened just before changing frequency; I'm not sure how important getting that report would be.

What PER is acceptable at a given SNR for AWGN and fading channels?

Speaking in terms of SNR, I'd say few if any errors would be acceptable above 1-2 dB over the lowest possible SNR for a given mode (e.g. 0 dB for 700D).

[Tyrbiter]

I was listening to some stations using 700D and 700E on 80m earlier today, one in particular was rarely audible using freedv, analogue SSB was equally poor, occasional syllables could be heard, 700D was struggling for sync. That is the case where some well-protected callsign data would be really useful, knowing distance and direction about the station is important.

It was noticeable how much better 700E was under the fast-fading conditions, it seemed to be worth anything up to 3-4dB SNR. I wonder if the callsign data could be modulated differently to the normal mode used for the speech?

[Tyrbiter]

The code change has allowed freedv to keep running for quite a long period, seems good.

[tmiw]

Good to hear, @Tyrbiter!

Anyway, I'm working on moving the main logic for the text encoding to codec2: https://github.com/drowe67/codec2/pull/209

[Tyrbiter]

OK, good, will monitor progress there and test as necessary.

[tmiw]

This PR now requires https://github.com/drowe67/codec2/pull/209 to compile. Based on minimal testing, it seems to work well on a live AWGN channel (to a KiwiSDR a few miles/km away from me). Some testing here would be good, then maybe we can do a test build and send that out to a wider audience.

[drowe67]

Fine Business @tmiw - looking forward to seeing how it works in the wild 🙂

[tmiw]

@drowe67, are you able to access portaudio.com by any chance? It's been down for me since last night so I'm currently unable to do any Windows builds (as that builds static PortAudio).

[Tyrbiter]

Down for me too Mooner, a shame as I'm very impressed with your pskreporter changes.A question; do both ends of a contact need to be running the new code for this to work? Will it make any difference if pskreporter is disabled?-- Brian. G8SEZSent from my Galaxy -------- Original message --------From: Mooneer Salem ***@***.***> Date: 24/08/2021 19:09 (GMT+00:00) To: drowe67/freedv-gui ***@***.***> Cc: Brian ***@***.***>, Mention ***@***.***> Subject: Re: [drowe67/freedv-gui] PSK Reporter encoding/decoding improvements (#156) @drowe67, are you able to access portaudio.com by any chance? It's been down for me since last night so I'm currently unable to do any Windows builds (as that builds static PortAudio). —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.

[tmiw]

Yeah, I switched freedv-gui to the PA GitHub repository to keep from holding this PR up. Currently building some Windows builds so we'll see how that goes.

[tmiw]

Test builds: https://www.dropbox.com/sh/044azug3aj6zsnt/AAAh573m0tv-MGweRa0mt-1ba?dl=0

[drowe67]

@drowe67, are you able to access portaudio.com by any chance? It's been down for me since last night so I'm currently unable to do any Windows builds (as that builds static PortAudio).

Down for me too ..

[Tyrbiter]

Tried to build from the git branch with build_linux.sh method, it's falling over with the codec2 checkout missing things including reliable_text.*, freedv-gui can't find the relevant header file it seems.

[tmiw]

Tried to build from the git branch with build_linux.sh method, it's falling over with the codec2 checkout missing things including reliable_text.*, freedv-gui can't find the relevant header file it seems.

You'll need to edit line 12 of build_linux.sh to change the branch to "ms-reliable-text". It's kept at "master" here so we don't forget to change it back before merge :)

[Tyrbiter]

Ah, yes, a very good idea. I should have thought of that.

[Tyrbiter]

OK, fixed that problem, now I note that the Report Frequency box is now truncated to 'eport Frequenc' and it doesn't scale with the window size.

[Tyrbiter]

Fix for that is to change 60 to 100 in topFrame.cpp:444

Can't quite see how to align the KHz with the frequency entry box. Also, should that be kHz?

[tmiw]

Can't quite see how to align the KHz with the frequency entry box. Also, should that be kHz?

I figured KHz would be the easiest to understand on HF but MHz could be an option too.

BTW the text inside the text box should be right-aligned now.

[Tyrbiter]

That's very nice, your wxWidgets-fu is much better than mine :)

For the frequency units, I think kHz is the correct choice but on all of my radio displays it is shown with a lower case 'k'

[ghost]

In the application of the Radio Regulations, the ITU uses the following units:

kHz for frequencies up to 28 000 kHz inclusive
MHz for frequencies above 28 000 kHz up to 10 500 MHz inclusive
GHz for frequencies above 10 500 MHz.

[tmiw]

I updated the GUI to use 'k' instead of 'K' and also fixed an issue discovered in the Windows build. I'm generating new builds now and will email them out shortly.

EDIT: new builds: https://www.dropbox.com/sh/0dwlherxbxbdr04/AADjcYRQA-3rtiGz4qXmNdX4a?dl=0

[tmiw]

So far, so good:

[tmiw]

So yeah, it looks like this + the corresponding codec2 changes are working well. I think we can start reviewing both PRs and merging them.

[drowe67]

Looks great @tmiw 🙂 Pls feel free to press merge when you've tweaked those branches back to master.

[tmiw]

@drowe67, can #158 be merged in first? I merged that PR into this one at some point so that both features would be available for test builds. I'll work on switching things back to master in the meantime.