osmocom-sdr

osmocom-sdr@lists.osmocom.org

904 discussions

just learning to fly with sdr ... and hit a 64-bit snag

by Gary Lawrence Murphy

First off, this is my first post to the group and I want to thank everyone who has worked to get this kit as far as it is; I was deathly worried that I might be stuck with unusable hardware, and it is still unusuable, but there seems to be light at the end of the SDR tunnel and I'm hoping this is the right forum for asking newbie questions :) Here's where I am so far: I have the Hama Nano DVB-T+DAB+FM with the Elonics E4000 tuner and my goal is really very modest (I hope) in that I only want to tune in one ordinary analog FM station, the FM transmitter in the next room that supplies our house with music from our MP3 collection. Rather than pay $40 at walmart for a radio for my lab, I thought I'd spend $20 on the USB device and have some fun in the process. And it's been fun: I found the recipe for the rtl_fm using the alsa aplay, and I assume the examples were concerned with some other sort of radio (shortwave?) because the recommended 48k sampling sounded like a taxi radio! Not really Easy Listening sort of audio. with some experimenting I found a formula that is still heavily distorted, but recognizable as music: rtl_fm -f 96.3e6 -s 192000 -l 5 -| aplay -t raw -f s16_le -r 192k -c 1 the trouble was that it wouldn't play continuously on my 3300-bogomips netbook, so I moved the code over to my 64-bit dual-core laptop and that's where a strange thing happened: when run as a regular user, the code aborts giving strange (unicode?) gibberish as the device name, but when run as root, the name is correctly reported although the program aborts. ~/Work/dev$ rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le Found 1 device(s): 0: , mX��, SN: ��z� Using device 0: Generic RTL2832U (e.g. hama nano) usb_open error -3 Failed to open rtlsdr device #0. ~/Work/dev$ sudo rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700 Using device 0: Generic RTL2832U (e.g. hama nano) usb_claim_interface error -6 Failed to open rtlsdr device #0. on the 32-bit platform, the *Using device* line is followed by Found Elonics E4000 tuner Oversampling input by: 6x Oversampling output by: 1x is there perhaps some simple config setting that I've overlooked in the 64-bit box? Both are running Ubuntu 12.04 here are the kernel messages on loading the device on 64bit Aug 9 13:47:58 strata kernel: [200306.632008] usb 3-1: new high-speed USB device number 3 using xhci_hcd Aug 9 13:47:58 strata kernel: [200306.663830] usb 3-1: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 microframes Aug 9 13:47:58 strata kernel: [200306.669822] dvb-usb: found a 'RTL2832U DVB-T USB DEVICE' in warm state. Aug 9 13:47:58 strata kernel: [200306.669840] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Aug 9 13:47:58 strata kernel: [200306.671500] DVB: registering new adapter (RTL2832U DVB-T USB DEVICE) Aug 9 13:47:58 strata kernel: [200306.689815] RTL2832U usb_init_bulk_setting : USB2.0 HIGH SPEED (480Mb/s) Aug 9 13:47:58 strata mtp-probe: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1" Aug 9 13:47:59 strata kernel: [200306.972506] RTL2832U check_tuner_type : E4000 tuner on board... Aug 9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device Aug 9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter 0 frontend 0 (Realtek DVB-T RTL2832)... Aug 9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1/input/input15 Aug 9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote query interval to 287 msecs. Aug 9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T USB DEVICE successfully initialized and connected. I notice that it DOESN'T say "*will pass the complete MPEG2 transport stream to the software demuxer"* as it does on the 32bit side. Also, what is the syntax for the -g switch? I have tried integers, decimals and the string -3dB and in all cases I get the message *Warning: Failed to set tuner gain* -- could the gain control simply be unsupported by my device? Lastly, I'd like to ask the hard question: are my goals here feasible? Is this an appropriate device for listening to FM broadcasts at the computer or is this more a hobbyist's SDR playground and, like a dancing bear, the bear doesn't dance amazingling, it is only amazing that the bear dances at all ;) -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com*

12 years, 12 months

Bug hunting

by Christian Gagneraud

Hi, Is there any bug tracker for the gr-osmosdr somewhere? It would be nice if the "audio_alsa_source[hw:X]: Device or resource busy" could be fixed. The problem with that bug is you can't even interogate the device driver for supported gain, etc... If the device is used by another application. For example, I have permanently 2 devices plugged in, I use an FCD to send AIS data to aishub.com, and a RTL to experiment with. The problem with this bug is that if you use python you can't even catch the exception, it simply crash the script. I think that the behaviour is different when using C++. Another "bug" I discovered is that if you just do a device scan to print available device and exit the python script, it will generate plenty of error messages like "libusb:warning [cancel_bulk_transfer] unrecognised discard errno 9", the workaround is to simply wait a bit before exiting. It seems that some USB packets are still pending after calling osmosdr.source_c(). Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

12 years, 12 months

[PATCH] [rtl-sdr] Relaxed async state machine

by chris＠techworks.ie

From: Christian Gagneraud <chris(a)techworks.ie> gr-osmosdr uses the driver in a multi-thread context, as a side effect the cancel_async() can be called before read_async(), in such a case the cancel is "forgotten". This patch fixed that by being a bit more relaxed with state machine transitions. This patch doesn't fix any race conditions, it just make an anoying one less likely to happen. This patch goes along this one [1] [1] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-August/000201.html Signed-off-by: Christian Gagneraud <chris(a)techworks.ie> --- src/librtlsdr.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 4e54d8e..d83010d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1256,6 +1256,12 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, if (!dev) return -1; + /* It can happen if cancel_async is called before read_async */ + if (dev->async_status != RTLSDR_INACTIVE) + return -1; + + dev->async_status = RTLSDR_RUNNING; + dev->cb = cb; dev->cb_ctx = ctx; @@ -1284,8 +1290,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, libusb_submit_transfer(dev->xfer[i]); } - dev->async_status = RTLSDR_RUNNING; - while (RTLSDR_INACTIVE != dev->async_status) { r = libusb_handle_events_timeout(dev->ctx, &tv); if (r < 0) { @@ -1326,7 +1330,7 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev) if (!dev) return -1; - if (RTLSDR_RUNNING == dev->async_status) { + if (RTLSDR_CANCELING != dev->async_status) { dev->async_status = RTLSDR_CANCELING; return 0; } -- 1.7.7

13 years

[PATCH] Wait in the destructor for all I/O to finish without a timeout

by Peter Stuge

Signed-off-by: Peter Stuge <peter(a)stuge.se> --- lib/rtl/rtl_source_c.cc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc index 8839a2f..c8cc772 100644 --- a/lib/rtl/rtl_source_c.cc +++ b/lib/rtl/rtl_source_c.cc @@ -180,7 +180,7 @@ rtl_source_c::~rtl_source_c () if (_dev) { _running = false; rtlsdr_cancel_async( _dev ); - _thread.timed_join( boost::posix_time::milliseconds(200) ); + _thread.join(); rtlsdr_close( _dev ); _dev = NULL; } -- 1.7.4.1.343.ga91df.dirty --YZ5djTAD1cGYuMQK--

13 years

gr-ais with osmosdr

by Christian Gagneraud

Hi there, I saw a message in the July archive (I wasn't subscribed yet at that date) about updating gr-ais with osmosdr support. I was working on the same thing recently, so i decided to publish my fixes on top of Antoine's one. The result can be found here: https://github.com/chgans/gr-ais I got it working with both an FCD and an RTL: ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0 ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0 Strangely passing freq_err=XX parameter to the source (using -D), doesn't work, the use of --error is thus needed (which will do a set_freq_corr()). Antoine, if you want sample file, just let me know. Nick, are you willing to integrate these changing back in gr-ais, Apart from the added automatic decimation filter, the changes are not intrusive at all. The default settings for UHD are 256Khz sampling with decimation filter 4, with this change, the decimation is one when using FCD (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this was the minimum working frequency for me). Or maybe would you prefer to allow the user to set it manually, and use this technique as a fall back only. Please let me know what you guys think. Thx, Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

13 years

Wiki page

by Christian Gagneraud

Hi, I started do add documentation to the wiki page of gr-osmosdr [1]. For now i've just added documentation about the "constructor" parameters. Any feedback welcome. [1] http://sdr.osmocom.org/trac/wiki/GrOsmoSDR PS: Could anyone tell me what the mcr is? (used for osmosdr source) -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

13 years

[PATCH] Add swig hint for devices_t objects

by chris＠techworks.ie

From: Christian Gagneraud <chris(a)techworks.ie> Signed-off-by: Christian Gagneraud <chris(a)techworks.ie> --- swig/osmosdr_swig.i | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/swig/osmosdr_swig.i b/swig/osmosdr_swig.i index afdbb0e..4205fd6 100644 --- a/swig/osmosdr_swig.i +++ b/swig/osmosdr_swig.i @@ -25,6 +25,7 @@ %ignore osmosdr::device_t::operator[]; //ignore warnings about %extend %template(string_string_dict_t) std::map<std::string, std::string>; //define before device +%template(devices_t)std::vector<osmosdr::device_t>; %include <osmosdr_device.h> %template(range_vector_t) std::vector<osmosdr::range_t>; //define before range -- 1.7.7

13 years

Iterating over gain ranges with python

by Christian Gagneraud

Hi there, In a python script, I would like to iterate over things like get_gain_names, get_gain_ranges, ... The problem is that these functions return a std::vector<std::string> *. The error i get is: TypeError: 'SwigPyObject' object is not iterable It would be very nice to be able to do something like: for src.get_sample_rates(): # do something for name in get_gain_names(): # do smth I found this: http://reference-man.com/files/generators.i But i haven't been able to use it so far. :( Any help or comments appreciated. Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

13 years

gr-ais for rtl-sdr

by Antoine Sirinelli

Hi, I have tried to modify the AIS decoding implementation from Nick Foster (https://cgran.org/wiki/AIS) in order to be able to use an rtl dongle as a source. Unfortunately I am not living by the sea and I cannot test it before a couple of week. Is there anybody able to receive AIS messages willing to test my changes? You can find it on github: https://github.com/asirinelli/gr-ais The 2 main assumptions I made are: - Nick first implementation is working - rtl-sdr is able to have a sample rate of 256 kHz. Many thanks, Antoine

13 years

RTL2832U FIR filter

by Michael Karcher

Hello people, in some experiments with my RTL2832 stick, I managed to find out how the FIR filter works. The FIR filter is running at the XTAL frequency (typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR filter with 32 real-number-valued taps. Using the symmetry, only 16 coefficients need to be specified. The coefficients are stored in the 20 bytes written to the FIR register. The first coefficient describes the outermost tap, the last one the tap 0.5 taps away from the symmetry axis. The first 8 values are 8-bit numbers, the second 8 values are 12 bit numbers, resulting in 64 + 96 = 160 bits (20 bytes). The first 8 bytes written to the chip are the first 8 coefficients. The 12-bit coefficients are stored like this pairwise in three bytes: In the byte sequence "12 34 56", the first coefficient is 0x123 and the second coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be interpreted as two's complement signed numbers (thus the 8-bit coefficients range from -128 to +127, while the 12-bit coefficients range from -2048 to +2047). The resolution of all 16 coefficients is the same. I furthermore found out that this is not the only filtering going on in the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing filter before the DAC, making signals disappear that are at frequencies above 0.7 times the sample rate (in the baseband), even if the programmable FIR filter lets them pass. As an example, I provide the decoded default coefficients: -54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421 421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54 This filter has a quite flat passband in the interesting range for DAB (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory adjacent channel rejection. The experimentally observed alias rejection is good enough, which lead to the conclusion that there is another low-pass filter, which might be part of the resampling unit. Regards, Michael Karcher

13 years

← Newer
1
...
81
82
83
84
85
86
87
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr