osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
912 discussions

[PATCH] [rtl-sdr] Relaxed async state machine
by chris＠techworks.ie 07 Aug '12

07 Aug '12

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

1 0

[PATCH] Wait in the destructor for all I/O to finish without a timeout
by Peter Stuge 07 Aug '12

07 Aug '12

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--

1 0

gr-ais with osmosdr
by Christian Gagneraud 07 Aug '12

07 Aug '12

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/

4 10

Wiki page
by Christian Gagneraud 07 Aug '12

07 Aug '12

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/

2 2

[PATCH] Add swig hint for devices_t objects
by chris＠techworks.ie 06 Aug '12

06 Aug '12

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

1 0

Iterating over gain ranges with python
by Christian Gagneraud 05 Aug '12

05 Aug '12

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/

2 2

gr-ais for rtl-sdr
by Antoine Sirinelli 24 Jul '12

24 Jul '12

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

2 1

RTL2832U FIR filter
by Michael Karcher 15 Jul '12

15 Jul '12

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

4 7

RTL2832U FIR filter
by Michael Karcher 14 Jul '12

14 Jul '12

2 1

OsmoSDR Hardware Design Questions
by Sandor Szilvasi 11 Jul '12

11 Jul '12

Hi OsmoCom, I was going to start a home project *very similar* to yours, when I bumped into the OsmoSDR. So, I'd like to ask a few questions regarding the OsmoSDR hardware. 1. Based on the photo<http://sdr.osmocom.org/trac/chrome/common/download.png>your fab could handle BGA packages. Why didn't you use the BGA packaged Atmel SAM3U MCU instead of the LQFP one? 2. The Lattice LatticeXP2 FPGA is available in the same package but in larger size at almost identical price. Why did you pick the smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E ($20)? 3. You are using the SAM3U SSC to transfer data from the FPGA. Before seeing your design I had the idea to use the EBI to interface with the FPGA. After all, the EBI is on the AHB and I assume you have a bunch of FPGA I/Os left. What do you think the drawbacks of using the EBI would be? 4. The differential clock output oscillator was connected in a weird way, but I can see that it has been corrected in Rev 2. 5. My understanding is that you configure the FPGA using the JTAG lines in bit-bang mode through SAM3U GPIOs. Why don't you use the sysConfig port of the Lattice FPGA? It's faster, easier to implement with the SAM3U SPI peripheral (and it's also a feature I haven't seen with other FPGAs). See Lattice TN1141 <http://www.latticesemi.com/documents/TN1141.pdf>. 6. The board seems to be powered from the USB only, but the oscillator already draws ~100mA and it's always enabled. Adding the consumption of the MCU and the FPGA you are already above 100mA. If it's really powered only from the USB, how is it ensured that you stay below the 100mA limit specified by the USB standard until you ask for a higher current, say 500mA? I hope you didn't mind my questions above, I didn't mean to be nosy. I just got a little excited about this project. Cheers, Sandor

3 3

← Newer
1
...
82
83
84
85
86
87
88
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr