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@earthlink.net<mailto:jdow@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@gmail.com
<mailto:putaoshu@gmail.com><mailto:putaoshu@gmail.com <mailto: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:
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
<mailto:putaoshu@gmail.com><mailto:putaoshu@gmail.com <mailto: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.
<mailto:osmocom-sdr@lists.__osmocom.org
From: Sdr Guru <mailto:sdrguru1@gmail.com
<mailto:sdrguru1@gmail.com>>
Sent: 2014/1/2 5:39
To: osmocom-sdr@lists.osmocom.org
<mailto:osmocom-sdr@lists.osmocom.org>https://github.com/keenerd/__rtl-sdr/commit/__b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f
<mailto: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/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f>
https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.chttps://github.com/keenerd/__rtl-sdr/commit/__ecf267737ca52f5005b7a12a352307__e8cd763ed6
<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/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@gmail.com <mailto:putaoshu@gmail.com><mailto:putaoshu@gmail.com <mailto:putaoshu@gmail.com>>> wrote:https://github.com/__JiaoXianjun/multi-rtl-sdr-udp-__relay.git
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