mode 2020 interoperability issue - very mysterious...

[cybork42]

During our sked yesterday on 40m we tried various CODECs, especially 2020, 2020B and 2020C.

My transmitting and receiving computer is a Lenovo Thinkpad T420, built with Intel processor type Intel i5-2520M @2.5GHz. There is nothing special with this laptop apart from its age. It runs with Win7, freeDV is FreeDV 1.8.3.1, 1.7 or 1.8.4-devel. My alternative Laptop is a Toshiba Satellite C70 which runs Win10 built with Intel processor i3-4005U @1.7 GHz. gain nothing special with this laptop. All different FreeDV SW versions here also.

Working modes 2020B and 2020C was no problem with the Thinkpad, however, no one could copy my 2020 transmission, which seemed odd. So I avoided the 2020 mode and took a note of this.

However, verifying the problem with both laptops exchanging files ("save modulator" and "play from radio") and swapping files between computers reveals that with only mode 2020 the Satellite fails to decode the Thinkpad, and the Thinkpad refuses to decode the Satellite recording. Each laptop decodes its own recording just fine, but crossing the recordings --> all decoding fails.

The decoding GUI display is special: both computers show a full maximum SNR while having a BER of 0.4..0.45, waterfalls show something, but no audio output (what you don't expect at >20% BER). Guessing I would point at the Thinkpad that something is going wrong with its FreeDV software (as this one failed also in the sked), trusting the Satellite works well (better). There seems no load issue with both computers, and the fact that each one decodes its own recording would not support this as a root cause, would it?

Adding up, using latest SW version 1.8.4 and comparing with the 1.8.3.1 behaviours don't change at all. Also crossing old-SW-recordings with new-SW-decoding and vice versa seems to show the same behaviour: each laptop is fine with its recording, no matter which FreeDV software version, but interoperability between both computers is nil.

What's happening here, what's wrong with

FreeDV mode 2020 on my Thinkpad?

2020_recordings.zip

[tmiw]

On my 2019 MacBook Pro, the Thinkpad files have no audio with squelch on (with possibly incorrectly high SNR) but the Satellite files decode to valid audio with no issues. I also tried to disable multiple decode just in case that was contributing but didn't see a difference.

Anyway, I tried to decode the files from both machines using the freedv_rx tool from Codec2 but am having issues getting it to report sync at all, even after resampling to 16K and exporting as raw audio. Perhaps @drowe67 can try and let us know?

[cybork42]

During the day I thought about this a little further. Is it possible that there is some incorrect implementation with a processor specific accelerator (math) function? I mean it's striking that the Thinkpad works fine with files encoded and decoded by itself, but won't decode other computers' files as much as other computers won't decode the Thinkpad coded files...?

Am 03.10.2022 um 21:43 schrieb Mooneer Salem:

On my 2019 MacBook Pro, the Thinkpad files have no audio with squelch on (with possibly incorrectly high SNR) but the Satellite files decode to valid audio with no issues. I also tried to disable multiple decode just in case that was contributing but didn't see a difference.

Anyway, I tried to decode the files from both machines using the freedv_rx tool from Codec2 but am having issues getting it to report sync at all, even after resampling to 16K and exporting as raw audio. Perhaps @drowe67 https://github.com/drowe67 can try and let us know?

— Reply to this email directly, view it on GitHub https://github.com/drowe67/freedv-gui/issues/282#issuecomment-1265946129, or unsubscribe https://github.com/notifications/unsubscribe-auth/APY6YIU2VZDH2KN6ZWAEZ2DWBMZOFANCNFSM6AAAAAAQ3XKZII. You are receiving this because you authored the thread.Message ID: @.***>

[tmiw]

During the day I thought about this a little further. Is it possible that there is some incorrect implementation with a processor specific accelerator (math) function? I mean it's striking that the Thinkpad works fine with files encoded and decoded by itself, but won't decode other computers' files as much as other computers won't decode the Thinkpad coded files...?

Both machines seem new enough that I doubt this would be the problem. Plus, the audio files sound similar enough at first listen inside Audacity (i.e. no obvious audio artifacts) that I would expect to be there if there was some sort of issue like what you described.

[drowe67]

I think the DPSK option is checked on the Thinkpad:

$ sox ~/Downloads/thinkpad_184_2020.wav -r 8000 -c 1 thinkpad_184_2020.wav
$ ./src/freedv_rx 2020 thinkpad_184_2020.wav /dev/null -v --dpsk
frame: 1  demod sync: 0  nin: 1440 demod snr: -5.00 dB  bit errors: 0 clock_offset: 0.000000
frame: 2  demod sync: 0  nin: 382 demod snr: -5.00 dB  bit errors: 0 clock_offset: 0.000000
frame: 3  demod sync: 1  nin: 1440 demod snr: 62.70 dB  bit errors: 0 clock_offset: 0.000000
frame: 4  demod sync: 1  nin: 1440 demod snr: 63.52 dB  bit errors: 0 clock_offset: -0.000694
frame: 5  demod sync: 1  nin: 1440 demod snr: 62.15 dB  bit errors: 0 clock_offset: -0.000347
frame: 6  demod sync: 1  nin: 1440 demod snr: 61.96 dB  bit errors: 0 clock_offset: -0.000231
frame: 7  demod sync: 1  nin: 1440 demod snr: 61.91 dB  bit errors: 0 clock_offset: -0.000174
frame: 8  demod sync: 1  nin: 1440 demod snr: 61.73 dB  bit errors: 0 clock_offset: -0.000139

[cybork42]

Verified: the Thinkpad encoded files decode well when the Satellite is configured with "high bandwidth" and "DPSK". However, if not configured woth "high bandwidth" the decoding is not perfect (artefacts and BER), it's only good when both are set inactive.

Still strange: files encoded on the Thinkpad e.g. in mode 2020B (with the same settings) are not affected by DPSK and BANDWITH setting when decoded on the Satellite. Why is that?

[tmiw]

Still strange: files encoded on the Thinkpad e.g. in mode 2020B (with the same settings) are not affected by DPSK and BANDWITH setting when decoded on the Satellite. Why is that?

Looks like the codec2 library as it is currently ignores those for 2020B:

void freedv_set_dpsk(struct freedv *f, int val) {
    if (FDV_MODE_ACTIVE( FREEDV_MODE_700D, f->mode) || FDV_MODE_ACTIVE( FREEDV_MODE_2020, f->mode)) {
        ofdm_set_dpsk(f->ofdm, val);
    }
}

void freedv_set_phase_est_bandwidth_mode(struct freedv *f, int val) {
    if (FDV_MODE_ACTIVE( FREEDV_MODE_700D, f->mode) || FDV_MODE_ACTIVE( FREEDV_MODE_2020, f->mode)) {
        ofdm_set_phase_est_bandwidth_mode(f->ofdm, val);
    }
}

I'm not fully sure if 2020B/C should actually support either of those options but if they're supposed to, it should be a relatively easy fix.

[drowe67]

The code is correct - those options are 2020A only. It was an early attempt to handle fast fading. The DPSK and high bandwidth options for 2020A may not be required any more, as 2020B/C handles fast fading by design.

[tmiw]

The code is correct - those options are 2020A only. It was an early attempt to handle fast fading. The DPSK and high bandwidth options for 2020A may not be required any more, as 2020B/C handles fast fading by design.

Should those options be removed from the UI in freedv-gui? Or at the very least, restricted so they only apply for 700D?

[drowe67]

Sure, they could be removed from the UI in freedv-gui, and the Manual Section 9.2.2. It's the same story for 700E - it handles fast fading channels better than 700D + these options

[cybork42]

One more thing to note here: I didnt touch those settings during the last six months. They surcived all SW Updates. Probably the settings files should also be purged with Respekt to both values?

Am 4. Oktober 2022 22:23:42 MESZ schrieb drowe67 @.***>:

Sure, they could be removed from the UI in freedv-gui, and the Manual Section 9.2.2. It's the same story for 700E - it handles fast fading channels better than 700D + these options

-- Reply to this email directly or view it on GitHub: https://github.com/drowe67/freedv-gui/issues/282#issuecomment-1267534709 You are receiving this because you authored the thread.

Message ID: @.***>

[tmiw]

I went ahead and removed those two options and there don't seem to be any issues at first glance. The changes are in #283 if you'd like to give them a shot.

[cybork42]

explained well and solved.