Investigate using fsk_demod fork from auto_rx to allow negative frequencies

[darksidelemm]

Current fsk_demod within this repo does not seem to allow setting the frequency estimator to negative frequencies:
https://github.com/projecthorus/wenet/blob/master/src/fsk_demod.c#L215

        fsk = fsk_create_hbr(Fs,Rs,P,M,1200,400);
        if(fsk_lower> 0 && fsk_upper > fsk_lower){
            fsk_set_est_limits(fsk,fsk_lower,fsk_upper);
            fprintf(stderr,"Setting estimator limits to %d to %d Hz.\n",fsk_lower, fsk_upper);
        }

The fsk_demod fork from radiosonde_auto_rx has a different construct around this setting: https://github.com/projecthorus/radiosonde_auto_rx/blob/master/utils/fsk_demod.c#L215
And this version definitely allows for negative frequencies.

Suggest testing dropping in the version from auto_rx. This will allow for centring the wenet signal within the passband, rather than having it offset like it is now. This should allow dropping the oversampling rate, and hence the sample rate required for reception. (P=4 might be possible)

[ke5gdb]

I had a first pass at making this work over on my testing branch (https://github.com/ke5gdb/wenet/tree/testing). It's decoding images, but the SNR may be lower than expected.

[wenet-1]
data = wenet-1-pcm.local
# freq = 431298440
freq = 431500000
mode = linear
samprate = 460800
# samprate = 921600
# 90% of samprate / 2 -- best guess? 
low =  -207360
high = +207360
stereo = yes

And the FFT seems to be a little off-center, even though the fskstatsudp.py --freq argument was changed to be the center frequency.

More testing is needed, but it's a decent start.

[darksidelemm]

I think we need to test this with a sample recording. I made some for @TheSkorm when they were testing webwenet. These have the usual +0.25 Fs frequency offset, but can be shifted to have the wenet signal at the centre using csdr's shift_addition_cc

One problem I did notice is that the rtlsdr output from rtl-sdr (e.g 8-bit IQ) has a big DC spike, which will impact modem performance, as the frequency estimator will lock onto it. I don't have an easy solution to this one. It might be possible to include some kind of DC error compensation into the demod itself, or insert some other bit of software that does this, and probably also converts the IQ into signed 16-bit IQ or float, since part of the reason we have a DC offset is because of the limited sample resolution.