From laforge at gnumonks.org  Wed Jan  1 18:49:42 2014
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 1 Jan 2014 19:49:42 +0100
Subject: OsmoDevCon 2014 / Date / Venue
In-Reply-To: <20131105155825.GK12353@nataraja.gnumonks.org>
References: <20131105155825.GK12353@nataraja.gnumonks.org>
Message-ID: <20140101184942.GM7022@nataraja.gnumonks.org>

Dear all,

as the December 31st registration deadline has just passed,
I'm happy to announce that all 17 requests for participation have been
approved.  We are still below the ~20 people limit of the venue.

What we now need to do is to fill the schedule with talks / discussions.

Please add your suggestions to
https://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014
even if it is just a topic you would like to discuss about, and not
something that anyone feels compelled to hold a formal presentation
about.

Looking forward to seeing you in ~ 2 months in Berlin,

	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From sdrguru1 at gmail.com  Wed Jan  1 21:37:53 2014
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Wed, 1 Jan 2014 23:37:53 +0200
Subject: How to get IQ samples from multiple rtl-sdr dongles in a
	synchronized manner?
In-Reply-To: <CABs6FUo9KvxADVV1oK9w_T2m8V9Z7f3Fi5SLo1MBHAu9vGy_Hg@mail.gmail.com>
References: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
	<CACR-seexrTBw2+Qz2Ds8OcLck6PVuc49=LdN63U1x0FSRn9ZWw@mail.gmail.com>
	<CAHZVKw0Gv9eovgXuuQhqBtc2wW19YXSTLcSsTLn5=aPyqiGBBQ@mail.gmail.com>
	<CABs6FUo9KvxADVV1oK9w_T2m8V9Z7f3Fi5SLo1MBHAu9vGy_Hg@mail.gmail.com>
Message-ID: <CACR-sefvE3=S=mNj32RD8bihB6=XhAgqP__ej+Y8rmk=497ohA@mail.gmail.com>

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.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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140101/2954f804/attachment.htm>

From putaoshu at gmail.com  Thu Jan  2 12:09:56 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Thu, 2 Jan 2014 20:09:56 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <20131230160903.0edd821a25c25c62f5abc7cc@sm5bsz.com>
References: <52c15c7c.25c5440a.5956.ffffc3a7@mx.google.com>
	<20131230160903.0edd821a25c25c62f5abc7cc@sm5bsz.com>
Message-ID: <CABs6FUqc-mYoONy4dWAu00efyO7Qrjwv2mriL59khArG0Da_2w@mail.gmail.com>

Good to know that. Actually I also notice that radio astronomy is
attracting more and more signla processing researchers to work on it. Some
conference, such as ICASSP, envn setup a dedicate session on radio
astronomy. There is a radio astronomy called "DOME" are carrying on, which
involves computation on massive data and signal processing algorithm.

You have notice the problem that re-tuning will casue lossing
synchronization. That's also the problem I considered.

Because we always want the rtl-sdr work in the band we are interested, but
unfortunatelly in that band there maybe no any pre-known reference signal
for us to do synchronization. So a possible solution maybe make a beacon,
which can generate ultra-narrow-band or ultra-low-power signal in the
target band to help us do the on-line calibration. Any better ideas to
avoid this dedicate beacon?


On Mon, Dec 30, 2013 at 11:09 PM, Leif Asbrink <leif at sm5bsz.com> wrote:

> Hello Jiao,
>
> > My thought is doing the compensation by software according
> > to a common source over the air instead of over the hardware.
> >
> > Do you think it is doable?
>
> Yes. This is most certainly possible. The same thing was done long
> ago in radio astronomy. Two big telescopes on different continents
> made recordings aiming at a coomon direction in the sky. By
> evaluating the recordings they could make interferometry.
>
> http://en.wikipedia.org/wiki/Very-long-baseline_interferometry
>
> This is a very interesting approach for the future.
> With several dongles that have some signals in common it
> will be possible to synchronize in software.
>
> One of the common signals could be a GPS diciplined frequency
> standard that the software could use to provide extreme
> frequency stability on the processed signals from all the dongles.
>
> Once syncronization is arranged one could use the multi-channel
> antenna for interference suppression and to improve S/N of any
> desired signal.
>
> > And what would be the bottleneck according to your experience?
> There is a lot of code that has to be written, but
> I do not think there is any bottleneck to worry about
> in hardware
>
> > Any possibility to tune the hardware by software after we
> > estimate the synchronization error in frequency and timing?
> The entire passband of the dongles will be coherent.
> You can tune to any frequency within the passband and also
> evaluate several frequencies at the same time.
>
> In case one wants to change the center frequency one would
> loose synchronization and one would have to restart the
> synchronization procedure.
>
> SDR has just begun. Most of the interesting things have
> not yet been done:-)
>
> Regards
>
> Leif / SM5BSZ
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140102/836623bf/attachment.htm>

From putaoshu at gmail.com  Thu Jan  2 12:15:30 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Thu, 2 Jan 2014 20:15:30 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles in a
	synchronized manner?
In-Reply-To: <CACR-sefvE3=S=mNj32RD8bihB6=XhAgqP__ej+Y8rmk=497ohA@mail.gmail.com>
References: <CABs6FUqY9D8-+aiTYOYGfRpgKdeK=UboTzr19i1o+j=m7b9KUg@mail.gmail.com>
	<CACR-seexrTBw2+Qz2Ds8OcLck6PVuc49=LdN63U1x0FSRn9ZWw@mail.gmail.com>
	<CAHZVKw0Gv9eovgXuuQhqBtc2wW19YXSTLcSsTLn5=aPyqiGBBQ@mail.gmail.com>
	<CABs6FUo9KvxADVV1oK9w_T2m8V9Z7f3Fi5SLo1MBHAu9vGy_Hg@mail.gmail.com>
	<CACR-sefvE3=S=mNj32RD8bihB6=XhAgqP__ej+Y8rmk=497ohA@mail.gmail.com>
Message-ID: <CABs6FUqk+RgY6GaDqEaX84fwBfwqbGfMA+WvTd-Ki3yDqi7y4g@mail.gmail.com>

Hi

Thanks for youar advices. I will check them as soon as possible.
Now I am concentrating on GSM downlink FCCH and SCH channel synchronization.
Today, the FCCH can be detected roughly.

The repo is expected progressing fast recently.

BR

Jiao Xianjun



On Thu, Jan 2, 2014 at 5:37 AM, Sdr Guru <sdrguru1 at gmail.com> wrote:

> 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.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 at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140102/82ed06c4/attachment.htm>

From putaoshu at gmail.com  Thu Jan  2 13:25:45 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Thu, 2 Jan 2014 21:25:45 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
Message-ID: <52c568b9.e68e420a.6720.4cb2@mx.google.com>

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.

-----Original Message-----
From: "Sdr Guru" <sdrguru1 at gmail.com>
Sent: ?2014/?1/?2 5:39
To: "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at 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.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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140102/e205d889/attachment.htm>

From leif at sm5bsz.com  Thu Jan  2 18:23:26 2014
From: leif at sm5bsz.com (Leif Asbrink)
Date: Thu, 2 Jan 2014 19:23:26 +0100
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <CABs6FUqc-mYoONy4dWAu00efyO7Qrjwv2mriL59khArG0Da_2w@mail.gmail.com>
References: <52c15c7c.25c5440a.5956.ffffc3a7@mx.google.com>
	<20131230160903.0edd821a25c25c62f5abc7cc@sm5bsz.com>
	<CABs6FUqc-mYoONy4dWAu00efyO7Qrjwv2mriL59khArG0Da_2w@mail.gmail.com>
Message-ID: <20140102192326.481780fd629708edfe35c060@sm5bsz.com>

On Thu, 2 Jan 2014 20:09:56 +0800
Jiao Xianjun <putaoshu at gmail.com> wrote:

> Because we always want the rtl-sdr work in the band we are interested, but
> unfortunatelly in that band there maybe no any pre-known reference signal
> for us to do synchronization. So a possible solution maybe make a beacon,
> which can generate ultra-narrow-band or ultra-low-power signal in the
> target band to help us do the on-line calibration. Any better ideas to
> avoid this dedicate beacon?
To add a beacon is a very good idea. It can be placed near the band
edge where S/N is not so good due to aliasing so it would not disturb
signals of interest. By having very good frequency accuracy on the
beacon one can synchronize all the dongles to get very high stability
and accuracy:-)

 - leif -




From putaoshu at gmail.com  Sat Jan  4 12:34:18 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Sat, 4 Jan 2014 20:34:18 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <-5467292776275938694@unknownmsgid>
References: <-5467292776275938694@unknownmsgid>
Message-ID: <CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>

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 at 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 at gmail.com>
> Sent: 2014/1/2 5:39
> To: osmocom-sdr at 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.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 at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140104/7df44c19/attachment.htm>

From rsenykoff at gmail.com  Sat Jan  4 18:02:02 2014
From: rsenykoff at gmail.com (Ron Senykoff)
Date: Sat, 4 Jan 2014 13:02:02 -0500
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
References: <-5467292776275938694@unknownmsgid>
	<CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
Message-ID: <CAAiVu1aZTubPOCx5OU3CM==BMgZo0FFdCuQ9MV-YuT+BPA=PwA@mail.gmail.com>

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



From joris at jorisvr.nl  Sun Jan  5 14:54:19 2014
From: joris at jorisvr.nl (Joris van Rantwijk)
Date: Sun, 5 Jan 2014 15:54:19 +0100
Subject: Incorrect samplerate from RTL-SDR
Message-ID: <20140105155419.4e034a36@bever>

Hi,

Let me first say that librtlsdr is great. It is a fantastic way for me
to learn about SDR. Also, the library seems very well designed, easy to
use, and at a convenient level of abstraction. Many thanks for putting
this together!

I'm using librtlsdr to make a wideband FM receiver in C++. Perhaps more
about that later.

I noticed the following problem:
When I configure a sample rate lower than 1 MS/s, I often get a very
different sample rate then what I ask for. The library reports back the
same sample rate that I asked (via rtlsdr_get_sample_rate), but the
actual sample rate does not match at all.

For example, asking 900 kS/s results in ~ 290 kS/s.
Asking 800 kS/s gives ~ 285 kS/s.
Asking 600 kS/s gives ~ 255 kS/s.
Asking 400 kS/s gives ~ 1700 kS/s.
Asking 300 kS/s gives 300 kS/s.

I know the real samplerate from looking at the amount of data I get out
of the library in a given amount of time. I have also looked at the
FFT spectrum of the data and this confirms my estimate of the actual
sample rate (this eliminates the hypothesis that RTL is sampling at
configured rate but losing some of the data packets).

After diving into librtlsdr.c, I found that the pattern of configured
vs real sample rate can be explained by assuming a specific bit error in
the configuration word rsamp_ratio. Bit 28 of the word is forced equal
to bit 27.

It is as if somebody is doing
  rsamp_ratio = (rsamp_ratio  & 0x0fffffff) |
                ((rsamp_ratio & 0x08000000) << 1);
after the configuration is sent out via USB but before it is applied by
the RTL chip.

I have a Terratec Cinergy Tstick RC rev3, USB ID 0ccd:00d3.
The RTL-SDR library reports:
  Realtek, RTL2838UHIDIR, SN: 00000001
  Using device 0: Terratec Cinergy T Stick RC (Rev.3)
  Found Elonics E4000 tuner

Does this ring any bells for people who understand the RTL chip?
Is it caused by the difference between RTL2832 vs RTL2838?

I have seen other reports on the mailing list, saying that sample rates
between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
devices, then maybe it should be documented and the library can return
an error code for such sample rates. Otherwise people will keep walking
into this trap.

Kind regards,
Joris van Rantwijk.



From steve at steve-m.de  Sun Jan  5 15:37:06 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 05 Jan 2014 16:37:06 +0100
Subject: Incorrect samplerate from RTL-SDR
In-Reply-To: <20140105155419.4e034a36@bever>
References: <20140105155419.4e034a36@bever>
Message-ID: <52C97C22.5030102@steve-m.de>

Hi,

On 05.01.2014 15:54, Joris van Rantwijk wrote:
> I noticed the following problem:
> When I configure a sample rate lower than 1 MS/s, I often get a very
> different sample rate then what I ask for. The library reports back the
> same sample rate that I asked (via rtlsdr_get_sample_rate), but the
> actual sample rate does not match at all.

Yes, this is a known hardware limitation.

> It is as if somebody is doing
>   rsamp_ratio = (rsamp_ratio  & 0x0fffffff) |
>                 ((rsamp_ratio & 0x08000000) << 1);
> after the configuration is sent out via USB but before it is applied by
> the RTL chip.

Good find, we could use this to calculate the real rate in those cases.

> I have a Terratec Cinergy Tstick RC rev3, USB ID 0ccd:00d3.
> The RTL-SDR library reports:
>   Realtek, RTL2838UHIDIR, SN: 00000001
>   Using device 0: Terratec Cinergy T Stick RC (Rev.3)
>   Found Elonics E4000 tuner
> 
> Does this ring any bells for people who understand the RTL chip?
> Is it caused by the difference between RTL2832 vs RTL2838?

There is no RTL2838 really, it's only used in the USB descriptor of OEM
dongles, don't ask my why... but if you open up your dongle, you'll
find an RTL2832U.

> I have seen other reports on the mailing list, saying that sample rates
> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
> devices, then maybe it should be documented and the library can return
> an error code for such sample rates. Otherwise people will keep walking
> into this trap.

We could return some sort of error in those cases, but such low rates
(< 1MS/s) aren't recommended in general. First of all, the
anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
although the coefficients can be changed, I doubt you can get a nice
filter for lower bandwidths with such a low order. And then the ADCs
only have 8 bits resolution, so you want to improve that by decimating,
and also profit from decimation gain.
Even Realtek uses 2.048 MS/s for FM reception in their original Windows
software.

Regards,
Steve



From joris at jorisvr.nl  Sun Jan  5 17:04:01 2014
From: joris at jorisvr.nl (Joris van Rantwijk)
Date: Sun, 5 Jan 2014 18:04:01 +0100
Subject: Incorrect samplerate from RTL-SDR
In-Reply-To: <52C97C22.5030102@steve-m.de>
References: <20140105155419.4e034a36@bever>
	<52C97C22.5030102@steve-m.de>
Message-ID: <20140105180401.55de3aa3@bever>

Hi Steve,

Thanks for your quick answer.

On 2014-01-05, Steve Markgraf wrote:
> We could return some sort of error in those cases, but such low rates
> (< 1MS/s) aren't recommended in general.

If you know that the hardware is going to freak out, I think returning
-EINVAL is a more useful thing to do.

Normally I expect a function to either do what it promised or return an
error. Because RTL-SDR is reverse-engineered, it is not fair to judge
it to such high standards. Still, it would be good to document known
limitations of the RTL chip in the library via comments or error codes.

> First of all, the
> anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
> although the coefficients can be changed, I doubt you can get a nice
> filter for lower bandwidths with such a low order. And then the ADCs
> only have 8 bits resolution, so you want to improve that by
> decimating, and also profit from decimation gain.

That is good to know. So in general I should try to keep the hardware
sample rate high, and resample in software if needed.

Thanks,
Joris.



From steve at steve-m.de  Sun Jan  5 21:55:02 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Sun, 05 Jan 2014 22:55:02 +0100
Subject: Incorrect samplerate from RTL-SDR
In-Reply-To: <20140105180401.55de3aa3@bever>
References: <20140105155419.4e034a36@bever>	<52C97C22.5030102@steve-m.de>
	<20140105180401.55de3aa3@bever>
Message-ID: <52C9D4B6.6080408@steve-m.de>

Hi,

On 05.01.2014 18:04, Joris van Rantwijk wrote:
> If you know that the hardware is going to freak out, I think returning
> -EINVAL is a more useful thing to do.

Thanks for the suggestion, after some further testing I've now pushed
a change that excactly does this.

> Normally I expect a function to either do what it promised or return an
> error. Because RTL-SDR is reverse-engineered, it is not fair to judge
> it to such high standards. Still, it would be good to document known
> limitations of the RTL chip in the library via comments or error codes.

I've also documented the function in rtl-sdr.h now.

> That is good to know. So in general I should try to keep the hardware
> sample rate high, and resample in software if needed.

Yes, that indeed is the best approach with those devices.

Regards,
Steve




From putaoshu at gmail.com  Mon Jan  6 09:34:23 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Mon, 6 Jan 2014 17:34:23 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
References: <-5467292776275938694@unknownmsgid>
	<CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
Message-ID: <CABs6FUoXJV2NkgHLeG7SoFzNyyHL01EO6UhxZ6dENBDf5Op5dQ@mail.gmail.com>

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 at 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 at 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 at gmail.com>
>> Sent: 2014/1/2 5:39
>>
>> To: osmocom-sdr at 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.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 at 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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140106/b2e38546/attachment.htm>

From jsalsburg at bellsouth.net  Mon Jan  6 20:21:08 2014
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Mon, 6 Jan 2014 14:21:08 -0600
Subject: GNU RADIO ported to Android
In-Reply-To: <CABs6FUoXJV2NkgHLeG7SoFzNyyHL01EO6UhxZ6dENBDf5Op5dQ@mail.gmail.com>
References: <-5467292776275938694@unknownmsgid>	<CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
	<CABs6FUoXJV2NkgHLeG7SoFzNyyHL01EO6UhxZ6dENBDf5Op5dQ@mail.gmail.com>
Message-ID: <005401cf0b1c$d6236f30$826a4d90$@net>

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140106/1fbd46d0/attachment.htm>

From putaoshu at gmail.com  Wed Jan  8 07:40:29 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Wed, 8 Jan 2014 15:40:29 +0800
Subject: One issue with LTE cell scanner?
Message-ID: <CABs6FUrsdfRCjW-taZauX=mxaH0gNfNOQFC91N+isViR2P9=0w@mail.gmail.com>

I found that librtlsdr in github 003bd51167d9680e9721c7296323fdffe4be5a09
can't work with
LTE-Cell-Scanner<https://github.com/Evrytania/LTE-Cell-Scanner>5fa3df8a5d915c73cacea843021ce0c5b317522f
in github.
But librtlsdr release 0.5.2
2d0eaa898d2d4e271aed87ae3849a80ac12cf76c is OK.

The 'can't work' means:

LTE-Cell-Scanner show seg-fault/core-dump when it checks the second
frequency point after finishes the first frequency point.
A debug tracing shows that the crash is at rtlsdr_set_center_freq().

BR

Ryan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140108/4ebee862/attachment.htm>

From steve at steve-m.de  Wed Jan  8 18:13:00 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Wed, 08 Jan 2014 19:13:00 +0100
Subject: One issue with LTE cell scanner?
In-Reply-To: <CABs6FUrsdfRCjW-taZauX=mxaH0gNfNOQFC91N+isViR2P9=0w@mail.gmail.com>
References: <CABs6FUrsdfRCjW-taZauX=mxaH0gNfNOQFC91N+isViR2P9=0w@mail.gmail.com>
Message-ID: <52CD952C.9070701@steve-m.de>

Hi,

On 08.01.2014 08:40, Jiao Xianjun wrote:
> I found that librtlsdr in github
> 003bd51167d9680e9721c7296323fdffe4be5a09 can't work with
> LTE-Cell-Scanner <https://github.com/Evrytania/LTE-Cell-Scanner>
> 5fa3df8a5d915c73cacea843021ce0c5b317522f in github.
> But librtlsdr release 0.5.2
> 2d0eaa898d2d4e271aed87ae3849a80ac12cf76c is OK.
> 
> The 'can't work' means:
> 
> LTE-Cell-Scanner show seg-fault/core-dump when it checks the second
> frequency point after finishes the first frequency point.
> A debug tracing shows that the crash is at rtlsdr_set_center_freq().

On a first try, I can't reproduce the issue here.
Can you please provide the following additional information:

- exact command line arguments you invoked CellSearch with
- tuner of your rtl-sdr device (I tried with both R820T and E4000)
- name, version and architecture of the distribution you are using

Regards,
Steve



From johan+osmocom-sdr at lowestorder.com  Wed Jan  8 17:06:17 2014
From: johan+osmocom-sdr at lowestorder.com (johan+osmocom-sdr at lowestorder.com)
Date: Wed, 8 Jan 2014 12:06:17 -0500 (EST)
Subject: LIBOSMOSDR_FOUND = FALSE
Message-ID: <alpine.DEB.2.00.1401081205140.10213@acheron.squamscot.com>

Hey list, new guy here!

Got rtl-sdr built and it looks like my dongle (ezcap RTL2832U/FC0013) is 
working. I have gnuradio v3.7.2.1-116-ge751e54a installed and working.

I'm confused about configuring gr-osmosdr. In particular this output from 
cmake:

-- Configuring sysmocom OsmoSDR support...
--   Dependency LIBOSMOSDR_FOUND = FALSE
--   Disabling sysmocom OsmoSDR support.
--   Override with -DENABLE_OSMOSDR=ON/OFF

Isn't libosmosdr part of gr-osmosdr? How can it have itself as a dependency? 
I tried overriding, but it didn't have any effect.

I went ahead and built and installed anyway and a bunch of osmosdr stuff did 
get installed in my gnuradio dir (see below).

Before I try to get my dongle working in gnuradio, I just wanted to check 
that there aren't any important pieces missing due to "Disabling sysmocom 
OsmoSDR support". It sounds scary.

Thanks, Johan

foo:~/local/gnuradio> find . -name \*osmo\*
./lib/libgnuradio-osmosdr-0.1.1git.so.0
./lib/pkgconfig/gnuradio-osmosdr.pc
./lib/libgnuradio-osmosdr-0.1.1git.so.0.0.0
./lib/libgnuradio-osmosdr.so
./lib/libgnuradio-osmosdr-0.1.1git.so
./include/osmosdr
./include/osmosdr/swig/osmosdr_swig.i
./include/osmosdr/swig/osmosdr_swig_doc.i
./share/gnuradio/grc/blocks/osmosdr_source.xml
./share/gnuradio/grc/blocks/osmosdr_sink.xml
./lib64/python2.7/site-packages/osmosdr
./lib64/python2.7/site-packages/osmosdr/osmosdr_swig.pyc
./lib64/python2.7/site-packages/osmosdr/osmocom_siggen_base.pyo
./lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py
./lib64/python2.7/site-packages/osmosdr/osmocom_siggen_base.py
./lib64/python2.7/site-packages/osmosdr/_osmosdr_swig.so
./lib64/python2.7/site-packages/osmosdr/osmocom_siggen_base.pyc
./lib64/python2.7/site-packages/osmosdr/osmosdr_swig.pyo
./bin/osmocom_siggen_nogui
./bin/osmocom_fft
./bin/osmocom_siggen
./bin/osmocom_spectrum_sense
foo:~/local/gnuradio>



From 246tnt at gmail.com  Thu Jan  9 08:37:29 2014
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 9 Jan 2014 09:37:29 +0100
Subject: LIBOSMOSDR_FOUND = FALSE
In-Reply-To: <alpine.DEB.2.00.1401081205140.10213@acheron.squamscot.com>
References: <alpine.DEB.2.00.1401081205140.10213@acheron.squamscot.com>
Message-ID: <CAHL+j09J-y-ZDatZupi_0kv1hUWLtx1nP49ZWATyZKmAYZpd=Q@mail.gmail.com>

Hi,

> I'm confused about configuring gr-osmosdr. In particular this output from
> cmake:
>
> -- Configuring sysmocom OsmoSDR support...
> --   Dependency LIBOSMOSDR_FOUND = FALSE
> --   Disabling sysmocom OsmoSDR support.
> --   Override with -DENABLE_OSMOSDR=ON/OFF
>
> Isn't libosmosdr part of gr-osmosdr? How can it have itself as a dependency?
> I tried overriding, but it didn't have any effect.

No libosmosdr is not part of gr-osmosdr and is not required.

libosmosdr is a library to support an "Osmo-SDR" hardware (
http://sdr.osmocom.org/trac/attachment/wiki/WikiStart/osmosdr-beta.jpg
). So if you don't own this hardware, there is no need for the
library.

gr-osmosdr was originally the block to support that same hw. Then
rtl-sdr support was added to it, then uhd, then ... and finally
gr-osmosdr evolved to be the block it is today, accepting _many_
different hardware with the same GR block interface to allow GR app to
work without mod with all of theses.

Granted the choice of naming isn't the best, but renaming at this
point would just create havoc and break stuff ...


Cheers,

    Sylvain



From nikos.balkanas at eyeonix.com  Thu Jan  9 11:51:27 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 9 Jan 2014 13:51:27 +0200
Subject: Elonics DVB-T dongle initialization
Message-ID: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>

Hi,

I am new to sdr and reading the site, I got an Elonics DVB-T dongle for it.
Does anyone know the initialization sequence that need to be send for it to
work correctly, or a reference for them?

I work with Linux and a lot of the rtl drivers are for windows. Therefore I
am developing my own drivers and would like to skip libsdr for now.

Thanks,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140109/745079af/attachment.htm>

From steve at steve-m.de  Thu Jan  9 14:00:18 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 09 Jan 2014 15:00:18 +0100
Subject: Elonics DVB-T dongle initialization
In-Reply-To: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>
References: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>
Message-ID: <52CEAB72.4000900@steve-m.de>

Hi,

On 09.01.2014 12:51, Nikos Balkanas wrote:
> I work with Linux and a lot of the rtl drivers are for windows. Therefore I
> am developing my own drivers and would like to skip libsdr for now.

"a lot of the rtl drivers are for windows"?
rtl-sdr was originally developed on and for Linux, but since it is
based on libusb it is now used on Windows and OS X as well.

Build instructions for Linux can be found here:
http://sdr.osmocom.org/trac/wiki/rtl-sdr#Buildingthesoftware

rtl-sdr will is part of Debian sid and will also be found in
Ubuntu 14.04:

https://launchpad.net/ubuntu/trusty/+package/rtl-sdr

Regards,
Steve



From nikos.balkanas at eyeonix.com  Thu Jan  9 15:52:28 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 9 Jan 2014 17:52:28 +0200
Subject: Elonics DVB-T dongle initialization
In-Reply-To: <52CEAB72.4000900@steve-m.de>
References: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>
	<52CEAB72.4000900@steve-m.de>
Message-ID: <CAAdsYnbgo4D=fw+S1N-TZsfnL5TwDoKhPiqTZJ4nHf=1e=HCjg@mail.gmail.com>

Thx,

I searched for "Elonics +DVB-T +driver + download" and ended up with HDSDR,
gr-baz and librtl2832++. All except gr-baz are windows based.
rtl-sdr built in a jiffy in Ubuntu 12.04. Except 1 thing:

"sudo cmake ../ -DINSTALL_UDEV_RULES=ON

There is no such target in the makefile. Site needs to be updated.

BR,
Nikos



On Thu, Jan 9, 2014 at 4:00 PM, Steve Markgraf <steve at steve-m.de> wrote:

> Hi,
>
>
> On 09.01.2014 12:51, Nikos Balkanas wrote:
>
>> I work with Linux and a lot of the rtl drivers are for windows. Therefore
>> I
>> am developing my own drivers and would like to skip libsdr for now.
>>
>
> "a lot of the rtl drivers are for windows"?
> rtl-sdr was originally developed on and for Linux, but since it is
> based on libusb it is now used on Windows and OS X as well.
>
> Build instructions for Linux can be found here:
> http://sdr.osmocom.org/trac/wiki/rtl-sdr#Buildingthesoftware
>
> rtl-sdr will is part of Debian sid and will also be found in
> Ubuntu 14.04:
>
> https://launchpad.net/ubuntu/trusty/+package/rtl-sdr
>
> Regards,
> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140109/ec10c351/attachment.htm>

From steve at steve-m.de  Thu Jan  9 15:59:47 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 09 Jan 2014 16:59:47 +0100
Subject: Elonics DVB-T dongle initialization
In-Reply-To: <CAAdsYnbgo4D=fw+S1N-TZsfnL5TwDoKhPiqTZJ4nHf=1e=HCjg@mail.gmail.com>
References: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>	<52CEAB72.4000900@steve-m.de>
	<CAAdsYnbgo4D=fw+S1N-TZsfnL5TwDoKhPiqTZJ4nHf=1e=HCjg@mail.gmail.com>
Message-ID: <52CEC773.8040405@steve-m.de>

Hi,

On 09.01.2014 16:52, Nikos Balkanas wrote:

> "sudo cmake ../ -DINSTALL_UDEV_RULES=ON
>
> There is no such target in the makefile. Site needs to be updated.

?!

steve at sleeper:/tmp$ cd rtl-sdr/
steve at sleeper:/tmp/rtl-sdr$ mkdir build
steve at sleeper:/tmp/rtl-sdr$ cd build/
steve at sleeper:/tmp/rtl-sdr/build$ cmake ../ -DINSTALL_UDEV_RULES=ON
[...]
-- Build files have been written to: /tmp/rtl-sdr/build
steve at sleeper:/tmp/rtl-sdr/build$ make
[...]
steve at sleeper:/tmp/rtl-sdr/build$ sudo make install
[...]
-- Installing: /etc/udev/rules.d/rtl-sdr.rules

Are you sure you really followed the instructions in the wiki?

Regards,
Steve



From steve at steve-m.de  Thu Jan  9 17:18:00 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 09 Jan 2014 18:18:00 +0100
Subject: Elonics DVB-T dongle initialization
In-Reply-To: <52CEC773.8040405@steve-m.de>
References: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>	<52CEAB72.4000900@steve-m.de>	<CAAdsYnbgo4D=fw+S1N-TZsfnL5TwDoKhPiqTZJ4nHf=1e=HCjg@mail.gmail.com>
	<52CEC773.8040405@steve-m.de>
Message-ID: <52CED9C8.3070007@steve-m.de>

Hi,

On 09.01.2014 18:05, Nikos Balkanas wrote:
 > Yeap. Repeated it 3x. Was referring to:
 >
 > sudo make install-udev-rules
 >
 >
 > not to make install ;-)

As you can see in the wiki, the caption of that section is "Building
with autotools". As you used cmake, this section is not relevant, since 
the udev rules are installed by running sudo make install when
INSTALL_UDEV_RULES has been set to ON.

Regards,
Steve



From nikos.balkanas at eyeonix.com  Thu Jan  9 17:42:07 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 9 Jan 2014 19:42:07 +0200
Subject: Elonics DVB-T dongle initialization
In-Reply-To: <52CED9C8.3070007@steve-m.de>
References: <CAAdsYnYhbRn_e-usdzxgS4HYgkMWPyt=G1-nYi=3A3d2gcPchg@mail.gmail.com>
	<52CEAB72.4000900@steve-m.de>
	<CAAdsYnbgo4D=fw+S1N-TZsfnL5TwDoKhPiqTZJ4nHf=1e=HCjg@mail.gmail.com>
	<52CEC773.8040405@steve-m.de> <52CED9C8.3070007@steve-m.de>
Message-ID: <CAAdsYnbXPRA9w6ww-MePfm6om=SQsn8vbw8S4n0d9Om8dsnaQA@mail.gmail.com>

You are right.

And thanks again for the rtl-sdr tip ;-)

Nikos


On Thu, Jan 9, 2014 at 7:18 PM, Steve Markgraf <steve at steve-m.de> wrote:

> Hi,
>
>
> On 09.01.2014 18:05, Nikos Balkanas wrote:
> > Yeap. Repeated it 3x. Was referring to:
> >
> > sudo make install-udev-rules
> >
> >
> > not to make install ;-)
>
> As you can see in the wiki, the caption of that section is "Building
> with autotools". As you used cmake, this section is not relevant, since
> the udev rules are installed by running sudo make install when
> INSTALL_UDEV_RULES has been set to ON.
>
> Regards,
> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140109/c651376c/attachment.htm>

From n1gp at hotmail.com  Thu Jan  9 22:53:30 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Thu, 9 Jan 2014 17:53:30 -0500
Subject: Incorrect samplerate from RTL-SDR
Message-ID: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>

Hi Steve,

In regards to your post about the anti-aliasing filter
you referred to, it appears that it is getting set in
librtlsdr.c, rtlsdr_init_baseband()

If one wanted to change that to optimize the anti-aliasing
to a lower bandwidth, say 1500 Khz instead of the 2048 Khz

How would you change the fir_coeff[] table entries to achieve
this? The 8 bit entries and 12 bit entries are confusing to me.


==== orig post ====

> I have seen other reports on the mailing list, saying that sample rates
> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
> devices, then maybe it should be documented and the library can return
> an error code for such sample rates. Otherwise people will keep walking
> into this trap.

We could return some sort of error in those cases, but such low rates
(< 1MS/s) aren't recommended in general. First of all, the
anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
although the coefficients can be changed, I doubt you can get a nice
filter for lower bandwidths with such a low order. And then the ADCs
only have 8 bits resolution, so you want to improve that by decimating,
and also profit from decimation gain.
Even Realtek uses 2.048 MS/s for FM reception in their original Windows
software. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140109/9eef9131/attachment.htm>

From j-pi at seznam.cz  Fri Jan 10 00:50:51 2014
From: j-pi at seznam.cz (=?UTF-8?B?SmnFmcOtIFBpbmthdmE=?=)
Date: Fri, 10 Jan 2014 01:50:51 +0100
Subject: Incorrect samplerate from RTL-SDR
In-Reply-To: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
Message-ID: <52CF43EB.5010200@seznam.cz>

You cannot fit internal FIR filter in SDR to such narrow bandwidth, it
does not have enough coefficients.
You can adapt it only to wider band width (some small improvement can be
done for
sample rates above 2048 kHz). Select proper values is a bit tricky and
specialised software
is almost unavoidable. You can get good hint from FIR filter designer in
GNU Radio, but
this software is not designed for this task and the work is cumbersome.

The 8 / 12 bit means the coefficients  can be only in range form -128 to
127 / -2048 to 2047.
The usual FIR coefficients absolute value decreases from center to the
side eg:

1, -3, 5, 10, 5, -3, 1,

so this just reduces complexity of the device.

For lower bandwidth you need more cofficients (more samples because the
wave is wider).

JP


Dne 9.1.2014 23:53, Richard Koch napsal(a):
> Hi Steve,
>
> In regards to your post about the anti-aliasing filter
> you referred to, it appears that it is getting set in
> librtlsdr.c, rtlsdr_init_baseband()
>
> If one wanted to change that to optimize the anti-aliasing
> to a lower bandwidth, say 1500 Khz instead of the 2048 Khz
>
> How would you change the fir_coeff[] table entries to achieve
> this? The 8 bit entries and 12 bit entries are confusing to me.
>
>
> ==== orig post ====
>
>> I have seen other reports on the mailing list, saying that sample rates
>> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
>> devices, then maybe it should be documented and the library can return
>> an error code for such sample rates. Otherwise people will keep walking
>> into this trap.
> We could return some sort of error in those cases, but such low rates
> (< 1MS/s) aren't recommended in general. First of all, the
> anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
> although the coefficients can be changed, I doubt you can get a nice
> filter for lower bandwidths with such a low order. And then the ADCs
> only have 8 bits resolution, so you want to improve that by decimating,
> and also profit from decimation gain.
> Even Realtek uses 2.048 MS/s for FM reception in their original Windows
> software. 		 	   		  




From n1gp at hotmail.com  Fri Jan 10 04:23:02 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Thu, 9 Jan 2014 23:23:02 -0500
Subject: FW: Incorrect samplerate from RTL-SDR
In-Reply-To: <BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>,
	<52CF43EB.5010200@seznam.cz>,
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
Message-ID: <BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>





JP,

Thanks for your reply and explanation.

I understand the cutting the coefficient table in half since it
repeats in a backwards manner, but what I don't understand
is why half the table is in 8 bit and the other in 12 bit?

Also I now understand that there is not enough room for extra
coefficients in the rtl2832 for lower bandwidth than 2048Khz.
That is unfortunate if you want lower bandwidth as it forces you
to sample at 2048 or greater and perform your own FIR and
decimation consuming CPU cycles on your host. On an armv4
SBC that is very taxing :^)

-Rick

> Date: Fri, 10 Jan 2014 01:50:51 +0100
> From: j-pi at seznam.cz
> To: n1gp at hotmail.com; osmocom-sdr at lists.osmocom.org
> Subject: Re: Incorrect samplerate from RTL-SDR
> CC: steve at steve-m.de
> 
> You cannot fit internal FIR filter in SDR to such narrow bandwidth, it
> does not have enough coefficients.
> You can adapt it only to wider band width (some small improvement can be
> done for
> sample rates above 2048 kHz). Select proper values is a bit tricky and
> specialised software
> is almost unavoidable. You can get good hint from FIR filter designer in
> GNU Radio, but
> this software is not designed for this task and the work is cumbersome.
> 
> The 8 / 12 bit means the coefficients  can be only in range form -128 to
> 127 / -2048 to 2047.
> The usual FIR coefficients absolute value decreases from center to the
> side eg:
> 
> 1, -3, 5, 10, 5, -3, 1,
> 
> so this just reduces complexity of the device.
> 
> For lower bandwidth you need more cofficients (more samples because the
> wave is wider).
> 
> JP
> 
> 
> Dne 9.1.2014 23:53, Richard Koch napsal(a):
> > Hi Steve,
> >
> > In regards to your post about the anti-aliasing filter
> > you referred to, it appears that it is getting set in
> > librtlsdr.c, rtlsdr_init_baseband()
> >
> > If one wanted to change that to optimize the anti-aliasing
> > to a lower bandwidth, say 1500 Khz instead of the 2048 Khz
> >
> > How would you change the fir_coeff[] table entries to achieve
> > this? The 8 bit entries and 12 bit entries are confusing to me.
> >
> >
> > ==== orig post ====
> >
> >> I have seen other reports on the mailing list, saying that sample rates
> >> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
> >> devices, then maybe it should be documented and the library can return
> >> an error code for such sample rates. Otherwise people will keep walking
> >> into this trap.
> > We could return some sort of error in those cases, but such low rates
> > (< 1MS/s) aren't recommended in general. First of all, the
> > anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
> > although the coefficients can be changed, I doubt you can get a nice
> > filter for lower bandwidths with such a low order. And then the ADCs
> > only have 8 bits resolution, so you want to improve that by decimating,
> > and also profit from decimation gain.
> > Even Realtek uses 2.048 MS/s for FM reception in their original Windows
> > software. 		 	   		  
> 
> 
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140109/5181da3b/attachment.htm>

From j-pi at seznam.cz  Fri Jan 10 09:52:07 2014
From: j-pi at seznam.cz (=?UTF-8?B?SmnFmcOtIFBpbmthdmE=?=)
Date: Fri, 10 Jan 2014 10:52:07 +0100
Subject: FW: Incorrect samplerate from RTL-SDR
In-Reply-To: <BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>,
	<52CF43EB.5010200@seznam.cz>,
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
Message-ID: <52CFC2C7.8080904@seznam.cz>

Dne 10.1.2014 05:23, Richard Koch napsal(a):
>
>
>
> JP,
>
> Thanks for your reply and explanation.
>
> I understand the cutting the coefficient table in half since it
> repeats in a backwards manner, but what I don't understand
> is why half the table is in 8 bit and the other in 12 bit?
8 / 12 bit is used inside the dongle and is how the hardware is designed.
It reduces the cost of hardware. You can think of it in the way
the coefficients rea all 12 bit, but for the first 8 coefficients the
top 4 bits must
be always zero.
This is only the bite width of coefficients not the actual width of
multiplication
result. Unfortunately I'm not able to explain details about FIR and
hardware design here.

I'm not sure if I explained your question, try reformulate and extend it
if not.

>
> Also I now understand that there is not enough room for extra
> coefficients in the rtl2832 for lower bandwidth than 2048Khz.
> That is unfortunate if you want lower bandwidth as it forces you
> to sample at 2048 or greater and perform your own FIR and
> decimation consuming CPU cycles on your host. On an armv4
> SBC that is very taxing :^)
Working with such hardware is always a challenge, but the tweaked result
is often beautifull.
Good luck,
    JP
>
> -Rick
>
>> Date: Fri, 10 Jan 2014 01:50:51 +0100
>> From: j-pi at seznam.cz
>> To: n1gp at hotmail.com; osmocom-sdr at lists.osmocom.org
>> Subject: Re: Incorrect samplerate from RTL-SDR
>> CC: steve at steve-m.de
>>
>> You cannot fit internal FIR filter in SDR to such narrow bandwidth, it
>> does not have enough coefficients.
>> You can adapt it only to wider band width (some small improvement can be
>> done for
>> sample rates above 2048 kHz). Select proper values is a bit tricky and
>> specialised software
>> is almost unavoidable. You can get good hint from FIR filter designer in
>> GNU Radio, but
>> this software is not designed for this task and the work is cumbersome.
>>
>> The 8 / 12 bit means the coefficients  can be only in range form -128 to
>> 127 / -2048 to 2047.
>> The usual FIR coefficients absolute value decreases from center to the
>> side eg:
>>
>> 1, -3, 5, 10, 5, -3, 1,
>>
>> so this just reduces complexity of the device.
>>
>> For lower bandwidth you need more cofficients (more samples because the
>> wave is wider).
>>
>> JP
>>
>>
>> Dne 9.1.2014 23:53, Richard Koch napsal(a):
>>> Hi Steve,
>>>
>>> In regards to your post about the anti-aliasing filter
>>> you referred to, it appears that it is getting set in
>>> librtlsdr.c, rtlsdr_init_baseband()
>>>
>>> If one wanted to change that to optimize the anti-aliasing
>>> to a lower bandwidth, say 1500 Khz instead of the 2048 Khz
>>>
>>> How would you change the fir_coeff[] table entries to achieve
>>> this? The 8 bit entries and 12 bit entries are confusing to me.
>>>
>>>
>>> ==== orig post ====
>>>
>>>> I have seen other reports on the mailing list, saying that sample rates
>>>> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
>>>> devices, then maybe it should be documented and the library can return
>>>> an error code for such sample rates. Otherwise people will keep walking
>>>> into this trap.
>>> We could return some sort of error in those cases, but such low rates
>>> (< 1MS/s) aren't recommended in general. First of all, the
>>> anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
>>> although the coefficients can be changed, I doubt you can get a nice
>>> filter for lower bandwidths with such a low order. And then the ADCs
>>> only have 8 bits resolution, so you want to improve that by decimating,
>>> and also profit from decimation gain.
>>> Even Realtek uses 2.048 MS/s for FM reception in their original Windows
>>> software. 		 	   		  
>>
>  		 	   		   		 	   		  




From retzlerandras at gmail.com  Fri Jan 10 15:24:09 2014
From: retzlerandras at gmail.com (=?ISO-8859-1?Q?Andr=E1s_Retzler?=)
Date: Fri, 10 Jan 2014 16:24:09 +0100
Subject: FW: Incorrect samplerate from RTL-SDR
In-Reply-To: <52CFC2C7.8080904@seznam.cz>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<52CFC2C7.8080904@seznam.cz>
Message-ID: <CABrNoDA3sZdPAc-AxqcVNLbE71aBwdJ8+GF7nGSYe1Ukk9BCyg@mail.gmail.com>

Hi All,

Thanks for explaining how that works.

I was curious about the frequency response of the original filter that the
Windows driver used, so I've created a little script to calculate it.
Not sure if it helps anyone (I suppose that you've already done this), but
here are the results:
image: http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.png
script: http://ha5kfu.sch.bme.hu/up/levlista/sim_rtl_filt.py
It turns out that amplitude is quite at its maximum until ~0.67 MHz, and is
half of the maximum at about 1.5 MHz (-3 dB bandwidth).
Looks okay for 2 Msps.
Anyway, I'll be using only +/-500 kHz for hunting for really weak signals
:-))

Regards,

Andras, ha7ilm


2014/1/10 Ji?? Pinkava <j-pi at seznam.cz>

> Dne 10.1.2014 05:23, Richard Koch napsal(a):
> >
> >
> >
> > JP,
> >
> > Thanks for your reply and explanation.
> >
> > I understand the cutting the coefficient table in half since it
> > repeats in a backwards manner, but what I don't understand
> > is why half the table is in 8 bit and the other in 12 bit?
> 8 / 12 bit is used inside the dongle and is how the hardware is designed.
> It reduces the cost of hardware. You can think of it in the way
> the coefficients rea all 12 bit, but for the first 8 coefficients the
> top 4 bits must
> be always zero.
> This is only the bite width of coefficients not the actual width of
> multiplication
> result. Unfortunately I'm not able to explain details about FIR and
> hardware design here.
>
> I'm not sure if I explained your question, try reformulate and extend it
> if not.
>
> >
> > Also I now understand that there is not enough room for extra
> > coefficients in the rtl2832 for lower bandwidth than 2048Khz.
> > That is unfortunate if you want lower bandwidth as it forces you
> > to sample at 2048 or greater and perform your own FIR and
> > decimation consuming CPU cycles on your host. On an armv4
> > SBC that is very taxing :^)
> Working with such hardware is always a challenge, but the tweaked result
> is often beautifull.
> Good luck,
>     JP
> >
> > -Rick
> >
> >> Date: Fri, 10 Jan 2014 01:50:51 +0100
> >> From: j-pi at seznam.cz
> >> To: n1gp at hotmail.com; osmocom-sdr at lists.osmocom.org
> >> Subject: Re: Incorrect samplerate from RTL-SDR
> >> CC: steve at steve-m.de
> >>
> >> You cannot fit internal FIR filter in SDR to such narrow bandwidth, it
> >> does not have enough coefficients.
> >> You can adapt it only to wider band width (some small improvement can be
> >> done for
> >> sample rates above 2048 kHz). Select proper values is a bit tricky and
> >> specialised software
> >> is almost unavoidable. You can get good hint from FIR filter designer in
> >> GNU Radio, but
> >> this software is not designed for this task and the work is cumbersome.
> >>
> >> The 8 / 12 bit means the coefficients  can be only in range form -128 to
> >> 127 / -2048 to 2047.
> >> The usual FIR coefficients absolute value decreases from center to the
> >> side eg:
> >>
> >> 1, -3, 5, 10, 5, -3, 1,
> >>
> >> so this just reduces complexity of the device.
> >>
> >> For lower bandwidth you need more cofficients (more samples because the
> >> wave is wider).
> >>
> >> JP
> >>
> >>
> >> Dne 9.1.2014 23:53, Richard Koch napsal(a):
> >>> Hi Steve,
> >>>
> >>> In regards to your post about the anti-aliasing filter
> >>> you referred to, it appears that it is getting set in
> >>> librtlsdr.c, rtlsdr_init_baseband()
> >>>
> >>> If one wanted to change that to optimize the anti-aliasing
> >>> to a lower bandwidth, say 1500 Khz instead of the 2048 Khz
> >>>
> >>> How would you change the fir_coeff[] table entries to achieve
> >>> this? The 8 bit entries and 12 bit entries are confusing to me.
> >>>
> >>>
> >>> ==== orig post ====
> >>>
> >>>> I have seen other reports on the mailing list, saying that sample
> rates
> >>>> between 300 kS/s and 900 kS/s don't work. If this applies to all RTL
> >>>> devices, then maybe it should be documented and the library can return
> >>>> an error code for such sample rates. Otherwise people will keep
> walking
> >>>> into this trap.
> >>> We could return some sort of error in those cases, but such low rates
> >>> (< 1MS/s) aren't recommended in general. First of all, the
> >>> anti-aliasing filter we're using has a fixed bandwidth of 2 MHz, and
> >>> although the coefficients can be changed, I doubt you can get a nice
> >>> filter for lower bandwidths with such a low order. And then the ADCs
> >>> only have 8 bits resolution, so you want to improve that by decimating,
> >>> and also profit from decimation gain.
> >>> Even Realtek uses 2.048 MS/s for FM reception in their original Windows
> >>> software.
> >>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140110/fcc9d8f5/attachment.htm>

From batchdrake at gmail.com  Sat Jan 11 10:56:15 2014
From: batchdrake at gmail.com (=?ISO-8859-1?Q?Gonzalo_Jos=E9_Carracedo_Carballal?=)
Date: Sat, 11 Jan 2014 11:56:15 +0100
Subject: Bug in rtl-sdr / libusb / usbfs
Message-ID: <CANO8ntKtX-J7aPMTjXzKNpraGw24t=rTohqOB09GPJr4kPdyHA@mail.gmail.com>

Hello!

This is my first time using this mailing list, hope it's the right
place to post this.

I compiled rtl-sdr under Debian 7.2 (32 bits x86) it detects my ezcap
e4k properly but it's unable to read samples. When running rtl_sdr
like this, it just hangs:

---8<--------------------------------------------------------------------------------------------
% rtl_sdr -f 100000000 -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in async mode...
---8<--------------------------------------------------------------------------------------------

Pressing Ctrl+C only makes rdl_sdr say "Signal caught, exiting!", but
it won't exit unless you kill it explicitly with SIGKILL. If I run it
in synchronous mode, I get this output instead:

---8<--------------------------------------------------------------------------------------------
% rtl_sdr -f 100000000 -S -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in sync mode...
WARNING: sync read failed.

Library error -8, exiting...
rtlsdr_demod_write_reg failed with -1
---8<--------------------------------------------------------------------------------------------

I tried to reinstall libusb, recompiling it from a newer version (I'm
currently using 1.0-16rc10)  and got the same output. As -8 means
overflow for libusb, I decided to increase the output block size. I
had to edit rtl_sdr.c to read as much as 30M, and that was the only
way I could get some output. Block sizes below 10M just won't do the
trick:

---8<--------------------------------------------------------------------------------------------
 % rtl_sdr -b 30000000 -f 100000000 -S -
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN:

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in sync mode...
Short read, samples lost, exiting!

Library error 0, exiting...
(here be messy bytes of 64 bytes sampled by RTL)
---8<--------------------------------------------------------------------------------------------

That's why I recompiled libusb with logging, and I got this output
(now, with 3M blocks):

---8<--------------------------------------------------------------------------------------------
[...]
Reading samples in sync mode...
libusb: 1.079895 debug [submit_bulk_transfer] need 184 urbs for new
transfer with length 3000000
libusb: 1.080660 debug [libusb_handle_events_timeout_completed] doing
our own event handling
libusb: 1.080692 debug [handle_events] poll() 4 fds with timeout in 60000ms
libusb: 1.083056 debug [handle_events] poll() returned 1
libusb: 1.083082 debug [reap_for_handle] urb type=3 status=-75 transferred=64
libusb: 1.083104 debug [handle_bulk_completion] handling completion
status -75 of bulk urb 1/184
libusb: 1.083125 debug [handle_bulk_completion] overflow, actual_length=64
libusb: 1.083146 debug [disarm_timerfd]
libusb: 1.083161 debug [usbi_handle_transfer_completion] transfer
0x97a0424 has callback 0xb775c7f0
libusb: 1.083182 debug [bulk_transfer_cb] actual_length=64
WARNING: sync read failed.

Library error -8, exiting...
[...]
---8<--------------------------------------------------------------------------------------------

Status -75 (overflow) made me think about a limitation on the URB size
in my system, but it looks that in Linux that's a standard (16K), so I
ran out of ideas. I don't know where the problem is anymore, whether
in rtl-sdr, libusb, usbfs or even in my system; because I've compiled
it in two different systems already (my laptop - Ubuntu 12.04 - and my
home computer - Debian Sid -) and it works fine in both of them.

Regards,
-- 
>> Gonzalo Jos? Carracedo Carballal



From nikos.balkanas at eyeonix.com  Sat Jan 11 11:24:21 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Sat, 11 Jan 2014 13:24:21 +0200
Subject: Bug in rtl-sdr / libusb / usbfs
In-Reply-To: <CANO8ntKtX-J7aPMTjXzKNpraGw24t=rTohqOB09GPJr4kPdyHA@mail.gmail.com>
References: <CANO8ntKtX-J7aPMTjXzKNpraGw24t=rTohqOB09GPJr4kPdyHA@mail.gmail.com>
Message-ID: <CAAdsYnaU-d8XtZM23uO98Tz7jr0vpLFnmSUKj_ubAXpPNkXHmQ@mail.gmail.com>

Hi,

I am also fairly new to the list, but I am using the DVB-T e4k dongle that
you use. I was under the impression that e4k has a range up to 2.2 Mhz, and
yet you are feeding it 100 Mhz. I am surprised it even tunes in! I don't
think it is meant to work that high :-(

BR,
Nikos


On Sat, Jan 11, 2014 at 12:56 PM, Gonzalo Jos? Carracedo Carballal <
batchdrake at gmail.com> wrote:

> Hello!
>
> This is my first time using this mailing list, hope it's the right
> place to post this.
>
> I compiled rtl-sdr under Debian 7.2 (32 bits x86) it detects my ezcap
> e4k properly but it's unable to read samples. When running rtl_sdr
> like this, it just hangs:
>
>
> ---8<--------------------------------------------------------------------------------------------
> % rtl_sdr -f 100000000 -
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN:
>
> Using device 0: Generic RTL2832U OEM
> Found Elonics E4000 tuner
> Tuned to 100000000 Hz.
> Reading samples in async mode...
>
> ---8<--------------------------------------------------------------------------------------------
>
> Pressing Ctrl+C only makes rdl_sdr say "Signal caught, exiting!", but
> it won't exit unless you kill it explicitly with SIGKILL. If I run it
> in synchronous mode, I get this output instead:
>
>
> ---8<--------------------------------------------------------------------------------------------
> % rtl_sdr -f 100000000 -S -
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN:
>
> Using device 0: Generic RTL2832U OEM
> Found Elonics E4000 tuner
> Tuned to 100000000 Hz.
> Reading samples in sync mode...
> WARNING: sync read failed.
>
> Library error -8, exiting...
> rtlsdr_demod_write_reg failed with -1
>
> ---8<--------------------------------------------------------------------------------------------
>
> I tried to reinstall libusb, recompiling it from a newer version (I'm
> currently using 1.0-16rc10)  and got the same output. As -8 means
> overflow for libusb, I decided to increase the output block size. I
> had to edit rtl_sdr.c to read as much as 30M, and that was the only
> way I could get some output. Block sizes below 10M just won't do the
> trick:
>
>
> ---8<--------------------------------------------------------------------------------------------
>  % rtl_sdr -b 30000000 -f 100000000 -S -
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN:
>
> Using device 0: Generic RTL2832U OEM
> Found Elonics E4000 tuner
> Tuned to 100000000 Hz.
> Reading samples in sync mode...
> Short read, samples lost, exiting!
>
> Library error 0, exiting...
> (here be messy bytes of 64 bytes sampled by RTL)
>
> ---8<--------------------------------------------------------------------------------------------
>
> That's why I recompiled libusb with logging, and I got this output
> (now, with 3M blocks):
>
>
> ---8<--------------------------------------------------------------------------------------------
> [...]
> Reading samples in sync mode...
> libusb: 1.079895 debug [submit_bulk_transfer] need 184 urbs for new
> transfer with length 3000000
> libusb: 1.080660 debug [libusb_handle_events_timeout_completed] doing
> our own event handling
> libusb: 1.080692 debug [handle_events] poll() 4 fds with timeout in 60000ms
> libusb: 1.083056 debug [handle_events] poll() returned 1
> libusb: 1.083082 debug [reap_for_handle] urb type=3 status=-75
> transferred=64
> libusb: 1.083104 debug [handle_bulk_completion] handling completion
> status -75 of bulk urb 1/184
> libusb: 1.083125 debug [handle_bulk_completion] overflow, actual_length=64
> libusb: 1.083146 debug [disarm_timerfd]
> libusb: 1.083161 debug [usbi_handle_transfer_completion] transfer
> 0x97a0424 has callback 0xb775c7f0
> libusb: 1.083182 debug [bulk_transfer_cb] actual_length=64
> WARNING: sync read failed.
>
> Library error -8, exiting...
> [...]
>
> ---8<--------------------------------------------------------------------------------------------
>
> Status -75 (overflow) made me think about a limitation on the URB size
> in my system, but it looks that in Linux that's a standard (16K), so I
> ran out of ideas. I don't know where the problem is anymore, whether
> in rtl-sdr, libusb, usbfs or even in my system; because I've compiled
> it in two different systems already (my laptop - Ubuntu 12.04 - and my
> home computer - Debian Sid -) and it works fine in both of them.
>
> Regards,
> --
> >> Gonzalo Jos? Carracedo Carballal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140111/8f77823f/attachment.htm>

From 246tnt at gmail.com  Sat Jan 11 11:43:52 2014
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 11 Jan 2014 12:43:52 +0100
Subject: Bug in rtl-sdr / libusb / usbfs
In-Reply-To: <CAAdsYnaU-d8XtZM23uO98Tz7jr0vpLFnmSUKj_ubAXpPNkXHmQ@mail.gmail.com>
References: <CANO8ntKtX-J7aPMTjXzKNpraGw24t=rTohqOB09GPJr4kPdyHA@mail.gmail.com>
	<CAAdsYnaU-d8XtZM23uO98Tz7jr0vpLFnmSUKj_ubAXpPNkXHmQ@mail.gmail.com>
Message-ID: <CAHL+j0-=F69XzGVW=N4oO0+63TWTXsNtnB3rik-Z7Z1VQMX62A@mail.gmail.com>

> I am also fairly new to the list, but I am using the DVB-T e4k dongle that
> you use. I was under the impression that e4k has a range up to 2.2 Mhz, and
> yet you are feeding it 100 Mhz. I am surprised it even tunes in! I don't
> think it is meant to work that high :-(

Up to 2.2 GHz ... not MHz ... you're off by a 1000x factor.

Cheers,

    Sylvain



From nikos.balkanas at eyeonix.com  Sat Jan 11 12:25:31 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Sat, 11 Jan 2014 14:25:31 +0200
Subject: Bug in rtl-sdr / libusb / usbfs
In-Reply-To: <CANO8ntKtX-J7aPMTjXzKNpraGw24t=rTohqOB09GPJr4kPdyHA@mail.gmail.com>
References: <CANO8ntKtX-J7aPMTjXzKNpraGw24t=rTohqOB09GPJr4kPdyHA@mail.gmail.com>
Message-ID: <CAAdsYnaTAX426AvY9jbVVpozKwAeC2U+_LQ+4d_P4qnDrbiObg@mail.gmail.com>

I am sorry, my mistake. You are right, it tunes to 2.2 GHz. Mixing up my
Ghz with Mhz :-(

I am not using, however, rtl-sdr, just librtlsdr with my program. I tune to
2.1 Ghz with no problems ;-)

Just to make sure I ran your command line:

rtl_sdr -f 100000000 -
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000074

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Tuned to 100000000 Hz.
Reading samples in async mode...
<Binary data deleted>...

The only problem I noticed is giving me a core-dump when I kill it with
<ctrl>-C.

I have a 64x Ubuntu 12.04 using latest rtl_sdr sources ;-)

BR,
Nikos


On Sat, Jan 11, 2014 at 12:56 PM, Gonzalo Jos? Carracedo Carballal <
batchdrake at gmail.com> wrote:

> Hello!
>
> This is my first time using this mailing list, hope it's the right
> place to post this.
>
> I compiled rtl-sdr under Debian 7.2 (32 bits x86) it detects my ezcap
> e4k properly but it's unable to read samples. When running rtl_sdr
> like this, it just hangs:
>
>
> ---8<--------------------------------------------------------------------------------------------
> % rtl_sdr -f 100000000 -
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN:
>
> Using device 0: Generic RTL2832U OEM
> Found Elonics E4000 tuner
> Tuned to 100000000 Hz.
> Reading samples in async mode...
>
> ---8<--------------------------------------------------------------------------------------------
>
> Pressing Ctrl+C only makes rdl_sdr say "Signal caught, exiting!", but
> it won't exit unless you kill it explicitly with SIGKILL. If I run it
> in synchronous mode, I get this output instead:
>
>
> ---8<--------------------------------------------------------------------------------------------
> % rtl_sdr -f 100000000 -S -
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN:
>
> Using device 0: Generic RTL2832U OEM
> Found Elonics E4000 tuner
> Tuned to 100000000 Hz.
> Reading samples in sync mode...
> WARNING: sync read failed.
>
> Library error -8, exiting...
> rtlsdr_demod_write_reg failed with -1
>
> ---8<--------------------------------------------------------------------------------------------
>
> I tried to reinstall libusb, recompiling it from a newer version (I'm
> currently using 1.0-16rc10)  and got the same output. As -8 means
> overflow for libusb, I decided to increase the output block size. I
> had to edit rtl_sdr.c to read as much as 30M, and that was the only
> way I could get some output. Block sizes below 10M just won't do the
> trick:
>
>
> ---8<--------------------------------------------------------------------------------------------
>  % rtl_sdr -b 30000000 -f 100000000 -S -
> Found 1 device(s):
>   0:  Realtek, RTL2838UHIDIR, SN:
>
> Using device 0: Generic RTL2832U OEM
> Found Elonics E4000 tuner
> Tuned to 100000000 Hz.
> Reading samples in sync mode...
> Short read, samples lost, exiting!
>
> Library error 0, exiting...
> (here be messy bytes of 64 bytes sampled by RTL)
>
> ---8<--------------------------------------------------------------------------------------------
>
> That's why I recompiled libusb with logging, and I got this output
> (now, with 3M blocks):
>
>
> ---8<--------------------------------------------------------------------------------------------
> [...]
> Reading samples in sync mode...
> libusb: 1.079895 debug [submit_bulk_transfer] need 184 urbs for new
> transfer with length 3000000
> libusb: 1.080660 debug [libusb_handle_events_timeout_completed] doing
> our own event handling
> libusb: 1.080692 debug [handle_events] poll() 4 fds with timeout in 60000ms
> libusb: 1.083056 debug [handle_events] poll() returned 1
> libusb: 1.083082 debug [reap_for_handle] urb type=3 status=-75
> transferred=64
> libusb: 1.083104 debug [handle_bulk_completion] handling completion
> status -75 of bulk urb 1/184
> libusb: 1.083125 debug [handle_bulk_completion] overflow, actual_length=64
> libusb: 1.083146 debug [disarm_timerfd]
> libusb: 1.083161 debug [usbi_handle_transfer_completion] transfer
> 0x97a0424 has callback 0xb775c7f0
> libusb: 1.083182 debug [bulk_transfer_cb] actual_length=64
> WARNING: sync read failed.
>
> Library error -8, exiting...
> [...]
>
> ---8<--------------------------------------------------------------------------------------------
>
> Status -75 (overflow) made me think about a limitation on the URB size
> in my system, but it looks that in Linux that's a standard (16K), so I
> ran out of ideas. I don't know where the problem is anymore, whether
> in rtl-sdr, libusb, usbfs or even in my system; because I've compiled
> it in two different systems already (my laptop - Ubuntu 12.04 - and my
> home computer - Debian Sid -) and it works fine in both of them.
>
> Regards,
> --
> >> Gonzalo Jos? Carracedo Carballal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140111/bb0b0311/attachment.htm>

From dennissheirer2002 at yahoo.com  Sun Jan 12 12:07:13 2014
From: dennissheirer2002 at yahoo.com (Dennis Sheirer)
Date: Sun, 12 Jan 2014 04:07:13 -0800 (PST)
Subject: RTL2832/E4000 Crystal Frequency?
Message-ID: <1389528433.98064.YahooMailNeo@web125804.mail.ne1.yahoo.com>

Does anyone know if you can check the crystal frequency from one of the RTL2832 registers?

Or, has anyone seen an early version E4000 dongle using a crystal other than 28.8 MHz?

I've been measuring the sample output rates of my E4000 and found the output rates differed from the expected rates that I'm setting using the rtlsdr library method.
https://groups.google.com/forum/#!topic/ultra-cheap-sdr/r_BLWQ5C4mw


Denny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140112/cad98371/attachment.htm>

From nikos.balkanas at eyeonix.com  Sun Jan 12 12:54:16 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Sun, 12 Jan 2014 14:54:16 +0200
Subject: RTL2832/E4000 Crystal Frequency?
In-Reply-To: <1389528433.98064.YahooMailNeo@web125804.mail.ne1.yahoo.com>
References: <1389528433.98064.YahooMailNeo@web125804.mail.ne1.yahoo.com>
Message-ID: <CAAdsYnYm-q-eSQLrtn9LQFvSAGiyFtfwYX+DKh=X4tuph1vwHQ@mail.gmail.com>

I actually don't. But the first place i would check is the
include/e4k_tuner.h file in the library. There are a lot of registers
defined there that you could try with software ;-)

BR,
Nikos


On Sun, Jan 12, 2014 at 2:07 PM, Dennis Sheirer <dennissheirer2002 at yahoo.com
> wrote:

> Does anyone know if you can check the crystal frequency from one of the
> RTL2832 registers?
>
> Or, has anyone seen an early version E4000 dongle using a crystal other
> than 28.8 MHz?
>
> I've been measuring the sample output rates of my E4000 and found the
> output rates differed from the expected rates that I'm setting using the
> rtlsdr library method.
> https://groups.google.com/forum/#!topic/ultra-cheap-sdr/r_BLWQ5C4mw
>
> Denny
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140112/3fbf3f9d/attachment.htm>

From dennissheirer2002 at yahoo.com  Sun Jan 12 13:29:50 2014
From: dennissheirer2002 at yahoo.com (Dennis Sheirer)
Date: Sun, 12 Jan 2014 05:29:50 -0800 (PST)
Subject: RTL2832/E4000 Crystal Frequency?
In-Reply-To: <1389528433.98064.YahooMailNeo@web125804.mail.ne1.yahoo.com>
References: <1389528433.98064.YahooMailNeo@web125804.mail.ne1.yahoo.com> 
Message-ID: <1389533390.6878.YahooMailNeo@web125805.mail.ne1.yahoo.com>

Thanks Joanne. ?I ran some more tests this morning and I was able to get the dongle to run at greater than 3.0 MHz sample rates.

Yesterday, when I was testing the upper limits, I must have put the 2832 into a bad state and wasn't able to get it to output anything higher than ~2 MHz.

When I compare the settings in my spreadsheet to what rtlsdr setSampleRate() method is producing, they're not too far apart. ?I think I'm just using a different approach to get the setting versus what the rtlsdr library is using ( 2^22 * oscillator / sample rate).

On the bright side, I'm able to use a whole new set of (lower) sample rates with the 2832.

Denny



On Sunday, January 12, 2014 7:07 AM, Dennis Sheirer <dennissheirer2002 at yahoo.com> wrote:
 
Does anyone know if you can check the crystal frequency from one of the RTL2832 registers?

Or, has anyone seen an early version E4000 dongle using a crystal other than 28.8 MHz?

I've been measuring the sample output rates of my E4000 and found the output rates differed from the expected rates that I'm setting using the rtlsdr library method.
https://groups.google.com/forum/#!topic/ultra-cheap-sdr/r_BLWQ5C4mw


Denny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140112/934b18c7/attachment.htm>

From Ethem.Sozer at mathworks.com  Mon Jan 13 16:46:25 2014
From: Ethem.Sozer at mathworks.com (Ethem Sozer)
Date: Mon, 13 Jan 2014 16:46:25 +0000
Subject: RTL-SDR support package available for MATLAB and Simulink
Message-ID: <936d6271feac40d6b3d43fee826e5508@ex13amer-00-ah.ad.mathworks.com>

Hi All,

RTL-SDR support package for MATLAB and Simulink has been released:

http://www.mathworks.com/hardware-support/rtl-sdr.html

Using this support package, you can receive signals from your RTL-SDR dongle directly into MATLAB and Simulink. The package also contains several examples to get you started.

Have fun and let me know if you have any questions or comments.

Ethem Mutlu Sozer
Principal Engineer
Signal Processing and Communications Group
MathWorks, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140113/0b18a92d/attachment.htm>

From nikos.balkanas at eyeonix.com  Mon Jan 13 21:26:43 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Mon, 13 Jan 2014 23:26:43 +0200
Subject: rtlsdr_read_sync failure
Message-ID: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>

Hi,

I need to get a few traffic data bytes ~ 16 B from my dongle. libusb's bulk
transfer and therefore rtlsdr_read_sync, will fail with -8 if used with
less than 1024 B. Can anyone think of another way to read them? (async also
uses libusb's fill_bulk_transfer :-()

I could possibly use rtlsdr_read_array, except that i don't know the block
and address that I need to use for traffic data :-(

Thanks,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140113/f5f27e67/attachment.htm>

From zaitcev at kotori.zaitcev.us  Mon Jan 13 22:08:37 2014
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Mon, 13 Jan 2014 15:08:37 -0700
Subject: rtlsdr_read_sync failure
In-Reply-To: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
Message-ID: <20140113150837.521cac86@lembas.zaitcev.lan>

On Mon, 13 Jan 2014 23:26:43 +0200
Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:

> I need to get a few traffic data bytes ~ 16 B from my dongle. libusb's bulk
> transfer and therefore rtlsdr_read_sync, will fail with -8 if used with
> less than 1024 B. Can anyone think of another way to read them? (async also
> uses libusb's fill_bulk_transfer :-()

AFAIK, usbfs has no such limitation inherently and in fact I have
transferred arbitrary amounts, for example in printer drivers.
So you can go directly to usbfs if that helps.

-- Pete



From steve at steve-m.de  Mon Jan 13 23:11:04 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Tue, 14 Jan 2014 00:11:04 +0100
Subject: rtlsdr_read_sync failure
In-Reply-To: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
Message-ID: <52D47288.9080905@steve-m.de>

Hi,

On 13.01.2014 22:26, Nikos Balkanas wrote:
> I need to get a few traffic data bytes ~ 16 B from my dongle. libusb's
> bulk transfer and therefore rtlsdr_read_sync, will fail with -8 if used
> with less than 1024 B. Can anyone think of another way to read them?
> (async also uses libusb's fill_bulk_transfer :-()

Read more and throw the rest away, what's the issue with that?
But what do you need *16 bytes* for? That's just 62.5?s of
samples...

> I could possibly use rtlsdr_read_array, except that i don't know the
> block and address that I need to use for traffic data :-(

Those functions trigger control transfers and have nothing to do with
the actual I/Q samples at all, so no, you can't use them.

I have no idea what you're trying to accomplish, but it seems to me
whatever it is, you are completely off track.

Regards,
Steve



From nikos.balkanas at eyeonix.com  Mon Jan 13 23:14:26 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Tue, 14 Jan 2014 01:14:26 +0200
Subject: rtlsdr_read_sync failure
In-Reply-To: <20140113150837.521cac86@lembas.zaitcev.lan>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
	<20140113150837.521cac86@lembas.zaitcev.lan>
Message-ID: <CAAdsYnZk=ZpD7J-v5o4R1LD-ve_2XY9wUdGEbeBfFq_snA0zoQ@mail.gmail.com>

What function from the libusb API are you using for the read?

TIA,
Nikos


On Tue, Jan 14, 2014 at 12:08 AM, Pete Zaitcev <zaitcev at kotori.zaitcev.us>wrote:

> On Mon, 13 Jan 2014 23:26:43 +0200
> Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:
>
> > I need to get a few traffic data bytes ~ 16 B from my dongle. libusb's
> bulk
> > transfer and therefore rtlsdr_read_sync, will fail with -8 if used with
> > less than 1024 B. Can anyone think of another way to read them? (async
> also
> > uses libusb's fill_bulk_transfer :-()
>
> AFAIK, usbfs has no such limitation inherently and in fact I have
> transferred arbitrary amounts, for example in printer drivers.
> So you can go directly to usbfs if that helps.
>
> -- Pete
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/d25f9386/attachment.htm>

From nikos.balkanas at eyeonix.com  Mon Jan 13 23:20:26 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Tue, 14 Jan 2014 01:20:26 +0200
Subject: rtlsdr_read_sync failure
In-Reply-To: <52D47288.9080905@steve-m.de>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
	<52D47288.9080905@steve-m.de>
Message-ID: <CAAdsYnbcWNeTZQZ=e+fWwFi4Obozt2bUC4cWuM0Y0FvCQ3yj8A@mail.gmail.com>

On Tue, Jan 14, 2014 at 1:11 AM, Steve Markgraf <steve at steve-m.de> wrote:

> Hi,
>
> On 13.01.2014 22:26, Nikos Balkanas wrote:
> > I need to get a few traffic data bytes ~ 16 B from my dongle. libusb's
> > bulk transfer and therefore rtlsdr_read_sync, will fail with -8 if used
> > with less than 1024 B. Can anyone think of another way to read them?
> > (async also uses libusb's fill_bulk_transfer :-()
>
> Read more and throw the rest away, what's the issue with that?
> But what do you need *16 bytes* for? That's just 62.5? of
>  samples...
>

Performance is very important, Call is repeated many times. BTW that's what
I am using right now, but looking for better.


> > I could possibly use rtlsdr_read_array, except that i don't know the
> > block and address that I need to use for traffic data :-(
>
> Those functions trigger control transfers and have nothing to do with
> the actual I/Q samples at all, so no, you can't use them.
>
> I have no idea what you're trying to accomplish, but it seems to me
> whatever it is, you are completely off track.
>

I am not. Control transfers are fine with me. There must be a memory region
where traffic I/O takes place.

>
> Regards,
> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/e0b96e28/attachment.htm>

From steve at steve-m.de  Tue Jan 14 00:00:39 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Tue, 14 Jan 2014 01:00:39 +0100
Subject: rtlsdr_read_sync failure
In-Reply-To: <CAAdsYnbcWNeTZQZ=e+fWwFi4Obozt2bUC4cWuM0Y0FvCQ3yj8A@mail.gmail.com>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>	<52D47288.9080905@steve-m.de>
	<CAAdsYnbcWNeTZQZ=e+fWwFi4Obozt2bUC4cWuM0Y0FvCQ3yj8A@mail.gmail.com>
Message-ID: <52D47E27.6080806@steve-m.de>

Hi,

On 14.01.2014 00:20, Nikos Balkanas wrote:
> Performance is very important, Call is repeated many times. BTW that's
> what I am using right now, but looking for better.

With the approach you're taking you're going to have no performance
whatsoever, please learn about how USB bulk transfers work, especially
about the size of URBs.

> I am not. Control transfers are fine with me. There must be a memory
> region where traffic I/O takes place.

There is no such 'memory region', because the FIFO of the RTL2832 has
it's own memory, which is completely outside of the 8051 address space
and thus cannot be accessed with control transfers.

Anyway, I'm out of the discussion.

Regards,
Steve



From zaitcev at kotori.zaitcev.us  Tue Jan 14 01:10:37 2014
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Mon, 13 Jan 2014 18:10:37 -0700
Subject: rtlsdr_read_sync failure
In-Reply-To: <CAAdsYnZk=ZpD7J-v5o4R1LD-ve_2XY9wUdGEbeBfFq_snA0zoQ@mail.gmail.com>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
	<20140113150837.521cac86@lembas.zaitcev.lan>
	<CAAdsYnZk=ZpD7J-v5o4R1LD-ve_2XY9wUdGEbeBfFq_snA0zoQ@mail.gmail.com>
Message-ID: <20140113181037.0b27fed9@lembas.zaitcev.lan>

On Tue, 14 Jan 2014 01:14:26 +0200
Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:

> What function from the libusb API are you using for the read?

I wrote usbfs, not libusb. Of course it's no use for you if you're on OSX,
but it works on Linux. See here:
 http://people.redhat.com/zaitcev/linux/canonf50.tar.gz

-- Pete



From nikos.balkanas at eyeonix.com  Tue Jan 14 07:15:55 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Tue, 14 Jan 2014 09:15:55 +0200
Subject: rtlsdr_read_sync failure
In-Reply-To: <20140113181037.0b27fed9@lembas.zaitcev.lan>
References: <CAAdsYnaP-=NdsVLjxj0jJexF3V+kdpG3tXqr-AJFzKMrEuBcoQ@mail.gmail.com>
	<20140113150837.521cac86@lembas.zaitcev.lan>
	<CAAdsYnZk=ZpD7J-v5o4R1LD-ve_2XY9wUdGEbeBfFq_snA0zoQ@mail.gmail.com>
	<20140113181037.0b27fed9@lembas.zaitcev.lan>
Message-ID: <CAAdsYnYFrT6XueSFECqoB4Utqbq6P6t0GJ+QToc5xCg4EZ3o_g@mail.gmail.com>

 You are using ioctl to talk directly to the kernel driver, bypassing
libusb. Maybe it is time to download libusb sources and check it out.
The call I am doing is run upto 10000x. It is part of a tunning scanner ;-)

Thnx,
Nikos


On Tue, Jan 14, 2014 at 3:10 AM, Pete Zaitcev <zaitcev at kotori.zaitcev.us>wrote:

> On Tue, 14 Jan 2014 01:14:26 +0200
> Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:
>
> > What function from the libusb API are you using for the read?
>
> I wrote usbfs, not libusb. Of course it's no use for you if you're on OSX,
> but it works on Linux. See here:
>  http://people.redhat.com/zaitcev/linux/canonf50.tar.gz
>
> -- Pete
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/22677493/attachment.htm>

From putaoshu at gmail.com  Tue Jan 14 08:01:43 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Tue, 14 Jan 2014 16:01:43 +0800
Subject: RTL-SDR support package available for MATLAB and Simulink
In-Reply-To: <936d6271feac40d6b3d43fee826e5508@ex13amer-00-ah.ad.mathworks.com>
References: <936d6271feac40d6b3d43fee826e5508@ex13amer-00-ah.ad.mathworks.com>
Message-ID: <CABs6FUre8-o6wbLsV3gdA5Qa3bx2q-QqUJFB__pUJPs1h3kRWQ@mail.gmail.com>

Just can't install it in Ubuntu-Linux. Does it support?


On Tue, Jan 14, 2014 at 12:46 AM, Ethem Sozer <Ethem.Sozer at mathworks.com>wrote:

>  Hi All,
>
>
>
> RTL-SDR support package for MATLAB and Simulink has been released:
>
>
>
> http://www.mathworks.com/hardware-support/rtl-sdr.html
>
>
>
> Using this support package, you can receive signals from your RTL-SDR
> dongle directly into MATLAB and Simulink. The package also contains several
> examples to get you started.
>
>
>
> Have fun and let me know if you have any questions or comments.
>
>
>
> Ethem Mutlu Sozer
>
> Principal Engineer
>
> Signal Processing and Communications Group
>
> MathWorks, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/8dc47c14/attachment.htm>

From putaoshu at gmail.com  Tue Jan 14 08:17:50 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Tue, 14 Jan 2014 16:17:50 +0800
Subject: RTL-SDR support package available for MATLAB and Simulink
In-Reply-To: <CABs6FUre8-o6wbLsV3gdA5Qa3bx2q-QqUJFB__pUJPs1h3kRWQ@mail.gmail.com>
References: <936d6271feac40d6b3d43fee826e5508@ex13amer-00-ah.ad.mathworks.com>
	<CABs6FUre8-o6wbLsV3gdA5Qa3bx2q-QqUJFB__pUJPs1h3kRWQ@mail.gmail.com>
Message-ID: <CABs6FUpCuRGQxjNsStEwHLHGCvG+_LGeGyvxKOwkX7fbKLx_-w@mail.gmail.com>

OK. I see a network error. Maybe not the problem of package.


On Tue, Jan 14, 2014 at 4:01 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:

> Just can't install it in Ubuntu-Linux. Does it support?
>
>
> On Tue, Jan 14, 2014 at 12:46 AM, Ethem Sozer <Ethem.Sozer at mathworks.com>wrote:
>
>>  Hi All,
>>
>>
>>
>> RTL-SDR support package for MATLAB and Simulink has been released:
>>
>>
>>
>> http://www.mathworks.com/hardware-support/rtl-sdr.html
>>
>>
>>
>> Using this support package, you can receive signals from your RTL-SDR
>> dongle directly into MATLAB and Simulink. The package also contains several
>> examples to get you started.
>>
>>
>>
>> Have fun and let me know if you have any questions or comments.
>>
>>
>>
>> Ethem Mutlu Sozer
>>
>> Principal Engineer
>>
>> Signal Processing and Communications Group
>>
>> MathWorks, Inc.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/004e4694/attachment.htm>

From putaoshu at gmail.com  Tue Jan 14 14:23:44 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Tue, 14 Jan 2014 22:23:44 +0800
Subject: What's the settling time after new frequency set to dongle?
Message-ID: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>

Hi,

Is there any information or hint on the settling time after new frequency
set to dongle?

Or is there any method to read information from dongle to see if all things
get stable?

Can I immediately read samples after new frequency is set by
rtlsdr_set_center_freq?
If so, will the samples quality be degraded?

Thanks!

BR

Jiao Xianjun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/385061b8/attachment.htm>

From nikos.balkanas at eyeonix.com  Tue Jan 14 15:11:50 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Tue, 14 Jan 2014 17:11:50 +0200
Subject: What's the settling time after new frequency set to dongle?
In-Reply-To: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
References: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
Message-ID: <CAAdsYnbE-+zH8Lr9mv_VYwqG5pBKtDpwOAe9n72Re5HN-L_=ng@mail.gmail.com>

Yes, you can read traffic immediately after setting new frequency. No
settling needed ;-)

Just make sure your read buffer is at least 512 B or libusb_bulk_transfer
will fail :-(

BR,
Nikos


On Tue, Jan 14, 2014 at 4:23 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:

> Hi,
>
> Is there any information or hint on the settling time after new frequency
> set to dongle?
>
> Or is there any method to read information from dongle to see if all
> things get stable?
>
> Can I immediately read samples after new frequency is set by rtlsdr_set_center_freq?
> If so, will the samples quality be degraded?
>
> Thanks!
>
> BR
>
> Jiao Xianjun
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/314d1194/attachment.htm>

From j-pi at seznam.cz  Tue Jan 14 15:20:32 2014
From: j-pi at seznam.cz (=?UTF-8?B?SmnFmcOtIFBpbmthdmE=?=)
Date: Tue, 14 Jan 2014 16:20:32 +0100
Subject: What's the settling time after new frequency set to dongle?
In-Reply-To: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
References: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
Message-ID: <52D555C0.9050608@seznam.cz>

Settling time should be wery small (up to few tenths of ms or even
faster), internal
buffering in dongle is also small.

You should drop few thousand samles to be sure all is fine.

This results are from observation, not from measurement, can someone
provide hard data?

Dne 14.1.2014 15:23, Jiao Xianjun napsal(a):
> Hi,
>
> Is there any information or hint on the settling time after new frequency
> set to dongle?
>
> Or is there any method to read information from dongle to see if all things
> get stable?
>
> Can I immediately read samples after new frequency is set by
> rtlsdr_set_center_freq?
> If so, will the samples quality be degraded?
>
> Thanks!
>
> BR
>
> Jiao Xianjun
>




From steve at steve-m.de  Tue Jan 14 15:50:37 2014
From: steve at steve-m.de (steve at steve-m.de)
Date: Tue, 14 Jan 2014 16:50:37 +0100
Subject: What's the settling time after new frequency set to
	=?UTF-8?Q?dongle=3F?=
In-Reply-To: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
References: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
Message-ID: <f2f543920064e63f650790bf394f0317@steve-m.de>

Hi,

On 2014-01-14 15:23, Jiao Xianjun wrote:
> Is there any information or hint on the settling time after new
> frequency set to dongle?

That depends a bit on the tuner and the sample FIFO of the RTL2832,
but you need to drop a few buffers, as the PLL of the tuner takes
some time to lock and stabilize.

> Can I immediately read samples after new frequency is set by
> rtlsdr_set_center_freq? If so, will the samples quality be degraded?

Kyle Keen did some experiments for his scanning application
(rtl_power), and he settled for waiting a few milliseconds and
flushing the buffer to get optimal results. See here:

http://cgit.osmocom.org/rtl-sdr/tree/src/rtl_power.c#n626

Regards,
Steve



From nikos.balkanas at eyeonix.com  Tue Jan 14 16:47:27 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Tue, 14 Jan 2014 18:47:27 +0200
Subject: What's the settling time after new frequency set to dongle?
In-Reply-To: <f2f543920064e63f650790bf394f0317@steve-m.de>
References: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
	<f2f543920064e63f650790bf394f0317@steve-m.de>
Message-ID: <CAAdsYnaWsV3TO1qJ9j+H4JycwY9Msp1AQUY9K-w8VqJH43SwsA@mail.gmail.com>

On Tue, Jan 14, 2014 at 5:50 PM, <steve at steve-m.de> wrote:

> Hi,
>
>
> On 2014-01-14 15:23, Jiao Xianjun wrote:
>
>> Is there any information or hint on the settling time after new
>> frequency set to dongle?
>>
>
> That depends a bit on the tuner and the sample FIFO of the RTL2832,
> but you need to drop a few buffers, as the PLL of the tuner takes
> some time to lock and stabilize.
>
> Sample FiFO should be full at all times in a DVB-T. I have never seen it
empty due to interfernce, noise, etc.

>
>  Can I immediately read samples after new frequency is set by
>> rtlsdr_set_center_freq? If so, will the samples quality be degraded?
>>
>
> Kyle Keen did some experiments for his scanning application
> (rtl_power), and he settled for waiting a few milliseconds and
> flushing the buffer to get optimal results. See here:
>
> http://cgit.osmocom.org/rtl-sdr/tree/src/rtl_power.c#n626
>
> Regards,
> Steve
>
> That's a little too long, making large spectrum tuners inoperable. In my
scanner I use a read immediately after the frequency
set without any problems. Of course I cannot vouch for correct frequency,
but I have noticed that the frequency doesn't drift
appreciably when resetting frequency and locking to a band.

BR,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/9aa8364e/attachment.htm>

From jonpeckthe4th at gmail.com  Tue Jan 14 18:09:45 2014
From: jonpeckthe4th at gmail.com (Jonathan Peck)
Date: Tue, 14 Jan 2014 13:09:45 -0500
Subject: RTL-SDR support package available for MATLAB and Simulink
In-Reply-To: <936d6271feac40d6b3d43fee826e5508@ex13amer-00-ah.ad.mathworks.com>
References: <936d6271feac40d6b3d43fee826e5508@ex13amer-00-ah.ad.mathworks.com>
Message-ID: <CADQqNMFS3ns=X9dKJs2=iw1ezoERCgGai1EZ6Y2c=SJJuwF4Fg@mail.gmail.com>

Ethem,
  I just tried this out and it works great with my ezcap dongle on 64 bit
MATLAB 2013b. I was able to use the FM demodulation example provided to
play back a local FM radio station. Great work!

-Jon


On Mon, Jan 13, 2014 at 11:46 AM, Ethem Sozer <Ethem.Sozer at mathworks.com>wrote:

>  Hi All,
>
>
>
> RTL-SDR support package for MATLAB and Simulink has been released:
>
>
>
> http://www.mathworks.com/hardware-support/rtl-sdr.html
>
>
>
> Using this support package, you can receive signals from your RTL-SDR
> dongle directly into MATLAB and Simulink. The package also contains several
> examples to get you started.
>
>
>
> Have fun and let me know if you have any questions or comments.
>
>
>
> Ethem Mutlu Sozer
>
> Principal Engineer
>
> Signal Processing and Communications Group
>
> MathWorks, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/1d384177/attachment.htm>

From nikos.balkanas at eyeonix.com  Tue Jan 14 19:26:37 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Tue, 14 Jan 2014 21:26:37 +0200
Subject: What's the settling time after new frequency set to dongle?
In-Reply-To: <CAAdsYnaWsV3TO1qJ9j+H4JycwY9Msp1AQUY9K-w8VqJH43SwsA@mail.gmail.com>
References: <CABs6FUrEHdskUcUvbXrPfAiiV=a_63y8sBzUvj0-BNt00eOaZQ@mail.gmail.com>
	<f2f543920064e63f650790bf394f0317@steve-m.de>
	<CAAdsYnaWsV3TO1qJ9j+H4JycwY9Msp1AQUY9K-w8VqJH43SwsA@mail.gmail.com>
Message-ID: <CAAdsYnYm84QUQP+OXCzM2xcVg2n8fsxu_ThjK27maMoijB-JHQ@mail.gmail.com>

We forgot the most important parameter. The frequency "jump". If the
frequency change is large, i.e. from 10 Khz to 1 Ghz, then of course it
will take longer for the tuner to equilibrate. In my scanner, when I
approach a target I take 10 baby steps of 2 Khz each to zero in. Drift is
negligible. I tried using the 5000 us in my scanner, and the results were
the same as without it, except for the delay of an additional 50 s. I
promptly removed it.

The way I see it, tuner needs some time to settle in a new frequency, but
there is no fixed delay. It is situation specific and depends highly on the
amount of frequency change.

HTH,
Nikos


On Tue, Jan 14, 2014 at 6:47 PM, Nikos Balkanas
<nikos.balkanas at eyeonix.com>wrote:

>
>
>
> On Tue, Jan 14, 2014 at 5:50 PM, <steve at steve-m.de> wrote:
>
>> Hi,
>>
>>
>> On 2014-01-14 15:23, Jiao Xianjun wrote:
>>
>>> Is there any information or hint on the settling time after new
>>> frequency set to dongle?
>>>
>>
>> That depends a bit on the tuner and the sample FIFO of the RTL2832,
>> but you need to drop a few buffers, as the PLL of the tuner takes
>> some time to lock and stabilize.
>>
>> Sample FiFO should be full at all times in a DVB-T. I have never seen it
> empty due to interfernce, noise, etc.
>
>>
>>  Can I immediately read samples after new frequency is set by
>>> rtlsdr_set_center_freq? If so, will the samples quality be degraded?
>>>
>>
>> Kyle Keen did some experiments for his scanning application
>> (rtl_power), and he settled for waiting a few milliseconds and
>> flushing the buffer to get optimal results. See here:
>>
>> http://cgit.osmocom.org/rtl-sdr/tree/src/rtl_power.c#n626
>>
>> Regards,
>> Steve
>>
>> That's a little too long, making large spectrum tuners inoperable. In my
> scanner I use a read immediately after the frequency
> set without any problems. Of course I cannot vouch for correct frequency,
> but I have noticed that the frequency doesn't drift
> appreciably when resetting frequency and locking to a band.
>
> BR,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/bc804198/attachment.htm>

From n1gp at hotmail.com  Wed Jan 15 23:15:42 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Wed, 15 Jan 2014 18:15:42 -0500
Subject: rtl_hpsdr an RTL to HPSDR software translation server
Message-ID: <BLU180-W21A8F15F4506138EEE2AB887BE0@phx.gbl>

I am releasing to the public via GPL an RTL to HPSDR software
translation server.

Hosted on https://github.com/n1gp/rtl_hpsdr

Screenshots listed and end.

README:

It currently builds and runs on Linux. It identifies and uses up to
seven (theoretically eight) USB RTL2832U-based DVB-T dongles. The
dongles can be set up with an up converter or use RTL direct-mode
for HF receive. Or direct input to provide it's native > HF receive
range.

The program can be passed in a variety of command line options.
One of which is a frequency offset not only for up converter use
but also to allow a full range of frequency options to HPSDR programs
that are coded to only allow the real HPSDR radio's (i.e. Hermes)
frequency range which is from 10KHz to 55MHz.

The main purpose of this program is to provide a mechanism that
allows RTL Dongle owners the ability to use them on HPSDR specific
software programs.

One such program, cuSDR64 has the ability to control and display
up to 7 rcvr slices simultaneously. With rtl_hpsdr, if your host
has the horsepower, you can run 7 RTL Dongles to emulate the HPSDR
rcvr. cuSDR64 also can be built and run on Linux.

Since the real HPSDR (i.e. Hermes) rcvr can do up to eight rcvr
slices, there is a concept of 'COPY' rcvrs in this server. This
would allow one to use HPSDR programs that expected more rcvrs
than were attached. Currently if a program request more rcvrs
than are actually attached the rtl_hpsdr server will make copies
of the last 'real' rcvr. This alows one to only have one RTL dongle
attached and run PowerSDR mRX which may expect up to four rcvr
slices.

Refer to: http://openhpsdr.org/softwareinfo.php  for a list of
HPSDR supported applications.

I have tested this only on cuSDR64, cuSDR32, and PowerSDR mRX.

I was successful running 7 RTL dongles simultaneously on a
Quad core ARM Cortex A9 based mini-pc, model EKB311
running a version of Picuntu, http://ubuntu.g8.net/
This was using R820T based dongles on a USB 2.0 hub. I did
have to replace the USB hub power supply with one that
provided 5V @ 2A.

My 7 reveiver dongle setup:
http://home.comcast.net/~n1gp/RTL_HPSDR/7_usb_rcvr.jpg

Display of using 5 RTL dongle rcvrs with cuSDR64
http://home.comcast.net/~n1gp/RTL_HPSDR/5_rcvrs.jpg

This PCIE card provides 4 RTL Dongles (DigitalNow Quad DVB-T)
http://home.comcast.net/~n1gp/RTL_HPSDR/dn_quad.jpg

Display of using 2 RTL dongle rcvrs with PowerSDR mRX
http://home.comcast.net/~n1gp/RTL_HPSDR/powersdr.jpg
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140115/b686e8f8/attachment.htm>

From nikos.balkanas at eyeonix.com  Thu Jan 16 09:57:40 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 16 Jan 2014 11:57:40 +0200
Subject: Elonics 4000 bandpass
Message-ID: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>

Hi,

I would like to use my E4k dongle for wider spectrum analysis. Currently
the tuner is very specific to a frequency. Is there a way to widen its
bandpass filter?

I have noticed some filters in src/tuner_e4k.c: Mixer filter, IF RC filter
and IF channel filter. Are they of any use?

Is there a librtlsdr API?

TIA,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140116/0795cb7f/attachment.htm>

From 393775602 at qq.com  Thu Jan 16 15:20:22 2014
From: 393775602 at qq.com (=?gb18030?B?MzkzNzc1NjAy?=)
Date: Thu, 16 Jan 2014 23:20:22 +0800
Subject: Elonics 4000 bandpass
In-Reply-To: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
References: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
Message-ID: <tencent_28B33C051620A41402716F95@qq.com>

i want to write an android app with the Realtek DVB-T Dongles ?is there any librtlsdr API for android?




------------------ Original ------------------
From:  "Nikos Balkanas";<nikos.balkanas at eyeonix.com>;
Date:  Thu, Jan 16, 2014 05:57 PM
To:  "osmocom-sdr"<osmocom-sdr at lists.osmocom.org>; 

Subject:  Elonics 4000 bandpass



Hi,


I would like to use my E4k dongle for wider spectrum analysis. Currently the tuner is very specific to a frequency. Is there a way to widen its bandpass filter?


 I have noticed some filters in src/tuner_e4k.c: Mixer filter, IF RC filter and IF channel filter. Are they of any use?


Is there a librtlsdr API?


TIA,

Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140116/a50b5716/attachment.htm>

From peter at stuge.se  Thu Jan 16 15:50:50 2014
From: peter at stuge.se (Peter Stuge)
Date: Thu, 16 Jan 2014 16:50:50 +0100
Subject: Elonics 4000 bandpass
In-Reply-To: <tencent_28B33C051620A41402716F95@qq.com>
References: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
	<tencent_28B33C051620A41402716F95@qq.com>
Message-ID: <20140116155050.13186.qmail@stuge.se>

393775602 wrote:
> i want to write an android app with the Realtek DVB-T Dongles ?
> is there any librtlsdr API for android?

A dongle could be connected to an Android device with USB host
functionality but the Dalvik app must help open the device, libusb
is unable to do that on its own. The current version of libusb
doesn't have provisions for this, but a future version will. That
function would then have to be passed through by librtlsdr as well.

At the moment I think the answer is no.


//Peter



From retzlerandras at gmail.com  Thu Jan 16 15:56:40 2014
From: retzlerandras at gmail.com (=?ISO-8859-1?Q?Andr=E1s_Retzler?=)
Date: Thu, 16 Jan 2014 16:56:40 +0100
Subject: Elonics 4000 bandpass
In-Reply-To: <tencent_28B33C051620A41402716F95@qq.com>
References: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
	<tencent_28B33C051620A41402716F95@qq.com>
Message-ID: <CABrNoDA1ku_mwxk=DMGStV+Yd=SSCJ4OQ-XpOPzu-rDD6Ui6XQ@mail.gmail.com>

Hi,


i want to write an android app with the Realtek DVB-T
Dongles<http://wiki.spench.net/wiki/RTL2832U> ?is
> there any librtlsdr API for android?
>

What about these?

https://play.google.com/store/apps/details?id=marto.rtl_tcp_andro
https://github.com/keesj/android-rtlsdr
https://github.com/keesj/librtlsdr-android

Regards,

Andras, HA7ILM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140116/4203f815/attachment.htm>

From peter at stuge.se  Thu Jan 16 16:39:41 2014
From: peter at stuge.se (Peter Stuge)
Date: Thu, 16 Jan 2014 17:39:41 +0100
Subject: Elonics 4000 bandpass
In-Reply-To: <CABrNoDA1ku_mwxk=DMGStV+Yd=SSCJ4OQ-XpOPzu-rDD6Ui6XQ@mail.gmail.com>
References: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
	<tencent_28B33C051620A41402716F95@qq.com>
	<CABrNoDA1ku_mwxk=DMGStV+Yd=SSCJ4OQ-XpOPzu-rDD6Ui6XQ@mail.gmail.com>
Message-ID: <20140116163941.16989.qmail@stuge.se>

Andr?s Retzler wrote:
> What about these?
> 
> https://github.com/keesj/librtlsdr-android

This includes a hacked up patch for an older libusb version to get
that help from the Dalvik app with device opening.

If you must proceed to use that code today then do yourself a favor
and at least forward-port that patch to current git.libusb.org/libusb.git 


//Peter



From n1gp at hotmail.com  Thu Jan 16 18:39:37 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Thu, 16 Jan 2014 13:39:37 -0500
Subject: [hpsdr] rtl_hpsdr an RTL to HPSDR software translation server
In-Reply-To: <CACNyZdDLTM6TECSJU2ae=y1ghBZ3MMhLV0AM4TNxsURtSBCY1w@mail.gmail.com>
References: <BLU180-W21A8F15F4506138EEE2AB887BE0@phx.gbl>,
	<CACNyZdDLTM6TECSJU2ae=y1ghBZ3MMhLV0AM4TNxsURtSBCY1w@mail.gmail.com>
Message-ID: <BLU180-W2227C3952C3BB851265A4787B90@phx.gbl>

Hi Vasiliy,

It identifies itself as a Hermes FW version 2.4

I was hoping it may be useful for skimmer use. I don't
know a lot about it though.

-Rick

===================

Hi Rich

This is great!  What Board ID and fw version does rtl_hpsdr send to the
discovery request?  your solution can be used potentially with the skimmer
server and HermesIntf.dll for multichannel decoding. (I don't have a dongle
yet to give this a try)

73
Vasiliy 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140116/ef60c086/attachment.htm>

From putaoshu at gmail.com  Fri Jan 17 01:38:45 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Fri, 17 Jan 2014 09:38:45 +0800
Subject: Use multi-dongles to speedup scanner
Message-ID: <CABs6FUoMao7-z5GQQRJNrQbkUa1N9Ty-qf9Z22TfGYqqZJTaVQ@mail.gmail.com>

Hi,

As a "side product" of this thread: "How to get IQ samples from multiple
rtl-sdr dongles in a synchronized manner",A Matlab script is released.

http://www.mathworks.com/matlabcentral/fileexchange/45024-rtl-sdr-multi-dongles-based-flexible-spectrum-scanner
or
https://github.com/JiaoXianjun/multi-rtl-sdr-calibration

The script can use multiple dongles to do scanning, and get significant
speedup compared to single dongle. (You can check reported time cost by
running the script with different number of dongles)
Another script uses multiple dongles to scan the same band, and combine
those results together incoherently.

I admit that before calibrating multiple dongles, the significant is
limited.

Just for FUN.

README is also pasted here:

Multiple rtl-sdr(rtl_tcp) dongles based Matlab frequency scanner.
1. multi_rtl_sdr_split_scanner.m
Have multiple dongles run concurrently to speedup scanning wide band by
scanning different sub-band with different dongle.
2. multi_rtl_sdr_diversity_scanner.m
All dongles scan the same band, and then results from different dongles are
combined incoherently.
------------Usage------------

1. Assume that you have installed rtl-sdr
(http://sdr.osmocom.org/trac/wiki/rtl-sdr) and have those native utilities
run correctly already.

For example, you have multiple dongles, please run multiple rtl_tcp in
multiple shell respectively as:
rtl_tcp -p 1234 -d 0
rtl_tcp -p 1235 -d 1
rtl_tcp -p 1236 -d 3
...

2. Then run script multi_rtl_sdr_split_scanner.m or
multi_rtl_sdr_diversity_scanner.m in MATLAB.

ATTENTION! In some computer, each time before you run script, maybe you
need to terminate multiple rtl_tcp and re-launch them again.

Change following parameters in the script as you need:

num_dongle = 2;
start_freq = 935e6;
end_freq = 960e6;
freq_step = 0.05e6;
observe_time = 0.1;
gain = 0;
sample_rate = 2.048e6;
...

------------Algorithm------------
Use high sampling rate for each frequency point. Then Auto generated narrow
FIR is used to suppress noise and extract signal.
At last, power of signal at each frequency is estimated and spectrum of all
frequencies is generated.



BR


Jiao Xianjun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140117/02a9448e/attachment.htm>

From nikos.balkanas at eyeonix.com  Fri Jan 17 17:55:05 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Fri, 17 Jan 2014 19:55:05 +0200
Subject: E4K tuner blues
Message-ID: <CAAdsYnY7_O4FYB8fjk2onTvtvs2X4irD9jv7Xn9_vK4uAgNCAg@mail.gmail.com>

I need to manipulate the tuners bandpass behavior. I have exported 2 more
functions from librtlsdr, rtlsdr_set_filter_bw and rtlsdr_get_filter_bw and
change the channel filter. However, when I use them I get libusb error(-22)
**UNKNOWN ERROR**.
I have tried bracketing the call with start/stop i2c repeater and
disable/enable channel to no avail :-(
It errs both when setting filter to 5.5 Mhz (max) and to 2.1 Mhz (min).
What is going on? What other context should I provide for it to work?

TIA,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140117/d98f23f4/attachment.htm>

From mailman at lists.osmocom.org  Fri Jan 17 18:13:49 2014
From: mailman at lists.osmocom.org (mailman at lists.osmocom.org)
Date: Fri, 17 Jan 2014 19:13:49 +0100
Subject: Bounce action notification
Message-ID: <mailman.981.1389982429.1438.osmocom-sdr@lists.osmocom.org>

This is a Mailman mailing list bounce action notice:

    List:       osmocom-sdr
    Member:     benjamin at southpole.se
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at
mailman at lists.osmocom.org.
-------------- next part --------------
An embedded message was scrubbed...
From: Mail Delivery System <Mailer-Daemon at ganesha.gnumonks.org>
Subject: Mail delivery failed: returning message to sender
Date: Fri, 17 Jan 2014 19:13:48 +0100
Size: 5138
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140117/0519027a/attachment.eml>

From nikos.balkanas at eyeonix.com  Fri Jan 17 19:46:25 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Fri, 17 Jan 2014 21:46:25 +0200
Subject: E4K tuner blues
In-Reply-To: <CAAdsYnY7_O4FYB8fjk2onTvtvs2X4irD9jv7Xn9_vK4uAgNCAg@mail.gmail.com>
References: <CAAdsYnY7_O4FYB8fjk2onTvtvs2X4irD9jv7Xn9_vK4uAgNCAg@mail.gmail.com>
Message-ID: <CAAdsYnarLkjrkb49=f3Q=TCYo8q0bYXgpDFPp7E2DkJQ3-F=Lg@mail.gmail.com>

On Fri, Jan 17, 2014 at 7:55 PM, Nikos Balkanas
<nikos.balkanas at eyeonix.com>wrote:

> I need to manipulate the tuners bandpass behavior. I have exported 2 more
> functions from librtlsdr, rtlsdr_set_filter_bw and rtlsdr_get_filter_bw and
> change the channel filter. However, when I use them I get libusb error(-22)
> **UNKNOWN ERROR**.
> I have tried bracketing the call with start/stop i2c repeater and
> disable/enable channel to no avail :-(
> It errs both when setting filter to 5.5 Mhz (max) and to 2.1 Mhz (min).
> What is going on? What other context should I provide for it to work
>

I was barking up the wrong tree. Error was -EINVAL from librtlsdr. I was
passing the wrong filter argument and librtlsdr was complaining about it
:-( Fixed it, added a couple of i2c repeaters, and it works like a charm ;-)


> TIA,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140117/cce69477/attachment.htm>

From peter at stuge.se  Fri Jan 17 19:50:23 2014
From: peter at stuge.se (Peter Stuge)
Date: Fri, 17 Jan 2014 20:50:23 +0100
Subject: E4K tuner blues
In-Reply-To: <CAAdsYnY7_O4FYB8fjk2onTvtvs2X4irD9jv7Xn9_vK4uAgNCAg@mail.gmail.com>
References: <CAAdsYnY7_O4FYB8fjk2onTvtvs2X4irD9jv7Xn9_vK4uAgNCAg@mail.gmail.com>
Message-ID: <20140117195023.4978.qmail@stuge.se>

Nikos Balkanas wrote:
> when I use them I get libusb error(-22)

It would be interesting to see a debug log from libusb, copypaste
instructions at http://libusb.org/wiki/debug

libusb should never return -22..


//Peter



From nikos.balkanas at eyeonix.com  Fri Jan 17 20:25:21 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Fri, 17 Jan 2014 22:25:21 +0200
Subject: E4K tuner blues
In-Reply-To: <20140117195023.4978.qmail@stuge.se>
References: <CAAdsYnY7_O4FYB8fjk2onTvtvs2X4irD9jv7Xn9_vK4uAgNCAg@mail.gmail.com>
	<20140117195023.4978.qmail@stuge.se>
Message-ID: <CAAdsYnYVQL9K4WG1_6+pxnYGfZPh0UqQgBdhA1oqLTksL1_fZQ@mail.gmail.com>

On Fri, Jan 17, 2014 at 9:50 PM, Peter Stuge <peter at stuge.se> wrote:

> Nikos Balkanas wrote:
> > when I use them I get libusb error(-22)
>
> It would be interesting to see a debug log from libusb, copypaste
> instructions at http://libusb.org/wiki/debug
>
> libusb should never return -22..
>
>
> //Peter
>
>
As it turns out it doesn't. But with open source, you can never be too sure
;-)
On the other hand it was the prime suspect, because I was pushing the e4k
to its limits and besides
librtlsdr doesn't do much at that point other than passing functions
around...

Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140117/d29117d9/attachment.htm>

From 393775602 at qq.com  Sat Jan 18 15:42:35 2014
From: 393775602 at qq.com (=?gb18030?B?MzkzNzc1NjAy?=)
Date: Sat, 18 Jan 2014 23:42:35 +0800
Subject: =?gb18030?B?u9i4tKO6IEVsb25pY3MgNDAwMCBiYW5kcGFzcw==?=
In-Reply-To: <CABrNoDA1ku_mwxk=DMGStV+Yd=SSCJ4OQ-XpOPzu-rDD6Ui6XQ@mail.gmail.com>
References: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
	<tencent_28B33C051620A41402716F95@qq.com>
	<CABrNoDA1ku_mwxk=DMGStV+Yd=SSCJ4OQ-XpOPzu-rDD6Ui6XQ@mail.gmail.com>
Message-ID: <tencent_2CE41EB5795030031D4CFC8A@qq.com>

thanks to all of u,i have start the rtl_tcp and see the log like:
rtl_tcp -a 127.0.0.1 -p 14423 -f 91800000 -s 1024000
Found 1 device(s).
Found Fitipower FC0013 tuner
Using Terratec NOXON DAB/DAB+ USB dongle (rev 1)
Tuned to 91800000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:14423' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).




my question now is what should i do next?where should i type command rtl_tcp=127.0.0.1:14423
to get the fft specturm data?


------------------ ???? ------------------
???: "Andr?s Retzle";<retzlerandras at gmail.com>;
????: 2014?1?16?(???) ??11:56
???: ""<393775602 at qq.com>; 
??: "osmocom-sdr"<osmocom-sdr at lists.osmocom.org>; 
??: Re: Elonics 4000 bandpass



Hi,



 i want to write an android app with the Realtek DVB-T Dongles ?is there any librtlsdr API for android?
 

What about these?


https://play.google.com/store/apps/details?id=marto.rtl_tcp_andro
  https://github.com/keesj/android-rtlsdr

https://github.com/keesj/librtlsdr-android

 

Regards,


Andras, HA7ILM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140118/6d5c8038/attachment.htm>

From retzlerandras at gmail.com  Sat Jan 18 16:36:08 2014
From: retzlerandras at gmail.com (=?ISO-8859-1?Q?Andr=E1s_Retzler?=)
Date: Sat, 18 Jan 2014 17:36:08 +0100
Subject: =?GB2312?B?UmU6ILvYuLSjuiBFbG9uaWNzIDQwMDAgYmFuZHBhc3M=?=
In-Reply-To: <tencent_2CE41EB5795030031D4CFC8A@qq.com>
References: <CAAdsYnZ51wwZOUkrzHx1KW6o26-e9_L+SWG1Y-h1=YHaaQckBA@mail.gmail.com>
	<tencent_28B33C051620A41402716F95@qq.com>
	<CABrNoDA1ku_mwxk=DMGStV+Yd=SSCJ4OQ-XpOPzu-rDD6Ui6XQ@mail.gmail.com>
	<tencent_2CE41EB5795030031D4CFC8A@qq.com>
Message-ID: <CABrNoDAGRthUoXZvtp8cxif99qYWXjtQQf54yW5KRAycmGgGJg@mail.gmail.com>

Hi,

You can type this to a gr-osmosdr block in GNU Radio. I doubt that GNU
Radio would be easy to compile on Android.

If you want to write your own client that processes I/Q data, you should
look at rtl_tcp source
code<http://cgit.osmocom.org/rtl-sdr/tree/src/rtl_tcp.c>,
it's quite self-documenting.

Anyway, some key points: if you open a TCP connection to the rtl_tcp
server, it immediately starts to send you the 8-bit I/Q samples acquired
from the dongle. Every odd byte is an I, every even byte is a Q sample.

You can control rtl_tcp with five byte commands. Look for "switch(cmd.cmd)"
and "struct command" in the source code.

When your client connects, it also gets 12 bytes with the dongle identifier
at the beginning of the stream, but it can be ignored. Look for "
dongle_info_t" if interested.

You will need to process the I/Q data yourself and calculate FFT to draw
the waterfall.

Regards,

Andras, HA7ILM




2014/1/18 393775602 <393775602 at qq.com>

> thanks to all of u,i have start the rtl_tcp and see the log like:
> rtl_tcp -a 127.0.0.1 -p 14423 -f 91800000 -s 1024000
> Found 1 device(s).
> Found Fitipower FC0013 tuner
> Using Terratec NOXON DAB/DAB+ USB dongle (rev 1)
> Tuned to 91800000 Hz.
> listening...
> Use the device argument 'rtl_tcp=127.0.0.1:14423' in OsmoSDR (gr-osmosdr)
> source
> to receive samples in GRC and control rtl_tcp parameters (frequency,
> gain, ...).
>
>
> my question now is what should i do next?where should i type command
> rtl_tcp=127.0.0.1:14423
> to get the fft specturm data?
>
> ------------------ ???? ------------------
> *???:* "Andr?s Retzle";<retzlerandras at gmail.com>;
> *????:* 2014?1?16?(???) ??11:56
> *???:* ""<393775602 at qq.com>;
> *??:* "osmocom-sdr"<osmocom-sdr at lists.osmocom.org>;
> *??:* Re: Elonics 4000 bandpass
>
> Hi,
>
>
> i want to write an android app with the Realtek DVB-T Dongles<http://wiki.spench.net/wiki/RTL2832U> ?is
>> there any librtlsdr API for android?
>>
>
> What about these?
>
> https://play.google.com/store/apps/details?id=marto.rtl_tcp_andro
>  https://github.com/keesj/android-rtlsdr
> https://github.com/keesj/librtlsdr-android
>
> Regards,
>
> Andras, HA7ILM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140118/e2e13372/attachment.htm>

From billhatch40 at yahoo.com  Sun Jan 19 01:56:10 2014
From: billhatch40 at yahoo.com (william hatch)
Date: Sat, 18 Jan 2014 17:56:10 -0800 (PST)
Subject: python rtlsdr for android ?
Message-ID: <1390096570.10665.YahooMailNeo@web162201.mail.bf1.yahoo.com>

I have been trying to install pyrtlsdr from https://github.com/roger-/pyrtlsdr? using the librtlsdr shared libraries from https://github.com/keesj/android-rtlsdr . So far the python code installed under /mnt/sdcard/sl4a/scripts is unable to find the librtlsdr shared libraries installed in /data/data/local with that location appended to sys.path.?

My objective is to access and control the USB SDR tuner directly from my python code without relying on the TCP server. Any help or hints welcome. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140118/d1285006/attachment.htm>

From nikos.balkanas at eyeonix.com  Sun Jan 19 08:08:35 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Sun, 19 Jan 2014 10:08:35 +0200
Subject: python rtlsdr for android ?
In-Reply-To: <1390096570.10665.YahooMailNeo@web162201.mail.bf1.yahoo.com>
References: <1390096570.10665.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Message-ID: <CAAdsYnYpk+t87+x4LAti988eLj-BO-bDox_Yz8MrMyFKs836fA@mail.gmail.com>

On Sun, Jan 19, 2014 at 3:56 AM, william hatch <billhatch40 at yahoo.com>wrote:

> I have been trying to install pyrtlsdr from
> https://github.com/roger-/pyrtlsdr  using the librtlsdr shared libraries
> from https://github.com/keesj/android-rtlsdr . So far the python code
> installed under /mnt/sdcard/sl4a/scripts is unable to find the librtlsdr
> shared libraries installed in /data/data/local with that location appended
> to sys.path.
>
> My objective is to access and control the USB SDR tuner directly from my
> python code without relying on the TCP server. Any help or hints welcome.
>
>
>
Does android run linux? Seems like a python question. In linux i would
check on PYTHONPATH or other similar pyVariables...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140119/2619e132/attachment.htm>

From billhatch40 at yahoo.com  Sun Jan 19 11:30:44 2014
From: billhatch40 at yahoo.com (william hatch)
Date: Sun, 19 Jan 2014 03:30:44 -0800 (PST)
Subject: python rtlsdr for android ?
In-Reply-To: <CAAdsYnYpk+t87+x4LAti988eLj-BO-bDox_Yz8MrMyFKs836fA@mail.gmail.com>
References: <1390096570.10665.YahooMailNeo@web162201.mail.bf1.yahoo.com>
	<CAAdsYnYpk+t87+x4LAti988eLj-BO-bDox_Yz8MrMyFKs836fA@mail.gmail.com>
Message-ID: <1390131044.14058.YahooMailNeo@web162202.mail.bf1.yahoo.com>

Android is a modified version of Linux. The shared library locations were appended to sys.path. the relocatable path /data/data/local is one of the location that other folks had recommended placing shared libraries. My SG3 is rooted, thus I was able to place the shared libraries in /data/data/local and set the file permissions.

I have also started looking at how to access the tcp server from my python code. So far no progress there.





On Sunday, January 19, 2014 3:08 AM, Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:
 





On Sun, Jan 19, 2014 at 3:56 AM, william hatch <billhatch40 at yahoo.com> wrote:

I have been trying to install pyrtlsdr from https://github.com/roger-/pyrtlsdr? using the librtlsdr shared libraries from https://github.com/keesj/android-rtlsdr . So far the python code installed under /mnt/sdcard/sl4a/scripts is unable to find the librtlsdr shared libraries installed in /data/data/local with that location appended to sys.path.?
>
>
>My objective is to access and control the USB SDR tuner directly from my python code without relying on the TCP server. Any help or hints welcome. 
>
>
>
>
>

Does android run linux? Seems like a python question. In linux i would check on PYTHONPATH or other similar pyVariables...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140119/da74216a/attachment.htm>

From laforge at gnumonks.org  Tue Jan 21 15:04:20 2014
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 21 Jan 2014 16:04:20 +0100
Subject: [omri@iluz.net: Sniffing and decoding NRF24L01+ and Bluetooth LE
	packets using RTL-SDR]
Message-ID: <20140121150420.GG14476@nataraja>

Dear all,

with the permission of the original poster, I hereby forward a message
from Omri regarding his use of rtl-sdr to sniff and decode NRF24L01+ and
Bluetooth LE packets.

I have no involvement in the project, I'm just passing on the mail,
thats' all ;)

Regards,
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
An embedded message was scrubbed...
From: "Omri Iluz" <omri at iluz.net>
Subject: Sniffing and decoding NRF24L01+ and Bluetooth LE packets using RTL-SDR
Date: Tue, 21 Jan 2014 04:32:51 -0800
Size: 7039
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140121/447cd52c/attachment.eml>

From putaoshu at gmail.com  Wed Jan 22 01:13:23 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Wed, 22 Jan 2014 09:13:23 +0800
Subject: [omri@iluz.net: Sniffing and decoding NRF24L01+ and Bluetooth LE
	packets using RTL-SDR]
In-Reply-To: <20140121150420.GG14476@nataraja>
References: <20140121150420.GG14476@nataraja>
Message-ID: <CABs6FUqyMwszrbsgG5TVdY_EPehExQtenJ-TWFO5RBSNkPdTLQ@mail.gmail.com>

That's great!
Frequency band is extended pretty much!


On Tue, Jan 21, 2014 at 11:04 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Dear all,
>
> with the permission of the original poster, I hereby forward a message
> from Omri regarding his use of rtl-sdr to sniff and decode NRF24L01+ and
> Bluetooth LE packets.
>
> I have no involvement in the project, I'm just passing on the mail,
> thats' all ;)
>
> Regards,
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
>
> ---------- Forwarded message ----------
> From: "Omri Iluz" <omri at iluz.net>
> To: <laforge at gnumonks.org>
> Cc:
> Date: Tue, 21 Jan 2014 04:32:51 -0800
> Subject: Sniffing and decoding NRF24L01+ and Bluetooth LE packets using
> RTL-SDR
>
> Hi,
>
> Link:
> http://blog.cyberexplorer.me/2014/01/sniffing-and-decoding-nrf24l01-and.html
>
>
>
> I was able to sniff and decode NRF24L01+ and Bluetooth Low Energy
> protocols using RTL-SDR.
>
>
> I?m using your great library. Happy to be included in your list. Code is
> at  https://github.com/omriiluz/NRF24-BTLE-Decoder
>
>
>
> Thanks,
>
> Omri
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140122/db08b3b7/attachment.htm>

From putaoshu at gmail.com  Wed Jan 22 01:28:46 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Wed, 22 Jan 2014 09:28:46 +0800
Subject: Use multi-dongles to speedup identifying all available/detectable GSM
	downlink broadcasting carrier
Message-ID: <CABs6FUokLPcCROw92ykKzan5tXFtF4_P6FM7=7b3wi2ALxyasA@mail.gmail.com>

Hi,

As a "side product" of this thread: "How to get IQ samples from multiple
rtl-sdr dongles in a synchronized manner",A scanning tool is released for
identifying all available/detectable GSM broadcasting carrier around you
quickly.

You can find it here:
http://www.mathworks.com/matlabcentral/fileexchange/45152-rtl-sdr-multi-dongles-based-gsm-fcch-scanner
or
https://github.com/JiaoXianjun/multi-rtl-sdr-calibration

By using 3 dongles, we can identify all available/detectable GSM
broadcasting carrier in the whole PGSM band downlink 935~960MHz in 30s (my
intel i7 12-core station) instead of 80s (only one dongles).

The original purpose of project multi-rtl-sdr-calibration is that
calibrating multiple dongles by the common GSM source.
So the first thing need to do is that finding out where is the strongest
GSM signal in the air.
This script (multi_rtl_sdr_gsm_FCCH_scanner.m) can identify GSM downlink
broadcasting carrier by detecting successive multiple FCCH bursts of all
possible carrier in a band you specify, such as PGSM downlink 935~960MHz.
I learn knowledge of GSM frame structure from here:
http://www.sharetechnote.com/html/FrameStructure_GSM.html
After the script is run, quality metrics of detected FCCH channel per
frequency will be displayed: SNR and number of detected FCCH burst (num of
hits).
Note: for speedup detection algorithm, a large decimation ratio is used,
thus shown SNR may be lower than actual SNR. But it is enough to help us
idendify which frequency is best.

README is also pasted here:

Multiple rtl-sdr(rtl_tcp) dongles based GSM FCCH scanner. (
putaoshu at gmail.com; putaoshu at msn.com)

multi_rtl_sdr_gsm_FCCH_scanner.m
Have multiple dongles run concurrently to speedup detecting FCCH(Frequency
correction channel) burst in wide GSM band by scanning different sub-band
with different dongle.

This is a sub script of project:
https://github.com/JiaoXianjun/multi-rtl-sdr-calibration

------------Purpose------------
The original purpose of project multi-rtl-sdr-calibration is that
calibrating multiple dongles by the common GSM source.
So the first thing need to do is that finding out where is the strongest
GSM signal in the air.
This script can identify GSM downlink broadcasting carrier by detecting
successive multiple FCCH burst.
I learn knowledge of GSM frame structure from here:
http://www.sharetechnote.com/html/FrameStructure_GSM.html
After the script is run, quality metrics of detected FCCH channel will be
displayed: SNR and number of detected FCCH burst (num of hits).
Note: for speedup detection algorithm, a large decimation ratio is used,
thus shown SNR may be lower than actual SNR. But it is enough to help us
idendify which frequency is best.

-------------Usage-------------
1. Assume that you have installed rtl-sdr
(http://sdr.osmocom.org/trac/wiki/rtl-sdr) and have those native utilities
run correctly already.

For example, you have multiple dongles, please run multiple rtl_tcp in
multiple shell respectively as:
rtl_tcp -p 1234 -d 0
rtl_tcp -p 1235 -d 1
rtl_tcp -p 1236 -d 2
...

2. Then run multi_rtl_sdr_gsm_FCCH_scanner.m in MATLAB.

ATTENTION! In some computer, each time before you run script, maybe you
need to terminate multiple rtl_tcp and re-launch them again.
ATTENTION! Please reduce number of inspected points by reducing frequency
range, if your computer hasn't enough memory installed. Because all sigals
are stored firstly before processing.

Change following parameters in the script as you need:

num_dongle = 1; % number of dongles you installed
start_freq = 935e6;
end_freq = 960e6;
freq_step = 0.2e6; % GSM channel spacing
gain = 0;
...

Some key parameters:
% how long signal we try to find multiple FCCH bursts in
num_frame = 64; % roughly speaking, there are 1 FCCH burst per 10 frames,
but 50 frames plus 1 idle frame construct one multiframe

FCCH_coarse_position.m
th = 10; % Peak to average threshold of detecting FCCH in moving averaging
SNR(estimated by FFT) stream.
max_offset = 5; % +/- range of predicted next postion of FCCH burst.

------------Algorithm------------
Because FCCH actually is a period of CW signal, we can use FFT to see if
there is sharp peak in frequency domain.
For the first FCCH detection, a continuous moving FFT is performed. After
the first FCCH is hit, the following FCCH will be only detected at
predicted position (+/- small range) according to GSM frame structure.
At least 3 successive FCCH need to be detected for we to ensure one
donwlink broadcasting carrier is there. See details in
FCCH_coarse_position.m.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140122/9c733c9f/attachment.htm>

From omri at iluz.net  Wed Jan 22 01:59:24 2014
From: omri at iluz.net (Omri Iluz)
Date: Tue, 21 Jan 2014 17:59:24 -0800
Subject: Sniffing digital wireless protocols at 2.4Ghz with RTL-SDR
Message-ID: <031e01cf1715$9370a9a0$ba51fce0$@iluz.net>

I was able to decode NRF24L01+ and Bluetooth Low Energy protocols using RTL-SDR. with some very cheap analog trickery.

This opens a world of possibilities at the ISM 2.4Ghz band.

 

Detailed walk-through of the journey from idea to a working solution at http://blog.cyberexplorer.me/2014/01/sniffing-and-decoding-nrf24l01-and.html

Code at https://github.com/omriiluz/NRF24-BTLE-Decoder

 

Thought it would be interesting for the folks here.

 

Also, I it would be great if you can add me to the list of decoders at http://sdr.osmocom.org/trac/wiki/rtl-sdr 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140121/35f9b08f/attachment.htm>

From 393775602 at qq.com  Wed Jan 22 03:50:26 2014
From: 393775602 at qq.com (=?gb18030?B?MzkzNzc1NjAy?=)
Date: Wed, 22 Jan 2014 11:50:26 +0800
Subject: what to see
Message-ID: <tencent_6102812C0C1677C60B99FC8B@qq.com>

Hi?
i have just transmited the rtl-sdr code into android using NDK?and i start the rtl-sdr and set the fequecny,samp_rate and so on.
Finally i get the output from rtl and write it into a txt file.
Then the problem came, i open the txt and find it a mess, does the output decode in utf-8 or something else,can anyone give me
a look to see what output is like


Thanks a lot


chenzujie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140122/d69c69a0/attachment.htm>

From zaitcev at kotori.zaitcev.us  Wed Jan 22 04:54:36 2014
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Tue, 21 Jan 2014 21:54:36 -0700
Subject: Another failure of decoding UAT
Message-ID: <20140121215436.6d41a3b0@lembas.zaitcev.lan>

Guys,

As you know, our sample rate is not good enough to decode UAT's FSK in
a conventional way, so I thought to try something else: use 2 samples
per bit to detect the frequency shift. This is obviously unreliable,
but I hoped to see something at least. But it didn't work: seems like
decoding noise.

The code is here:
 https://github.com/zaitcev/ruat

Anyone is willing to critique? Where did I go wrong?

Thanks,
-- Pete



From nikos.balkanas at eyeonix.com  Wed Jan 22 10:35:35 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Wed, 22 Jan 2014 12:35:35 +0200
Subject: Another failure of decoding UAT
In-Reply-To: <20140121215436.6d41a3b0@lembas.zaitcev.lan>
References: <20140121215436.6d41a3b0@lembas.zaitcev.lan>
Message-ID: <CAAdsYnYsOBS5A-BgKXn0yxiK=XefMrxBOn=SOsLduzz5=h1CUQ@mail.gmail.com>

Have you checked your hardware? Mostly antenna and grounds...

BR,
Nikos


On Wed, Jan 22, 2014 at 6:54 AM, Pete Zaitcev <zaitcev at kotori.zaitcev.us>wrote:

> Guys,
>
> As you know, our sample rate is not good enough to decode UAT's FSK in
> a conventional way, so I thought to try something else: use 2 samples
> per bit to detect the frequency shift. This is obviously unreliable,
> but I hoped to see something at least. But it didn't work: seems like
> decoding noise.
>
> The code is here:
>  https://github.com/zaitcev/ruat
>
> Anyone is willing to critique? Where did I go wrong?
>
> Thanks,
> -- Pete
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140122/05382b20/attachment.htm>

From zaitcev at kotori.zaitcev.us  Wed Jan 22 15:36:25 2014
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Wed, 22 Jan 2014 08:36:25 -0700
Subject: Another failure of decoding UAT
In-Reply-To: <CAAdsYnYsOBS5A-BgKXn0yxiK=XefMrxBOn=SOsLduzz5=h1CUQ@mail.gmail.com>
References: <20140121215436.6d41a3b0@lembas.zaitcev.lan>
	<CAAdsYnYsOBS5A-BgKXn0yxiK=XefMrxBOn=SOsLduzz5=h1CUQ@mail.gmail.com>
Message-ID: <20140122083625.4f4d757a@lembas.zaitcev.lan>

The hardware receives the Extended Squitter at 1090 MHz, so we may
assume that it works. I'm using a little monopole antenna sized for
978 MHz for this, sitting right on the connector.

-- Pete

On Wed, 22 Jan 2014 12:35:35 +0200
Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:

> Have you checked your hardware? Mostly antenna and grounds...
> 
> BR,
> Nikos
> 
> 
> On Wed, Jan 22, 2014 at 6:54 AM, Pete Zaitcev <zaitcev at kotori.zaitcev.us>wrote:
> 
> > Guys,
> >
> > As you know, our sample rate is not good enough to decode UAT's FSK in
> > a conventional way, so I thought to try something else: use 2 samples
> > per bit to detect the frequency shift. This is obviously unreliable,
> > but I hoped to see something at least. But it didn't work: seems like
> > decoding noise.
> >
> > The code is here:
> >  https://github.com/zaitcev/ruat
> >
> > Anyone is willing to critique? Where did I go wrong?
> >
> > Thanks,
> > -- Pete



From david.jacobowitz at gmail.com  Wed Jan 22 16:25:57 2014
From: david.jacobowitz at gmail.com (David Jacobowitz)
Date: Wed, 22 Jan 2014 08:25:57 -0800
Subject: Another failure of decoding UAT
In-Reply-To: <20140122083625.4f4d757a@lembas.zaitcev.lan>
References: <20140121215436.6d41a3b0@lembas.zaitcev.lan>
	<CAAdsYnYsOBS5A-BgKXn0yxiK=XefMrxBOn=SOsLduzz5=h1CUQ@mail.gmail.com>
	<20140122083625.4f4d757a@lembas.zaitcev.lan>
Message-ID: <CACuAV7QDAXCGqMPe35mcK5T=0yD7gWW=EBsWQ2_A6hJ3c43N2w@mail.gmail.com>

This may be dumb because I haven't looked into it, but is it reasonable to
expect to receive a signal?

Are you in the US? There really aren't that many UAT equipped aircraft yet.
The FAA is rebroadcasting ADSB ES responses on UAT as well as providing
weather and other data, but that is all coming from ground stations. If you
need line of sight and you're on the ground yourself you may be out of luck.

- Dave J
On Jan 22, 2014 7:36 AM, "Pete Zaitcev" <zaitcev at kotori.zaitcev.us> wrote:

> The hardware receives the Extended Squitter at 1090 MHz, so we may
> assume that it works. I'm using a little monopole antenna sized for
> 978 MHz for this, sitting right on the connector.
>
> -- Pete
>
> On Wed, 22 Jan 2014 12:35:35 +0200
> Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:
>
> > Have you checked your hardware? Mostly antenna and grounds...
> >
> > BR,
> > Nikos
> >
> >
> > On Wed, Jan 22, 2014 at 6:54 AM, Pete Zaitcev <zaitcev at kotori.zaitcev.us
> >wrote:
> >
> > > Guys,
> > >
> > > As you know, our sample rate is not good enough to decode UAT's FSK in
> > > a conventional way, so I thought to try something else: use 2 samples
> > > per bit to detect the frequency shift. This is obviously unreliable,
> > > but I hoped to see something at least. But it didn't work: seems like
> > > decoding noise.
> > >
> > > The code is here:
> > >  https://github.com/zaitcev/ruat
> > >
> > > Anyone is willing to critique? Where did I go wrong?
> > >
> > > Thanks,
> > > -- Pete
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140122/22249d55/attachment.htm>

From gisle.vanem at gmail.com  Wed Jan 22 16:54:12 2014
From: gisle.vanem at gmail.com (Gisle Vanem)
Date: Wed, 22 Jan 2014 17:54:12 +0100
Subject: stack-fault in rtl_fm.exe
Message-ID: <C721017FBF28496EB4652405C74DCB09@dev.null>

The rtl_fm program uses approx 1.8 MByte for it's stack. Mostly used
for 'stuct fm_state'. The default stack-size for a Windows program is
4kB (it can dynamically grow). I've compiled using MSVC v16 and option
'-GS'. Ref: http://support.microsoft.com/kb/100775

Adding '-stack:2000000' to the link stage works fine here. Or alloca() or malloc()
could be used? Or 'fm' could be made static?

--gv




From zaitcev at kotori.zaitcev.us  Wed Jan 22 16:54:52 2014
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Wed, 22 Jan 2014 09:54:52 -0700
Subject: Another failure of decoding UAT
In-Reply-To: <CACuAV7QDAXCGqMPe35mcK5T=0yD7gWW=EBsWQ2_A6hJ3c43N2w@mail.gmail.com>
References: <20140121215436.6d41a3b0@lembas.zaitcev.lan>
	<CAAdsYnYsOBS5A-BgKXn0yxiK=XefMrxBOn=SOsLduzz5=h1CUQ@mail.gmail.com>
	<20140122083625.4f4d757a@lembas.zaitcev.lan>
	<CACuAV7QDAXCGqMPe35mcK5T=0yD7gWW=EBsWQ2_A6hJ3c43N2w@mail.gmail.com>
Message-ID: <20140122095452.54c81efb@lembas.zaitcev.lan>

I know someone who's reveiving FIS-B with a GDL 39, although his
home base is about 100 km north-east. I'm somewhat confident that
I should have the coverage. One problem is, from what I heard,
the ground stations will not broadcast anything until a UAT-equipped
aircraft checks in.

Regardless, I was hoping that Nick or other experts chime in on
the code itself. Honestly I have no clue what I'm doing here.
I imagine that if signal is present, then vector pointed by Q+jI 
rotates at ~300 revolutions per second. Therefore, I calculate
the phase angle difference between two samples taken at twice
the UAT bit rate and see if it's anywhere reasonable. It may
be a bogus technique for any number of reasons.

-- Pete

On Wed, 22 Jan 2014 08:25:57 -0800
David Jacobowitz <david.jacobowitz at gmail.com> wrote:

> This may be dumb because I haven't looked into it, but is it reasonable to
> expect to receive a signal?
> 
> Are you in the US? There really aren't that many UAT equipped aircraft yet.
> The FAA is rebroadcasting ADSB ES responses on UAT as well as providing
> weather and other data, but that is all coming from ground stations. If you
> need line of sight and you're on the ground yourself you may be out of luck.
> 
> - Dave J



From bistromath at gmail.com  Wed Jan 22 17:33:14 2014
From: bistromath at gmail.com (Nick Foster)
Date: Wed, 22 Jan 2014 09:33:14 -0800
Subject: Another failure of decoding UAT
In-Reply-To: <20140122095452.54c81efb@lembas.zaitcev.lan>
References: <20140121215436.6d41a3b0@lembas.zaitcev.lan>
	<CAAdsYnYsOBS5A-BgKXn0yxiK=XefMrxBOn=SOsLduzz5=h1CUQ@mail.gmail.com>
	<20140122083625.4f4d757a@lembas.zaitcev.lan>
	<CACuAV7QDAXCGqMPe35mcK5T=0yD7gWW=EBsWQ2_A6hJ3c43N2w@mail.gmail.com>
	<20140122095452.54c81efb@lembas.zaitcev.lan>
Message-ID: <CA+JMMq8w4oxRK939a5SQ6B+yNNjSOd90a89AK_eHRmQ2UKHrhw@mail.gmail.com>

I'm assuming the GDL 39 is airborne when receiving -- there's no guarantee
of ground-based coverage, and unless you're close to a transmitter or have
line-of-sight due to elevation you might not have any signal to work with.

I think the first thing you should do is verify some sort of signal is
present, using osmocom_fft or whatever, and then record some samples you
can work with offline to decode. Maybe go for a flight near the uplink,
verify there's a signal using both the GDL 39 and the RTL dongle, and
record some nice strong samples to hack on later.

I haven't looked into decoding UAT with any seriousness apart from reading
DO-282B, but 2 samples per symbol should be enough to work with. Maybe I'm
being clueless here, but I don't see justification for saying the RTL
dongles can't sample fast enough for UAT. The usual noncoherent method -- a
differential quadrature demodulator -- should be fine, and saves you from
having to phase- and frequency-synchronize with the baseband signal. I
haven't looked closely at your code, but your description sounds pretty
close to that. You'll see (up to) 312.5kHz deviation on a '1' bit, and (up
to) -312.5kHz deviation on '0'.

You can probably get away with open-loop clock recovery since the packets
are so short, but you'll still have to estimate the center of the bit so
you can sample and slice.

Personally, as a registered GNU Radio fanboy, I'd be using GR to at least
get started demodulating UAT. It gets you graphical sinks to work with and
a set of proven signal processing blocks, so you don't have to worry as
much about an ad-hoc approach being valid or not.

--n


On Wed, Jan 22, 2014 at 8:54 AM, Pete Zaitcev <zaitcev at kotori.zaitcev.us>wrote:

> I know someone who's reveiving FIS-B with a GDL 39, although his
> home base is about 100 km north-east. I'm somewhat confident that
> I should have the coverage. One problem is, from what I heard,
> the ground stations will not broadcast anything until a UAT-equipped
> aircraft checks in.
>
> Regardless, I was hoping that Nick or other experts chime in on
> the code itself. Honestly I have no clue what I'm doing here.
> I imagine that if signal is present, then vector pointed by Q+jI
> rotates at ~300 revolutions per second. Therefore, I calculate
> the phase angle difference between two samples taken at twice
> the UAT bit rate and see if it's anywhere reasonable. It may
> be a bogus technique for any number of reasons.
>
> -- Pete
>
> On Wed, 22 Jan 2014 08:25:57 -0800
> David Jacobowitz <david.jacobowitz at gmail.com> wrote:
>
> > This may be dumb because I haven't looked into it, but is it reasonable
> to
> > expect to receive a signal?
> >
> > Are you in the US? There really aren't that many UAT equipped aircraft
> yet.
> > The FAA is rebroadcasting ADSB ES responses on UAT as well as providing
> > weather and other data, but that is all coming from ground stations. If
> you
> > need line of sight and you're on the ground yourself you may be out of
> luck.
> >
> > - Dave J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140122/cc304fe3/attachment.htm>

From 393775602 at qq.com  Thu Jan 23 03:28:24 2014
From: 393775602 at qq.com (=?ISO-8859-1?B?MzkzNzc1NjAy?=)
Date: Thu, 23 Jan 2014 11:28:24 +0800
Subject: RTL2832u;datesheet
Message-ID: <tencent_44790AAC43909DF4652C2C6A@qq.com>

Hi,
i am  studying the rtl-sdr code recently and get it start and receive some data,
and i want to analysis the data by myself, does anyone have a RTL2832U datasheet.
can anyone send me one? or tell me where i can download it or buy it!
           


             Thanks all the same
              Chen Zujie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140123/4351bed2/attachment.htm>

From 246tnt at gmail.com  Thu Jan 23 10:26:56 2014
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 23 Jan 2014 11:26:56 +0100
Subject: Sniffing digital wireless protocols at 2.4Ghz with RTL-SDR
In-Reply-To: <031e01cf1715$9370a9a0$ba51fce0$@iluz.net>
References: <031e01cf1715$9370a9a0$ba51fce0$@iluz.net>
Message-ID: <CAHL+j09MowKHLvwyAVTLHfPHMhazUNzTwrhHUF407HPUoJ4V8A@mail.gmail.com>

Hi Omri,

> I was able to decode NRF24L01+ and Bluetooth Low Energy protocols using
> RTL-SDR. with some very cheap analog trickery.
>
> This opens a world of possibilities at the ISM 2.4Ghz band.

Very nice.  And good find for the cheap downconverter source :)

I added a link to the code and the blog post in the "Known Apps" section.

Cheers,

    Sylvain



From mas.ignacio at gmail.com  Tue Jan 14 07:21:48 2014
From: mas.ignacio at gmail.com (Nacho Mas)
Date: Tue, 14 Jan 2014 08:21:48 +0100
Subject: rtl-sdr. SVEON STV27 works
Message-ID: <CAG2DOwP7L9+W0GRG3HX39sOLSMufBo-GdYiX-YiQ_jc+oEj3DA@mail.gmail.com>

Hello everyone,

For your informaqtion. My "SVEON 27" start working just adding it to
librtlsdr.c:

{ 0x1b80, 0xd3af, "SVEON STV27 DVB-T USB & FM" },


Aparently it has a F00013 tuner.  It is reported by lsusb as:

Bus 002 Device 004: ID 1b80:d3af Afatech

Cheers
Nacho Mas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140114/f13d8f2c/attachment.htm>

From bon at elektron.ikp.physik.tu-darmstadt.de  Mon Jan 20 14:07:00 2014
From: bon at elektron.ikp.physik.tu-darmstadt.de (bon at elektron.ikp.physik.tu-darmstadt.de)
Date: Mon, 20 Jan 2014 15:07:00 +0100
Subject: sdrangelove: Allow to select build type on command line
Message-ID: <21213.11652.628554.750155@gargle.gargle.HOWL>


-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

From bon at elektron.ikp.physik.tu-darmstadt.de  Mon Jan 20 13:34:40 2014
From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes)
Date: Mon, 20 Jan 2014 14:34:40 +0100
Subject: cmake: Allow to choose build type on command line.
Message-ID: <mailman.12.1641746899.43026.osmocom-sdr@lists.osmocom.org>

---
 CMakeLists.txt | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ab899f2..9a6a2f1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,9 +3,12 @@ list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
 
 project(sdrangelove)
 
-set(CMAKE_BUILD_TYPE "Release")
+#set(CMAKE_BUILD_TYPE "Release")
 #set(CMAKE_BUILD_TYPE "ReleaseWithDebugInfo")
 #set(CMAKE_BUILD_TYPE "Debug")
+if (NOT DEFINED CMAKE_BUILD_TYPE)
+  set(CMAKE_BUILD_TYPE "Release")
+endif()
 
 set(QT_USE_QTOPENGL TRUE)
 set(CMAKE_AUTOMOC ON)
-- 
1.8.4




From nikos.balkanas at eyeonix.com  Thu Jan 23 12:39:14 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 23 Jan 2014 14:39:14 +0200
Subject: RTL2832u;datesheet
In-Reply-To: <tencent_44790AAC43909DF4652C2C6A@qq.com>
References: <tencent_44790AAC43909DF4652C2C6A@qq.com>
Message-ID: <CAAdsYnZ0B+w6Cv1LqTJyeGW9HrY9TVOPodkksoUDyhk01mFJWw@mail.gmail.com>

Hi,

Just read the rtl-sdr/include/rtl-sdr.h. It includes all API functions with
helpful notes for each one ;-).

BR,
Nikos


On Thu, Jan 23, 2014 at 5:28 AM, 393775602 <393775602 at qq.com> wrote:

> Hi,
> i am  studying the rtl-sdr code recently and get it start and receive some
> data,
> and i want to analysis the data by myself, does anyone have a RTL2832U
> datasheet.
> can anyone send me one? or tell me where i can download it or buy it!
>
>
>              Thanks all the same
>               Chen Zujie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140123/51878d97/attachment.htm>

From zaitcev at kotori.zaitcev.us  Thu Jan 23 16:00:43 2014
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Thu, 23 Jan 2014 09:00:43 -0700
Subject: RTL2832u;datesheet
In-Reply-To: <CAAdsYnZ0B+w6Cv1LqTJyeGW9HrY9TVOPodkksoUDyhk01mFJWw@mail.gmail.com>
References: <tencent_44790AAC43909DF4652C2C6A@qq.com>
	<CAAdsYnZ0B+w6Cv1LqTJyeGW9HrY9TVOPodkksoUDyhk01mFJWw@mail.gmail.com>
Message-ID: <20140123090043.0460562f@guren.zaitcev.lan>

On Thu, 23 Jan 2014 14:39:14 +0200
Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:

> Just read the rtl-sdr/include/rtl-sdr.h. It includes all API functions with
> helpful notes for each one ;-).

It's not sufficient. The header file does not specify the I/Q
format: the integer encoding and which byte is I and which is Q.
When I needed it, I had to cargo-cult it from bits and pieces
in the sample programs.

-- Pete



From retzlerandras at gmail.com  Thu Jan 23 23:23:16 2014
From: retzlerandras at gmail.com (=?ISO-8859-1?Q?Andr=E1s_Retzler?=)
Date: Fri, 24 Jan 2014 00:23:16 +0100
Subject: RTL2832u;datesheet
In-Reply-To: <20140123090043.0460562f@guren.zaitcev.lan>
References: <tencent_44790AAC43909DF4652C2C6A@qq.com>
	<CAAdsYnZ0B+w6Cv1LqTJyeGW9HrY9TVOPodkksoUDyhk01mFJWw@mail.gmail.com>
	<20140123090043.0460562f@guren.zaitcev.lan>
Message-ID: <CABrNoDDaf2xHDPDhSFvNfD5-SKMP+Gxyv1dKcntNtg-EJhUR8w@mail.gmail.com>

I/Q format is 8-bit unsigned, odd bytes are I, even bytes are Q, quite
similar to a stereo wave file.

Regards,

Andras, HA7ILM


2014/1/23 Pete Zaitcev <zaitcev at kotori.zaitcev.us>

> On Thu, 23 Jan 2014 14:39:14 +0200
> Nikos Balkanas <nikos.balkanas at eyeonix.com> wrote:
>
> > Just read the rtl-sdr/include/rtl-sdr.h. It includes all API functions
> with
> > helpful notes for each one ;-).
>
> It's not sufficient. The header file does not specify the I/Q
> format: the integer encoding and which byte is I and which is Q.
> When I needed it, I had to cargo-cult it from bits and pieces
> in the sample programs.
>
> -- Pete
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140124/129c5ddf/attachment.htm>

From steve at steve-m.de  Fri Jan 24 00:08:54 2014
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 24 Jan 2014 01:08:54 +0100
Subject: rtl-sdr. SVEON STV27 works
In-Reply-To: <CAG2DOwP7L9+W0GRG3HX39sOLSMufBo-GdYiX-YiQ_jc+oEj3DA@mail.gmail.com>
References: <CAG2DOwP7L9+W0GRG3HX39sOLSMufBo-GdYiX-YiQ_jc+oEj3DA@mail.gmail.com>
Message-ID: <52E1AF16.80502@steve-m.de>

Hi,

On 14.01.2014 08:21, Nacho Mas wrote:
> For your informaqtion. My "SVEON 27" start working just adding it to
> librtlsdr.c:

Thanks, added to the device list.

Regards,
Steve



From j.arndt at sis-germany.com  Fri Jan 24 15:35:42 2014
From: j.arndt at sis-germany.com (Jochen Arndt)
Date: Fri, 24 Jan 2014 16:35:42 +0100
Subject: E4000 tuner gain settings
Message-ID: <52E2884E.4020308@sis-germany.com>

After playing around with the E4000 tuner gain settings, I will 
summarize my results.

LNA Gain Enhancement
--------------------

LNA Gain Enhancement is working in automatic mode but not in manual mode.

To enable LNA enhancement, write 0x05 to register AGC11. This can be 
left unchanged even when enabling manual gain mode.

Required updates for tuner_e4k.c:
  Function e4k_enable_manual_gain():
   Remove or comment the line that disables LNA Enhancement for auto mode
    e4k_reg_set_mask(e4k, E4K_REG_AGC11, 0x7, 0);
  Function e4k_init():
   Pull line out of null condition to enable LNA Enhancement
    e4k_reg_set_mask(e4k, E4K_REG_AGC11, 0x7, E4K_AGC11_LNA_GAIN_ENH | 
(2 << 1));


Automatic Mode
--------------

The mixer control register AGC7 defines a threshold value. When 
automatic mixer control is enabled and the LNA gain index reaches the 
threshold value, the high mixer gain of 12 dB will be used. Upon reset, 
the AGC7 register is cleared and the threshold value is never set by the 
RTLSDR library. This results in always using the high mixer gain 
(threshold value 0 corresponds to the lowest LNA gain).

The datasheet recommends writing 0x15 to AGC7. This corresponds to a 
threshold of 15 dB (0x15 >> 1 = 0x0A LNA gain index). A value of 0x1D 
would set the threshold to max. LNA gain.
NOTE:
When LNA Enhancement is enabled, setting the threshold to max. gain is 
not useful. There will be a strong gain increasement step from 25 + 4 = 
29 dB to 25 + 5 + 12 = 42 dB.

Required updates for tuner_e4k.c:
  Function e4k_init():
   Replace the line
    e4k_reg_set_mask(e4k, E4K_REG_AGC7, E4K_AGC7_MIX_GAIN_AUTO, 0);
   with this
    e4k_reg_write(e4k, E4K_REG_AGC7, 0x14);

The above modification will set the threshold value and disable auto 
mixer gain control. e4k_enable_manual_gain() is called later and will 
modify only bit 0 of AGC7.


Manual Mode
-----------

In manual mode LNA enhancement is not used. So the list of gains must be 
changed because the last two values assume that it is used.

The actually used gains are based on Table 6 and the register map of the 
E4000 data sheet. The gain table contains those values plus the mixer 
gain of 12 db for the last value and 4 db for all others. But the LNA 
gain of 30 dB specified in the data sheet is only valid when LNA gain 
enhancement is enabled.
Cite from data sheet section 1.16 LNA Gain enhancement referring 
register AGC7:
  "The LNA gain numbers quoted throughout this document assume that this
   register is programmed to the recommended value."
Even when LNA Enhancement would work with manual mode, the second to 
last value is wrong because LNA enhancement requires that the mixer gain 
is at 12 dB.

Required updates for librtlsdr.c:
  Change int e4k_gains[]  from
   const int e4k_gains[] = {
    -10, 15, 40, 65, 90, 115, 140, 165, 190, 215, 240, 290, 340, 420
};
  to
   const int e4k_gains[] = {
	-50 + 40, -25 + 40, 0 + 40, 25 + 40, 50 + 40, 75 + 40,
	100 + 40, 125 + 40, 150 + 40, 175 + 40, 200 + 40, 250 + 40,
	200 + 120,	// 320, optional additional entry
	250 + 120
};

  Change top of e4000_set_gain() function from
   int e4000_set_gain(void *dev, int gain) {
	rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
	int mixgain = (gain > 340) ? 12 : 4;
	if(e4k_set_lna_gain(&devt->e4k_s, min(300, gain - mixgain * 10)) == 
-EINVAL)
  to
   int e4000_set_gain(void *dev, int gain) {
	rtlsdr_dev_t* devt = (rtlsdr_dev_t*)dev;
	int mixgain = (0 == (gain - 120) % 25) ? 12 : 4;
	if(e4k_set_lna_gain(&devt->e4k_s, gain - mixgain * 10) == -EINVAL)

The above extraction of the mixer gain from the combined LNA and mixer 
gain can be used for all possible valid LNA/mixer gain combinations.

Required updates for tuner_e4k.c:
  Change last value of static const int32_t lnagain[] from 300 to 250
  Optionally change second to last value from 250 to 249 to force
   selection of the highest possible LNA gain index.

The 2-dim array may be also replaced by a smaller 1-dim array
  when updating also e4k_set_lna_gain():
static const int32_t lna_gain[16] = {
	-50, -25, -50, -25, 0, 25, 50, 75,
	100, 125, 150, 175, 200, 249, 250, 250
};
int e4k_set_lna_gain(struct e4k_state *e4k, int32_t gain)
{
	uint32_t i;
	for(i = 0; i < ARRAY_SIZE(lnagain); ++i) {
		if(lnagain[i] == gain) {
			e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, i);
			return gain;
		}
	}
	return -EINVAL;
}


Detecting Signal Strength
-------------------------

The signal strength can be calculated by determining the relative 
strength of a signal (e.g. using a FFT) and subtracting the total gain.

To get the total gain in automatic mode, read the registers 0x14 to 0x17
(E4K_REG_GAIN1 to E4K_REG_GAIN4) and calculate the gains. Note again 
that the max. LNA gain of 30 dB is only valid when LNA enhancement is 
enabled and the mixer gain is at 12 dB. Otherwise, the max. LNA gain is 
25 dB.

For signals in the range of -50 to -10 dBm, the RSSI indicator can be 
also read from register 0x1C (E4K_REG_AGC3) in automatic mode to 
calculate the input power in dBm:
  double InputPower = 10 * log10(RSSI)) - 28.5 - LNA_Gain;
The above calculation can be used when the RSSI value is in the range 
from 5 to 24. Higher RSSI values occur with strong signals at min. LNA 
gain and give too low results due to clipped signals.


Jochen Arndt



From 393775602 at qq.com  Sun Jan 26 09:26:11 2014
From: 393775602 at qq.com (=?ISO-8859-1?B?MzkzNzc1NjAy?=)
Date: Sun, 26 Jan 2014 17:26:11 +0800
Subject: how to get a certain frequency spectrum using rtl_power
Message-ID: <tencent_2453651C56586B8D3BCF7F21@qq.com>

Hi,
   i am doing a project to get a certain fequencyspectrum  . And thanks to the wonderful tool rtl_power, i can get some dbm data over a very wide area of the frequency specturm.
 and i read the source code in order to change it to get a certain frequency specturm.Sadly, i know little about digital signal processiong and getting a hard time solving it.
 does anyone know how to get a certain fequencyspectrum using rtl_power or some other tool.
 
   sincerely
   Chen Zujie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140126/6289ffdc/attachment.htm>

From putaoshu at gmail.com  Sun Jan 26 10:25:54 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Sun, 26 Jan 2014 18:25:54 +0800
Subject: how to get a certain frequency spectrum using rtl_power
Message-ID: <dxsbrppkjjxm3hmccvtb4fjt.1390731954764@email.android.com>

If you are familiar with matlab, maybe you can try my matlab scanner.

It is easy to change frequency range, RBW, etc, and get spectrum picture.

Please google:
" rtl sdr matlab scanner"

Good luck!


393775602 <393775602 at qq.com> wrote:

>Hi,
>
>? ?i am doing a project to get?a certain fequencyspectrum ?. And thanks to the wonderful tool rtl_power, i can get some dbm data over a very wide?area of the frequency specturm.
>
>?and i read the source code in order to change it to get a certain frequency specturm.Sadly, i know little about digital signal processiong and getting a hard time solving it.
>
>?does anyone know how to?get?a certain fequencyspectrum using rtl_power or some other tool.
>
>?
>
>? ?sincerely
>
>? ?Chen Zujie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140126/784df863/attachment.htm>

From 393775602 at qq.com  Sun Jan 26 12:19:26 2014
From: 393775602 at qq.com (=?gb18030?B?MzkzNzc1NjAy?=)
Date: Sun, 26 Jan 2014 20:19:26 +0800
Subject: =?gb18030?B?u9i4tKO6IGhvdyB0byBnZXQgYSBjZXJ0YWluIGZy?=
	=?gb18030?B?ZXF1ZW5jeSBzcGVjdHJ1bSB1c2luZyBydGxfcG93?=
	=?gb18030?B?ZXI=?=
In-Reply-To: <dxsbrppkjjxm3hmccvtb4fjt.1390731954764@email.android.com>
References: <dxsbrppkjjxm3hmccvtb4fjt.1390731954764@email.android.com>
Message-ID: <tencent_6B74F4034D433CDE13B80AB4@qq.com>

thanks for your response,but i run the rtl_power in android and want to display the frequency specturm in android too. so maybe matlab scanner is not fit,anyway, thanks all the same


------------------ ???? ------------------
???: "Jiao Xianjun";<putaoshu at gmail.com>;
????: 2014?1?26?(???) ??6:25
???: ""<393775602 at qq.com>; 
??: "osmocom-sdr"<osmocom-sdr at lists.osmocom.org>; 
??: Re: how to get a certain frequency spectrum using rtl_power



If you are familiar with matlab, maybe you can try my matlab scanner.

It is easy to change frequency range, RBW, etc, and get spectrum picture.

Please google:
" rtl sdr matlab scanner"

Good luck!


393775602 <393775602 at qq.com> wrote:

Hi,
   i am doing a project to get a certain fequencyspectrum  . And thanks to the wonderful tool rtl_power, i can get some dbm data over a very wide area of the frequency specturm.
 and i read the source code in order to change it to get a certain frequency specturm.Sadly, i know little about digital signal processiong and getting a hard time solving it.
 does anyone know how to get a certain fequencyspectrum using rtl_power or some other tool.
 
   sincerely
   Chen Zujie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140126/847c29f8/attachment.htm>

From keenerd at gmail.com  Sun Jan 26 13:47:31 2014
From: keenerd at gmail.com (keenerd)
Date: Sun, 26 Jan 2014 08:47:31 -0500
Subject: how to get a certain frequency spectrum using rtl_power
In-Reply-To: <tencent_2453651C56586B8D3BCF7F21@qq.com>
References: <tencent_2453651C56586B8D3BCF7F21@qq.com>
Message-ID: <CAAKTTKMBAMsxzFn2VgMSoSPbJWkVU7P5h6p2qLA843UrO56R=Q@mail.gmail.com>

On 1/26/14, 393775602 <393775602 at qq.com> wrote:
> does anyone know how to get a certain fequency spectrum using rtl_power or
> some other tool.

Rtl_power already does that.  Use the -f option to select the
frequencies of interest.  If the -f option does not do what you want,
please explain what you are trying to do.

-Kyle
http://kmkeen.com



From n1gp at hotmail.com  Tue Jan 28 23:50:08 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Tue, 28 Jan 2014 18:50:08 -0500
Subject: Direct sampling mode frequency range?
In-Reply-To: <BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>,
	<52CF43EB.5010200@seznam.cz>,
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>,
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
Message-ID: <BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>

Can someone clarify what the frequency range is in Direct sampling mode.

The rtl2832u dongle has a 28.8Mhz osc. 

So can the dongle in "direct sampling mode" (with appropriate antenna connection)
receive > 14.4 Mhz (Nyquist) ?

Googling I find conflicting advice.

I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if
that's due to some non-optimal method...?

I'm guessing it can because the tuner chip provides both I & Q data therefore
allowing the double rate...?



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140128/e176c8a6/attachment.htm>

From putaoshu at gmail.com  Wed Jan 29 03:25:43 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Wed, 29 Jan 2014 11:25:43 +0800
Subject: Direct sampling mode frequency range?
In-Reply-To: <BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
Message-ID: <CABs6FUoMhhy5-J7hOg69k7A_-aJd+8UUuzCH=_53LbXZJ+fFQA@mail.gmail.com>


From fabien.lementec at gmail.com  Wed Jan 29 09:09:21 2014
From: fabien.lementec at gmail.com (lementec fabien)
Date: Wed, 29 Jan 2014 10:09:21 +0100
Subject: [ rtl-sdr / rtl_fm to decode NRF905 frames ]
Message-ID: <CAAPMK-QBaCMjQP8=tV=2LPW+N7a_DZ9OzE8qQb0Wi_+9vsJC+w@mail.gmail.com>

Hi,

I recently used rtl-sdr / rtl_fm and some adhoc code to decode
NRF905 frames. A post is here:
http://www.embeddedrelated.com/showarticle/548.php

If you think it can be useful to anyone, maybe you can add it to
the 'Known Apps' section of this page:
http://sdr.osmocom.org/trac/wiki/rtl-sdr

Thanks for your great work,

Cheers,

flm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140129/3c65ad44/attachment.htm>

From pksato at gmail.com  Wed Jan 29 11:33:38 2014
From: pksato at gmail.com (Paulino Kenji Sato)
Date: Wed, 29 Jan 2014 09:33:38 -0200
Subject: Direct sampling mode frequency range?
In-Reply-To: <BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
Message-ID: <CAMM-fMh4FMD+oMKhwL8w5qjWWU=TJAhA5a1F5VGSF+6CJqMysA@mail.gmail.com>

Hi,
(from my little knowledge about DSP)
RTL2832U (if) sample at 28.8MHz, by Nyquist, usable maximum frequency
is 14.4MHz, above you have a aliases (mirrors, ghosts, harmonics).
Frequencies above half of sample rate (Nyquist frequency) need to
filtered to avoid aliases effect. For example, sound cards at
44.1KHz/48KHz have filter to cut frequencies above 20KHz.
Front end tuner (E4000, R820T), used on RTL dongles, have a low pass filter.
I don't know if RTL chip have a input filter, probable no.
Direct Sampling mode, or IF mode of RTL2832U, use ability of RTL chip
to tune to any IF used on front end tuner (3.57MHz for R820T).
I suppose, ADCs of RTL3832U always sample at 28.8MHz, and decimate to
lower sample rate, and output as I/Q signal.
RTL IF can tune from 0 to 28.8MHz and output a small chunk of sample
rate frequency as I/Q.
If set sample rate at 2400000Hz (or samples per second), and tune IF
to 1.2MHz, you have a signal from 0 to 2.4MHz. If tune to 10MHz,
signal from 8.8MHz to 11.2MHz.
On direct sampling mode (IF mode), use only one ADC, at 28.8MHz, input
need to filtered to pass only frequency bellow 14.4MHz. But, IF can
tuned above 14.4MHz, entering on zone of aliases.
Suppose that you want ti listem a Medium Wave (MW/AM) radio at
1500KHz, you have a station on 1.5MHz and 27.3MHz, or inverse, instead
you favorite station, you hear some one talking on CB band channel 29
or 30.
So, to use Direct sampling mode need a low pass filter to tune below
14.4MHz and a band pass filter to tune from 14.4MHz to 28.8MHz.



On Tue, Jan 28, 2014 at 9:50 PM, Richard Koch <n1gp at hotmail.com> wrote:
> Can someone clarify what the frequency range is in Direct sampling mode.
>
> The rtl2832u dongle has a 28.8Mhz osc.
>
> So can the dongle in "direct sampling mode" (with appropriate antenna
> connection)
> receive > 14.4 Mhz (Nyquist) ?
>
> Googling I find conflicting advice.
>
> I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if
> that's due to some non-optimal method...?
>
> I'm guessing it can because the tuner chip provides both I & Q data
> therefore
> allowing the double rate...?
>
>
>



-- 
Paulino Kenji Sato



From a.nielsen at shikadi.net  Wed Jan 29 12:12:03 2014
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Wed, 29 Jan 2014 22:12:03 +1000
Subject: Direct sampling mode frequency range?
In-Reply-To: <BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
Message-ID: <20140129221203.44bf64a5@korath.teln.shikadi.net>

> Can someone clarify what the frequency range is in Direct sampling
> mode.

In direct sampling mode you can "tune" by setting the IF between 0 and
30MHz.

> So can the dongle in "direct sampling mode" (with appropriate antenna
> connection) receive > 14.4 Mhz (Nyquist) ?

Yes, and it has nothing to do with Nyquist because the sample rate you
receive is only 2MHz or so as per normal.  Direct sampling mode does not
capture a wider band than normal, it just uses a different method to
tune the receiver.  So the oscillator frequency is irrelevant, and
Nyquist doesn't come into it any differently with direct sampling than
with normal sampling.

Cheers,
Adam.



From n1gp at hotmail.com  Wed Jan 29 12:25:38 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Wed, 29 Jan 2014 07:25:38 -0500
Subject: Direct sampling mode frequency range?
In-Reply-To: <20140129221203.44bf64a5@korath.teln.shikadi.net>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>,
	<52CF43EB.5010200@seznam.cz>,
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>,
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>,
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>,
	<20140129221203.44bf64a5@korath.teln.shikadi.net>
Message-ID: <BLU180-W9374536FF5AAA88F8EA94587AC0@phx.gbl>

Ah yes, that makes sense now.  Tnx everyone.


> Date: Wed, 29 Jan 2014 22:12:03 +1000
> From: a.nielsen at shikadi.net
> To: osmocom-sdr at lists.osmocom.org
> Subject: Re: Direct sampling mode frequency range?
> 
> > Can someone clarify what the frequency range is in Direct sampling
> > mode.
> 
> In direct sampling mode you can "tune" by setting the IF between 0 and
> 30MHz.
> 
> > So can the dongle in "direct sampling mode" (with appropriate antenna
> > connection) receive > 14.4 Mhz (Nyquist) ?
> 
> Yes, and it has nothing to do with Nyquist because the sample rate you
> receive is only 2MHz or so as per normal.  Direct sampling mode does not
> capture a wider band than normal, it just uses a different method to
> tune the receiver.  So the oscillator frequency is irrelevant, and
> Nyquist doesn't come into it any differently with direct sampling than
> with normal sampling.
> 
> Cheers,
> Adam.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140129/17dc3881/attachment.htm>

From 246tnt at gmail.com  Wed Jan 29 12:27:55 2014
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 29 Jan 2014 13:27:55 +0100
Subject: Direct sampling mode frequency range?
In-Reply-To: <20140129221203.44bf64a5@korath.teln.shikadi.net>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
	<20140129221203.44bf64a5@korath.teln.shikadi.net>
Message-ID: <CAHL+j08hD7WQ0gGvLYVhEN+t1ru_GGY1TbyvCWmsNuYGKM7Reg@mail.gmail.com>

> Yes, and it has nothing to do with Nyquist because the sample rate you
> receive is only 2MHz or so as per normal.  Direct sampling mode does not
> capture a wider band than normal, it just uses a different method to
> tune the receiver.  So the oscillator frequency is irrelevant, and
> Nyquist doesn't come into it any differently with direct sampling than
> with normal sampling.

Mmm, AFAIK, the rtl ADC work at 28.8 MHz and then the IF tuning is
done by an internal digital DDC (which will also decimate down to 2MHz
or so to ship via usb).


Cheers,

    Sylvain



From nikos.balkanas at eyeonix.com  Wed Jan 29 13:58:39 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Wed, 29 Jan 2014 15:58:39 +0200
Subject: rtl_power sine_tbl
Message-ID: <CAAdsYnaoho1_xswgVTFpNkgjdw2by1hRxhmJftKw_jj+6=jyUQ@mail.gmail.com>

What is the purpose of the sine wave added to the spectrum by rtl_power?
Clouds all spectrum :-(

TIA,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140129/a12ea41f/attachment.htm>

From putaoshu at gmail.com  Thu Jan 30 03:14:39 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Thu, 30 Jan 2014 11:14:39 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <52CD190E.4020305@earthlink.net>
References: <-5467292776275938694@unknownmsgid>
	<CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
	<CABs6FUoXJV2NkgHLeG7SoFzNyyHL01EO6UhxZ6dENBDf5Op5dQ@mail.gmail.com>
	<52CAED34.70301@earthlink.net>
	<CABs6FUqStya+-4OtLd0ddP0sO4iqNEKDBCdJ_bXcGARAch57gA@mail.gmail.com>
	<52CD190E.4020305@earthlink.net>
Message-ID: <CABs6FUqxfi7mCPTnZVCdoc0DGM+B_vd5uqdxkNK+PfF_xk27AA@mail.gmail.com>

Hi everybody,

Let me report current progress of this thread.

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.

You can try it by yourself here :
https://github.com/JiaoXianjun/multi-rtl-sdr-calibration

Some runs results have also been attached here. (time location of FCCH SCH
and BCCH have also been shown there in different color)

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

Unfortunately, this fixed sampling phase difference may vary from run to
run (one rum means we restart rtl_tcp).
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.

Why do carrier and sampling error estimation and correction respectively?
Inspired by James Peroulas james at peroulas.com (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 omri at iluz.net 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).

But for my in-hands dongles, sampling error and carrier seems have
relationship. This may be because they have common clock source inside
dongle.

Which I detected by my matlab program gsm_sync_demod.m:
dongle 1: sampling PPM 27.1739,     carrier PPM -28.513
dongle 2: sampling PPM 116.3043,   carrier PPM -118.4247

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).
I don't know if my guess is correct. Anyone is familiar with the hardware
architecture of the 820t dongle?

BR

Jiao Xianjun




On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow at earthlink.net> wrote:

> 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 at earthlink.net
>> <mailto:jdow at 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 at gmail.com
>>         <mailto:putaoshu at gmail.com>
>>         <mailto:putaoshu at gmail.com <mailto:putaoshu at 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 at gmail.com
>>         <mailto:putaoshu at gmail.com>
>>              <mailto:putaoshu at gmail.com <mailto:putaoshu at 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 <mailto:sdrguru1 at gmail.com
>>         <mailto:sdrguru1 at gmail.com>>
>>                  Sent: 2014/1/2 5:39
>>
>>                  To: osmocom-sdr at lists.osmocom.org
>>         <mailto:osmocom-sdr at lists.osmocom.org>
>>         <mailto:osmocom-sdr at lists.__osmocom.org
>>
>>         <mailto:osmocom-sdr at 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/__
>> b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f
>>         <https://github.com/keenerd/rtl-sdr/commit/
>> b5f89dcf40463130e717b6c9bb3a39a3c8b9535f>
>>         https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c
>>
>>         <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/__
>> ecf267737ca52f5005b7a12a352307__e8cd763ed6
>>
>>         <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 at gmail.com <mailto:putaoshu at gmail.com>
>>                  <mailto:putaoshu at gmail.com <mailto:putaoshu at 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
>>
>>         <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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/43c79b94/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSM_synchronization_two_dongles.png
Type: image/png
Size: 10461 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/43c79b94/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSM_synchronization_two_dongles1.png
Type: image/png
Size: 9677 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/43c79b94/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GSM_synchronization_two_dongles2.png
Type: image/png
Size: 9063 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/43c79b94/attachment-0002.png>

From a.nielsen at shikadi.net  Thu Jan 30 06:06:56 2014
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Thu, 30 Jan 2014 16:06:56 +1000
Subject: Direct sampling mode frequency range?
In-Reply-To: <CAHL+j08hD7WQ0gGvLYVhEN+t1ru_GGY1TbyvCWmsNuYGKM7Reg@mail.gmail.com>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
	<20140129221203.44bf64a5@korath.teln.shikadi.net>
	<CAHL+j08hD7WQ0gGvLYVhEN+t1ru_GGY1TbyvCWmsNuYGKM7Reg@mail.gmail.com>
Message-ID: <20140130160656.102923b8@teln.shikadi.net>

> > Yes, and it has nothing to do with Nyquist because the sample rate
> > you receive is only 2MHz or so as per normal.  Direct sampling mode
> > does not capture a wider band than normal, it just uses a different
> > method to tune the receiver.  So the oscillator frequency is
> > irrelevant, and Nyquist doesn't come into it any differently with
> > direct sampling than with normal sampling.
> 
> Mmm, AFAIK, the rtl ADC work at 28.8 MHz and then the IF tuning is
> done by an internal digital DDC (which will also decimate down to 2MHz
> or so to ship via usb).

Good point, that may be correct but I'm not familiar enough to say for
sure.  But either way, direct sampling doesn't impose any additional
limitations than you already have with normal sampling.

It's also worth noting that there seems to be a way to do direct
sampling without any hardware modifications, by exploiting some
undocumented behaviour/bugs in the tuner chip(s?).  I hadn't seen any
mention of this on any of the mailing lists so I thought I would
mention it.  Seems to be plenty of info about it on Google!

Cheers,
Adam.



From sdrguru1 at gmail.com  Thu Jan 30 08:11:44 2014
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Thu, 30 Jan 2014 10:11:44 +0200
Subject: Direct sampling mode frequency range?
In-Reply-To: <20140130160656.102923b8@teln.shikadi.net>
References: <BLU180-W858B59395A4C2BE79EA86687B00@phx.gbl>
	<52CF43EB.5010200@seznam.cz>
	<BLU180-W405D222B09EACDDF72B24A87B30@phx.gbl>
	<BLU180-W31AB1896DCFE3D85EC740887B30@phx.gbl>
	<BLU180-W223AE48B7E8DC91502E56A87AD0@phx.gbl>
	<20140129221203.44bf64a5@korath.teln.shikadi.net>
	<CAHL+j08hD7WQ0gGvLYVhEN+t1ru_GGY1TbyvCWmsNuYGKM7Reg@mail.gmail.com>
	<20140130160656.102923b8@teln.shikadi.net>
Message-ID: <CACR-sec6JLDTpFTwYJ1oLEtwbzHgChB+o7i6rgOJpYkOVqVHuw@mail.gmail.com>

On Thu, Jan 30, 2014 at 8:06 AM, Adam Nielsen <a.nielsen at shikadi.net> wrote:

> ...
> It's also worth noting that there seems to be a way to do direct
> sampling without any hardware modifications, by exploiting some
> undocumented behaviour/bugs in the tuner chip(s?).  I hadn't seen any
> mention of this on any of the mailing lists so I thought I would
> mention it.  Seems to be plenty of info about it on Google!
>

http://www.reddit.com/r/RTLSDR/comments/12d2wc/a_very_surprising_discovery/
https://github.com/keenerd/rtl-sdr/commit/39b5cd1561602d4f99c49bbc6434004ad9182636
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/3e31ad16/attachment.htm>

From anders at lyes.dk  Thu Jan 30 09:19:02 2014
From: anders at lyes.dk (Anders Lynge Esbensen)
Date: Thu, 30 Jan 2014 10:19:02 +0100
Subject: new FM demodulator
Message-ID: <52EA1906.8040901@lyes.dk>

Hi and thanks for a great tool set.

I've implemented a faster FM demodulator for rlt_fm. Its an 
instantaneous frequency demodulator, like the already implemented atan 
method, but it uses some math tricks to get rid of the the actual atan 
calculation. Feel free to use it if you wish

Best regards
Anders
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fm_demod2.patch
Type: text/x-patch
Size: 2351 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/7224d9f3/attachment.bin>

From nikos.balkanas at eyeonix.com  Thu Jan 30 10:09:07 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 30 Jan 2014 12:09:07 +0200
Subject: new FM demodulator
In-Reply-To: <52EA1906.8040901@lyes.dk>
References: <52EA1906.8040901@lyes.dk>
Message-ID: <CAAdsYnb8gTaq099pHNB=3g2CbAXi6pdN3UDdbNs9g9rgPBrCpQ@mail.gmail.com>

Great! Performance is always welcome;-)

Do you have any benchmarks?

Nikos


On Thu, Jan 30, 2014 at 11:19 AM, Anders Lynge Esbensen <anders at lyes.dk>wrote:

> Hi and thanks for a great tool set.
>
> I've implemented a faster FM demodulator for rlt_fm. Its an instantaneous
> frequency demodulator, like the already implemented atan method, but it
> uses some math tricks to get rid of the the actual atan calculation. Feel
> free to use it if you wish
>
> Best regards
> Anders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/7a4e7b1f/attachment.htm>

From anders at lyes.dk  Thu Jan 30 13:56:41 2014
From: anders at lyes.dk (Anders Lynge Esbensen)
Date: Thu, 30 Jan 2014 14:56:41 +0100
Subject: new FM demodulator
In-Reply-To: <CAAdsYnb8gTaq099pHNB=3g2CbAXi6pdN3UDdbNs9g9rgPBrCpQ@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAdsYnb8gTaq099pHNB=3g2CbAXi6pdN3UDdbNs9g9rgPBrCpQ@mail.gmail.com>
Message-ID: <52EA5A19.5090503@lyes.dk>

Hi Nikos

Roughly speaking, the old atan demod, would load my cpu(3ghz core 2 duo) 
on approx 8.5%, with the new
modulator the load would be ~5%

There is a little penalty however, it seems that my demodulator is a 
little more noise sensitive, but it is not much.

/Anders

On 01/30/2014 11:09 AM, Nikos Balkanas wrote:
> Great! Performance is always welcome;-)
>
> Do you have any benchmarks?
>
> Nikos
>
>
> On Thu, Jan 30, 2014 at 11:19 AM, Anders Lynge Esbensen 
> <anders at lyes.dk <mailto:anders at lyes.dk>> wrote:
>
>     Hi and thanks for a great tool set.
>
>     I've implemented a faster FM demodulator for rlt_fm. Its an
>     instantaneous frequency demodulator, like the already implemented
>     atan method, but it uses some math tricks to get rid of the the
>     actual atan calculation. Feel free to use it if you wish
>
>     Best regards
>     Anders
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/e613b197/attachment.htm>

From keenerd at gmail.com  Thu Jan 30 14:19:55 2014
From: keenerd at gmail.com (keenerd)
Date: Thu, 30 Jan 2014 09:19:55 -0500
Subject: new FM demodulator
In-Reply-To: <52EA1906.8040901@lyes.dk>
References: <52EA1906.8040901@lyes.dk>
Message-ID: <CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>

On 1/30/14, Anders Lynge Esbensen <anders at lyes.dk> wrote:
> Hi and thanks for a great tool set.
>
> I've implemented a faster FM demodulator for rlt_fm. Its an
> instantaneous frequency demodulator, like the already implemented atan
> method, but it uses some math tricks to get rid of the the actual atan
> calculation. Feel free to use it if you wish

Nice, thank you.

It should probably be under the -A option with all the other types of
FM demodulator math.  Maybe benchmark it against the other FM
demodulators, "-A fast" or "-A lut".  The default "-A std" was not
designed to be very quick, just accurate.  Being faster than "-A std"
is not very difficult.

Let me see if I can get a fixed-point version written.

-Kyle
http://kmkeen.com



From sdrguru1 at gmail.com  Thu Jan 30 14:45:54 2014
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Thu, 30 Jan 2014 16:45:54 +0200
Subject: new FM demodulator
In-Reply-To: <CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
Message-ID: <CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>

Hi

Perhaps you can add a simple performance test to rtl_fm.
"decoding 100000 samples takes xxx ms" or something like that.
It helps to compare different CPU and OS families.


On Thu, Jan 30, 2014 at 4:19 PM, keenerd <keenerd at gmail.com> wrote:

> On 1/30/14, Anders Lynge Esbensen <anders at lyes.dk> wrote:
> > Hi and thanks for a great tool set.
> >
> > I've implemented a faster FM demodulator for rlt_fm. Its an
> > instantaneous frequency demodulator, like the already implemented atan
> > method, but it uses some math tricks to get rid of the the actual atan
> > calculation. Feel free to use it if you wish
>
> Nice, thank you.
>
> It should probably be under the -A option with all the other types of
> FM demodulator math.  Maybe benchmark it against the other FM
> demodulators, "-A fast" or "-A lut".  The default "-A std" was not
> designed to be very quick, just accurate.  Being faster than "-A std"
> is not very difficult.
>
> Let me see if I can get a fixed-point version written.
>
> -Kyle
> http://kmkeen.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/c549639e/attachment.htm>

From oz9aec at gmail.com  Thu Jan 30 15:23:36 2014
From: oz9aec at gmail.com (Alexandru Csete)
Date: Thu, 30 Jan 2014 16:23:36 +0100
Subject: new FM demodulator
In-Reply-To: <CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
Message-ID: <CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>

On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1 at gmail.com> wrote:
> Hi
>
> Perhaps you can add a simple performance test to rtl_fm.
> "decoding 100000 samples takes xxx ms" or something like that.
> It helps to compare different CPU and OS families.

We can already do simple benchmarking using the "time" command, or
more detailed measurements using the "perf" tool that comes with the
linux kernel.

Alex



From keenerd at gmail.com  Thu Jan 30 15:35:29 2014
From: keenerd at gmail.com (keenerd)
Date: Thu, 30 Jan 2014 10:35:29 -0500
Subject: new FM demodulator
In-Reply-To: <CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
Message-ID: <CAAKTTKMGSZbfDf8LJJ3xA+jN=MFscBqU=hd8pDV=bSCbnvaQfw@mail.gmail.com>

On 1/30/14, keenerd <keenerd at gmail.com> wrote:
> On 1/30/14, Anders Lynge Esbensen <anders at lyes.dk> wrote:
>> I've implemented a faster FM demodulator for rlt_fm.
>
> Let me see if I can get a fixed-point version written.

I've cleaned it up and it is in my repo.  You can enable it with "-A ale"
https://github.com/keenerd/rtl-sdr/commit/025fb56dff98

Some quick benchmarks:
std: 10%
fast: 7%
lut: 7%
ale: 7%

Sound quality is also noticably worse with ale, but that might be from
an error in the fixed point conversion.  How does the math look to
you?

-Kyle
http://kmkeen.com



From rsenykoff at gmail.com  Thu Jan 30 15:04:57 2014
From: rsenykoff at gmail.com (Ron Senykoff)
Date: Thu, 30 Jan 2014 10:04:57 -0500
Subject: How to get IQ samples from multiple rtl-sdr dongles in
	asynchronized manner?
In-Reply-To: <CABs6FUqxfi7mCPTnZVCdoc0DGM+B_vd5uqdxkNK+PfF_xk27AA@mail.gmail.com>
References: <-5467292776275938694@unknownmsgid>
	<CABs6FUqvKMeacr3V3r8t8aOtY9pGRatWTWNXzmN=Q5TOJvFnpQ@mail.gmail.com>
	<CABs6FUoXJV2NkgHLeG7SoFzNyyHL01EO6UhxZ6dENBDf5Op5dQ@mail.gmail.com>
	<52CAED34.70301@earthlink.net>
	<CABs6FUqStya+-4OtLd0ddP0sO4iqNEKDBCdJ_bXcGARAch57gA@mail.gmail.com>
	<52CD190E.4020305@earthlink.net>
	<CABs6FUqxfi7mCPTnZVCdoc0DGM+B_vd5uqdxkNK+PfF_xk27AA@mail.gmail.com>
Message-ID: <CAAiVu1Z_aO5tWiTL_0nqNAE3vREV2kp=BOmmTdC0gMZ885eL+g@mail.gmail.com>

Hi Jiao,

Thanks for your work on this. I'm curious if Octave could be used for
some of this.

-Ron / KB1UMH


On Wed, Jan 29, 2014 at 10:14 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:
> Hi everybody,
>
> Let me report current progress of this thread.
>
> 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.
>
> You can try it by yourself here :
> https://github.com/JiaoXianjun/multi-rtl-sdr-calibration
>
> Some runs results have also been attached here. (time location of FCCH SCH
> and BCCH have also been shown there in different color)
>
> 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).
>
> Unfortunately, this fixed sampling phase difference may vary from run to run
> (one rum means we restart rtl_tcp).
> 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.
>
> Why do carrier and sampling error estimation and correction respectively?
> Inspired by James Peroulas james at peroulas.com (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 omri at iluz.net 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).
>
> But for my in-hands dongles, sampling error and carrier seems have
> relationship. This may be because they have common clock source inside
> dongle.
>
> Which I detected by my matlab program gsm_sync_demod.m:
> dongle 1: sampling PPM 27.1739,     carrier PPM -28.513
> dongle 2: sampling PPM 116.3043,   carrier PPM -118.4247
>
> 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).
> I don't know if my guess is correct. Anyone is familiar with the hardware
> architecture of the 820t dongle?
>
> BR
>
> Jiao Xianjun
>
>
>
>
> On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow at earthlink.net> wrote:
>>
>> 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 at earthlink.net
>>> <mailto:jdow at 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 at gmail.com
>>>         <mailto:putaoshu at gmail.com>
>>>         <mailto:putaoshu at gmail.com <mailto:putaoshu at 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 at gmail.com
>>>         <mailto:putaoshu at gmail.com>
>>>              <mailto:putaoshu at gmail.com <mailto:putaoshu at 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 <mailto:sdrguru1 at gmail.com
>>>         <mailto:sdrguru1 at gmail.com>>
>>>
>>>                  Sent: 2014/1/2 5:39
>>>
>>>                  To: osmocom-sdr at lists.osmocom.org
>>>         <mailto:osmocom-sdr at lists.osmocom.org>
>>>         <mailto:osmocom-sdr at lists.__osmocom.org
>>>
>>>         <mailto:osmocom-sdr at 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/__b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f
>>>
>>> <https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f>
>>>         https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c
>>>
>>>         <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/__ecf267737ca52f5005b7a12a352307__e8cd763ed6
>>>
>>>
>>> <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 at gmail.com <mailto:putaoshu at gmail.com>
>>>                  <mailto:putaoshu at gmail.com <mailto:putaoshu at 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
>>>
>>>         <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
>
>



From sdrguru1 at gmail.com  Thu Jan 30 15:51:45 2014
From: sdrguru1 at gmail.com (Sdr Guru)
Date: Thu, 30 Jan 2014 17:51:45 +0200
Subject: new FM demodulator
In-Reply-To: <CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
Message-ID: <CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>

On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec at gmail.com> wrote:

> On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1 at gmail.com> wrote:
> > Hi
> >
> > Perhaps you can add a simple performance test to rtl_fm.
> > "decoding 100000 samples takes xxx ms" or something like that.
> > It helps to compare different CPU and OS families.
>
> We can already do simple benchmarking using the "time" command, or
> more detailed measurements using the "perf" tool that comes with the
> linux kernel.
>

You can bring us some examples. Or write a guide.
Especially with "time" command.


> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/a93b275c/attachment.htm>

From oz9aec at gmail.com  Thu Jan 30 16:13:19 2014
From: oz9aec at gmail.com (Alexandru Csete)
Date: Thu, 30 Jan 2014 17:13:19 +0100
Subject: new FM demodulator
In-Reply-To: <CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
Message-ID: <CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>

On Thu, Jan 30, 2014 at 4:51 PM, Sdr Guru <sdrguru1 at gmail.com> wrote:
> On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec at gmail.com> wrote:
>>
>> On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1 at gmail.com> wrote:
>> > Hi
>> >
>> > Perhaps you can add a simple performance test to rtl_fm.
>> > "decoding 100000 samples takes xxx ms" or something like that.
>> > It helps to compare different CPU and OS families.
>>
>> We can already do simple benchmarking using the "time" command, or
>> more detailed measurements using the "perf" tool that comes with the
>> linux kernel.
>
> You can bring us some examples. Or write a guide.
> Especially with "time" command.

In a terminal you type:

time rtl_fm

with the rtl_fm parameters you want to use. When you stop the program
it will print out how much real time has passed and how much time was
used by the application. See "man time" for options.

Alex



From nikos.balkanas at eyeonix.com  Thu Jan 30 16:21:46 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 30 Jan 2014 18:21:46 +0200
Subject: new FM demodulator
In-Reply-To: <CAAKTTKMGSZbfDf8LJJ3xA+jN=MFscBqU=hd8pDV=bSCbnvaQfw@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CAAKTTKMGSZbfDf8LJJ3xA+jN=MFscBqU=hd8pDV=bSCbnvaQfw@mail.gmail.com>
Message-ID: <CAAdsYnbphoO=JYd+KS2Vts6E1Gz+NVFGKce=Kv0vcfoWdwRR-w@mail.gmail.com>

On Thu, Jan 30, 2014 at 5:35 PM, keenerd <keenerd at gmail.com> wrote:

> On 1/30/14, keenerd <keenerd at gmail.com> wrote:
> > On 1/30/14, Anders Lynge Esbensen <anders at lyes.dk> wrote:
> >> I've implemented a faster FM demodulator for rlt_fm.
> >
> > Let me see if I can get a fixed-point version written.
>
> I've cleaned it up and it is in my repo.  You can enable it with "-A ale"
> https://github.com/keenerd/rtl-sdr/commit/025fb56dff98
>
> Some quick benchmarks:
> std: 10%
> fast: 7%
> lut: 7%
> ale: 7%
>
> Sound quality is also noticably worse with ale, but that might be from
> an error in the fixed point conversion.  How does the math look to
> you?
>

I have also be playing around with the atan demodulators. gnuradio uses
fast-atan tables instead of the libC version.
I dunno how libc implements it, but they could be worth considering...

Nikos



>
> -Kyle
> http://kmkeen.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/9856d670/attachment.htm>

From nikos.balkanas at eyeonix.com  Thu Jan 30 16:43:27 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 30 Jan 2014 18:43:27 +0200
Subject: new FM demodulator
In-Reply-To: <CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
Message-ID: <CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>

On Thu, Jan 30, 2014 at 6:13 PM, Alexandru Csete <oz9aec at gmail.com> wrote:

> On Thu, Jan 30, 2014 at 4:51 PM, Sdr Guru <sdrguru1 at gmail.com> wrote:
> > On Thu, Jan 30, 2014 at 5:23 PM, Alexandru Csete <oz9aec at gmail.com>
> wrote:
> >>
> >> On Thu, Jan 30, 2014 at 3:45 PM, Sdr Guru <sdrguru1 at gmail.com> wrote:
> >> > Hi
> >> >
> >> > Perhaps you can add a simple performance test to rtl_fm.
> >> > "decoding 100000 samples takes xxx ms" or something like that.
> >> > It helps to compare different CPU and OS families.
> >>
> >> We can already do simple benchmarking using the "time" command, or
> >> more detailed measurements using the "perf" tool that comes with the
> >> linux kernel.
> >
> > You can bring us some examples. Or write a guide.
> > Especially with "time" command.
>
> In a terminal you type:
>
> time rtl_fm
>
> with the rtl_fm parameters you want to use. When you stop the program
> it will print out how much real time has passed and how much time was
> used by the application. See "man time" for options.
>

Not the best way, unless you print #of packets processed and cpu is
limiting. A better choice would be gprof (Linux).

Nikos




> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/73180f71/attachment.htm>

From nikos.balkanas at eyeonix.com  Thu Jan 30 17:25:54 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 30 Jan 2014 19:25:54 +0200
Subject: rtl_fm.c & fast_atan2
Message-ID: <CAAdsYnYvkDxbN4zs=krP2Vu9qMMS3finZ+b8ue+d13594Czmsg@mail.gmail.com>

Is this correct?

if (x >= 0) {
>.......angle = pi4  - pi4 * (x-yabs) / (x+yabs);
} else {
.......angle = pi34 - pi4 * (x+yabs) / (yabs-x);
}

Shouldn't it be:

if (x >= 0) {
>.......angle = pi34  - pi4 * (x-yabs) / (x+yabs);
} else {
.......angle = pi34 - pi4 * (x+yabs) / (yabs-x);
}


TIA,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/7f5cface/attachment.htm>

From n1gp at hotmail.com  Thu Jan 30 18:21:43 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Thu, 30 Jan 2014 13:21:43 -0500
Subject: kalibrate-rtl results...
In-Reply-To: <CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>,
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>,
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>,
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>,
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>,
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>,
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
Message-ID: <BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>

I'm attempting to calibrate my RTL dongles. I notice they are
all about 2-4khz off if I compare against a known broadcast
station's frequency.

I am trying out kalibrate-rtl and am getting varied results.
I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:

        chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
        chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
        chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92

Then 'kal -c CHANNELNUM -g 20'  for each channel number.

I then get the results below which the average frequency error looks
different for each channel. It is consistent though if I run them multiple times.

I would have expected less frequency error since I know that it is really only
about 4Khz off. Or am I not reading the results correctly?

-Rick

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 991 (928.4MHz)
average         [min, max]      (range, stddev)
+ 21.342kHz             [17837, 27433]  (9596, 3402.206299)
overruns: 0
not found: 199
average absolute error: -22.988 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1002 (930.6MHz)
average         [min, max]      (range, stddev)
- 11.529kHz             [-15293, -5679] (9614, 3640.780273)
overruns: 0
not found: 194
average absolute error: 12.389 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1003 (930.8MHz)
average         [min, max]      (range, stddev)
+ 14.283kHz             [9462, 19098]   (9636, 4777.044922)
overruns: 0
not found: 126
average absolute error: -15.345 ppm
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/c4a75262/attachment.htm>

From n1gp at hotmail.com  Thu Jan 30 18:30:11 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Thu, 30 Jan 2014 13:30:11 -0500
Subject: kalibrate-rtl results...
In-Reply-To: <BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
References: <52EA1906.8040901@lyes.dk>, ,
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>,
	,
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>,
	,
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>,
	,
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>,
	,
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>,
	,
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>,
	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
Message-ID: <BLU180-W3520B31D022244E3E4D38787AF0@phx.gbl>

Ah, I think I should be looking at the stddev which is telling me
that the average deviation from the range was approx 3-4Khz...?

From: n1gp at hotmail.com
To: osmocom-sdr at lists.osmocom.org
Subject: kalibrate-rtl results...
Date: Thu, 30 Jan 2014 13:21:43 -0500




I'm attempting to calibrate my RTL dongles. I notice they are
all about 2-4khz off if I compare against a known broadcast
station's frequency.

I am trying out kalibrate-rtl and am getting varied results.
I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:

        chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
        chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
        chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92

Then 'kal -c CHANNELNUM -g 20'  for each channel number.

I then get the results below which the average frequency error looks
different for each channel. It is consistent though if I run them multiple times.

I would have expected less frequency error since I know that it is really only
about 4Khz off. Or am I not reading the results correctly?

-Rick

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 991 (928.4MHz)
average         [min, max]      (range, stddev)
+ 21.342kHz             [17837, 27433]  (9596, 3402.206299)
overruns: 0
not found: 199
average absolute error: -22.988 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1002 (930.6MHz)
average         [min, max]      (range, stddev)
- 11.529kHz             [-15293, -5679] (9614, 3640.780273)
overruns: 0
not found: 194
average absolute error: 12.389 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1003 (930.8MHz)
average         [min, max]      (range, stddev)
+ 14.283kHz             [9462, 19098]   (9636, 4777.044922)
overruns: 0
not found: 126
average absolute error: -15.345 ppm
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/1ba867e7/attachment.htm>

From nikos.balkanas at eyeonix.com  Thu Jan 30 18:34:53 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Thu, 30 Jan 2014 20:34:53 +0200
Subject: kalibrate-rtl results...
In-Reply-To: <BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
Message-ID: <CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>

On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp at hotmail.com> wrote:

> I'm attempting to calibrate my RTL dongles. I notice they are
> all about 2-4khz off if I compare against a known broadcast
> station's frequency.
>
> I am trying out kalibrate-rtl and am getting varied results.
> I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:
>
>         chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
>         chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
>         chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92
>
> Then 'kal -c CHANNELNUM -g 20'  for each channel number.
>
> I then get the results below which the average frequency error looks
> different for each channel. It is consistent though if I run them multiple
> times.
>
> I would have expected less frequency error since I know that it is really
> only
> about 4Khz off. Or am I not reading the results correctly?
>
>
Results seem OK. Do not forget that most BSTs hop around in their allotted
20 Khz channel.
So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against
"anchor" BSTs that are steady.
And yes, recommendation is to calibrate against 3 BSTs and correct for the
average or stddev if you wish...

Nikos

-Rick
>
> Using device 0: Generic RTL2832U OEM
> Found Fitipower FC0013 tuner
> Exact sample rate is: 270833.002142 Hz
> Setting gain: 100.0 dB
> kal: Calculating clock frequency offset.
> Using E-GSM-900 channel 991 (928.4MHz)
> average         [min, max]      (range, stddev)
> + 21.342kHz             [17837, 27433]  (9596, 3402.206299)
> overruns: 0
> not found: 199
> average absolute error: -22.988 ppm
>
> Using device 0: Generic RTL2832U OEM
> Found Fitipower FC0013 tuner
> Exact sample rate is: 270833.002142 Hz
> Setting gain: 100.0 dB
> kal: Calculating clock frequency offset.
> Using E-GSM-900 channel 1002 (930.6MHz)
> average         [min, max]      (range, stddev)
> - 11.529kHz             [-15293, -5679] (9614, 3640.780273)
> overruns: 0
> not found: 194
> average absolute error: 12.389 ppm
>
> Using device 0: Generic RTL2832U OEM
> Found Fitipower FC0013 tuner
> Exact sample rate is: 270833.002142 Hz
> Setting gain: 100.0 dB
> kal: Calculating clock frequency offset.
> Using E-GSM-900 channel 1003 (930.8MHz)
> average         [min, max]      (range, stddev)
> + 14.283kHz             [9462, 19098]   (9636, 4777.044922)
> overruns: 0
> not found: 126
> average absolute error: -15.345 ppm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140130/101f8433/attachment.htm>

From anders at lyes.dk  Thu Jan 30 20:18:41 2014
From: anders at lyes.dk (Anders Esbensen)
Date: Thu, 30 Jan 2014 21:18:41 +0100
Subject: new FM demodulator
In-Reply-To: <CAAKTTKMGSZbfDf8LJJ3xA+jN=MFscBqU=hd8pDV=bSCbnvaQfw@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CAAKTTKMGSZbfDf8LJJ3xA+jN=MFscBqU=hd8pDV=bSCbnvaQfw@mail.gmail.com>
Message-ID: <26E1BE21-8FA3-4C3E-9E16-BFA5663C3E16@lyes.dk>

Hi Kyle

I?ve looked at your commit. They way you are calculating the derivative of the sample may not actuate enough. I?m calculating the derivative as ds(n) = (s(n+1) - s(n-1))/2. Implementing a higher order derivative gives better sound, but eats the performance gain.

I?ve also tried to make a integer only version of the demodulator, but the rounding errors makes it sound terrible. Strange enough it is also faster doing things partly in integer and partly in floats.

I?v tried to profile the four methods in osx:

atan Fast: 11.5%running time
aran:lut 17.6% running time
atan std: 49.6% running time
aes: fm_demod2 22.9% running time

The percentage given is time spend in fm_dmod relative to the rest of the program.
/Anders

Den 30/01/2014 kl. 16.35 skrev keenerd <keenerd at gmail.com>:

> On 1/30/14, keenerd <keenerd at gmail.com> wrote:
>> On 1/30/14, Anders Lynge Esbensen <anders at lyes.dk> wrote:
>>> I've implemented a faster FM demodulator for rlt_fm.
>> 
>> Let me see if I can get a fixed-point version written.
> 
> I've cleaned it up and it is in my repo.  You can enable it with "-A ale"
> https://github.com/keenerd/rtl-sdr/commit/025fb56dff98
> 
> Some quick benchmarks:
> std: 10%
> fast: 7%
> lut: 7%
> ale: 7%
> 
> Sound quality is also noticably worse with ale, but that might be from
> an error in the fixed point conversion.  How does the math look to
> you?
> 
> -Kyle
> http://kmkeen.com
> 




From oz9aec at gmail.com  Thu Jan 30 20:36:34 2014
From: oz9aec at gmail.com (Alexandru Csete)
Date: Thu, 30 Jan 2014 21:36:34 +0100
Subject: new FM demodulator
In-Reply-To: <CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
Message-ID: <CAHG=S_df9_B0Ob+3Ktk7MJBSFVH5xHiVj+UdF469a+GJ=umR5g@mail.gmail.com>

On Thu, Jan 30, 2014 at 5:43 PM, Nikos Balkanas
<nikos.balkanas at eyeonix.com> wrote:
> On Thu, Jan 30, 2014 at 6:13 PM, Alexandru Csete <oz9aec at gmail.com> wrote:
>>
>> In a terminal you type:
>>
>> time rtl_fm
>>
>> with the rtl_fm parameters you want to use. When you stop the program
>> it will print out how much real time has passed and how much time was
>> used by the application. See "man time" for options.
>
> Not the best way, unless you print #of packets processed and cpu is
> limiting. A better choice would be gprof (Linux).
>

The time command prints how much time was required by the application.
If you divide that with the elapsed time you have the CPU load of the
application. The number of packets is irrelevant and the cpu must not
be limiting; if it is the application will not run in real time and
the measurement will be incorrect.

Alex



From putaoshu at gmail.com  Fri Jan 31 00:27:53 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Fri, 31 Jan 2014 08:27:53 +0800
Subject: How to get IQ samples from multiple rtl-sdr dongles
	inasynchronized manner?
Message-ID: <52eaee0a.6cf5420a.017f.2e16@mx.google.com>

while, I can try it, and let's see.

Actually, maybe I will turn it to C some time in the future.

-----Original Message-----
From: "Ron Senykoff" <rsenykoff at gmail.com>
Sent: ?2014/?1/?30 23:04
To: "Jiao Xianjun" <putaoshu at gmail.com>
Cc: "jdow" <jdow at earthlink.net>; "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at lists.osmocom.org>
Subject: Re: How to get IQ samples from multiple rtl-sdr dongles inasynchronized manner?

Hi Jiao,

Thanks for your work on this. I'm curious if Octave could be used for
some of this.

-Ron / KB1UMH


On Wed, Jan 29, 2014 at 10:14 PM, Jiao Xianjun <putaoshu at gmail.com> wrote:
> Hi everybody,
>
> Let me report current progress of this thread.
>
> 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.
>
> You can try it by yourself here :
> https://github.com/JiaoXianjun/multi-rtl-sdr-calibration
>
> Some runs results have also been attached here. (time location of FCCH SCH
> and BCCH have also been shown there in different color)
>
> 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).
>
> Unfortunately, this fixed sampling phase difference may vary from run to run
> (one rum means we restart rtl_tcp).
> 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.
>
> Why do carrier and sampling error estimation and correction respectively?
> Inspired by James Peroulas james at peroulas.com (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 omri at iluz.net 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).
>
> But for my in-hands dongles, sampling error and carrier seems have
> relationship. This may be because they have common clock source inside
> dongle.
>
> Which I detected by my matlab program gsm_sync_demod.m:
> dongle 1: sampling PPM 27.1739,     carrier PPM -28.513
> dongle 2: sampling PPM 116.3043,   carrier PPM -118.4247
>
> 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).
> I don't know if my guess is correct. Anyone is familiar with the hardware
> architecture of the 820t dongle?
>
> BR
>
> Jiao Xianjun
>
>
>
>
> On Wed, Jan 8, 2014 at 5:23 PM, jdow <jdow at earthlink.net> wrote:
>>
>> 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 at earthlink.net
>>> <mailto:jdow at 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 at gmail.com
>>>         <mailto:putaoshu at gmail.com>
>>>         <mailto:putaoshu at gmail.com <mailto:putaoshu at 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 at gmail.com
>>>         <mailto:putaoshu at gmail.com>
>>>              <mailto:putaoshu at gmail.com <mailto:putaoshu at 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 <mailto:sdrguru1 at gmail.com
>>>         <mailto:sdrguru1 at gmail.com>>
>>>
>>>                  Sent: 2014/1/2 5:39
>>>
>>>                  To: osmocom-sdr at lists.osmocom.org
>>>         <mailto:osmocom-sdr at lists.osmocom.org>
>>>         <mailto:osmocom-sdr at lists.__osmocom.org
>>>
>>>         <mailto:osmocom-sdr at 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/__b5f89dcf40463130e717b6c9bb3a39__a3c8b9535f
>>>
>>> <https://github.com/keenerd/rtl-sdr/commit/b5f89dcf40463130e717b6c9bb3a39a3c8b9535f>
>>>         https://github.com/keenerd/__rtl-sdr/blob/master/src/rtl___test.c
>>>
>>>         <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/__ecf267737ca52f5005b7a12a352307__e8cd763ed6
>>>
>>>
>>> <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 at gmail.com <mailto:putaoshu at gmail.com>
>>>                  <mailto:putaoshu at gmail.com <mailto:putaoshu at 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
>>>
>>>         <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/c842b293/attachment.htm>

From ralph at schmid.xxx  Fri Jan 31 10:47:54 2014
From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras)
Date: Fri, 31 Jan 2014 11:47:54 +0100
Subject: kalibrate-rtl results...
In-Reply-To: <CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>
Message-ID: <009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>

GSM does not hop around inside its channel, this is wrong, the frequency is
+- some Hz accurate, at least in normal western European commercial GSM
networks.

 

Ralph. 

 

From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Nikos Balkanas
Sent: Thursday, January 30, 2014 7:35 PM
To: Richard Koch
Cc: osmocom-sdr at lists.osmocom.org
Subject: Re: kalibrate-rtl results...

 

 

 

On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp at hotmail.com> wrote:

I'm attempting to calibrate my RTL dongles. I notice they are
all about 2-4khz off if I compare against a known broadcast
station's frequency.

I am trying out kalibrate-rtl and am getting varied results.
I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:

        chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
        chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
        chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92

Then 'kal -c CHANNELNUM -g 20'  for each channel number.

I then get the results below which the average frequency error looks
different for each channel. It is consistent though if I run them multiple
times.

I would have expected less frequency error since I know that it is really
only
about 4Khz off. Or am I not reading the results correctly?

 

Results seem OK. Do not forget that most BSTs hop around in their allotted
20 Khz channel.

So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against
"anchor" BSTs that are steady.

And yes, recommendation is to calibrate against 3 BSTs and correct for the
average or stddev if you wish...

Nikos

 

-Rick

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 991 (928.4MHz)
average         [min, max]      (range, stddev)
+ 21.342kHz             [17837, 27433]  (9596, 3402.206299)
overruns: 0
not found: 199
average absolute error: -22.988 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1002 (930.6MHz)
average         [min, max]      (range, stddev)
- 11.529kHz             [-15293, -5679] (9614, 3640.780273)
overruns: 0
not found: 194
average absolute error: 12.389 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1003 (930.8MHz)
average         [min, max]      (range, stddev)
+ 14.283kHz             [9462, 19098]   (9636, 4777.044922)
overruns: 0
not found: 126
average absolute error: -15.345 ppm

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/fbcb9fe3/attachment.htm>

From nikos.balkanas at eyeonix.com  Fri Jan 31 11:00:36 2014
From: nikos.balkanas at eyeonix.com (Nikos Balkanas)
Date: Fri, 31 Jan 2014 13:00:36 +0200
Subject: kalibrate-rtl results...
In-Reply-To: <009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>
	<009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>
Message-ID: <CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>

On Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras
<ralph at schmid.xxx>wrote:

> GSM does not hop around inside its channel, this is wrong, the frequency
> is +- some Hz accurate, at least in normal western European commercial GSM
> networks.
>
>
>

Are you sure about that? Check it out:

https://svn.berlin.ccc.de/projects/airprobe/wiki/A

Legend of first picture. If still in doubt that *most" GSM carriers are
hoppers, use rtl_power to scan your region ;-)

Nikos


> Ralph.
>
>
>
> *From:* osmocom-sdr-bounces at lists.osmocom.org [mailto:
> osmocom-sdr-bounces at lists.osmocom.org] *On Behalf Of *Nikos Balkanas
> *Sen**t:* Thursday, January 30, 2014 7:35 PM
> *To:* Richard Koch
> *Cc:* osmocom-sdr at lists.osmocom.org
> *Subject:* Re: kalibrate-rtl results...
>
>
>
>
>
>
>
> On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp at hotmail.com> wrote:
>
> I'm attempting to calibrate my RTL dongles. I notice they are
> all about 2-4khz off if I compare against a known broadcast
> station's frequency.
>
> I am trying out kalibrate-rtl and am getting varied results.
> I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:
>
>         chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
>         chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
>         chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92
>
> Then 'kal -c CHANNELNUM -g 20'  for each channel number.
>
> I then get the results below which the average frequency error looks
> different for each channel. It is consistent though if I run them multiple
> times.
>
> I would have expected less frequency error since I know that it is really
> only
> about 4Khz off. Or am I not reading the results correctly?
>
>
>
> Results seem OK. Do not forget that most BSTs hop around in their allotted
> 20 Khz channel.
>
> So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against
> "anchor" BSTs that are steady.
>
> And yes, recommendation is to calibrate against 3 BSTs and correct for the
> average or stddev if you wish...
>
> Nikos
>
>
>
> -Rick
>
> Using device 0: Generic RTL2832U OEM
> Found Fitipower FC0013 tuner
> Exact sample rate is: 270833.002142 Hz
> Setting gain: 100.0 dB
> kal: Calculating clock frequency offset.
> Using E-GSM-900 channel 991 (928.4MHz)
> average         [min, max]      (range, stddev)
> + 21.342kHz             [17837, 27433]  (9596, 3402.206299)
> overruns: 0
> not found: 199
> average absolute error: -22.988 ppm
>
> Using device 0: Generic RTL2832U OEM
> Found Fitipower FC0013 tuner
> Exact sample rate is: 270833.002142 Hz
> Setting gain: 100.0 dB
> kal: Calculating clock frequency offset.
> Using E-GSM-900 channel 1002 (930.6MHz)
> average         [min, max]      (range, stddev)
> - 11.529kHz             [-15293, -5679] (9614, 3640.780273)
> overruns: 0
> not found: 194
> average absolute error: 12.389 ppm
>
> Using device 0: Generic RTL2832U OEM
> Found Fitipower FC0013 tuner
> Exact sample rate is: 270833.002142 Hz
> Setting gain: 100.0 dB
> kal: Calculating clock frequency offset.
> Using E-GSM-900 channel 1003 (930.8MHz)
> average         [min, max]      (range, stddev)
> + 14.283kHz             [9462, 19098]   (9636, 4777.044922)
> overruns: 0
> not found: 126
> average absolute error: -15.345 ppm
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/541216da/attachment.htm>

From 246tnt at gmail.com  Fri Jan 31 11:25:16 2014
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 31 Jan 2014 12:25:16 +0100
Subject: kalibrate-rtl results...
In-Reply-To: <CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>
	<009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>
	<CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>
Message-ID: <CAHL+j0_e-Bhs4nb6b2LLzi+dMcOYDZtco4A6Rt_5z5skrS-0cg@mail.gmail.com>

Hi,

>> GSM does not hop around inside its channel, this is wrong, the frequency
>> is +- some Hz accurate, at least in normal western European commercial GSM
>> networks.
>
> Are you sure about that? Check it out:
>
> https://svn.berlin.ccc.de/projects/airprobe/wiki/A
>
> Legend of first picture. If still in doubt that *most" GSM carriers are
> hoppers, use rtl_power to scan your region ;-)

GSM doesn't hope _inside_ a channel, it hops between channels.

And the main channel "C0" that contains the FCCH bursts that kalibrate
locks to, doesn't hop at all, it's required by spec to be a continuous
carrier.


OTOH, the OP said he was in the US and used EGSM band option ... huh
... I thought the US was GSM-800 ?!?


Cheers,

   Sylvain



From putaoshu at gmail.com  Fri Jan 31 11:27:14 2014
From: putaoshu at gmail.com (Jiao Xianjun)
Date: Fri, 31 Jan 2014 19:27:14 +0800
Subject: kalibrate-rtl results...
Message-ID: <52eb8896.01ee440a.212b.ffffd429@mx.google.com>

Though GSM spec has frequency hopping option, it can be switched on or off by operator. Yes, most operator switch it on.

I think You too are talking different thing. GSM doesn't hops inside each 200khz channel. It hops among multiple 200khz channel.

There is an exception: The downlink broadcasting carrier which carries FCCH SCH BCCH etc doesn't hop, and accordingly uplink RACH carrier doesn't hop either. These two uplink and downlink carrier frequency have a fixed 45MHz spacing if I recall correctly.

I think most of calibration programs use downlink broadcasting carrier to calibrate the dongle, because it doesn't hop and is easy to  be captured.

You may also try my matlab  calibration tool:

https://github.com/JiaoXianjun/multi-rtl-sdr-calibration




-----Original Message-----
From: "Nikos Balkanas" <nikos.balkanas at eyeonix.com>
Sent: ?2014/?1/?31 19:13
To: "Ralph A. Schmid, dk5ras" <ralph at schmid.xxx>
Cc: "osmocom-sdr at lists.osmocom.org" <osmocom-sdr at lists.osmocom.org>; "Richard Koch" <n1gp at hotmail.com>
Subject: Re: kalibrate-rtl results...






On Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras <ralph at schmid.xxx> wrote:

GSM does not hop around inside its channel, this is wrong, the frequency is +- some Hz accurate, at least in normal western European commercial GSM networks.
 


Are you sure about that? Check it out:

https://svn.berlin.ccc.de/projects/airprobe/wiki/A


Legend of first picture. If still in doubt that *most" GSM carriers are hoppers, use rtl_power to scan your region ;-)


Nikos

 

Ralph. 
 
From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Nikos Balkanas
Sent: Thursday, January 30, 2014 7:35 PM
To: Richard Koch
Cc: osmocom-sdr at lists.osmocom.org
Subject: Re: kalibrate-rtl results...
 
 
 
On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp at hotmail.com> wrote:
I'm attempting to calibrate my RTL dongles. I notice they are
all about 2-4khz off if I compare against a known broadcast
station's frequency.

I am trying out kalibrate-rtl and am getting varied results.
I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:

        chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
        chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
        chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92

Then 'kal -c CHANNELNUM -g 20'  for each channel number.

I then get the results below which the average frequency error looks
different for each channel. It is consistent though if I run them multiple times.

I would have expected less frequency error since I know that it is really only
about 4Khz off. Or am I not reading the results correctly?
 
Results seem OK. Do not forget that most BSTs hop around in their allotted 20 Khz channel.
So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against "anchor" BSTs that are steady.
And yes, recommendation is to calibrate against 3 BSTs and correct for the average or stddev if you wish...
Nikos
 
-Rick

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 991 (928.4MHz)
average         [min, max]      (range, stddev)
+ 21.342kHz             [17837, 27433]  (9596, 3402.206299)
overruns: 0
not found: 199
average absolute error: -22.988 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1002 (930.6MHz)
average         [min, max]      (range, stddev)
- 11.529kHz             [-15293, -5679] (9614, 3640.780273)
overruns: 0
not found: 194
average absolute error: 12.389 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1003 (930.8MHz)
average         [min, max]      (range, stddev)
+ 14.283kHz             [9462, 19098]   (9636, 4777.044922)
overruns: 0
not found: 126
average absolute error: -15.345 ppm
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/b402a0ee/attachment.htm>

From ralph at schmid.xxx  Fri Jan 31 11:29:54 2014
From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras)
Date: Fri, 31 Jan 2014 12:29:54 +0100
Subject: FW: kalibrate-rtl results...
References: <52EA1906.8040901@lyes.dk>	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>	<009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>
	<CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>
Message-ID: <00b901cf1e77$c3c7b3a0$4b571ae0$@schmid.xxx>

 

I am sure, a BCCH is a BCCH, this does not hop at all, and the frequency
hopping carriers do not hop some KHz, but in a sequence over a fixed scheme
of normal ARFCNs. There is no free frequency choice in GSM, hopping or not.

 

Ralph.

 

 

From: Nikos Balkanas [mailto:nikos.balkanas at eyeonix.com] 
Sent: Friday, January 31, 2014 12:01 PM
To: Ralph A. Schmid, dk5ras
Cc: Richard Koch; osmocom-sdr at lists.osmocom.org
Subject: Re: kalibrate-rtl results...

 

 

 

On Fri, Jan 31, 2014 at 12:47 PM, Ralph A. Schmid, dk5ras <ralph at schmid.xxx>
wrote:

GSM does not hop around inside its channel, this is wrong, the frequency is
+- some Hz accurate, at least in normal western European commercial GSM
networks.

 

 

Are you sure about that? Check it out:

https://svn.berlin.ccc.de/projects/airprobe/wiki/A

Legend of first picture. If still in doubt that *most" GSM carriers are
hoppers, use rtl_power to scan your region ;-)

Nikos

 

Ralph. 

 

From: osmocom-sdr-bounces at lists.osmocom.org
[mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Nikos Balkanas
Sent: Thursday, January 30, 2014 7:35 PM
To: Richard Koch
Cc: osmocom-sdr at lists.osmocom.org
Subject: Re: kalibrate-rtl results...

 

 

 

On Thu, Jan 30, 2014 at 8:21 PM, Richard Koch <n1gp at hotmail.com> wrote:

I'm attempting to calibrate my RTL dongles. I notice they are
all about 2-4khz off if I compare against a known broadcast
station's frequency.

I am trying out kalibrate-rtl and am getting varied results.
I am in the US, so I did a 'kal -s EGSM  -g 20' and got the following:

        chan: 991 (928.4MHz + 26.986kHz)        power: 448020.99
        chan: 1002 (930.6MHz - 5.631kHz)        power: 320357.07
        chan: 1003 (930.8MHz + 16.192kHz)       power: 109489.92

Then 'kal -c CHANNELNUM -g 20'  for each channel number.

I then get the results below which the average frequency error looks
different for each channel. It is consistent though if I run them multiple
times.

I would have expected less frequency error since I know that it is really
only
about 4Khz off. Or am I not reading the results correctly?

 

Results seem OK. Do not forget that most BSTs hop around in their allotted
20 Khz channel.

So a result of +/- 20 Khz shouldn't surprise you. Best calibrate against
"anchor" BSTs that are steady.

And yes, recommendation is to calibrate against 3 BSTs and correct for the
average or stddev if you wish...

Nikos

 

-Rick

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 991 (928.4MHz)
average         [min, max]      (range, stddev)
+ 21.342kHz             [17837, 27433]  (9596, 3402.206299)
overruns: 0
not found: 199
average absolute error: -22.988 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1002 (930.6MHz)
average         [min, max]      (range, stddev)
- 11.529kHz             [-15293, -5679] (9614, 3640.780273)
overruns: 0
not found: 194
average absolute error: 12.389 ppm

Using device 0: Generic RTL2832U OEM
Found Fitipower FC0013 tuner
Exact sample rate is: 270833.002142 Hz
Setting gain: 100.0 dB
kal: Calculating clock frequency offset.
Using E-GSM-900 channel 1003 (930.8MHz)
average         [min, max]      (range, stddev)
+ 14.283kHz             [9462, 19098]   (9636, 4777.044922)
overruns: 0
not found: 126
average absolute error: -15.345 ppm

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/1e0f9a1b/attachment.htm>

From n1gp at hotmail.com  Fri Jan 31 12:38:57 2014
From: n1gp at hotmail.com (Richard Koch)
Date: Fri, 31 Jan 2014 07:38:57 -0500
Subject: kalibrate-rtl results...
In-Reply-To: <CAHL+j0_e-Bhs4nb6b2LLzi+dMcOYDZtco4A6Rt_5z5skrS-0cg@mail.gmail.com>
References: <52EA1906.8040901@lyes.dk>,
	<CAAKTTKNbrWRXc6M-JwV3aaCyvfMd50i=Emg-5voabnH5nGj0ng@mail.gmail.com>,
	<CACR-sefSxY5UTC-myZAJgX4PNeu0hYsMxK-Oo=hasKxLe6k5QQ@mail.gmail.com>,
	<CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>,
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>,
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>,
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>,
	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>,
	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>,
	<009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>,
	<CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>,
	<CAHL+j0_e-Bhs4nb6b2LLzi+dMcOYDZtco4A6Rt_5z5skrS-0cg@mail.gmail.com>
Message-ID: <BLU180-W4185B51DE38744B91828DD87AE0@phx.gbl>

There is no GSM-800 option in kalibrate-rtl unless it goes by another
name. I'm not that familiar with this technology.

"        -s      band to scan (GSM850, GSM-R, GSM900, EGSM, DCS, PCS)"

I tried all the options several times and the only hits I got were using
EGSM.

> 
> OTOH, the OP said he was in the US and used EGSM band option ... huh
> ... I thought the US was GSM-800 ?!?
> 
> 
> Cheers,
> 
>    Sylvain
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/64e3a24d/attachment.htm>

From alexander.huemer at xx.vu  Fri Jan 31 12:49:04 2014
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Fri, 31 Jan 2014 13:49:04 +0100
Subject: kalibrate-rtl results...
In-Reply-To: <BLU180-W4185B51DE38744B91828DD87AE0@phx.gbl>
References: <CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>
	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>
	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>
	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>
	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>
	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>
	<009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>
	<CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>
	<CAHL+j0_e-Bhs4nb6b2LLzi+dMcOYDZtco4A6Rt_5z5skrS-0cg@mail.gmail.com>
	<BLU180-W4185B51DE38744B91828DD87AE0@phx.gbl>
Message-ID: <20140131124904.GA2694@yade.xx.vu>

On Fri, Jan 31, 2014 at 07:38:57AM -0500, Richard Koch wrote:
> 
> > OTOH, the OP said he was in the US and used EGSM band option ... huh
> > ... I thought the US was GSM-800 ?!?
> 
> There is no GSM-800 option in kalibrate-rtl unless it goes by another
> name. I'm not that familiar with this technology.
> 
> "-s band to scan (GSM850, GSM-R, GSM900, EGSM, DCS, PCS)"
> 
> I tried all the options several times and the only hits I got were 
> using EGSM.

I am pretty sure what Sylvain meant is GSM850. That's the lower band 
that is used in the U.S, see [1].

Kind regards,
-Alex

[1] https://en.wikipedia.org/wiki/GSM_frequency_bands



From ralph at schmid.xxx  Fri Jan 31 13:04:29 2014
From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras)
Date: Fri, 31 Jan 2014 14:04:29 +0100
Subject: kalibrate-rtl results...
In-Reply-To: <20140131124904.GA2694@yade.xx.vu>
References: <CAHG=S_c2Ctq16vp2qWnd8wAoR749GkVjygVoUOJGaDTLxfGctw@mail.gmail.com>	<CACR-sedOP4fT5sHHG2=FCvj_K0jXVEDz+OQ1EjrWyYC-MER1iA@mail.gmail.com>	<CAHG=S_ctCztMG2MddGwo8qGQNBqextdC2+ORy+Aw9gsYYroPXA@mail.gmail.com>	<CAAdsYnabP4Mp5bMP2v2_z-DCXwDs4Tk6b8QWZFi7BkLjZ6SjHA@mail.gmail.com>	<BLU180-W123F7AB9CF6A969551ADD087AF0@phx.gbl>	<CAAdsYnbzucJR_Aj0TMj9gg-qfNJOezu05noUQNzd9qUnR7KkeA@mail.gmail.com>	<009301cf1e71$e5e45d40$b1ad17c0$@schmid.xxx>	<CAAdsYnaDiQ6LocMG-oFiUGnp12gieKZHJ5dDQeCPPDPjxqifNA@mail.gmail.com>	<CAHL+j0_e-Bhs4nb6b2LLzi+dMcOYDZtco4A6Rt_5z5skrS-0cg@mail.gmail.com>	<BLU180-W4185B51DE38744B91828DD87AE0@phx.gbl>
	<20140131124904.GA2694@yade.xx.vu>
Message-ID: <00e801cf1e84$fa534030$eef9c090$@schmid.xxx>


Hi,

> I am pretty sure what Sylvain meant is GSM850. That's the lower band that
is
> used in the U.S, see [1].

Here a very nice site regarding mobile phone bands:

http://niviuk.free.fr/

 
> Kind regards,
> -Alex
> 
> [1] https://en.wikipedia.org/wiki/GSM_frequency_bands





From jjmiller at nwlink.com  Fri Jan 31 13:25:49 2014
From: jjmiller at nwlink.com (Jeff Miller)
Date: Fri, 31 Jan 2014 05:25:49 -0800
Subject: UNSUBSCRIBE
Message-ID: <002501cf1e87$f4cb0dc0$de612940$@nwlink.com>

 

 

Jeff Miller

360.630.5073

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7048 - Release Date: 01/31/14

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140131/4d222966/attachment.htm>