<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>