This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Jiao Xianjun putaoshu at gmail.comHi, Today I did some experiments using CW signal which is generated by signal generator. The conclusion is a little bit sad. sync read and UDP lose samples/data high probably: 1. If there are some other operations (which costs some time) between two successive sync reads, some samples will be lost. 2. Some times, UDP packets are just lost. So, seems that I have two choices: 1. struggle to use async read mode. 2. use rtl_tcp utility directly, which is offered with rtl-sdr code. This program use async mode and TCP, which has avoided the two shortcomings I addressed. I will try the 2nd method, and try to move on with calibration. BR Jiao Xianjun On Sat, Jan 4, 2014 at 8:34 PM, Jiao Xianjun <putaoshu at gmail.com> wrote: > 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 at 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 at gmail.com> >> Sent: 2014/1/2 5:39 >> >> To: osmocom-sdr at 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/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f >> 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/ecf267737ca52f5005b7a12a352307e8cd763ed6 >> >> 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 at 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 >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140106/b2e38546/attachment.htm>