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.comwhile, 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.htm>