<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type></HEAD>
<BODY>
<DIV>
<DIV style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">while, I can try it, and let's see.<BR><BR>Actually, maybe I will turn it to C some time in the future.</DIV></DIV>
<DIV dir=ltr>
<HR>
<SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">From: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><A href="mailto:rsenykoff@gmail.com">Ron Senykoff</A></SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Sent: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">2014/1/30 23:04</SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">To: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><A href="mailto:putaoshu@gmail.com">Jiao Xianjun</A></SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Cc: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><A href="mailto:jdow@earthlink.net">jdow</A>; <A href="mailto:osmocom-sdr@lists.osmocom.org">osmocom-sdr@lists.osmocom.org</A></SPAN><BR><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Subject: </SPAN><SPAN style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re: How to get IQ samples from multiple rtl-sdr dongles inasynchronized manner?</SPAN><BR><BR></DIV>Hi Jiao,<BR><BR>Thanks for your work on this. I'm curious if Octave could be used for<BR>some of this.<BR><BR>-Ron / KB1UMH<BR><BR><BR>On Wed, Jan 29, 2014 at 10:14 PM, Jiao Xianjun <putaoshu@gmail.com> wrote:<BR>> Hi everybody,<BR>><BR>> Let me report current progress of this thread.<BR>><BR>> Now my matlab program can detect and correct sampling and carrier (both<BR>> phase and frequency) error for dongles, and show the sampling phase<BR>> difference between two dongles (at 8X oversampling rate) after correction.<BR>><BR>> You can try it by yourself here :<BR>> https://github.com/JiaoXianjun/multi-rtl-sdr-calibration<BR>><BR>> Some runs results have also been attached here. (time location of FCCH SCH<BR>> and BCCH have also been shown there in different color)<BR>><BR>> In the attached pictures, you may find that from the GSM frame point of view<BR>> those FCCH, SCH and BCCH from two dongles seem almost in the same time<BR>> location. (this needs to be verified further by check/demodulate information<BR>> carried in SCH and BCCH, which is still under development). But if we<BR>> inspect the time location in a 8X oversampling scale (zoom-in), there is a<BR>> fixed sampling phase difference between two dongles (after correction<BR>> respectively).<BR>><BR>> Unfortunately, this fixed sampling phase difference may vary from run to run<BR>> (one rum means we restart rtl_tcp).<BR>> Fortunately, it remains fixed in a single run. This offers us a opportunity<BR>> to track continuous input I&Q (don't re-run rtl_tcp!) from multiple dongles,<BR>> and needn't worry about phase/sampling jumping/discontinuous things.<BR>><BR>> Why do carrier and sampling error estimation and correction respectively?<BR>> Inspired by James Peroulas james@peroulas.com (author of Lte-Cell-Scanner),<BR>> for example, when there is a non-coherent up/down-converter used outside<BR>> dongle (like MMDS LNB used by Omri Iluz omri@iluz.net to detect 2.4GHz band<BR>> signal), there won't be strict relationship between sampling error (which is<BR>> in baseband) and carrier error (which may be located in inside dongle or<BR>> outside dongle mixer).<BR>><BR>> But for my in-hands dongles, sampling error and carrier seems have<BR>> relationship. This may be because they have common clock source inside<BR>> dongle.<BR>><BR>> Which I detected by my matlab program gsm_sync_demod.m:<BR>> dongle 1: sampling PPM 27.1739, carrier PPM -28.513<BR>> dongle 2: sampling PPM 116.3043, carrier PPM -118.4247<BR>><BR>> In my program a positive sampling PPM means sampling clock is slower than<BR>> standard/ideal source (in our case, this source is GSM base-station). If LO<BR>> of mixer uses the same clock as sampling, that may cause a lower LO in<BR>> mixer/down-converter. I guess the LO frequency of mixer in dongle is higher<BR>> than input antenna RF frequency, which means for mixer: output = LO - input.<BR>> Thus a lower LO generates a lower input into baseband, that's why I get a<BR>> negative carrier PPM (negative carrier PPM means detected carrier frequency<BR>> is lower than standard/ideal source).<BR>> I don't know if my guess is correct. Anyone is familiar with the hardware<BR>> architecture of the 820t dongle?<BR>><BR>> BR<BR>><BR>> Jiao Xianjun<BR>><BR>><BR>><BR>><BR>> On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow@earthlink.net> wrote:<BR>>><BR>>> The last I looked rtl_tcp did not allow full control over the dongle. But,<BR>>> then, to do what I really want has required bypassing rtlsdr to go<BR>>> directly to the usb library so I can access the underlying USB system<BR>>> directly for a specific feature. (A feed through feature in rtlsdr's<BR>>> shared library would be nice when trying to nail down the dongle's<BR>>> identity for restoring context on program startup.)<BR>>><BR>>> (Building an SDR program without multi-threading is rather like trying<BR>>> to build a bicycle without chains or cables. It can be done. But it's<BR>>> a pathetic tool when you get done with it. Erm, but I do note gear<BR>>> driven bikes need less maintenance under adverse conditions. Been there<BR>>> done that - MANY decades ago.)<BR>>><BR>>> {^_^} Joanne/W6MKU<BR>>><BR>>><BR>>> On 2014/01/07 23:32, Jiao Xianjun wrote:<BR>>>><BR>>>> Good idea.<BR>>>><BR>>>> Thanks for your advice!<BR>>>><BR>>>> But that seems we will do some repeating works.<BR>>>><BR>>>> rtl_tcp already use mutiple buffers and multi-threading. So why not use<BR>>>> it<BR>>>> directly as a reliable relay.<BR>>>><BR>>>><BR>>>> On Tue, Jan 7, 2014 at 1:51 AM, jdow <jdow@earthlink.net<BR>>>> <mailto:jdow@earthlink.net>> wrote:<BR>>>><BR>>>> Have you tried using ping-pong buffers? Process on one buffer and<BR>>>> receive<BR>>>> to another. You may have to use multi-threading to make this work<BR>>>> nicely.<BR>>>><BR>>>> {^_^} Joanne/W6MKU<BR>>>><BR>>>><BR>>>><BR>>>> On 2014/01/06 01:34, Jiao Xianjun wrote:<BR>>>><BR>>>> Hi,<BR>>>><BR>>>> Today I did some experiments using CW signal which is generated<BR>>>> by signal<BR>>>> generator. The conclusion is a little bit sad.<BR>>>><BR>>>> sync read and UDP lose samples/data high probably:<BR>>>> 1. If there are some other operations (which costs some time)<BR>>>> between two<BR>>>> successive sync reads, some samples will be lost.<BR>>>> 2. Some times, UDP packets are just lost.<BR>>>><BR>>>> So, seems that I have two choices:<BR>>>> 1. struggle to use async read mode.<BR>>>> 2. use rtl_tcp utility directly, which is offered with rtl-sdr<BR>>>> code. This<BR>>>> program use async mode and TCP, which has avoided the two<BR>>>> shortcomings I<BR>>>> addressed.<BR>>>><BR>>>> I will try the 2nd method, and try to move on with calibration.<BR>>>><BR>>>> BR<BR>>>><BR>>>> Jiao Xianjun<BR>>>><BR>>>><BR>>>><BR>>>> On Sat, Jan 4, 2014 at 8:34 PM, Jiao Xianjun <putaoshu@gmail.com<BR>>>> <mailto:putaoshu@gmail.com><BR>>>> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> wrote:<BR>>>><BR>>>> Hi,<BR>>>><BR>>>> I have questions on usage of rtlsdr_read_sync(dev, buffer,<BR>>>> out_block_size,<BR>>>> &n_read):<BR>>>><BR>>>> For example, if sampling rate is 1Msps, and out_block_size<BR>>>> is 1000000,<BR>>>> question is:<BR>>>><BR>>>> 1. the rtlsdr_read_sync() will cost 1s exactly? Or is there<BR>>>> any<BR>>>> lower level<BR>>>> device/driver buffer, which perhaps feed rtlsdr_read_sync()<BR>>>> with<BR>>>> history<BR>>>> data quickly and makes rtlsdr_read_sync() return in a time<BR>>>> shorter<BR>>>> than 1s?<BR>>>><BR>>>> 2. in this infinite processing loop:<BR>>>> while(1)<BR>>>> {<BR>>>> rtlsdr_read_sync(dev, buffer, out_block_size, &n_read);<BR>>>> processing_function(buffer); // let's assume that this cost<BR>>>> 0.001s<BR>>>> }<BR>>>> Those samples during the 0.001s processing period will be<BR>>>> losted or<BR>>>> not? Is<BR>>>> there any method to not lost them?<BR>>>><BR>>>> Thanks very much!<BR>>>><BR>>>> BR<BR>>>><BR>>>> Jiao Xianjun<BR>>>><BR>>>><BR>>>><BR>>>> On Thu, Jan 2, 2014 at 9:25 PM, Jiao Xianjun<BR>>>> <putaoshu@gmail.com<BR>>>> <mailto:putaoshu@gmail.com><BR>>>> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>><BR>>>> wrote:<BR>>>><BR>>>> I see some UDP packet performance issues in my laptop<BR>>>> (but not<BR>>>> in my<BR>>>> desktop computer). Will the common (interleave multiple<BR>>>> receives) UDP<BR>>>> link helps?<BR>>>><BR>>>> The issue is that fread for the second dongle in matlab<BR>>>> get<BR>>>> less data<BR>>>> than expectation sometimes. Seem that fread for the<BR>>>> first<BR>>>> dongle works well.<BR>>>><BR>>>><BR>>>> ------------------------------__------------------------------__--------------------<BR>>>><BR>>>> From: Sdr Guru <mailto:sdrguru1@gmail.com<BR>>>> <mailto:sdrguru1@gmail.com>><BR>>>><BR>>>> Sent: 2014/1/2 5:39<BR>>>><BR>>>> To: osmocom-sdr@lists.osmocom.org<BR>>>> <mailto:osmocom-sdr@lists.osmocom.org><BR>>>> <mailto:osmocom-sdr@lists.__osmocom.org<BR>>>><BR>>>> <mailto:osmocom-sdr@lists.osmocom.org>><BR>>>><BR>>>><BR>>>> Subject: Re: How to get IQ samples from multiple rtl-sdr<BR>>>> dongles in<BR>>>> asynchronized manner?<BR>>>><BR>>>> Hi<BR>>>><BR>>>> rtl-sdr-relay<BR>>>> Some of the recommendations.<BR>>>> Please add PPM error calculation, exactly like new<BR>>>> rtl_test -p<BR>>>> but multiple receivers simultaneously.<BR>>>> It provides immediate information if something is wrong<BR>>>> with<BR>>>> USB or dongles.<BR>>>><BR>>>> https://github.com/keenerd/__rtl-sdr/commit/__b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f<BR>>>><BR>>>> <https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f><BR>>>> https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c<BR>>>><BR>>>> <https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c><BR>>>><BR>>>> Please add automatic eeprom PPM calibration<BR>>>><BR>>>> https://github.com/keenerd/__rtl-sdr/commit/__ecf267737ca52f5005b7a12a352307__e8cd763ed6<BR>>>><BR>>>><BR>>>> <https://github.com/keenerd/rtl-sdr/commit/ecf267737ca52f5005b7a12a352307e8cd763ed6><BR>>>><BR>>>> default sample rate 2.4M (28.8/12) or 1.2M (28.8/24),<BR>>>> probably<BR>>>> lower jitter<BR>>>> MAX_NUM_DEV 4->16 :)<BR>>>><BR>>>> Some nice to have features.<BR>>>> ip binding<BR>>>> multicast support<BR>>>> one common (interleaved) stream of all the receivers<BR>>>> timestamped stream<BR>>>><BR>>>> I'm trying to convert MATLAB script to Ocatve.<BR>>>><BR>>>> SG<BR>>>><BR>>>> On Mon, Dec 30, 2013 at 9:38 AM, Jiao Xianjun<BR>>>> <putaoshu@gmail.com <mailto:putaoshu@gmail.com><BR>>>> <mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>><BR>>>> wrote:<BR>>>><BR>>>> Hi guys,<BR>>>><BR>>>> For the multiple dongles synchronization in signal<BR>>>> level<BR>>>> instead of<BR>>>> bits/packets level, I setup a working repo in<BR>>>> github, and<BR>>>> write a<BR>>>> initial demo framework. See below:<BR>>>><BR>>>> https://github.com/__JiaoXianjun/multi-rtl-sdr-udp-__relay.git<BR>>>><BR>>>> <https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git><BR>>>><BR>>>> You may find information and instruction of demo<BR>>>> quickly by<BR>>>> reading<BR>>>> the README.<BR>>>><BR>>>> My initial purpose is performing in-fly calibration<BR>>>> for<BR>>>> multiple<BR>>>> dongles according to some pre-known signal (GSM,<BR>>>> ADS-B?) to<BR>>>> let them<BR>>>> work together coherently.<BR>>>><BR>>>> An ideal scheme may be that we should generate a<BR>>>> very<BR>>>> narrow band<BR>>>> and very week signal in (or just located at the edge<BR>>>> of) target<BR>>>> working band of dongles, and perform the software<BR>>>> in-fly<BR>>>> calibration<BR>>>> in background (or driver level). This would be user<BR>>>> friendly.<BR>>>><BR>>>> I know it is far from final state currently, and<BR>>>> many<BR>>>> things are not<BR>>>> clear yet (See TODO). But please join me if you also<BR>>>> think<BR>>>> this is a<BR>>>> good idea. Just check out the demo and run it to<BR>>>> have a look.<BR>>>><BR>>>> Currently I just test the demo in Ubuntu-Linux.<BR>>>><BR>>>> BR<BR>>>><BR>>>> Jiao Xianjun<BR>><BR>><BR></BODY></HTML>