Hey all:
Just a heads up, the certificate on the mailing list site has expired.
It expired two days ago, 12 June 2018.
Since it's signed by Lets Encrypt, shouldn't be too hard to update,
but you might want to do that ;)
Cheers,
--
Tom Swartz
Hello. I have some problems.I want to create a GSM network for my final
diploma project for University.I'm using USRP2 and I haven't find any
specific configuration files for this type of USRP.Do you have any
configuration files for USRP2? I'm running Kali Linux (amd64). I've
attached the config files that I've used from osmocom.org and some
printscreens.Sorry for my English.I'm looking forward for your
response.Thank you!
Hi all,
as some of you know Osmo-fl2k has a bothersome software issue that sometimes just stop transmitting without any good reason. in my case when I was transmitting WBFM sometimes it may stop transmitting. I mean the RF output will be interrupted completely without any error or warnings on screen and I should re-execute the commands to transmit again and this goes on and on. sometimes it may work without any issues for like 10 min and sometimes it may fail after just a few seconds. the problem also appeared in executing <fl2k_file> when I was transmitting DVB-T.
you can watch this video to gain a better understanding: https://www.youtube.com/watch?v=G0tjzPHFFA8
I have no idea if this issue been discussed earlier in the mailing list or not, anyway I didn't find anything useful by Googling.your comments and suggestions are greatly appreciated.
Regards,Sajjad
Hello,
I have a question about osmo-fl2k,
the generated binary file using the fl2k grc transmission flow graphs, contains the carrier frequency,
the fl2k_file stream the file to the device, so how the device can transmit these data in that frequency.
I mean how it recognize the frequency to transmit on.
Thank you.
Hi,
I've compiled osmo-fl2k with libusb-1.0.22-1 and this happens when I
tried to start fl2k_test:
feanor@silmaril ~> fl2k_test -s 162e6
Using 6 zero-copy buffers
libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12
Failed to allocate zero-copy buffer for transfer 4
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
real sample rate: 15372775 current PPM: -905106 cumulative PPM: -905106
then when I try to connect red and ground output to oscilloscope,
there is no output at all, even if I use fl2k_fm
Hi!
Today I've added rtl-sdr and osmo-fl2k to the automatic nightly package
builds at https://build.opensuse.org/project/monitor/network:osmocom:nightly
I also wanted to add them to the "latest" feeds (which build that latest
tagged version, as opposed to a nightly snapshot). However, for this to
work we need tagged versions that include the "debian" sub-directory
in the respective projects.
I hence temporarily disabled the "latest" builds until that happens,
see
https://build.opensuse.org/project/monitor/network:osmocom:nightly
Please let me know once new versions are tagged and
the above patch can be reverted. Thanks!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi everyone,
There has been a considerable discussion in the past couple of days about a
device called the Tzumi MagicTV. This is an Atheros-chipset OpenWRT device
connected to an RTL2832P, which seems to be used as a bridge/DAC for a
MaxLinear MxL608 tuner and a Panasonic ATSC demodulator.
The device is sold at Wal-Mart stores for $13, and is intended to allow the
user to view OTA broadcasts using a WiFi connection to the device, which
functions as an access point by default. There also seems to be an Eardatek
Tevemo device which is similar.
>From tear-down inspection as well as poking around the file system, some
uses have concluded that the device could be used as a software defined
radio with some software modifications (for example replacing the default
ATSC server software with rtl_tcp). However, librtlsdr does not currently
support the MxL608 tuner, and right now rtl_tcp (when placed on the openWRT
device) defaults to direct sampling mode.
There is a general sense in these discussion groups that MaxLinear's source
code could be ported to work with librtlsdr, but someone would have to make
that happen.
I am sending this message to the group, to reach out with a humble
request/suggest/beg that someone(s) please help us out by doing the
following:
1. Sanity-check the claims being made; if what is being discussed is not
workable, it would be of benefit for us to be told so.
2. Start work on forking librtlsdr and porting the MxL608 driver over (if
possible/practical);
3. Coordinate with the broader community to beta-test and refine // help
spread the knowledge so that the community can maintain/improve the fork
and perhaps submit a pull-request in the future.
Please let me know if I can help you help us by procuring/shipping a couple
of hardware units for development purposes.
I understand that asking people to do volunteer work can be
presumptuous/annoying. All I can say in my defense is that there are
already at least a few dozen people who would be really happy and
appreciative if this came to fruition, and "one does not get what one does
not ask for."
Moreover, adding MxL608 support to librtlsdr might help broaden the hobby
to include a whole bunch of other devices; MaxLinear tuners seem to be used
a lot with set-top gear.
Thank you very much,
James "Gwen" Dallas, AD5NL
Reddit user: texasyojimbo
Phone: 1-713-254-4175
P.S. here are the existing discussion threads for reference:
1. RTL-SDR.com blog:
https://www.rtl-sdr.com/tzumi-magictv-wifi-tv-tuner-device-contains-an-rtl-…
2. Reddit RTLSDR group:
https://www.reddit.com/r/RTLSDR/comments/8mlbps/tzumi_magictv_is_an_openwrt…
P.P.S here is a link to the existing MxL608 driver source code:
https://github.com/avlogic/AVL6862/tree/master/2.10.7/tuner/MxL608
and data sheet: https://datasheet.lcsc.com/szlcsc/MXL608-AG-T_C141783.pdf
Hi,
I am packaging some of your software for Arch Linux. For that, I need
to fetch the source tree I want to build. The problem is that there's
no need to fetch the whole git repository to build a specific tag. As a
solution, I propose that compressed files from every tag would be
available, like GitHub releases.
Please let me know if this is something you would consider doing.
Thanks,
Filipe Laíns (FFY00)
https://github.com/FFY00
3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2
Sent via Migadu.com, world's easiest email hosting
I am having this problem with all of my dongles (from multiple sources) and was wondering if it could be some sort of problem with it not getting closed properly,
In all cases the chip that gets hot is the actual SDR not the tuner. But I don’t understand why it is heating up when the dongle is not in use and is just plugged in.
Or is this just some weird problem with the dongles.
Sincerely,
William
Hello,
would like to know, what is the average time that an RTL-SDR (R820T2) can
run nonstop without affecting its internals
The use case, is to sniff GSM packets
noting that sniffing will take several intervals during the day, and the
experiment should only run for 1 day , thus what could be the appropriate
interval
thanks
Is there any reason for this to be turned on during normal operation of the
RTL-SDR?
Turning it off seems to reduce current usage by 10 to 20 mA. To turn it off
set reg 0x05 bit 7 to 1. Seems to turned be on by default. Haven't seen any
effects from turning it off.
Hi gr-osmosdr maintainer,
can I respectfully ask if the several patches to the gr-osmosdr library,
sent in the past months on this list, will have a chance to be considered
in the near future?
Many thanks in advance
*am*
--
Andrea Montefusco IW0HDV
------------------------------------------
As my old boss, an Apollo veteran, would often remind us “It’s good to be
smart, but it’s better to be lucky.”
Wayne Hale, Space Shuttle Flight Director
This code stayed unchanged for many years, but for some reason
rtl_adsb started hanging upon exit:
*b66116a5164b69281eacc42ae950;
^CSignal caught, exiting!
<------ hangs here forever
Examining it with gdb reveals that the demod thread waits
peacefully on the condition variable, which we're trying to
destroy. Either the signals killed all threads before, or
condition variables were possible to destroy while other
threads still waited on them.
The easiest fix appears to be just cancel the demod thread
and wait for it to exit before proceeding for the door.
---
src/rtl_adsb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c
index 07fdd2a..9087de4 100644
--- a/src/rtl_adsb.c
+++ b/src/rtl_adsb.c
@@ -492,6 +492,8 @@ int main(int argc, char **argv)
else {
fprintf(stderr, "\nLibrary error %d, exiting...\n", r);}
rtlsdr_cancel_async(dev);
+ pthread_cancel(demod_thread);
+ pthread_join(demod_thread, NULL);
pthread_cond_destroy(&ready);
pthread_mutex_destroy(&ready_m);
$ fl2k_file
fl2k_file, a sample player for FL2K VGA dongles
Usage:
[-d device_index (default: 0)]
[-r repeat file (default: 1)]
[-s samplerate (default: 100 MS/s)]
filename (use '-' to read from stdin)
$ fl2k_file -s 8192000 -
Failed to open -
I'm perfectly willing to pitch in and fix this. How do you prefer to
receive contributions?
I received following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and installed but despite this still unable to compile osmo-trx, any one can help to resolve the issue!
configure: error: Package requirements (libosmocore >= 0.11.0) were not met:
Requested ‘libosmocore >= 0.11.0’ but version of Osmocom Core Library is UNKNOWN
Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.”
I have already build following components on Rasbian from source successfully
LimeSuite SoapySDR SoapyUHD libosmocore-0.11.0/ libosmocore-0.96.0
Regards
Babar
Hi everybody,
Thank you for developing osmo-fl2k.
Just wanted to report some relevant code issues/warnings I've found in osmo-fl2k's codebase: hope you'll find it useful.
All the issues reported below are based upon the source code as seen in commit 16b102efcdae6c33b1761e4f2da8c507eed03bb4 (osmo-fl2k's git repo current HEAD).
- libosmo-fl2k.c:213 Implicit cast of expression '(pll_clock * mult) / (uint32_t) div' from 'uint32_t' type to 'double' type (perform explicit cast to avoid the loss of the fractional part. Is it intentional?).
- libosmo-fl2k.c:216 Implicit cast of expression '(uint32_t) offset * frac' from 'uint32_t' type to 'double' type (perform explicit cast to avoid integer overflow).
- libosmo-fl2k.c:250 Absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value (use function 'fabs' instead).
- libosmo-fl2k.c:252 Absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value (use function 'fabs' instead).
- libosmo-fl2k.c:262 Absolute value function 'fabsf' given an argument of type 'double' but has parameter of type 'float' which may cause truncation of value (use function 'fabs' instead).
- libosmo-fl2k.c:263 Incorrect 'fprintf' format for argument 'target_freq' (use '%lu' format specifier and add explicit cast like: '(unsigned long)target_freq' or use 'PRIu32' macro from 'inttypes.h').
- libosmo-fl2k.c:458 Useless if (expression 'dev' is always true).
- libosmo-fl2k.c:577 There might be dereferencing of a potential null pointer 'dev->xfer' (malloc call at may return NULL: line 574).
- libosmo-fl2k.c:580 A potential null pointer is given to 'memset' function (malloc call may return NULL: line 579).
- libosmo-fl2k.c:583 A potential null pointer is given to 'memset' function (malloc call may return NULL: line 582).
- libosmo-fl2k.c:586 Incorrect 'fprintf' format for argument 'dev->xfer_buf_num' (use '%lu' format specifier and add explicit cast like: '(unsigned long)dev->xfer_buf_num' or use 'PRIu32' macro from 'inttypes.h').
- libosmo-fl2k.c:593 Incorrect 'fprintf' format for argument 'i' (use '%u' format specifier).
- libosmo-fl2k.c:650 Incorrect 'fprintf' format for argument 'i' (use '%u' format specifier).
- libosmo-fl2k.c:856 Incorrect 'fprintf' format for argument 'dev->underflow_cnt - underflows' (use '%lu' format specifier and add explicit cast like: '(unsigned long)(dev->underflow_cnt - underflows)' or use 'PRIu32' macro from 'inttypes.h').
- fl2k_file.c:98 Incorrect 'fprintf' format for argument 'repeat_cnt' (use '%lu' format specifier and add explicit cast like: '(unsigned long)repeat_cnt' or use 'PRIu32' macro from 'inttypes.h').
- fl2k_file.c:169 The 'r' variable is assigned values twice successively (missing return code check after first assignment?).
- fl2k_fm.c:570 The 'r' variable is assigned values twice successively (missing return code check after first assignment?).
- fl2k_tcp.c:193 The 'r' variable is assigned values twice successively (missing return code check after first assignment?).
- fl2k_test.c:259 Incorrect 'fprintf' format for argument 'dev_index' (use '%lu' format specifier and add explicit cast like: '(unsigned long)dev_index' or use 'PRIu32' macro from 'inttypes.h').
- fl2k_test.c:278 Integer overflow (attempt to store value 255 in a char type variable (which may be signed: range [-128, 127]): redefine 'buffer' variable as 'signed char' type to fix the issue).
- fl2k_test.c:284 The 'r' variable is assigned values twice successively (missing return code check after first assignment?).
- fl2k_test.c:301 Useless if (expression 'do_exit' is always true).
Regards,
SDR_is_cool
Hi everyone,
Do osmo-sdr <https://git.osmocom.org/osmo-sdr> or gr-osmosdr
<https://git.osmocom.org/gr-osmosdr> place blacklist files in
/etc/modprobe.d/ when they are installed?
I am asking this because there I have found the files
"hackrf-blacklist.conf" and "rtl-sdr-blacklist.conf" and I would like to
know where they came from.
Thank you.
Regards,
Álvaro
Hi all,
I am new to Software Defined Radio and I was wondering if it was possible
to broadcast a Digital ATSC TV channel using Osmo-fl2k (
https://osmocom.org/projects/osmo-fl2k/wiki/Osmo-fl2k).
I am in need of a device that can do this for my work and didn't want to
pay $1000+ for the equipment designed for this purpose.
Thank you for your help,
Chase Johnson
--
Sent from an Apple Newton MessagePad 100
https://goo.gl/v82H1C
Greetings,
In Steve Markgraf's slide presentation
(http://people.osmocom.org/steve-m/fl2k_slides/osmo-fl2k.html),
do slides 16 and 17 imply that some FL2K devices have LDO regulators
while other
using switching regulators? Obviously, the FL2K devices that have LDO
regulators
are preferred, due to fewer spurious RF emissions. How can one
determine which
FL2K devices have LDOs? Can an FL2K device be reworked to use LDO
regulators?
Thanks,
Mac
Hi
I would like to use the fl2k_tcp utility to transmit remotely but are not
sure what is tje format of stream to send to this utility.
1) Do I send an IQ stream or audio stream?
2) is there some example to generate stream for this and format explenation?
3) how do you define carrier freq?
73 ' Anton
Hello,
First thank you for this FL2000 hack, it's very nice!
I tried to make an FM & AM transmitter with it and GNU Radio. It's working fine if I save to a file and then use fl2k_file to transmit the data but with the tcp server and fl2k_tcp, my computer is not fast enough to sample in real time at 100 MHz. I also tried with a 35 Mhz sampling rate but it's not real time. Here is the diagram I used.
Is there a possibility to avoid sampling at a very fast rate if the data bandwidth is small to do the baseband to carrier shift?
[cid:0115622e-668a-46ae-8e49-07a3a7aba391]
Thank you,
Best regards,
Jean-Paul
Hi all,
I just wanted to let you know I am working on adding interleaved IQ
support (to red and green DAC). Haven't had time to test it yet.
http://git.mpb.li/git/osmo-fl2k/commit/?id=db70e939c8b1e8ab19d1baef5c98c7ab…
Is anybody else working on this?
For contributions, do you prefer patch files?
Best regards and thanks for this development!
mpb
Hi everyone, hi especially Steve,
I'm in the process of making a distro package for fl2k for sharing and
inclusion in my bootable Fedora sticks; as a version, I'd use 0.0.0.1-
githash, but I think that's an understatement, because it looks to me
like fl2k was officially released at OsmoCon.
Now, I'm not the author, and I'd hate to be the one to define today's
git head as version 1, or something like that, but I honestly think
that it's worth encouraging tagging of a release (as it would make it
easy to refer to things like "hey, that used to work with 1.0.2.1, but
broke in 1.0.3.1", or include it with other software etc).
Would it be very annoying to kindly request that you add a version tag,
and to even brazenly recommend semver.org as versioning scheme?
Thanks, and I'm having great fun with this,
Marcus
Hi folks,
I tried building the code on Mac, and it threw a bag full of errors.
Does anyone have a working mechanism/script to build on Mac, if not, what was the reference platform? What was this built on?
I.
Hi,
I'm (ab)using gr-fosphor for audio spectrum visualization by using
float to complex because it is the most colorful spectrum analyzer
that I have. Unfortunately, for some reason gr-fosphor is choppy at 48
kHz, while it is smooth at rtl-sdr output, about 2 MSPS or so. Is
there any FFT configuration setting like other spectrum analyzer to
change how many FFT bins and the framerate?
Hi Joshua,
have you tried your experiment with a powered USB hub? I've found a number
of times that a powered hub can solve mystery problems with USB devices.
Cheers!
-Justin N2TOH
---------- Forwarded message ----------
From: DC7IA <mailinglists(a)dc7ia.eu>
To: osmocom-sdr(a)lists.osmocom.org
Cc:
Bcc:
Date: Thu, 26 Apr 2018 19:56:01 +0200
Subject: [osmo-fl2k] can't receive anything
Hi there,
I've set up osmo-fl2k yesterday and since then I'm trying to get WBFM or
GSM working, but I cannot receive anything.
Software does not give me any errors, so I don't know where to look for the
problem.
Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad T400,
could that make trouble as it is a USB 3.0 device?
--
*73 Joshua Hoffmann DC7IA | KK4RVI *
stellv. AJW-Referent im Distrikt O
(Süd-Westfalen) AJW-Seite des Distriktes
<http://www.darc.de/distrikte/o/referate/ajw/>
Diese E-Mailadresse ist ausschließlich für Mailinglisten E-Mails. Normale
E-Mails an DC7IA(a)DARC.de senden, da sie andernfalls nicht rechtzeitig
gelesen werden.
--
--Evil people do evil things, how is irrelevant.
Hi there,
I've set up osmo-fl2k yesterday and since then I'm trying to get WBFM or
GSM working, but I cannot receive anything.
Software does not give me any errors, so I don't know where to look for
the problem.
Maybe I should note that I'm only able to use USB 2.0 on my Thinkpad
T400, could that make trouble as it is a USB 3.0 device?
--
*73 Joshua Hoffmann DC7IA | KK4RVI *
stellv. AJW-Referent im Distrikt O
(Süd-Westfalen) AJW-Seite des Distriktes
<http://www.darc.de/distrikte/o/referate/ajw/>
Diese E-Mailadresse ist ausschließlich für Mailinglisten E-Mails.
Normale E-Mails an DC7IA(a)DARC.de senden, da sie andernfalls nicht
rechtzeitig gelesen werden.
can the USB to VGA adapter output quadrature I and Q pairs via the red and
blue channels? with maybe using green as a configurable local oscillator.
-Justin
--
--Evil people do evil things, how is irrelevant.
I am trying to understand the layout of the RGB buffers sent to the fl2k
over USB. From lines 755-820 in libosmo-fl2k.c I can see the RGB buffers
are "serialized" in this order:
g1,r1,b2,g2,b0,g0,r0,b1,b4,g4,r4,b5,r2,b3,g3,r3,r6,b7,g7,r7,g5,r5,b6,g6
(where r0 is the red component of first pixel, b3 is the blue component of
fourth pixel, etc)
What is this layout? Why does the chip expect the pixels to be sent in this
order?
Hi,
At first I reported this bug at Gqrx mailing list:
https://groups.google.com/forum/#!topic/gqrx/pVea3JObMLw , then Csete
mentioned that Gqrx uses gr-osmosdr source, while I'm using gr-uhd
source. Then I tried it again using osmocom source, then that weird
center frequency noise appears again.
I've attached several screenshots and GRC flowchart that I used to
reproduce this bug (it uses gr-fosphor). Maedhros_008.png is the
screenshot of gr-fosphor displaying the correct UHD: USRP source, with
all of FM broadcast radio visible, while Maedhros_011.png is the
gr-fosphor showing the output of osmocom source, with this big ~2MHz
spike at center frequency, and all of those FM broadcast radio are not
visible.
I'm using Arch Linux with gnuradio, gr-fosphor, and gr-osmosdr
compiled from source using makepkg/pkgbuild system, and libuhd
3.10.2.0-3
Hi,
A QT API change in Gnuradio 3.17.12.0 :
https://github.com/gnuradio/gnuradio/pull/1418 breaks modules that
relies on QT windowing system, resulting in Template error on
generated python file, resulting in this error when I try to run the
generated python file:
Executing: /usr/sbin/python2 -u /home/feanor/Development/SDR/top_block.py
File "/home/feanor/Development/SDR/top_block.py", line 69
self.fosphor_qt_sink_c_2 = Template error: #set $win = 'self._%s_win'%$id
^
SyntaxError: invalid syntax
>>> Done (return code 1)
This also affects other modules that relies on QT:
gr-inspector: https://github.com/gnuradio/gr-inspector/issues/2
Following the fix in this pull request for gr-inspector:
https://github.com/gnuradio/gr-inspector/pull/21/commits/9d00bb83c155c84ee8…
by changing a line:
15c15
< $(gui_hint()($win))</make>
---
> $(gui_hint() % $win)</make>
fixes the problem for gr-fosphor and make the flowgraph runnable again
All,
I installed GNU Radio for windows on my machine running Windows 10.when I try to run GRC it comes back with:
<<< Welcome to GNU Radio Companion 3.7.11.1 >>>
Block paths: C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks
Loading: "C:\Users\JoseM\Documents\GNU\test w grc.grc">>> Done
Generating: 'C:\\Users\\JoseM\\Documents\\GNU\\top_block.py'
Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u C:\Users\JoseM\Documents\GNU\top_block.py
Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.010.001.001-0-unknown
gr-osmosdr c653754d (0.1.5git) gnuradio 3.7.11.1built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf airspy redpitaya Using device #0 Generic RTL2832U OEMusb_open error -12
FATAL: Failed to open rtlsdr device.
Trying to fill up 1 missing channel(s) with null source(s).This is being done to prevent the application from crashingdue to gnuradio bug #528.
Anybody have any idea how to fix this ?Thanks,
Jose
Hi Theodric,
no, these values that appear on stdout are already audio samples (PCM
to be specific).
That is the "job" of rtl_fm:
It takes the complex time-domain baseband samples from the hardware,
detects FM (which implies detecting a frequency deviation) and convert
that to audio amplitude values.
The `aplay` command barely takes these samples and hands them over to
the sound card (after resampling to fit possible sampling rates, I
guess, as 120 kHz isn't something that sound systems usually operate
at).
The `rtl_fm` command takes a couple of parameters. In your case, `-M
wbfm` means that it's demodulating FM in a way compatible to broadcast
FM; that implies fixed parameters for deviation, emphasis etc.
What you want is really not `rtl_fm`, which primarily is a demo
program, not meant to be a flexible do-it-all solution.
What you want, showing deviation of a station, does very much sound
like a spectrum visualization. Wouldn't a waterfall or even just an
instantaneous spectrum visualization be what you want?
Best regards,
Marcus
On Wed, 2018-03-14 at 15:57 -0400, Theodric Young wrote:
> 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
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
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$
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
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$