Enable Direct Sampling

[chrisvwn]

I would like to use rtl_power_fftw for frequencies below 24MHz. This requires initializing the rtlsdr with direct sampling enabled. Is there a way to enable direct sampling with rtl-power-fftw?

[KlemenBlokar]

At the moment, there is no such option, but if my quick search on the subject is correct, it should not be difficult to implement this option, as librtlsdr seems to support it.

But I also noticed that there are several different methods to achieve "direct sampling" on rtl dongles, so it would be helpful to know a bit more about how do you use direct sampling with other software, what settings do you set, ... I assume you have some sort of a hardware mod to make it work?

[chrisvwn]

Thanks for the quick response!

So with the V3 dongle it comes enabled in the hardware already.

rtl_power has the -D option

[-D direct_sampling_mode (default: 0, 1 = I, 2 = Q, 3 = I below threshold, 4 = Q below threshold)]

In gqrx it is enabled by setting the bash variable before starting the app

export LIBRTLSDR_OPT=dm=4:dm=30000000

Hope this helps

[KlemenBlokar]

Ok, thank you for info. I will try to help you with this, just have a bit of patience...
Quite a strategic move, opening a feature request on Friday, I have no excuses in my bag, just a busy weekend ahead ;-)

[chrisvwn]

Thank you! Lol. The timing was quite by mistake. Been searching for a few days now how to do this. Well, now I know the best time to open feature requests :P

[KlemenBlokar]

I have still some issues trying to test things here, so you will probably have to wait at least till Sunday to hear more from me, but I just got an idea for you to try in the meantime: if you install librtlsdr form https://github.com/librtlsdr/librtlsdr and use it with rtl-power-fftw, the same method of setting environment variable as gqrx uses, should work as well.

[KlemenBlokar]

I have now been able to try this method, and librtlsdr seems to correctly pick up the LIBRTLSDR_OPT env variable.
This now opens the question if separate command-line options for direct sampling mode is even necessary. I hesitate to add too many librtlsdr specific options if there is another way to get things done. This inevitably not just expands the capabilities, but also adds constraints you need to be careful about in the future.

[chrisvwn]

I confirm this works. Thank you very much. Makes sense to keep the specifics of each device separate.

[chrisvwn]

Hmm. I have just noticed that it does not seem to get below 12MHz. I am running

export RTLSDR_OPT=dm=2 && rtl_power_fftw -f 0:30M -n 10 -b 512 -c > test1.dat

and the output headers are:

# rtl-power-fftw output
# Acquisition start: 2023-06-03 19:22:16 UTC
# Acquisition end: 2023-06-03 19:22:16 UTC
#
# frequency [Hz] power spectral density [dB/Hz]
1.2e+07 -51.6105
1.200391e+07 -52.6116

Saving to binary the .met file shows

12000000 # startFreq (Hz)
29996093 # endFreq (Hz)
3906 # stepFreq (Hz)

[KlemenBlokar]

If I try the above command on my dongle, I get some output on stderr indicating problems:

Tuning to 1000000 Hz (try 1)
Tuning to 1000000 Hz (try 2)
Tuning to 1000000 Hz (try 3)
Unable to tune to 1000000. Dropping from frequency list.
Tuning to 3000000 Hz (try 1)
Tuning to 3000000 Hz (try 2)
Tuning to 3000000 Hz (try 3)
Unable to tune to 3000000. Dropping from frequency list.
Tuning to 5000000 Hz (try 1)
Tuning to 5000000 Hz (try 2)
Tuning to 5000000 Hz (try 3)
Unable to tune to 5000000. Dropping from frequency list.
Tuning to 7000000 Hz (try 1)
Tuning to 7000000 Hz (try 2)
Tuning to 7000000 Hz (try 3)
Unable to tune to 7000000. Dropping from frequency list.
Tuning to 9000000 Hz (try 1)
Tuning to 9000000 Hz (try 2)
Tuning to 9000000 Hz (try 3)
Unable to tune to 9000000. Dropping from frequency list.
Tuning to 11000000 Hz (try 1)
Device tuned to: 11000000 Hz

It would seem that librtlsdr cannot tune device to a lower frequency ...

As I have no experience in this direct tuning mode, I can only ask you more about your process:

• can you provide an example of a rtl_power command that successfully tunes to a lower frequency? (If you could then transform the same command to use LIBRTLSDR_OPT instead of the -D option it would be extra bonus)
• maybe for debugging purposes use rtl_power-fftw without frequency hopping and with just a single spectrum, just so that it is less happening at once ... by the way, in your command, I noticed you use RTLSDR_OPT instead of LIBRTLSDR_OPT?

[chrisvwn]

Oh oops! Yes, I did put in the wrong variable. Putting the correct variable I get similar output to yours.

rtl_power seems to pick up the LIBRTLSDR_OPT variable but returns -2. Not sure if that is good. I wasn't able to scan a single frequency (not sure how) so did a 1M range. It works but the 1 second minimum is a pain. Just a note: I built this rtl_power as part of librtlsdr from https://github.com/librtlsdr

rtl_power -f 1M:2M:100k
Number of frequency hops: 1
Dongle bandwidth: 1000000Hz
Downsampling by: 1x
Cropping by: 0.00%
Total FFT bins: 16
Logged FFT bins: 16
FFT bin size: 62500.00Hz
Buffer size: 16384 bytes (8.19ms)
Reporting every 10 seconds
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T/2 tuner
Tuner gain set to automatic.
Exact sample rate is: 1000000.026491 Hz
process options 'dm=2' from environment 'LIBRTLSDR_OPT'

rtl_power -f 1M:2M:100k -i 0.5
Number of frequency hops: 1
Dongle bandwidth: 1000000Hz
Downsampling by: 1x
Cropping by: 0.00%
Total FFT bins: 16
Logged FFT bins: 16
FFT bin size: 62500.00Hz
Buffer size: 16384 bytes (8.19ms)
Reporting every 1 seconds
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T/2 tuner
Tuner gain set to automatic.
Exact sample rate is: 1000000.026491 Hz
process options 'dm=2' from environment 'LIBRTLSDR_OPT'

rtlsdr_set_opt_string(): parsed direct sampling mode 2 == 2: use Q
  application of parsed option returned -2
2023-06-04, 14:31:42, 1000000, 2000000, 62500.00, 4608, -17.28, -15.69, -13.85, -13.22, -13.51, -13.85, -13.79, -13.59, -13.56, -13.56, -13.99, -14.07, -13.80, -13.53, -14.22, -15.88, -15.88
2023-06-04, 14:31:43, 1000000, 2000000, 62500.00, 8192, -17.06, -15.49, -13.46, -12.88, -13.10, -13.48, -13.59, -13.30, -13.34, -13.34, -13.64, -13.68, -13.49, -13.35, -13.92, -15.61, -15.61
2023-06-04, 14:31:44, 1000000, 2000000, 62500.00, 8704, -17.01, -15.39, -13.52, -12.83, -13.15, -13.50, -13.48, -13.15, -13.38, -13.38, -13.61, -13.59, -13.45, -13.33, -13.90, -15.65, -15.65
2023-06-04, 14:31:45, 1000000, 2000000, 62500.00, 8192, -16.95, -15.32, -13.47, -12.79, -13.05, -13.39, -13.44, -13.07, -13.27, -13.27, -13.50, -13.71, -13.38, -13.24, -13.89, -15.56, -15.56
2023-06-04, 14:31:46, 1000000, 2000000, 62500.00, 8192, -16.90, -15.36, -13.32, -12.82, -12.97, -13.37, -13.48, -13.27, -13.26, -13.26, -13.55, -13.67, -13.35, -13.23, -13.84, -15.53, -15.53
2023-06-04, 14:31:47, 1000000, 2000000, 62500.00, 8192, -17.11, -15.47, -13.40, -12.89, -13.12, -13.48, -13.50, -13.25, -13.21, -13.21, -13.56, -13.66, -13.44, -13.28, -13.79, -15.58, -15.58
2023-06-04, 14:31:48, 1000000, 2000000, 62500.00, 8192, -16.89, -15.18, -13.31, -12.75, -12.93, -13.32, -13.30, -13.13, -13.22, -13.22, -13.41, -13.59, -13.25, -13.11, -13.75, -15.51, -15.51
2023-06-04, 14:31:49, 1000000, 2000000, 62500.00, 8704, -17.05, -15.29, -13.47, -12.86, -13.03, -13.38, -13.48, -13.25, -13.34, -13.34, -13.56, -13.61, -13.39, -13.19, -13.80, -15.51, -15.51
2023-06-04, 14:31:50, 1000000, 2000000, 62500.00, 8192, -17.01, -15.50, -13.45, -12.83, -13.05, -13.49, -13.49, -13.20, -13.27, -13.27, -13.62, -13.66, -13.35, -13.26, -13.92, -15.51, -15.51
2023-06-04, 14:31:51, 1000000, 2000000, 62500.00, 8192, -16.95, -15.25, -13.37, -12.63, -12.87, -13.29, -13.21, -13.12, -13.17, -13.17, -13.39, -13.53, -13.27, -13.06, -13.68, -15.48, -15.48
^CSignal caught, finishing scan pass.

User cancel, exiting...

EDIT: I notice I was supposed to do the single frequency on rtl_power_fttw. Here's the output:

> export LIBRTLSDR_OPT=dm=2 && rtl_power_fftw -f 1M
Found Rafael Micro R820T/2 tuner
Available gains (in 1/10th of dB): 0, 9, 14, 27, 37, 77, 87, 125, 144, 157, 166, 197, 207, 229, 254, 280, 297, 328, 338, 364, 372, 386, 402, 421, 434, 439, 445, 480, 496
Selected nearest available gain: 372 (37.2 dB)
Exact sample rate is: 2000000.052982 Hz
Actual sample rate: 2000000 Hz
Number of bins: 512
Total number of (complex) samples to collect: 819200
Buffer length: 1638400
Number of averaged spectra: 1600
Estimated time of measurements: 0.4096 seconds
Tuning to 1000000 Hz (try 1)
Tuning to 1000000 Hz (try 2)
Tuning to 1000000 Hz (try 3)
Unable to tune to 1000000. Dropping from frequency list.

No valid frequencies left.

[KlemenBlokar]

I played around a bit and as things were getting weird I started to comprehend the whole problem a little bit more ...
This direct sampling thing (of course, I could have imagined this before ;-) ) completely bypasses the tuner in front of the rtl chip itself. The problem is, that to accommodate different tuners and their specifics, rtl_power_fftw diligently checks whether the tuning to specified frequency and setting of gain succeeded - but in the direct sampling mode this all fails (intentionally, of course) spectacularly. So if I disable all the checks in code, I can get some data out of the dongle (but as I have no hw mod, no direct antenna present in the system, all this is hot garbage). These checks are crucial for sensible operation of all other modes of the program, so the only sensible way is to only disable them for direct sampling.

So we are back to needing to implement this specific mode in-program, as we can not do it transparently (by only librtlsdr knowing of this option). But this is not by just by setting the direct mode value in librtlsdr, the whole operation of the program (which currently is built around setting of gain and frequency tuning) needs to change.

Also, if I understand this correctly, in direct sampling mode, the only relevant settings that have an effect on the measurement itself are: sampling rate, number of samples to be collected and number of bins in the output spectra. Am I correct in this observation?

[chrisvwn]

Great! Glad you've got a hold on the problem. Unfortunately, I am pretty new to the SDR world and I am out of my depth here. I'm not sure about the settings that affect measurements in direct mode (or in any other mode really).

[chrisvwn]

By the way would it help if we got you a v3 dongle?

[KlemenBlokar]

At the moment, I definitely cannot receive any meaningful direct sampling data with the dongle I have, so in this regard it could help, yes. But on the other hand, shipping to Europe is a bit tedious these days, and I would also need to have a good idea of some reference signal to capture so that it would be useful for testing.

I will first try to figure out what others are doing to enable direct sampling, and when I have something ready, I will publish a branch for you to try...

Also, another question: have you validated that the data you get from gqrx is comparable to what you get with rtl_power directly? What kind of signal are you trying to measure?

[chrisvwn]

I think it would be really helpful to have a hw modded dongle so you're not working completely in the dark. I'm not sure what signals you can work with in your area. If there are no signals maybe also getting a signal generator would help. A cheap one is the tinySA spectrum analyzer which has the ability to generate signals as well. On shipping to Europe it would probably be better to just send you $$ and you can purchase how/where works best for you.

I haven't validated the data at all tbh. I am currently trying to track some interference..

[chrisvwn]

Hi. I hope all is well. Any word on the way forward?