by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2EJvsmv004135
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)
for <osmocom-sdr(a)lists.osmocom.org>; Wed, 14 Mar 2018 15:57:55 -0400
To: osmocom-sdr(a)lists.osmocom.org
From: Theodric Young <theodric(a)mit.edu>
Subject: Meaning of rtl_fm output values
Message-ID: <d96cc71b-6d81-d786-ccd1-708c84eba0ff(a)mit.edu>
Date: Wed, 14 Mar 2018 15:57:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker:
H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUixCmqrHusbmWUwc1tLBb7Jl9hcWD0WHXa
I4AxissmJTUnsyy1SN8ugSvjx87tbAX7OSv2bJ/G3sC4lr2LkZNDQsBEYvqcdSxdjFwcQgKL
mSQWnj/DCuFcZZSY37eNDcKZxizRv/4YI0iLiICixOTf24FaODjYBNQlJv6zAQkLC2hIrL91
jwXE5hWwkvh96Q0TiM0ioCrxdtsWZhBbVCBGomXJB0aIGkGJkzOfgNUzC5hJzNv8kBnClpfY
/nYO8wRG3llIymYhKZuFpGwBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXRO93MwSvdSU0k2M
4FCS5N/BOKfB+xCjAAejEg+vgdrKKCHWxLLiytxDjJIcTEqivPunrIgS4kvKT6nMSCzOiC8q
zUktPsQowcGsJMJ7vxConDclsbIqtSgfJiXNwaIkzutuoh0lJJCeWJKanZpakFoEk5Xh4FCS
4D1cC9QoWJSanlqRlplTgpBm4uAEGc4DNFyuDmR4cUFibnFmOkT+FKMxx5+HL9uYOW68eN3G
LMSSl5+XKiXO+x5knABIaUZpHtw0UDq4yHbi3CtGcaDnhHkFQAbyAFMJ3LxXQKuYgFZlblsB
sqokESEl1cAYvC/tgHRlS0bd5jnmP/RrNsU/5J6oKV7p8ixCsX/y/3f1+69NufA6bvK/ZD3H
9ONOL50fx7tsVejkM1b7PVkywsPsRnRig7Vbm3R4CnNom/9rs3aJA/Oas4WZ3H7tupb8N8np
Qy/bcu5Nib3zr84VOPDxw2mnkitF08Nv2O89u0UxJ+n8wa9KLMUZiYZazEXFiQCH7MfT4gIA
AA==
X-BeenThere: osmocom-sdr(a)lists.osmocom.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion on Osmocom SDR projects \(OsmoSDR,
rtl-sdr\)" <osmocom-sdr.lists.osmocom.org>
List-Unsubscribe: <https://lists.osmocom.org/mailman/options/osmocom-sdr>,
<mailto:osmocom-sdr-request@lists.osmocom.org?subject=unsubscribe>
List-Archive: <http://lists.osmocom.org/pipermail/osmocom-sdr/>
List-Post: <mailto:osmocom-sdr@lists.osmocom.org>
List-Help: <mailto:osmocom-sdr-request@lists.osmocom.org?subject=help>
List-Subscribe: <https://lists.osmocom.org/mailman/listinfo/osmocom-sdr>,
<mailto:osmocom-sdr-request@lists.osmocom.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 19:57:59 -0000
Hi,
I'm new to SDR and I have a question about the data values that are
generated by the rtl_fm program.
I got rtl_fm running on my system (cygwin running on Windows 7). It is
sending a stream of 16-bit signed integer values to stdout which I can
redirect to a file or pipe to an audio playback system, such as sox. So
when I do this:
rtl_fm -f 88.1M -M wbfm -s 240k -r120k -g 30 | play -t raw -r 120k -b
16 -c 1 -e s -V1 -
I hear sweet, sweet music! Hurray!
But how do these 16-bit integers relate to the modulation level of the
carrier? I'm assuming that the values are directly proportional to the
instantaneous frequency deviation of the transmitted signal. Is that
right? If so, how do I determine that ratio? I'm hoping to use this to
build a device that shows total modulation (as a percentage of the
maximum modulation of +/- 75kHz) for an FM radio station.
Also, I'm assuming that the sample-rate of the output data stream needs
to be at least 120kHz because the baseband signal includes the stereo
pilot (19kHz), the stereo subcarrier (38kHz) and an RBDS subcarrier (57
kHz).
Any insight would be appreciated. Thanks in advance,
Theodric Young
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
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
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
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
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
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