- osmocom-sdr - lists.osmocom.org

RTL-SDR sample bit depth
by John Ackermann N8UR 05 Mar '18

05 Mar '18

Hi -- I'm trying to understand the sampling and decimation structure of the RTL-SDR dongle, to work out the effective number of bits after decimation. From Google and looking at the librtlsdr code (which is beyond my programming depth), I think I've figured out the following. I'd much appreciate verification/correction/amplification. 1. Actual ADC in the RTL-2832U is a single-bit sigma-delta running at some very high rate. 2. This is converted to 28.8 msps at 8 bit depth. 3. 28.8 msps is downsampled to the rate requested by the user and sent over the USB bus as 8 bit unsigned IQ pairs. Based on that, I *think*: a. Any processing gain in the downsample from 28.8 msps/8 bits within the chip is lost because the wire samples are limited to 8 bits. The output is 8 bits dynamic range regardless of the sample rate set. b. THEREFORE... for best dynamic range one wants to set the RTL-2832U to the highest sample rate that avoids lost samples, and do further decimation in the host processor, where the added bits aren't lost on the wire. I'd appreciate any verification or correction of that analysis. Thanks, John

2 8

Is this compatible for AIS Receiver ?
by Irsyad Irsyad 22 Feb '18

22 Feb '18

Sent from my iPhone

1 0

RTL-SDR : No supported tuner found
by Lidoro 13 Feb '18

13 Feb '18

Hello, I try to install rtl-sdr and gnuradio on my computer, on Linux mint 18.1 cinnamon 3.2.7 64 bits. the installation is going well but when I try to execute rtl_test : Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM No supported tuner found Enabled direct sampling mode, input 1 Supported gain values (1): 0.0 Sampling at 2048000 S/s. I try intallling with a script and with pybombs, i have the same issue. My dongle have RTL2832 chip and FC0012 tuner it works on windows, and it works when i use "linux live gnuradio dvd". And it works if I start on "linux live gnuradio dvd" and reboot after on linux mint. Thank you for your help Best Regards Lidoro

1 0

rtl-sdr with bias T
by Cinaed Simson 13 Feb '18

13 Feb '18

Hi - there appears to be problem with rtl-sdr with bias T and the RTL2832U OEM Rafael Micro R820T tuner. I get PLL errors when I try to calibrate it using kal - or when I use rtl_test. Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner Exact sample rate is: 270833.002142 Hz [R82XX] PLL not locked! Setting gain: 33.8 dB And I get the same error PLL when I run rtl_test. If I back out of the latest git version to v0.5.3 it works correctly - I can calibrate the dongle using kal and run rtl_test without any PLL errors. This is a known problem? -- Cinaed

3 4

osmosdr::device::find fails to find Rfspace NetSDR on MacOS Sierra
by dale ranta 07 Feb '18

07 Feb '18

When I updated to MacOS Sierra osmosdr::device::find stopped finding my NetSDR. This short program shows the problem - ************************************************ fprintf(stderr,"I am here\n"); osmosdr::devices_t devs = osmosdr::device::find(); for(int k=0;k<devs.size();++k){ std::cerr << " k " << k << " "<< devs[k].to_string() << std::endl; } fprintf(stderr,"I am done 2\n"); src = osmosdr::source::make("rfspace=192.168.1.7:50000"); fprintf(stderr,"I am done 3\n"); Output- I am here sdrplay=0,label='SDRplay RSP2 1707039B20' k 0 label='Realtek RTL2838UHIDIR SN: 00000001',rtl=0 k 1 label='SDRplay RSP2 1707039B20',sdrplay=0 k 2 hackrf,label='HackRF HackRF One' k 3 label='RFSPACE SDR-IQ Receiver',sdr-iq=/dev/ttyUSB0 k 4 label='RFSPACE SDR-IP Receiver',sdr-ip=127.0.0.1:50000 k 5 label='RFSPACE NetSDR Receiver',netsdr=127.0.0.1:50000 k 6 cloudiq=127.0.0.1:50000,label='RFSPACE Cloud-IQ Receiver' k 7 driver=sdrplay,label='SDRplay Dev0 RSP2 1707039B20',soapy=0 k 8 label='RTL-SDR Spectrum Server',rtl_tcp=localhost:1234 k 9 label='Red Pitaya Transceiver Server',redpitaya=192.168.1.100:1001 k 10 file=/path/to/your/file,freq=100e6,label='Complex Sampled (IQ) File',rate=1e6,repeat=true,throttle=true I am done 2 gr-osmosdr v0.1.4-136-g49fb5538 (0.1.5git) gnuradio 3.7.11 built-in source types: file fcd rtl rtl_tcp sdrplay hackrf bladerf rfspace airspy soapy redpitaya Using RFSPACE NetSDR SN NS000448 option --DRS BOOT 107 FW 112 HW 100 FPGA 1/7 I am done 3 *********************************************** The device::find routine locates the three other SDRs that I have plugged in, but not the netSDR. The source::make routine however finds it without problem. Looking at the search routines, they are similar to the old ones in CuteSDR. Early last year the CuteSDR routines were revised and now work correctly to find the RFspace NetSDR on Sierra and High Sierra. Dale

1 0

osmosdr::device::find fails to find Rfspace NetSDR on MacOS Sierra
by dale ranta 07 Feb '18

07 Feb '18

When I updated to MacOS Sierra osmosdr::device::find stopped finding my NetSDR. This short program shows the problem - ************************************************ fprintf(stderr,"I am here\n"); osmosdr::devices_t devs = osmosdr::device::find(); for(int k=0;k<devs.size();++k){ std::cerr << " k " << k << " "<< devs[k].to_string() << std::endl; } fprintf(stderr,"I am done 2\n"); src = osmosdr::source::make("rfspace=192.168.1.7:50000"); fprintf(stderr,"I am done 3\n"); Output- I am here sdrplay=0,label='SDRplay RSP2 1707039B20' k 0 label='Realtek RTL2838UHIDIR SN: 00000001',rtl=0 k 1 label='SDRplay RSP2 1707039B20',sdrplay=0 k 2 hackrf,label='HackRF HackRF One' k 3 label='RFSPACE SDR-IQ Receiver',sdr-iq=/dev/ttyUSB0 k 4 label='RFSPACE SDR-IP Receiver',sdr-ip=127.0.0.1:50000 k 5 label='RFSPACE NetSDR Receiver',netsdr=127.0.0.1:50000 k 6 cloudiq=127.0.0.1:50000,label='RFSPACE Cloud-IQ Receiver' k 7 driver=sdrplay,label='SDRplay Dev0 RSP2 1707039B20',soapy=0 k 8 label='RTL-SDR Spectrum Server',rtl_tcp=localhost:1234 k 9 label='Red Pitaya Transceiver Server',redpitaya=192.168.1.100:1001 k 10 file=/path/to/your/file,freq=100e6,label='Complex Sampled (IQ) File',rate=1e6,repeat=true,throttle=true I am done 2 gr-osmosdr v0.1.4-136-g49fb5538 (0.1.5git) gnuradio 3.7.11 built-in source types: file fcd rtl rtl_tcp sdrplay hackrf bladerf rfspace airspy soapy redpitaya Using RFSPACE NetSDR SN NS000448 option --DRS BOOT 107 FW 112 HW 100 FPGA 1/7 I am done 3 *********************************************** The device::find routine locates the three other SDRs that I have plugged in, but not the netSDR. The source::make routine however finds it without problem. Looking at the search routines, they are similar to the old ones in CuteSDR. Early last year the CuteSDR routines were revised and now work correctly to find the RFspace NetSDR on Sierra and High Sierra. Dale

1 0

[PATCH] RTL-SDR: Fix regression in FC00012 tuner startup (needs testing on FC2580)
by David Basden 05 Feb '18

05 Feb '18

This patch fixes a regression of rtl-sdr dongles with the FC00012 tuner. The code to switch on the FC00012 tuner by pulling it's ~RESET line low ended up with an off-by-one error in a refactor a long time ago, The FC00012 only continued to work by accident as a different bug in rtlsdr_set_gpio_output had a side-effect of pulling low the FC00012's ~RESET line When the rtl_set_gpio_output bug was fixed in ba64a7459a43 the side- effect also went away, leaving the FC00012 tuner in reset, and failing to be detected (or indeed work at all). This patch fixes the original off-by-one error. It's been tested on an FC00012 in a GTek T803 from both warm and cold starts, but needs testing on the FC2580 as both the FC00012 and FC2580 are brought out of reset by a GPIO off the RTL (at least in some designs). If the FC2580 actually uses a different pin, this code will also break. (I'm only going from vague memory that the FC2580 used the same pin.) --- src/librtlsdr.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index b369a5d..678fadd 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1565,11 +1565,11 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) } /* initialise GPIOs */ - rtlsdr_set_gpio_output(dev, 5); + rtlsdr_set_gpio_output(dev, 4); /* reset tuner before probing */ - rtlsdr_set_gpio_bit(dev, 5, 1); - rtlsdr_set_gpio_bit(dev, 5, 0); + rtlsdr_set_gpio_bit(dev, 4, 1); + rtlsdr_set_gpio_bit(dev, 4, 0); reg = rtlsdr_i2c_read_reg(dev, FC2580_I2C_ADDR, FC2580_CHECK_ADDR); if ((reg & 0x7f) == FC2580_CHECK_VAL) { @@ -1581,7 +1581,7 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) reg = rtlsdr_i2c_read_reg(dev, FC0012_I2C_ADDR, FC0012_CHECK_ADDR); if (reg == FC0012_CHECK_VAL) { fprintf(stderr, "Found Fitipower FC0012 tuner\n"); - rtlsdr_set_gpio_output(dev, 6); + rtlsdr_set_gpio_output(dev, 5); dev->tuner_type = RTLSDR_TUNER_FC0012; goto found; } -- 2.13.2

2 1

(no subject)
by David Basden 04 Feb '18

04 Feb '18

Hi, I recently found my dongle with the FC0012 again after having lost it for a couple of years, and noticed the tuner wasn't detecting on recent builds (by recent, it looks like at least a year and a half ago. :) ) There were a few other posts around that I saw with the same issue so I dug into the problem a bit. It looks it was a behavioural regression in commit ba64a7459a43652354990855176a7d8dad5b9d54 which was a actually bugfix in the GPIO direction setting code (see below for the commit comment). The bugfix patch references http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html which The reason this regressed the FC0012 tuner support is that in tuner detection code, before the probe for the FC00012 there are a few lines: /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 5); /* reset tuner before probing */ rtlsdr_set_gpio_bit(dev, 5, 1); rtlsdr_set_gpio_bit(dev, 5, 0); Looking at one of the early (ugly) patches I wrote trying to get the FC0012 working, This is the original code before cleaned up: https://gist.github.com/dbasden/2171926#file-rtlsdr-fc0012-diff-L123 : + if (tuner_type == TUNER_FC0012) { + dump_rtl_regs(); + DEBUGF("reset fs0012 tuner... "); + /* the fs0012 has it's RESET line hooked up to GPIO5 + * + * If we don't set GPIO5 to an output and leave it floating, + * the tuner never comes up (just stays in RESET state) + * + * GPIO6 controls the V/U band filter, so we should set that + * to an output too + */ + r = rtl_read_reg(SYSB, GPD, 1); + r &= (~(0x30)); rtl_write_reg(SYSB, GPO, r, 1); + r = rtl_read_reg(SYSB, GPOE, 1); + r |= 0x30; rtl_write_reg(SYSB, GPOE, r, 1); + + /* Do reset */ + rtl_set_gpio_bit(5,1); + rtl_set_gpio_bit(5,0); + dump_rtl_regs(); + } This code was eventually abstracted out to The bug in the code above described in http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html, linked to in the commit log of the ba64a7459a43652354990855176a7d8dad5b9d54 fixing the same bug. The code was cleaned up eventually abstracted into rtl_sdr_set_output(), which had the same typo as my original code: I wrote back the GPD register to GPO. This accidentally worked enough to fix the specific case I was wanting (to stop the RESET line of the FC0012 floating), but didn't actually write to the GPIO direction register. Looking at some of the forum posts, and checking myself, if the older code runs once, the tuner will be just fine until the dongle loses power. Then as GPIO5 is not set up into a state for the FC0012 to be happy, it will not come up again. This seems to have made the problem harder to debug (I don't know if I would have not known where to look if I had not already hit the problem when originally porting the driver) Digging through some more just now (I really don't have a great dev environment right now, and nothing to probe the hardware itself easily available), I checked the state of GPD, GPO and GPOE before the tuner probing, at it looks like the only real side effect from the code above being buggy would be to set bit 1<<4 low. calling rtl_set_gpio_bit(4,0) brought up the FC0012 tuner. Re-reading the old and new code, it looks like it's an off-by-one error in GPIO numbering: * The original code set GPOE on 0x30, which is (1<<4) | (1<<5). * These are referred to in the code above as "GPIO5" as the FC0012 RESET line and "GPIO6" as the V/U band filter control. * rtlsdr_set_gpio_output(5) and rtl_set_gpio_bit(5,0) are switching the V/U band filter, not the RESET line for the FC0012 Sorry, I don't have access to the datasheet for the RTL, so I'm not sure if bit 0 is GPIO0 or GPIO1. In any case, it looks like the solution is to just fix the off-by-one error in the FC0012 probe code. I'll post a patch. Thanks, David (commit for bugfix where fc0012 tuner regressed.) commit ba64a7459a43652354990855176a7d8dad5b9d54 Author: Lucas Teske <lucas(a)teske.net.br> Date: Wed Aug 17 20:31:33 2016 -0300 lib: fix direction bit in GPIO code source: http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html * Removed unnecessary comment of old code. Signed-off-by: Fabian P. Schmidt <kerel-fs(a)gmx.de> Signed-off-by: Steve Markgraf <steve(a)steve-m.de> :040000 040000 12c5ea73db04c45699d7befa2c5916ae074a1999 2d08166fe31338f5ff90186272b40bc6ed3254fa M src (HEAD) davidb@grey:~/Personal/sdr/rtl-sdr$

2 1

Fix for FC0012
by David Basden 04 Feb '18

04 Feb '18

Hi, I think my messages are getting filtered, but on the chance that someone is reading these as unmoderated, the fix for the FC0012 is to set GPIO 4 to 0. It could be that GPIO4 is the RST, or that it is something else entirely. Looking through the code, and the state of the registers on startup, one of the surprisingly few side effects of writing GPD to GPO would be to set GPIO4 to 0. Multiple bugs working together made the whole thing work. David

1 0

librtlsdr: FC0012 tuner regression
by David Basden 04 Feb '18

04 Feb '18

Hi, I recently found my dongle with the FC0012 again after having lost it for a couple of years, and noticed the tuner wasn't detecting on recent builds (by recent, it looks like at least a year and a half ago. :) ) There were a few other posts around that I saw with the same issue so I dug into the problem a bit. It looks it was a behavioural regression in commit ba64a7459a43652354990855176a7d8dad5b9d54 which was a actually bugfix in the GPIO direction setting code (see below for the commit comment). The bugfix patch references http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html which The reason this regressed the FC0012 tuner support is that in tuner detection code, before the probe for the FC00012 there are a few lines: /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 5); /* reset tuner before probing */ rtlsdr_set_gpio_bit(dev, 5, 1); rtlsdr_set_gpio_bit(dev, 5, 0); Looking at one of the early (ugly) patches I wrote trying to get the FC0012 working, This is the original code before cleaned up: https://gist.github.com/dbasden/2171926#file-rtlsdr-fc0012-diff-L123 : + if (tuner_type == TUNER_FC0012) { + dump_rtl_regs(); + DEBUGF("reset fs0012 tuner... "); + /* the fs0012 has it's RESET line hooked up to GPIO5 + * + * If we don't set GPIO5 to an output and leave it floating, + * the tuner never comes up (just stays in RESET state) + * + * GPIO6 controls the V/U band filter, so we should set that + * to an output too + */ + r = rtl_read_reg(SYSB, GPD, 1); + r &= (~(0x30)); rtl_write_reg(SYSB, GPO, r, 1); + r = rtl_read_reg(SYSB, GPOE, 1); + r |= 0x30; rtl_write_reg(SYSB, GPOE, r, 1); + + /* Do reset */ + rtl_set_gpio_bit(5,1); + rtl_set_gpio_bit(5,0); + dump_rtl_regs(); + } This code was eventually abstracted out to The bug in the code above described in http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html, linked to in the commit log of the ba64a7459a43652354990855176a7d8dad5b9d54 fixing the same bug. The code was cleaned up eventually abstracted into rtl_sdr_set_output(), which had the same typo as my original code: I wrote back the GPD register to GPO. This accidentally worked enough to fix the specific case I was wanting (to stop the RESET line of the FC0012 floating), but didn't actually write to the GPIO direction register. This is as far as I've gotten so far. I don't really have a good setup right now for debugging much further right this moment, but I at least know where the problem is. I don't have a copy of the RTL datasheet, or easy access to anything to measure the levels on that line, but assuming that the bugfix is the correct behaviour, and the buggy code is undefined behaviour, it's quite possible that I've managed to get the GPIO5 into a state just enough to get keep the FC0012 out of reset. Looking at some of the forum posts, and checking myself, if the older code runs once, the tuner will be just fine until the dongle loses power. Then as GPIO5 is not set up into a state for the FC0012 to be happy, it will not come up again. This seems to have made the problem harder to debug (I don't know if I would have not known where to look if I had not already hit the problem when originally porting the driver) Flipping the gpio bits the other direction is not working, so I'm going to have to look at it further, but I figured I should at least post to say where the bug was even if I haven't gotten a solution yet. If I'm missing anything obvious there, please let me know Thanks, David (commit for bugfix where fc0012 tuner regressed.) commit ba64a7459a43652354990855176a7d8dad5b9d54 Author: Lucas Teske <lucas(a)teske.net.br> Date: Wed Aug 17 20:31:33 2016 -0300 lib: fix direction bit in GPIO code source: http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html * Removed unnecessary comment of old code. Signed-off-by: Fabian P. Schmidt <kerel-fs(a)gmx.de> Signed-off-by: Steve Markgraf <steve(a)steve-m.de> :040000 040000 12c5ea73db04c45699d7befa2c5916ae074a1999 2d08166fe31338f5ff90186272b40bc6ed3254fa M src (HEAD) davidb@grey:~/Personal/sdr/rtl-sdr$

1 0