search

greatscottgadgets / hackrf

low cost software radio platform
https://greatscottgadgets.com/hackrf/
GNU General Public License v2.0
6.53k stars 1.52k forks source link

baseband filter bandwidth sometimes not set correctly #193

Closed mossmann closed 7 years ago

mossmann commented 9 years ago

Software that doesn't call hackrf_set_baseband_filter_bandwidth() when setting the sample rate sometimes gives the user a very poor baseband filter selection. I'm thinking of fixing this by having the firmware always set a sensible filter bandwidth whenever the sample rate is changed. Software that wants to override that selection must then call hackrf_set_baseband_filter_bandwidth() after the sample rate is set, not before.

kpreid commented 9 years ago

FYI on precedent: gr-osmosdr already does this (or at least, the API is documented that way; individual device impls may vary). And it uses set_bandwidth(0) to denote “please auto-select for me again”.

natevw commented 9 years ago

Yes, I suspect this has been a cause of some long-time frustration for me with HackRF, using through GQRX. I had never put anything in its "Bandwidth" configuration as I hadn't considered what that was for or if the HackRF even supported it. So I have been plagued by a very "deaf" HackRF, which seems to be a common complaint, as well as much interference and noise problems.

Finally I discovered that for longer-band listening (with or without Ham It Up) it is veeery useful [i.e. ± necessary] to explicitly set a suitable bandwidth, at least to that of the sampling rate if not lower — this greatly reduces what I assume is distortion caused by strong signals outside of the sampling range but still overloading the receiver.

mossmann commented 7 years ago

Since we already had automatic filter selection in libhackrf but not in firmware, I implemented the fix in libhackrf. As far as I know, nobody uses HackRF without libhackrf except people who write custom firmware (e.g. PortaPack). Fixed in f388a3f.