Avoid DC offset when selecting from frequency database

[bitglue]

The SoftRock SDR I use interfaces with the soundcard, which is AC coupled, so there's a hole right at 0 Hz. For SSB this isn't a problem, but for AM, CW, RTTY, and so on it means when I select a station, shinysdr will tune such that the station is right in the dead spot.

It would be nice if it could instead tune such that the dead spot is just below or just above the passband of the selected station.

[kpreid]

IRXDrivers can report the un-usability of some part of their output using the get_usable_bandwidth method. The missing pieces are:

• There is no way to specify for an AudioDevice what that is. (This is also relevant for e.g. a SSB soundcard input, which has only 2.something kHz regardless of sample rate.)
• The tuning logic (which currently lives in shinysdr.i.top.ContextForReceiver) does not know how to avoid a gap in the usable bandwidth.

[kpreid]

Okay, as of 32ba841 both of the above are implemented. AudioDevice still defaults to no offset, which is arguably the wrong default, but I didn't want to put an arbitrary bandwidth in. You can add the parameter usable_bandwidth=(low_hz, high_hz).

Let me know how it works for you.

[bitglue]

Seems to have some bugs. I set the usable_bandwidth=(1000, 96e3/2-60). Here's what happens when I select WWV from the frequency DB:

So far, so good. Now here's one of the amateur 60 meter channels:

Note how the channel is shifted the wrong way, so instead of avoiding the bottom 1kHz, it's put the DC offset 1kHz into the channel.

[kpreid]

I can reproduce this if the receiver was in LSB mode before tuning (i.e. the offset would actually be appropriate for the other mode). Which still doesn't explain the problem, because the mode change is done before the frequency change.

[bitglue]

I didn't use LSB -- I just clicked on the entries in the stock frequency database.

[kpreid]

I had the direction of the offset backwards, and no test that would have caught it. Should be all fixed in 4a0560518b90211d17f9db4bcb2e2e3c9b94b83e.

[bitglue]

Confirmed fix. Thanks!