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

Jiao Xianjun putaoshu at gmail.com
Fri Jan 31 00:27:53 UTC 2014


while, I can try it, and let's see.

Actually, maybe I will turn it to C some time in the future.

-----Original Message-----
From: "Ron Senykoff" <rsenykoff at gmail.com>
Sent: ‎2014/‎1/‎30 23:04
To: "Jiao Xianjun" <putaoshu at gmail.com>
Cc: "jdow" <jdow at earthlink.net>; "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at lists.osmocom.org>
Subject: Re: How to get IQ samples from multiple rtl-sdr dongles inasynchronized manner?

Hi Jiao,

Thanks for your work on this. I'm curious if Octave could be used for
some of this.

-Ron / KB1UMH


On Wed, Jan 29, 2014 at 10:14 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:
> Hi everybody,
>
> Let me report current progress of this thread.
>
> Now my matlab program can detect and correct sampling and carrier (both
> phase and frequency) error for dongles, and show the sampling phase
> difference between two dongles (at 8X oversampling rate) after correction.
>
> You can try it by yourself here :
> https://github.com/JiaoXianjun/multi-rtl-sdr-calibration
>
> Some runs results have also been attached here. (time location of FCCH SCH
> and BCCH have also been shown there in different color)
>
> In the attached pictures, you may find that from the GSM frame point of view
> those FCCH, SCH and BCCH from two dongles seem almost in the same time
> location. (this needs to be verified further by check/demodulate information
> carried in SCH and BCCH, which is still under development). But if we
> inspect the time location in a 8X oversampling scale (zoom-in), there is a
> fixed sampling phase difference between two dongles (after correction
> respectively).
>
> Unfortunately, this fixed sampling phase difference may vary from run to run
> (one rum means we restart rtl_tcp).
> Fortunately, it remains fixed in a single run. This offers us a opportunity
> to track continuous input I&Q (don't re-run rtl_tcp!) from multiple dongles,
> and needn't worry about phase/sampling jumping/discontinuous things.
>
> Why do carrier and sampling error estimation and correction respectively?
> Inspired by James Peroulas james at peroulas.com (author of Lte-Cell-Scanner),
> for example, when there is a non-coherent up/down-converter used outside
> dongle (like MMDS LNB used by Omri Iluz omri at iluz.net to detect 2.4GHz band
> signal), there won't be strict relationship between sampling error (which is
> in baseband) and carrier error (which may be located in inside dongle or
> outside dongle mixer).
>
> But for my in-hands dongles, sampling error and carrier seems have
> relationship. This may be because they have common clock source inside
> dongle.
>
> Which I detected by my matlab program gsm_sync_demod.m:
> dongle 1: sampling PPM 27.1739,     carrier PPM -28.513
> dongle 2: sampling PPM 116.3043,   carrier PPM -118.4247
>
> In my program a positive sampling PPM means sampling clock is slower than
> standard/ideal source (in our case, this source is GSM base-station). If LO
> of mixer uses the same clock as sampling, that may cause a lower LO in
> mixer/down-converter. I guess the LO frequency of mixer in dongle is higher
> than input antenna RF frequency, which means for mixer: output = LO - input.
> Thus a lower LO generates a lower input into baseband, that's why I get a
> negative carrier PPM (negative carrier PPM means detected carrier frequency
> is lower than standard/ideal source).
> I don't know if my guess is correct. Anyone is familiar with the hardware
> architecture of the 820t dongle?
>
> BR
>
> Jiao Xianjun
>
>
>
>
> On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow at earthlink.net> wrote:
>>
>> The last I looked rtl_tcp did not allow full control over the dongle. But,
>> then, to do what I really want has required bypassing rtlsdr to go
>> directly to the usb library so I can access the underlying USB system
>> directly for a specific feature. (A feed through feature in rtlsdr's
>> shared library would be nice when trying to nail down the dongle's
>> identity for restoring context on program startup.)
>>
>> (Building an SDR program without multi-threading is rather like trying
>> to build a bicycle without chains or cables. It can be done. But it's
>> a pathetic tool when you get done with it. Erm, but I do note gear
>> driven bikes need less maintenance under adverse conditions. Been there
>> done that - MANY decades ago.)
>>
>> {^_^}   Joanne/W6MKU
>>
>>
>> On 2014/01/07 23:32, Jiao Xianjun wrote:
>>>
>>> Good idea.
>>>
>>> Thanks for your advice!
>>>
>>> But that seems we will do some repeating works.
>>>
>>> rtl_tcp already use mutiple buffers and multi-threading. So why not use
>>> it
>>> directly as a reliable relay.
>>>
>>>
>>> On Tue, Jan 7, 2014 at 1:51 AM, jdow <jdow at earthlink.net
>>> <mailto:jdow at earthlink.net>> wrote:
>>>
>>>     Have you tried using ping-pong buffers? Process on one buffer and
>>> receive
>>>     to another. You may have to use multi-threading to make this work
>>> nicely.
>>>
>>>     {^_^}   Joanne/W6MKU
>>>
>>>
>>>
>>>     On 2014/01/06 01:34, Jiao Xianjun wrote:
>>>
>>>         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
>>>         <mailto:putaoshu at gmail.com>
>>>         <mailto:putaoshu at gmail.com <mailto: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
>>>         <mailto:putaoshu at gmail.com>
>>>              <mailto:putaoshu at gmail.com <mailto: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 <mailto:sdrguru1 at gmail.com
>>>         <mailto:sdrguru1 at gmail.com>>
>>>
>>>                  Sent: 2014/1/2 5:39
>>>
>>>                  To: osmocom-sdr at lists.osmocom.org
>>>         <mailto:osmocom-sdr at lists.osmocom.org>
>>>         <mailto:osmocom-sdr at lists.__osmocom.org
>>>
>>>         <mailto: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/__b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f
>>>
>>> <https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f>
>>>         https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c
>>>
>>>         <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/__ecf267737ca52f5005b7a12a352307__e8cd763ed6
>>>
>>>
>>> <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 <mailto:putaoshu at gmail.com>
>>>                  <mailto:putaoshu at gmail.com <mailto: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
>>>
>>>         <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/20140131/c842b293/attachment.html>


More information about the osmocom-sdr mailing list