Mark J. Fine

Most shortwave is Chinese these days... What I've noticed is that the audio itself isn't necessarily the problem with TDF. It's phase noise within the transmission. Can't seem to get a good enough SNR to get the MSC layer to decode properly despite exceptionally strong signals. It's possible that it's intentional (as you say), but I'm not sure why they would do that for only some of the broadcasts. Either way, I'm pretty sure that since the extra MM overhead is 66% of the MSC layer, it's not helping...

Most shortwave is Chinese these days... What I've noticed is that the audio itself isn't necessarily the problem with TDF. It's phase noise within the transmission. Can't seem to get a good enough SNR to get the MSC layer to decode properly despite exceptionally strong signals. It's possible that it's intentional (as you say), but I'm not sure why they would do that for only some of the broadcasts. Either way, I'm pretty sure that since the extra MM overhead is 66% of the MSC layer, it's not helping...

Hmm. Have noticed that the MM wasn't working properly in the TDF broadcasts, but never really looked at why or what was the status messages. Next time I get a good TDF signal (which is rare anymore in the US) I'll look a little deeper to see what's going on. It could very well be that either there's something new that's not being handled correctly, or there are broadcasters that are implementing something non-standard.

Removed QT references to webenginewidgets in .pro file

Merge branch 'test_gpredict' of https://github.com/markjfine/Hamlib into test_gpredict

Initial rework of sdr#/gpredict backend

Apparently uint64_t is handled differently on CISC and RISC systems. CISC requires the %lu format while RISC requires %llu. Solved the cross-platform ping-pong game by using %llu and type casting rmode_t and setting_t values as (long long unsigned int).

Fix old_vfo could be uninitialized warnings that are generated in minGW by initializing to RIG_VFO_A in get/set_chan().