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

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.com
Mon Jan 6 09:34:23 UTC 2014


Hi,

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>


More information about the osmocom-sdr mailing list