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/.
Ron Senykoff rsenykoff at gmail.comHi 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 > >