SigDigger not responding to SoapySDR argument for Direct Sampling (RTL-SDR)

[kittybwained]

If i try to use Direct Sampling on my RTL-SDR by passing the argument direct_samp=2 (Value: direct_samp, Key: 2) in the SoapySDR arguments, it just doesn't respond. It still receives in the regular mode, and doesn't allow me to go below 24 MHz.

[chris4git]

Same issue, SigDigger 0.3.0 Hope this will be fixed

[BatchDrake]

Hi,

Is this still happening with the latest development builds?

Cheers,

[kittybwained]

Yep, just compiled it, and same issue

[BatchDrake]

Hi again,

Just found the reason behind this. Turns out that "direct sampling" is not exactly a device argument, but a "device setting". This is because this odd distinction SoapySDR does on stuff that is used to initialize devices.

The thing is, I do not have any code / UI to modify these settings yet. Since these settings look like they are becoming the norm (and you people are not the first to ask me about something that can only be change by means of device settings) I believe I will prepare a quick workaround that will let you define device settings on startup like any other device argument (maybe by prefixing device arguments with a string, like setting: or something like that), until I come up with a better solution. Would this work for you?

PS: More details, in case you are interested: The right way of doing this is a bit more complicate than that. It involves not only providing a specific UI to define these settings but:

1. Updating the Device API so these settings are exposed somewhere
2. Providing a way to save these settings separately in the config file and the source profile object
3. Providing a way to retrieve and alter these settings through the RPC interface when using remote Analyzers (and therefore bumping the protocol version)
4. Design a UI (maybe in the Source panel) that provides easy access to these settings.

The changes are so extensive that they may well justify bumping the version to 0.4.0. We will see.

[kittybwained]

That workaround sounds great!

[BatchDrake]

Hi,

Just wanted to let you know that I've just pushed the changes. Now you can tweak individual device settings by prepending the string setting: to their name in the Device Tweaks. Download the latest AppImage here.

[kittybwained]

Thank you very much!

[kittybwained]

I've just actually tested this, and it's being really weird. With the appimage direct sampling is actually enabled, but i cannot tune below 23.999 MHz, and if building from source, it's the same, but direct sampling doesn't actually get enabled, because higher frequency stuff still comes through just fine.

[BatchDrake]

The 23.9999 limit comes from the SoapySDR module, and fortunately can be overriden. Just go to GUI tweaks, and click ignore hardware limits.

On the other hand, you can see whether the library has accepted the argument in the log window. Just start the capture and hit Ctrl+L. You should see a message somewhere indicating that direct sampling has been activated.

Also, IIRC, you should set that setting to either 1 or 2. Any other than that disables it.

[kittybwained]

If i use this option, do i have a chance of bricking my SDR, or will it just crash?

[kittybwained]

It seems to work, but it's a bit weird, for some reason i see two of the same MW AM station.

[BatchDrake]

Are you seeing those AM stations reflected around the central frequency (i.e. 0 Hz)? If this is the case, this is the expected behavior. When you perform direct sampling, you are bypassing the mixer and therefore sampling the voltage of the antenna directly. This means that I/Q sampling is disabled, and you get a stream of real-valued samples that are placed either in the I channel (direct_samp = 1) or the Q channel (direct_samp = 2).

No matter what channel you use for direct sampling, this will result in a signal that is real up to a global complex phase. The power spectrum for real signals is symmetric, and you should see the same power spectrum at both sides of 0 Hz.

[BatchDrake]

Forgot to answer earlier @atlas-devel, I do not think you are going to brick the RTL-SDR. 1 and 2 are to specify in what complex component real samples are placed. 0 means that the RTL-SDR is configured in normal (complex) sampling. Other values than those are either ignored by the SoapySDR module, or raise an exception (which would be reported in the log window).

Apart from the mirrored spectrum, is everything working as expected?

[kittybwained]

No, it was at a higher frequency, i believe the original was 540 khz and the duplicate was somewhere around 1 MHz, but other than that it works just fine

[BatchDrake]

I see. My bet is that maybe the second was an harmonic of the first, but if you experience any weird pitch change, I'd say is just the same AM station broadcasting in two different frequencies.

In any case, I am closing the issue. Feel free to reopen it if anything related to this comes up.