<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi everybody,<br><br></div>Let me report current progress of this thread.<br><br></div>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.<br>
<br></div><div>You can try it by yourself here : <a href="https://github.com/JiaoXianjun/multi-rtl-sdr-calibration">https://github.com/JiaoXianjun/multi-rtl-sdr-calibration</a><br><br></div><div>Some runs results have also been attached here. (time location of FCCH SCH and BCCH have also been shown there in different color)<br>
</div><br></div>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).<br>
<br></div>Unfortunately, this fixed sampling phase difference may vary from run to run (one rum means we restart rtl_tcp).<br></div>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.<br>
<br></div>Why do carrier and sampling error estimation and correction respectively?<br></div>Inspired by James Peroulas <a href="mailto:james@peroulas.com">james@peroulas.com</a> (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 <a href="mailto:omri@iluz.net">omri@iluz.net</a> 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).<br>
<br></div>But for my in-hands dongles, sampling error and carrier seems have relationship. This may be because they have common clock source inside dongle.<br><br></div>Which I detected by my matlab program gsm_sync_demod.m:<br>
</div>dongle 1: sampling PPM 27.1739, carrier PPM -28.513<br></div>dongle 2: sampling PPM 116.3043, carrier PPM -118.4247<br><br></div>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).<br>
</div><div>I don't know if my guess is correct. Anyone is familiar with the hardware architecture of the 820t dongle?<br></div><div><br>BR<br><br></div>Jiao Xianjun<br><br><div><div><div><div><div><div><div><div><div>
<div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 8, 2014 at 5:23 PM, jdow <span dir="ltr"><<a href="mailto:jdow@earthlink.net" target="_blank">jdow@earthlink.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<div class="im"><br>
<br>
On 2014/01/07 23:32, Jiao Xianjun wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
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 it<br>
directly as a reliable relay.<br>
<br>
<br>
On Tue, Jan 7, 2014 at 1:51 AM, jdow <<a href="mailto:jdow@earthlink.net" target="_blank">jdow@earthlink.net</a><br></div><div class="im">
<mailto:<a href="mailto:jdow@earthlink.net" target="_blank">jdow@earthlink.net</a>>> wrote:<br>
<br>
Have you tried using ping-pong buffers? Process on one buffer and receive<br>
to another. You may have to use multi-threading to make this work nicely.<br>
<br>
{^_^} Joanne/W6MKU<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 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) 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 code. This<br>
program use async mode and TCP, which has avoided the two 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 <<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a><br>
<mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a>><br></div><div><div class="h5">
<mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a> <mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a>>>> 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 is 1000000,<br>
question is:<br>
<br>
1. the rtlsdr_read_sync() will cost 1s exactly? Or is there any<br>
lower level<br>
device/driver buffer, which perhaps feed rtlsdr_read_sync() with<br>
history<br>
data quickly and makes rtlsdr_read_sync() return in a time 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 0.001s<br>
}<br>
Those samples during the 0.001s processing period will be 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 <<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a><br>
<mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a>><br></div></div><div class="im">
<mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a> <mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a>>>> wrote:<br>
<br>
I see some UDP packet performance issues in my laptop (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 get<br>
less data<br>
than expectation sometimes. Seem that fread for the first<br>
dongle works well.<br>
<br></div>
------------------------------<u></u>__----------------------------<u></u>--__--------------------<div class="im"><br>
From: Sdr Guru <mailto:<a href="mailto:sdrguru1@gmail.com" target="_blank">sdrguru1@gmail.com</a><br>
<mailto:<a href="mailto:sdrguru1@gmail.com" target="_blank">sdrguru1@gmail.com</a>>><br>
Sent: 2014/1/2 5:39<br>
<br>
To: <a href="mailto:osmocom-sdr@lists.osmocom.org" target="_blank">osmocom-sdr@lists.osmocom.org</a><br>
<mailto:<a href="mailto:osmocom-sdr@lists.osmocom.org" target="_blank">osmocom-sdr@lists.<u></u>osmocom.org</a>><br></div>
<mailto:<a href="mailto:osmocom-sdr@lists." target="_blank">osmocom-sdr@lists.</a>__<a href="http://osmocom.org" target="_blank">os<u></u>mocom.org</a><div class="im"><br>
<mailto:<a href="mailto:osmocom-sdr@lists.osmocom.org" target="_blank">osmocom-sdr@lists.<u></u>osmocom.org</a>>><br>
<br>
Subject: Re: How to get IQ samples from multiple rtl-sdr 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 rtl_test -p<br>
but multiple receivers simultaneously.<br>
It provides immediate information if something is wrong with<br>
USB or dongles.<br></div>
<a href="https://github.com/keenerd/__rtl-sdr/commit/__b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f" target="_blank">https://github.com/keenerd/__<u></u>rtl-sdr/commit/__<u></u>b5f89dcf40463130e717b6c9bb3a39<u></u>__a3c8b9535f</a><br>
<<a href="https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f" target="_blank">https://github.com/keenerd/<u></u>rtl-sdr/commit/<u></u>b5f89dcf40463130e717b6c9bb3a39<u></u>a3c8b9535f</a>><br>
<a href="https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c" target="_blank">https://github.com/keenerd/__<u></u>rtl-sdr/blob/master/src/rtl___<u></u>test.c</a><div class="im"><br>
<<a href="https://github.com/keenerd/rtl-sdr/blob/master/src/rtl_test.c" target="_blank">https://github.com/keenerd/<u></u>rtl-sdr/blob/master/src/rtl_<u></u>test.c</a>><br>
<br>
Please add automatic eeprom PPM calibration<br></div>
<a href="https://github.com/keenerd/__rtl-sdr/commit/__ecf267737ca52f5005b7a12a352307__e8cd763ed6" target="_blank">https://github.com/keenerd/__<u></u>rtl-sdr/commit/__<u></u>ecf267737ca52f5005b7a12a352307<u></u>__e8cd763ed6</a><div class="im">
<br>
<<a href="https://github.com/keenerd/rtl-sdr/commit/ecf267737ca52f5005b7a12a352307e8cd763ed6" target="_blank">https://github.com/keenerd/<u></u>rtl-sdr/commit/<u></u>ecf267737ca52f5005b7a12a352307<u></u>e8cd763ed6</a>><br>
<br>
default sample rate 2.4M (28.8/12) or 1.2M (28.8/24), 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>
<<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a> <mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a>><br></div><div class="im">
<mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a> <mailto:<a href="mailto:putaoshu@gmail.com" target="_blank">putaoshu@gmail.com</a>>>> wrote:<br>
<br>
Hi guys,<br>
<br>
For the multiple dongles synchronization in signal level<br>
instead of<br>
bits/packets level, I setup a working repo in github, and<br>
write a<br>
initial demo framework. See below:<br>
<br></div>
<a href="https://github.com/__JiaoXianjun/multi-rtl-sdr-udp-__relay.git" target="_blank">https://github.com/__<u></u>JiaoXianjun/multi-rtl-sdr-udp-<u></u>__relay.git</a><div class="im"><br>
<<a href="https://github.com/JiaoXianjun/multi-rtl-sdr-udp-relay.git" target="_blank">https://github.com/<u></u>JiaoXianjun/multi-rtl-sdr-udp-<u></u>relay.git</a>><br>
<br>
You may find information and instruction of demo quickly by<br>
reading<br>
the README.<br>
<br>
My initial purpose is performing in-fly calibration for<br>
multiple<br>
dongles according to some pre-known signal (GSM, ADS-B?) to<br>
let them<br>
work together coherently.<br>
<br>
An ideal scheme may be that we should generate a very<br>
narrow band<br>
and very week signal in (or just located at the edge of) target<br>
working band of dongles, and perform the software in-fly<br>
calibration<br>
in background (or driver level). This would be user friendly.<br>
<br>
I know it is far from final state currently, and many<br>
things are not<br>
clear yet (See TODO). But please join me if you also think<br>
this is a<br>
good idea. Just check out the demo and run it to have a look.<br>
<br>
Currently I just test the demo in Ubuntu-Linux.<br>
<br>
BR<br>
<br>
Jiao Xianjun<br>
</div></blockquote>
</blockquote></div><br></div>