osmocom-sdr January 2014

osmocom-sdr@lists.osmocom.org

39 participants
47 discussions

by Jiao Xianjun

I found that librtlsdr in github 003bd51167d9680e9721c7296323fdffe4be5a09 can't work with LTE-Cell-Scanner<https://github.com/Evrytania/LTE-Cell-Scanner>5fa3df8a5d915c73cacea843021ce0c5b317522f in github. But librtlsdr release 0.5.2 2d0eaa898d2d4e271aed87ae3849a80ac12cf76c is OK. The 'can't work' means: LTE-Cell-Scanner show seg-fault/core-dump when it checks the second frequency point after finishes the first frequency point. A debug tracing shows that the crash is at rtlsdr_set_center_freq(). BR Ryan.

11 years, 5 months

Re: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner?

by Jiao Xianjun

Hi, I have questions on usage of rtlsdr_read_sync(dev, buffer, out_block_size, &n_read): For example, if sampling rate is 1Msps, and out_block_size is 1000000, question is: 1. the rtlsdr_read_sync() will cost 1s exactly? Or is there any lower level device/driver buffer, which perhaps feed rtlsdr_read_sync() with history data quickly and makes rtlsdr_read_sync() return in a time shorter than 1s? 2. in this infinite processing loop: while(1) { rtlsdr_read_sync(dev, buffer, out_block_size, &n_read); processing_function(buffer); // let's assume that this cost 0.001s } Those samples during the 0.001s processing period will be losted or not? Is there any method to not lost them? Thanks very much! BR Jiao Xianjun On Thu, Jan 2, 2014 at 9:25 PM, Jiao Xianjun <putaoshu(a)gmail.com> wrote: > I see some UDP packet performance issues in my laptop (but not in my > desktop computer). Will the common (interleave multiple receives) UDP link > helps? > > The issue is that fread for the second dongle in matlab get less data than > expectation sometimes. Seem that fread for the first dongle works well. > ------------------------------ > From: Sdr Guru <sdrguru1(a)gmail.com> > Sent: 2014/1/2 5:39 > To: osmocom-sdr(a)lists.osmocom.org > Subject: Re: How to get IQ samples from multiple rtl-sdr dongles in > asynchronized manner? > > Hi > > rtl-sdr-relay > Some of the recommendations. > Please add PPM error calculation, exactly like new rtl_test -p > but multiple receivers simultaneously. > It provides immediate information if something is wrong with USB or > dongles. > > https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c… > https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c > > Please add automatic eeprom PPM calibration > > https://github.com/keenerd/rtl-sdr/commit/ecf267737ca52f5005b7a12a352307e8c… > > default sample rate 2.4M (28.8/12) or 1.2M (28.8/24), probably lower jitter > MAX_NUM_DEV 4->16 :) > > Some nice to have features. > ip binding > multicast support > one common (interleaved) stream of all the receivers > timestamped stream > > I'm trying to convert MATLAB script to Ocatve. > > SG > > On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun <putaoshu(a)gmail.com> wrote: > >> Hi guys, >> >> For the multiple dongles synchronization in signal level instead of >> bits/packets level, I setup a working repo in github, and write a initial >> demo framework. See below: >> >> https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git >> >> You may find information and instruction of demo quickly by reading the >> README. >> >> My initial purpose is performing in-fly calibration for multiple dongles >> according to some pre-known signal (GSM, ADS-B?) to let them work together >> coherently. >> >> An ideal scheme may be that we should generate a very narrow band and >> very week signal in (or just located at the edge of) target working band of >> dongles, and perform the software in-fly calibration in background (or >> driver level). This would be user friendly. >> >> I know it is far from final state currently, and many things are not >> clear yet (See TODO). But please join me if you also think this is a good >> idea. Just check out the demo and run it to have a look. >> >> Currently I just test the demo in Ubuntu-Linux. >> >> BR >> >> Jiao Xianjun >> >>

11 years, 5 months

Incorrect samplerate from RTL-SDR

by Joris van Rantwijk

Hi, Let me first say that librtlsdr is great. It is a fantastic way for me to learn about SDR. Also, the library seems very well designed, easy to use, and at a convenient level of abstraction. Many thanks for putting this together! I'm using librtlsdr to make a wideband FM receiver in C++. Perhaps more about that later. I noticed the following problem: When I configure a sample rate lower than 1 MS/s, I often get a very different sample rate then what I ask for. The library reports back the same sample rate that I asked (via rtlsdr_get_sample_rate), but the actual sample rate does not match at all. For example, asking 900 kS/s results in ~ 290 kS/s. Asking 800 kS/s gives ~ 285 kS/s. Asking 600 kS/s gives ~ 255 kS/s. Asking 400 kS/s gives ~ 1700 kS/s. Asking 300 kS/s gives 300 kS/s. I know the real samplerate from looking at the amount of data I get out of the library in a given amount of time. I have also looked at the FFT spectrum of the data and this confirms my estimate of the actual sample rate (this eliminates the hypothesis that RTL is sampling at configured rate but losing some of the data packets). After diving into librtlsdr.c, I found that the pattern of configured vs real sample rate can be explained by assuming a specific bit error in the configuration word rsamp_ratio. Bit 28 of the word is forced equal to bit 27. It is as if somebody is doing rsamp_ratio = (rsamp_ratio & 0x0fffffff) | ((rsamp_ratio & 0x08000000) << 1); after the configuration is sent out via USB but before it is applied by the RTL chip. I have a Terratec Cinergy Tstick RC rev3, USB ID 0ccd:00d3. The RTL-SDR library reports: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Terratec Cinergy T Stick RC (Rev.3) Found Elonics E4000 tuner Does this ring any bells for people who understand the RTL chip? Is it caused by the difference between RTL2832 vs RTL2838? I have seen other reports on the mailing list, saying that sample rates between 300 kS/s and 900 kS/s don't work. If this applies to all RTL devices, then maybe it should be documented and the library can return an error code for such sample rates. Otherwise people will keep walking into this trap. Kind regards, Joris van Rantwijk.

11 years, 5 months

RE: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner?

by Jiao Xianjun

Hi, I don't use the method of hardware modification. That can do synchronization promisingly, sure. I know this scheme couple of months ago, and good to know it works pretty well from you. My thought is doing the compensation by software according to a common source over the air instead of over the hardware. Do you think it is doable? And what would be the bottleneck according to your experience? Any possibility to tune the hardware by software after we estimate the synchronization error in frequency and timing? BR Jiao xianjun -----Original Message----- From: "Sdr Guru" <sdrguru1(a)gmail.com> Sent: ‎2013/‎12/‎30 19:01 To: "Jiao Xianjun" <putaoshu(a)gmail.com> Cc: "osmocom-sdr(a)lists.osmocom.org" <osmocom-sdr(a)lists.osmocom.org> Subject: Re: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner? Hi Are you using a common clock? http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html I've modified some of the RTL dongles, played with GNURadio and Octave. The results are promising, sample level correlation (2.4M/10, FM radio signal). On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun <putaoshu(a)gmail.com> wrote: Hi guys, For the multiple dongles synchronization in signal level instead of bits/packets level, I setup a working repo in github, and write a initial demo framework. See below: https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git You may find information and instruction of demo quickly by reading the README. My initial purpose is performing in-fly calibration for multiple dongles according to some pre-known signal (GSM, ADS-B?) to let them work together coherently. An ideal scheme may be that we should generate a very narrow band and very week signal in (or just located at the edge of) target working band of dongles, and perform the software in-fly calibration in background (or driver level). This would be user friendly. Cheap (8USD+PP), simple, computer-controlled and legal FM band "marker" http://blog.palosaari.fi/2013/08/naked-hardware-12-usb-audio-transmitter.ht… I know it is far from final state currently, and many things are not clear yet (See TODO). But please join me if you also think this is a good idea. Just check out the demo and run it to have a look. Testing it and I'll let you know. Currently I just test the demo in Ubuntu-Linux. BR Jiao Xianjun On Mon, Sep 2, 2013 at 8:23 PM, Sylvain AZARIAN <sylvain.azarian(a)gmail.com> wrote: Thanks. sylvain 2013/9/2 Sdr Guru <sdrguru1(a)gmail.com> The second way, use MLAT enabled dump1090 https://github.com/antirez/dump1090/pull/23 http://www.satsignal.eu/raspberry-pi/dump1090.html On Sun, Aug 25, 2013 at 4:13 PM, Jiao Xianjun <putaoshu(a)gmail.com> wrote: Hi, I want to use multiple rtl-sdr dongles to do some multi-antenna experiments. Is it possible to read IQ samples from multiple rtl-sdr dongles in a synchronized manner? I already have a glance at dump1090 codes, which is a project using rtl-sdr to decode aircraft broadcasting ADS-B messages in 1090MHz. Seems that I should use rtlsdr_read_async() instead of rtlsdr_read_sync(), because that if rtlsdr_read_sync() is used, I have to call it multiple times sequentially. That looks not synchronized. But rtlsdr_read_async() function only accept one rtl-sdr device as input parameter, and it will be blocked after it is called. So seems that it also can't be used for my purpose directly. Also welcome any opinion on how to improve rtl-sdr lib/driver to support this feature. Thank you. BR Jiao Xianjun

11 years, 5 months

RE: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner?

by Jiao Xianjun

I see some UDP packet performance issues in my laptop (but not in my desktop computer). Will the common (interleave multiple receives) UDP link helps? The issue is that fread for the second dongle in matlab get less data than expectation sometimes. Seem that fread for the first dongle works well. -----Original Message----- From: "Sdr Guru" <sdrguru1(a)gmail.com> Sent: ‎2014/‎1/‎2 5:39 To: "osmocom-sdr(a)lists.osmocom.org" <osmocom-sdr(a)lists.osmocom.org> Subject: Re: How to get IQ samples from multiple rtl-sdr dongles in asynchronized manner? Hi rtl-sdr-relay Some of the recommendations. Please add PPM error calculation, exactly like new rtl_test -p but multiple receivers simultaneously. It provides immediate information if something is wrong with USB or dongles. https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c… https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c Please add automatic eeprom PPM calibration https://github.com/keenerd/rtl-sdr/commit/ecf267737ca52f5005b7a12a352307e8c… default sample rate 2.4M (28.8/12) or 1.2M (28.8/24), probably lower jitter MAX_NUM_DEV 4->16 :) Some nice to have features. ip binding multicast support one common (interleaved) stream of all the receivers timestamped stream I'm trying to convert MATLAB script to Ocatve. SG On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun <putaoshu(a)gmail.com> wrote: Hi guys, For the multiple dongles synchronization in signal level instead of bits/packets level, I setup a working repo in github, and write a initial demo framework. See below: https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git You may find information and instruction of demo quickly by reading the README. My initial purpose is performing in-fly calibration for multiple dongles according to some pre-known signal (GSM, ADS-B?) to let them work together coherently. An ideal scheme may be that we should generate a very narrow band and very week signal in (or just located at the edge of) target working band of dongles, and perform the software in-fly calibration in background (or driver level). This would be user friendly. I know it is far from final state currently, and many things are not clear yet (See TODO). But please join me if you also think this is a good idea. Just check out the demo and run it to have a look. Currently I just test the demo in Ubuntu-Linux. BR Jiao Xianjun

11 years, 5 months

How to get IQ samples from multiple rtl-sdr dongles in a synchronized manner?

by Jiao Xianjun

Hi, I want to use multiple rtl-sdr dongles to do some multi-antenna experiments. Is it possible to read IQ samples from multiple rtl-sdr dongles in a synchronized manner? I already have a glance at dump1090 codes, which is a project using rtl-sdr to decode aircraft broadcasting ADS-B messages in 1090MHz. Seems that I should use rtlsdr_read_async() instead of rtlsdr_read_sync(), because that if rtlsdr_read_sync() is used, I have to call it multiple times sequentially. That looks not synchronized. But rtlsdr_read_async() function only accept one rtl-sdr device as input parameter, and it will be blocked after it is called. So seems that it also can't be used for my purpose directly. Also welcome any opinion on how to improve rtl-sdr lib/driver to support this feature. Thank you. BR Jiao Xianjun

11 years, 5 months

OsmoDevCon 2014 / Date / Venue

by Harald Welte

Hi all, time is moving fast, and I want to start some initial discussion and planning for OsmoDevCon 2014. There are basically four questions which I'm raising below. Please provide your feedback to the osmocom-event-orga mailing list only, to avoid cross-posting over all the project lists. = Who? = My intention is to keep it an 'active developer/contributer only' event, like we had it before. I would also want to keep the group relatively small, to keep the 'Osmocom family' atmosphere. If desired, we could have one half or full day of public prsentations in a larger auditorium, but the developer meeting should be a close group, as known so far. = Where? = If we keep the number of attendees within the same range as this year, then I'm sure we could again hold it at the same venue. I know it is not perfect, but it is a place that we have access to, 24 hours per day, and free of cost for community projects like osmocom.org. If the community wants a larger event, then this is something that would require more funds and much more time organizing. And that is something that I personally could not offer to take care of, sorry. I'm happy to attend and support any larger events, but I'm unable to take care of fundraising and venue research. = When? = Q1/2014. In January, I'm not aware of any 'blocker' events. February, there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg March 17-21). Did I miss any other FOSS / mobile event that might clash in Q1? So my preference woudl be to do it either late January (23-26) or in February (6-9 or 13-16). Any preferences regarding preferred schedule? Once we have some concencus here on the list [and we want to do it in the same size / venue], I'll talk to IN-Berlin. = What? = I think that question is easy to answer, if we have the above three figured out... There's no shortage of topics, I suppose. You can start adding your suggestions to http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014 Regards, Harald -- - 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)

11 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr January 2014