Problems receiving around 70kHz

[srcejon]

It seems there are some problems in SDRangel receiving around 60kHz - 80kHz.

Here's a snapshot from SDR# with the HF Discovery:

And what should be the equivalent spectrum in SDRangel with SR 192 and Dec 8:

There doesn't appear to be any signals. However, with SR 768 and Dec 32 (which gives the same span), I get:

Which matches the original spectrum.

Then I gave a SDRplay Duo a try in Uno:

Then in SDRangel with a decimation of 16:

But when setting the decimation to 32 to match the span in Uno:

There are lots of spikes. They also appear for decimation equal to 64. (Quite possibly a different problem).

[f4exb]

Re AirspyHF+ I have the dual port version and although I do not receive anything else than noise at this frequency this noise has a particular shape and I could not notice any difference between 192/8 and 768/32 kS/s. I have upgraded to FW R3.0.6 to get the extra sample rates. I cannot use R3.0.7 because 912 and 456 kS/s are correct but the other sample rates do not yield the right actual sample rate obviously (appears lower than the specified value). I prefer having the lower sample rates correct.

[srcejon]

I manually built the latest version of lib airspyhf and that seems to fix it.

I then tried changing set(AIRSPYHF_TAG "1.1.5") to set(AIRSPYHF_TAG "1.6.8") in external/CMakeList.txt, but it seems that currently doesn't build:

CMake Error at tools/src/CMakeLists.txt:28 (add_library): Cannot find source file:

../getopt/getopt.c

Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

CMake Error at tools/src/CMakeLists.txt:28 (add_library): No SOURCES given to target: libgetopt_static

[f4exb]

I have come across this. This is a MSVC only issue it has been fixed at the head of master of libairspyhf more specifically with this commit: https://github.com/airspy/airspyhf/commit/00ff03b2cb3f1649e063be7f32820afd14dcdd9b

[f4exb]

Regarding SDRPlay. I have the legacy RSP2 not the Duo but I have the same symptoms with no input or if input is very low. The spurs are at about ~80 dB so they get easily swamped by the signal. I think it has a lot to do with the fact that at this sample rate (2 MS/s) and this frequency (70 kHz) the DC falls into the input baseband fairly close to the center frequency of reception. This may cause artifacts. What I noticed also is that it depends on the sample rate. It is enough to move a little bit upwards, say 2.048 MS/s to get rid of the spurs. Of course one may also use low IF instead of Zero IF. At 450 kHz it takes a bandwidth of 5000 kHz to get some signal which I cannot really explain as I would expect that 1536 kHz is enough.

[srcejon]

Ok, I'll give some other settings a try.

However, I thought the only difference between the last two images was the amount of software decimation. I don't see why such big spurs would be visible at /32, but not at /16.

[f4exb]

I think this could be due to the number of decimation stages. I was not able to spot a defect in the code.

[srcejon]

The Airspy decimators seem to be fine up to /256, but they are using floating point decimators, whereas SDRplay is fixed point. I compared the two versions of the code and they seem the same other than types/shifting etc. I tried then using the floating point version in SDRplay - but that had the same result as the fixed point version.

Looking at this spectrum, which is with no input signal, it does appear to be something to do with what is at DC:

Adjusting the sample rate does seem to make a difference for me too. The spurs are there up to 2,013,984, but disappear at 2,013,985Sa/s. Fine up until 2,685,312, then they reappear at 2,685,313 and so on at various frequencies. Strange.