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@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 sdrguru1@gmail.com Sent: 2014/1/2 5:39 To: osmocom-sdr@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/b5f89dcf40463130e717b6c9bb3a39a3c8... 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/ecf267737ca52f5005b7a12a352307e8cd...
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@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
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
I've been monitoring this thread and am interested in the progress. I'm a HAM and in the 2 meter FM band allocation we have APRS beaconing that I think could be used for synchronization. It doesn't matter GPS disciplined or anything, sync based on reception of an APRS packet and then take into account known distance from the APRS digipeater... just an idea.
73 -Ron / KB1UMH
On Sat, Jan 4, 2014 at 7:34 AM, Jiao Xianjun putaoshu@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:
- 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?
- 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@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 Sent: 2014/1/2 5:39
To: osmocom-sdr@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/b5f89dcf40463130e717b6c9bb3a39a3c8... 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/ecf267737ca52f5005b7a12a352307e8cd...
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@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
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
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@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:
- 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?
- 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@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 sdrguru1@gmail.com Sent: 2014/1/2 5:39
To: osmocom-sdr@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/b5f89dcf40463130e717b6c9bb3a39a3c8... 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/ecf267737ca52f5005b7a12a352307e8cd...
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@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
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
Has anyone had success with GNU RADIO (or some other SDR) ported to Android, and if they have please give me a place or link to start?
-
Jay Salsburg -
Jiao Xianjun -
Ron Senykoff