kpreid / shinysdr

Software-defined radio receiver application built on GNU Radio with a web-based UI and plugins. In development, usable but incomplete. Compatible with RTL-SDR.
https://shinysdr.switchb.org/
GNU General Public License v3.0
1.07k stars 115 forks source link

DC cancellation not shown when using explicit device #115

Closed Matioupi closed 6 years ago

Matioupi commented 6 years ago

Hi, i'm a new hackrf "explorer" and been building shinysdr yesterday on Ubuntu Mate 18.04. This is really a great piece of software ! Playing around with the setup, I have few questions/remarks :

When switching the config line between those 2 :

config.devices.add(u'hackrf-0', OsmoSDRDevice(''))

config.devices.add(u'hackrf-0', OsmoSDRDevice('hackrf=0',sample_rate=20e6))

  1. I have the DC cancellation check box showing only when not explicitly using hackrf=0 (or serial). I'm quite new to these, so maybe DC cancellation is not a feature of hackrf altough other tools (gqrx offers it and it seems it has some effect - not knowing if it's hardware of software activated) With shinysdr and jhackrf (even single device setup, it does not seems to have effect)

  2. The sample_rate switch does not seem to have effect either, even when resetting the json state.

I have also been giving a try to dual hackrf setup, to what extent should this kind of config be supported at the moment ? I can have the 2 devices showing in the drop menu, but seem that the web front end is getting a bit lost between both...

Best regards

kpreid commented 6 years ago

I have the DC cancellation check box showing only when not explicitly using hackrf=0 (or serial).

HackRF doesn't support DC cancellation, but the gr-osmosdr interface does not allow finding out whether DC cancellation is supported — or what the hardware actually is — so ShinySDR guesses based on the device string and can't guess if you use ''.

If you'd like this to work better, look into patching gr-osmosdr to have some way to report device capabilities, or even just a get_dc_offset_mode (which would show always off despite any settings otherwise).

The sample_rate switch does not seem to have effect either, even when resetting the json state.

That's unexpected. I'm busy right this minute so I'll have to dust off my HackRF One and see if anything recently broke later, but can you be more exact about the results? What rate do you get when you don't specify, and what do you do? The rate is not displayed directly in the UI but it corresponds to the span of the waterfall display. Screenshots would be great.

I have also been giving a try to dual hackrf setup, to what extent should this kind of config be supported at the moment ? I can have the 2 devices showing in the drop menu, but seem that the web front end is getting a bit lost between both...

Multiple devices should work just fine, but multiple HackRFs have been a problem in the past (with the driver, not with ShinySDR in particular). Unfortunately I don't have two to test with.

When you say "getting a bit lost", can you be more precise about your observations? Show exact steps and screenshots?

It's expected, though, that what shows in the waterfall is not necessarily the same device as a receiver is demodulating. They have separate selections on purpose so that you can listen to one while browsing another.

Matioupi commented 6 years ago

Thanks for your answer. So the actual correct behaviour when using hackrf is when the DC cancellation option is not shown.

As for sample rate, I've been trying a few of hackrf supported sample rates, but they do not get used at first launch, they always default to 6 MHz at first launch. However, they are correctly restored from the last run and settings done though the webui.

As for multiple devices, it seems to work pretty well actually. I don't know what I messed during first trials. I had the feeling the the radio config and receiver config may affect the wrong hackrf serial.

kpreid commented 6 years ago

However, they are correctly restored from the last run and settings done though the webui.

Could you explain exactly the steps you are doing? RF sample rates are not settable from the UI, so I don't know what this description means.

Oh! Is it possible that you're referring to the analog bandwidth control, which is in the UI and does not automatically follow the sample rate?

Matioupi commented 6 years ago

Oh, I see, this ui slider is the filter stage bandwidth and not the sampling rate... my bad... So many other tools just let the default "0" value for this parameter and let the driver choose the right one that I forgot it could be it.

kpreid commented 6 years ago

The analog bandwidth should be automatically set on first run but will then remember the previous setting — which is not great if you're changing the sample rate. I'll consider changing that. Thanks for the feedback.

In bd6c1b6bc99e879c83b551576cb9eb90dfd18f62 I've added a note to the manual about the using the empty device string with OsmoSDRDevice.

I think we've resolved everything but let me know if you have any more feedback!