From chris at techworks.ie  Sun Aug  5 18:45:28 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Sun, 05 Aug 2012 19:45:28 +0100
Subject: gr-ais with osmosdr
Message-ID: <501EBF48.9030608@techworks.ie>

Hi there,

I saw a message in the July archive (I wasn't subscribed yet at that 
date) about updating gr-ais with osmosdr support.
I was working on the same thing recently, so i decided to publish my 
fixes on top of Antoine's one.
The result can be found here:
https://github.com/chgans/gr-ais

I got it working with both an FCD and an RTL:
ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0

Strangely passing freq_err=XX parameter to the source (using -D), 
doesn't work, the use of --error is thus needed (which will do a 
set_freq_corr()).

Antoine, if you want sample file, just let me know.

Nick, are you willing to integrate these changing back in gr-ais, Apart 
from the added automatic decimation filter, the changes are not 
intrusive at all.

The default settings for UHD are 256Khz sampling with decimation filter 
4, with this change, the decimation is one when using FCD (96KHz fixed 
frequency) and 16 for RTL when used at 1.024MHz (this was the minimum 
working frequency for me).
Or maybe would you prefer to allow the user to set it manually, and use 
this technique as a fall back only.

Please let me know what you guys think.

Thx,
Chris

-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From chris at techworks.ie  Sun Aug  5 19:10:54 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Sun, 05 Aug 2012 20:10:54 +0100
Subject: Iterating over gain ranges with python
Message-ID: <501EC53E.3090002@techworks.ie>

Hi there,

In a python script, I would like to iterate over things like 
get_gain_names, get_gain_ranges, ...

The problem is that these functions return a std::vector<std::string> *.
The error i get is: TypeError: 'SwigPyObject' object is not iterable

It would be very nice to be able to do something like:
for src.get_sample_rates():
    # do something
for name in get_gain_names():
    # do smth

I found this: http://reference-man.com/files/generators.i
But i haven't been able to use it so far. :(

Any help or comments appreciated.

Chris


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From horiz0n at gmx.net  Sun Aug  5 19:52:31 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 05 Aug 2012 21:52:31 +0200
Subject: Iterating over gain ranges with python
In-Reply-To: <501EC53E.3090002@techworks.ie>
References: <501EC53E.3090002@techworks.ie>
Message-ID: <op.wik2tti1vay7ep@wopr.artelis.net>

Hi Christian,

please try the latest master, it should work now with the last commit.


Best regards,

Dimitri

On Sun, 05 Aug 2012 21:10:54 +0200, Christian Gagneraud  
<chris at techworks.ie> wrote:

> Hi there,
>
> In a python script, I would like to iterate over things like  
> get_gain_names, get_gain_ranges, ...
>
> The problem is that these functions return a std::vector<std::string> *.
> The error i get is: TypeError: 'SwigPyObject' object is not iterable
>
> It would be very nice to be able to do something like:
> for src.get_sample_rates():
>     # do something
> for name in get_gain_names():
>     # do smth
>
> I found this: http://reference-man.com/files/generators.i
> But i haven't been able to use it so far. :(
>
> Any help or comments appreciated.
>
> Chris
>



From horiz0n at gmx.net  Sun Aug  5 19:57:42 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 05 Aug 2012 21:57:42 +0200
Subject: gr-ais with osmosdr
In-Reply-To: <501EBF48.9030608@techworks.ie>
References: <501EBF48.9030608@techworks.ie>
Message-ID: <op.wik22gskvay7ep@wopr.artelis.net>

Hi Christian,

On Sun, 05 Aug 2012 20:45:28 +0200, Christian Gagneraud  
<chris at techworks.ie> wrote:

> Hi there,
>
> I saw a message in the July archive (I wasn't subscribed yet at that  
> date) about updating gr-ais with osmosdr support.
> I was working on the same thing recently, so i decided to publish my  
> fixes on top of Antoine's one.
> The result can be found here:
> https://github.com/chgans/gr-ais

thanks a lot for sharing your work.

> I got it working with both an FCD and an RTL:
> ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
> ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0
>
> Strangely passing freq_err=XX parameter to the source (using -D),  
> doesn't work, the use of --error is thus needed (which will do a  
> set_freq_corr()).

The parameter freq_err was never supported, you may use  
rtl_xtal/tuner_xtal parameters for rtlsdr devices only to specify the real  
xtal value you have measured, this is almost equivalent to calling  
set_freq_corr() function.


Best regards,

Dimitri



From chris at techworks.ie  Sun Aug  5 20:49:53 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Sun, 05 Aug 2012 21:49:53 +0100
Subject: gr-ais with osmosdr
In-Reply-To: <op.wik22gskvay7ep@wopr.artelis.net>
References: <501EBF48.9030608@techworks.ie>
	<op.wik22gskvay7ep@wopr.artelis.net>
Message-ID: <501EDC71.6050303@techworks.ie>

On 05/08/12 20:57, Dimitri Stolnikov wrote:
> Hi Christian,

Hi Dimitri,

>
> On Sun, 05 Aug 2012 20:45:28 +0200, Christian Gagneraud
> <chris at techworks.ie> wrote:
>
>> Hi there,
>>
>> I saw a message in the July archive (I wasn't subscribed yet at that
>> date) about updating gr-ais with osmosdr support.
>> I was working on the same thing recently, so i decided to publish my
>> fixes on top of Antoine's one.
>> The result can be found here:
>> https://github.com/chgans/gr-ais
>
> thanks a lot for sharing your work.
>
>> I got it working with both an FCD and an RTL:
>> ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
>> ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0
>>
>> Strangely passing freq_err=XX parameter to the source (using -D),
>> doesn't work, the use of --error is thus needed (which will do a
>> set_freq_corr()).
>
> The parameter freq_err was never supported, you may use
> rtl_xtal/tuner_xtal parameters for rtlsdr devices only to specify the
> real xtal value you have measured, this is almost equivalent to calling
> set_freq_corr() function.

Ok, it's good to know.
I've sent a request today to Harald for an access to the Wiki (according 
to the instructions on the login page), I would like to update the 
GsOsmoSdr page, I think it would be very nice if all the options were 
documented, with device specific information and example too.

Chris

>
>
> Best regards,
>
> Dimitri


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From chris at techworks.ie  Sun Aug  5 20:50:41 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Sun, 05 Aug 2012 21:50:41 +0100
Subject: Iterating over gain ranges with python
In-Reply-To: <op.wik2tti1vay7ep@wopr.artelis.net>
References: <501EC53E.3090002@techworks.ie>
	<op.wik2tti1vay7ep@wopr.artelis.net>
Message-ID: <501EDCA1.8000503@techworks.ie>

On 05/08/12 20:52, Dimitri Stolnikov wrote:
> Hi Christian,
>
> please try the latest master, it should work now with the last commit.

Thanks for the information, i'll give it a try!

Chris

>
>
> Best regards,
>
> Dimitri
>
> On Sun, 05 Aug 2012 21:10:54 +0200, Christian Gagneraud
> <chris at techworks.ie> wrote:
>
>> Hi there,
>>
>> In a python script, I would like to iterate over things like
>> get_gain_names, get_gain_ranges, ...
>>
>> The problem is that these functions return a std::vector<std::string> *.
>> The error i get is: TypeError: 'SwigPyObject' object is not iterable
>>
>> It would be very nice to be able to do something like:
>> for src.get_sample_rates():
>>     # do something
>> for name in get_gain_names():
>>     # do smth
>>
>> I found this: http://reference-man.com/files/generators.i
>> But i haven't been able to use it so far. :(
>>
>> Any help or comments appreciated.
>>
>> Chris
>>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From horiz0n at gmx.net  Sun Aug  5 20:54:29 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 05 Aug 2012 22:54:29 +0200
Subject: gr-ais with osmosdr
In-Reply-To: <501EDC71.6050303@techworks.ie>
References: <501EBF48.9030608@techworks.ie>
	<op.wik22gskvay7ep@wopr.artelis.net> <501EDC71.6050303@techworks.ie>
Message-ID: <op.wik5o3p2vay7ep@wopr.artelis.net>


> Ok, it's good to know.
> I've sent a request today to Harald for an access to the Wiki (according  
> to the instructions on the login page), I would like to update the  
> GsOsmoSdr page, I think it would be very nice if all the options were  
> documented, with device specific information and example too.

Indeed, that page requires some work. A good start is the original block  
documentation:

http://cgit.osmocom.org/cgit/gr-osmosdr/tree/grc/gen_osmosdr_blocks.py#n103


Best regards,

Dimitri



From nick at ettus.com  Sun Aug  5 21:13:14 2012
From: nick at ettus.com (Nick Foster)
Date: Sun, 5 Aug 2012 14:13:14 -0700
Subject: gr-ais with osmosdr
In-Reply-To: <501EBF48.9030608@techworks.ie>
References: <501EBF48.9030608@techworks.ie>
Message-ID: <CALALHJV=6dBcUy3RwMOt5Nb7v-vVtux0mq2evHDKMZLxNN1tdg@mail.gmail.com>

On Sun, Aug 5, 2012 at 11:45 AM, Christian Gagneraud <chris at techworks.ie>wrote:

> Hi there,
>
> I saw a message in the July archive (I wasn't subscribed yet at that date)
> about updating gr-ais with osmosdr support.
> I was working on the same thing recently, so i decided to publish my fixes
> on top of Antoine's one.
> The result can be found here:
> https://github.com/chgans/gr-**ais <https://github.com/chgans/gr-ais>
>
> I got it working with both an FCD and an RTL:
> ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
> ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0
>

Thanks for doing this. I haven't been looking at gr-ais lately as I've been
doing gr-air-modes development in anticipation of our DefCon talk. Now that
that's over, I'll have some time to integrate these changes and hopefully
modernize a few things in gr-ais which I've been putting off.


>
> Strangely passing freq_err=XX parameter to the source (using -D), doesn't
> work, the use of --error is thus needed (which will do a set_freq_corr()).
>
> Antoine, if you want sample file, just let me know.
>
> Nick, are you willing to integrate these changing back in gr-ais, Apart
> from the added automatic decimation filter, the changes are not intrusive
> at all.
>

Yep, I'll pull it back in. I'm also going to need your help vetting the
changes against the FCD, as I don't have one. I do have an RTL dongle I can
do some testing with. Have you had much success with AIS on RTL?

--n



>
> The default settings for UHD are 256Khz sampling with decimation filter 4,
> with this change, the decimation is one when using FCD (96KHz fixed
> frequency) and 16 for RTL when used at 1.024MHz (this was the minimum
> working frequency for me).
> Or maybe would you prefer to allow the user to set it manually, and use
> this technique as a fall back only.
>
> Please let me know what you guys think.
>
> Thx,
> Chris
>
> --
> Christian Gagneraud,
> Embedded systems engineer.
> Techworks Marine
> 1 Harbour road
> Dun Laoghaire
> Co. Dublin
> Ireland
> Tel: + 353 (0) 1 236 5990
> Web: http://www.techworks.ie/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120805/2d3ff8ac/attachment.htm>

From chris at techworks.ie  Mon Aug  6 13:18:57 2012
From: chris at techworks.ie (chris at techworks.ie)
Date: Mon,  6 Aug 2012 14:18:57 +0100
Subject: [PATCH] Add swig hint for devices_t objects
Message-ID: <1344259137-23893-1-git-send-email-chris@techworks.ie>

From: Christian Gagneraud <chris at techworks.ie>

Signed-off-by: Christian Gagneraud <chris at techworks.ie>
---
 swig/osmosdr_swig.i |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/swig/osmosdr_swig.i b/swig/osmosdr_swig.i
index afdbb0e..4205fd6 100644
--- a/swig/osmosdr_swig.i
+++ b/swig/osmosdr_swig.i
@@ -25,6 +25,7 @@
 %ignore osmosdr::device_t::operator[]; //ignore warnings about %extend
 
 %template(string_string_dict_t) std::map<std::string, std::string>; //define before device
+%template(devices_t)std::vector<osmosdr::device_t>;
 %include <osmosdr_device.h>
 
 %template(range_vector_t) std::vector<osmosdr::range_t>; //define before range
-- 
1.7.7




From chris at techworks.ie  Mon Aug  6 15:56:26 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Mon, 06 Aug 2012 16:56:26 +0100
Subject: gr-ais with osmosdr
In-Reply-To: <CALALHJV=6dBcUy3RwMOt5Nb7v-vVtux0mq2evHDKMZLxNN1tdg@mail.gmail.com>
References: <501EBF48.9030608@techworks.ie>
	<CALALHJV=6dBcUy3RwMOt5Nb7v-vVtux0mq2evHDKMZLxNN1tdg@mail.gmail.com>
Message-ID: <501FE92A.1020805@techworks.ie>

Hi Nick,

On 05/08/12 22:13, Nick Foster wrote:
> On Sun, Aug 5, 2012 at 11:45 AM, Christian Gagneraud <chris at techworks.ie
[...]
> Yep, I'll pull it back in. I'm also going to need your help vetting the
> changes against the FCD, as I don't have one. I do have an RTL dongle I

No problem, I can run test whenever you want.

> can do some testing with. Have you had much success with AIS on RTL?

Yes, It works as well as the FCD. I can't say it work the same, since 
sometimes the FCD picks up AIS messages the RTL doesn't, and sometimes 
it is exactly the opposite.

Chris

>
> --n
>
>
>     The default settings for UHD are 256Khz sampling with decimation
>     filter 4, with this change, the decimation is one when using FCD
>     (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this
>     was the minimum working frequency for me).
>     Or maybe would you prefer to allow the user to set it manually, and
>     use this technique as a fall back only.
>
>     Please let me know what you guys think.
>
>     Thx,
>     Chris
>
>     --
>     Christian Gagneraud,
>     Embedded systems engineer.
>     Techworks Marine
>     1 Harbour road
>     Dun Laoghaire
>     Co. Dublin
>     Ireland
>     Tel: + 353 (0) 1 236 5990 <tel:%2B%20353%20%280%29%201%20236%205990>
>     Web: http://www.techworks.ie/
>
>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From friedtj at free.fr  Mon Aug  6 22:05:42 2012
From: friedtj at free.fr (friedtj at free.fr)
Date: Tue, 7 Aug 2012 00:05:42 +0200 (CEST)
Subject: gr-ais with osmosdr
In-Reply-To: <CALALHJV=6dBcUy3RwMOt5Nb7v-vVtux0mq2evHDKMZLxNN1tdg@mail.gmail.com>
Message-ID: <3527745.66211683.1344290742152.JavaMail.root@zimbra9-e2.priv.proxad.net>

not sure what "I've been doing gr-air-modes development in anticipation of our ..." means,
but since ACARS was being discussed as an addition to gr-air-modes, please let me announce that I am
about to complete an ACARS-decoding block which was quite well tested on the rtl-sdr.

JM

----- Mail original -----
De: "Nick Foster" <nick at ettus.com>
?: "Christian Gagneraud" <chris at techworks.ie>
Cc: osmocom-sdr at lists.osmocom.org
Envoy?: Dimanche 5 Ao?t 2012 17:13:14
Objet: Re: gr-ais with osmosdr


On Sun, Aug 5, 2012 at 11:45 AM, Christian Gagneraud < chris at techworks.ie > wrote: 


Hi there, 

I saw a message in the July archive (I wasn't subscribed yet at that date) about updating gr-ais with osmosdr support. 
I was working on the same thing recently, so i decided to publish my fixes on top of Antoine's one. 
The result can be found here: 
https://github.com/chgans/gr- ais 

I got it working with both an FCD and an RTL: 
ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0 
ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0 



Thanks for doing this. I haven't been looking at gr-ais lately as I've been doing gr-air-modes development in anticipation of our DefCon talk. Now that that's over, I'll have some time to integrate these changes and hopefully modernize a few things in gr-ais which I've been putting off. 



Strangely passing freq_err=XX parameter to the source (using -D), doesn't work, the use of --error is thus needed (which will do a set_freq_corr()). 

Antoine, if you want sample file, just let me know. 

Nick, are you willing to integrate these changing back in gr-ais, Apart from the added automatic decimation filter, the changes are not intrusive at all. 



Yep, I'll pull it back in. I'm also going to need your help vetting the changes against the FCD, as I don't have one. I do have an RTL dongle I can do some testing with. Have you had much success with AIS on RTL? 


--n 





The default settings for UHD are 256Khz sampling with decimation filter 4, with this change, the decimation is one when using FCD (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this was the minimum working frequency for me). 
Or maybe would you prefer to allow the user to set it manually, and use this technique as a fall back only. 

Please let me know what you guys think. 

Thx, 
Chris 

-- 
Christian Gagneraud, 
Embedded systems engineer. 
Techworks Marine 
1 Harbour road 
Dun Laoghaire 
Co. Dublin 
Ireland 
Tel: + 353 (0) 1 236 5990 
Web: http://www.techworks.ie/ 




From nick at ettus.com  Mon Aug  6 22:20:30 2012
From: nick at ettus.com (Nick Foster)
Date: Mon, 6 Aug 2012 15:20:30 -0700
Subject: gr-ais with osmosdr
In-Reply-To: <3527745.66211683.1344290742152.JavaMail.root@zimbra9-e2.priv.proxad.net>
References: <CALALHJV=6dBcUy3RwMOt5Nb7v-vVtux0mq2evHDKMZLxNN1tdg@mail.gmail.com>
	<3527745.66211683.1344290742152.JavaMail.root@zimbra9-e2.priv.proxad.net>
Message-ID: <CALALHJXMVVrL1D=f-4omo+4APy1osUvjG6guX1dpLhLe8MSr4w@mail.gmail.com>

Looking forward to seeing it. Would be very nice to have ACARS data
alongside ADS-B.

--n

On Mon, Aug 6, 2012 at 3:05 PM, <friedtj at free.fr> wrote:

> not sure what "I've been doing gr-air-modes development in anticipation of
> our ..." means,
> but since ACARS was being discussed as an addition to gr-air-modes, please
> let me announce that I am
> about to complete an ACARS-decoding block which was quite well tested on
> the rtl-sdr.
>
> JM
>
> ----- Mail original -----
> De: "Nick Foster" <nick at ettus.com>
> ?: "Christian Gagneraud" <chris at techworks.ie>
> Cc: osmocom-sdr at lists.osmocom.org
> Envoy?: Dimanche 5 Ao?t 2012 17:13:14
> Objet: Re: gr-ais with osmosdr
>
>
> On Sun, Aug 5, 2012 at 11:45 AM, Christian Gagneraud < chris at techworks.ie> wrote:
>
>
> Hi there,
>
> I saw a message in the July archive (I wasn't subscribed yet at that date)
> about updating gr-ais with osmosdr support.
> I was working on the same thing recently, so i decided to publish my fixes
> on top of Antoine's one.
> The result can be found here:
> https://github.com/chgans/gr- ais
>
> I got it working with both an FCD and an RTL:
> ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
> ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0
>
>
>
> Thanks for doing this. I haven't been looking at gr-ais lately as I've
> been doing gr-air-modes development in anticipation of our DefCon talk. Now
> that that's over, I'll have some time to integrate these changes and
> hopefully modernize a few things in gr-ais which I've been putting off.
>
>
>
> Strangely passing freq_err=XX parameter to the source (using -D), doesn't
> work, the use of --error is thus needed (which will do a set_freq_corr()).
>
> Antoine, if you want sample file, just let me know.
>
> Nick, are you willing to integrate these changing back in gr-ais, Apart
> from the added automatic decimation filter, the changes are not intrusive
> at all.
>
>
>
> Yep, I'll pull it back in. I'm also going to need your help vetting the
> changes against the FCD, as I don't have one. I do have an RTL dongle I can
> do some testing with. Have you had much success with AIS on RTL?
>
>
> --n
>
>
>
>
>
> The default settings for UHD are 256Khz sampling with decimation filter 4,
> with this change, the decimation is one when using FCD (96KHz fixed
> frequency) and 16 for RTL when used at 1.024MHz (this was the minimum
> working frequency for me).
> Or maybe would you prefer to allow the user to set it manually, and use
> this technique as a fall back only.
>
> Please let me know what you guys think.
>
> Thx,
> Chris
>
> --
> Christian Gagneraud,
> Embedded systems engineer.
> Techworks Marine
> 1 Harbour road
> Dun Laoghaire
> Co. Dublin
> Ireland
> Tel: + 353 (0) 1 236 5990
> Web: http://www.techworks.ie/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120806/ea2d2d1a/attachment.htm>

From chris at techworks.ie  Tue Aug  7 10:58:54 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Tue, 07 Aug 2012 11:58:54 +0100
Subject: Wiki page
Message-ID: <5020F4EE.5080507@techworks.ie>

Hi,

I started do add documentation to the wiki page of gr-osmosdr [1].
For now i've just added documentation about the "constructor" 
parameters. Any feedback welcome.

[1] http://sdr.osmocom.org/trac/wiki/GrOsmoSDR

PS: Could anyone tell me what the mcr is? (used for osmosdr source)

-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From 246tnt at gmail.com  Tue Aug  7 11:01:20 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 7 Aug 2012 13:01:20 +0200
Subject: Wiki page
In-Reply-To: <5020F4EE.5080507@techworks.ie>
References: <5020F4EE.5080507@techworks.ie>
Message-ID: <CAHL+j0_W-_6s9b2Evmvx3YvV4pJOLkzP-YkXStNkowjvoXpQFA@mail.gmail.com>

Hi,

> PS: Could anyone tell me what the mcr is? (used for osmosdr source)

Master Clock Rate

The OsmoSDR features a programmable Si570 clock generator so if you
want your sample rate to be an exact multiple of the symbol rate, you
could use this.
But that's for the future :p

Cheers,

    Sylvain



From chris at techworks.ie  Tue Aug  7 11:13:14 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Tue, 07 Aug 2012 12:13:14 +0100
Subject: Bug hunting
Message-ID: <5020F84A.7080009@techworks.ie>

Hi,

Is there any bug tracker for the gr-osmosdr somewhere?

It would be nice if the "audio_alsa_source[hw:X]: Device or resource 
busy" could be fixed.
The problem with that bug is you can't even interogate the device driver 
for supported gain, etc... If the device is used by another application.

For example, I have permanently 2 devices plugged in, I use an FCD to 
send AIS data to aishub.com, and a RTL to experiment with.
The problem with this bug is that if you use python you can't even catch 
the exception, it simply crash the script. I think that the behaviour is 
different when using C++.

Another "bug" I discovered is that if you just do a device scan to print 
available device and exit the python script, it will generate plenty of 
error messages like "libusb:warning [cancel_bulk_transfer] unrecognised 
discard errno 9", the workaround is to simply wait a bit before exiting. 
It seems that some USB packets are still pending after calling 
osmosdr.source_c().

Chris

-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From chris at techworks.ie  Tue Aug  7 11:15:28 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Tue, 07 Aug 2012 12:15:28 +0100
Subject: Wiki page
In-Reply-To: <CAHL+j0_W-_6s9b2Evmvx3YvV4pJOLkzP-YkXStNkowjvoXpQFA@mail.gmail.com>
References: <5020F4EE.5080507@techworks.ie>
	<CAHL+j0_W-_6s9b2Evmvx3YvV4pJOLkzP-YkXStNkowjvoXpQFA@mail.gmail.com>
Message-ID: <5020F8D0.9030208@techworks.ie>

On 07/08/12 12:01, Sylvain Munaut wrote:
> Hi,
>
>> PS: Could anyone tell me what the mcr is? (used for osmosdr source)
>
> Master Clock Rate
>
> The OsmoSDR features a programmable Si570 clock generator so if you
> want your sample rate to be an exact multiple of the symbol rate, you
> could use this.
> But that's for the future :p

Thanks for the information.

>
> Cheers,
>
>      Sylvain
>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From friedtj at free.fr  Tue Aug  7 12:58:03 2012
From: friedtj at free.fr (friedtj at free.fr)
Date: Tue, 7 Aug 2012 14:58:03 +0200 (CEST)
Subject: gr-ais with osmosdr
In-Reply-To: <CALALHJXMVVrL1D=f-4omo+4APy1osUvjG6guX1dpLhLe8MSr4w@mail.gmail.com>
Message-ID: <690341597.67245781.1344344283959.JavaMail.root@zimbra9-e2.priv.proxad.net>

actually while I complete the real time decoding functionality for ACARS, I have a request
for the French speaking audience of this list (I believe I might have seen a couple of
.fr posts): I am completing an article for GNU/Linux Magazine France on this topic, and
would be grateful for a review by the experts (or actually also the non-experts to tell
me if what I wrote is worth discussing) of this list. The manuscript is available at

http://sequanux.org/jmfriedt/t/lm_sdr.pdf

I do try and describe there the development method I applied for writing several digital
mode decoders (not sure the method is the right one, but at least it is the one I use :)

Also if such a document might be useful for the non-French speaking community, I will
be happy to translate it to English as soon as time allows (ie probably after Sept 15th).

JM

----- Mail original -----
De: "Nick Foster" <nick at ettus.com>
?: friedtj at free.fr
Cc: osmocom-sdr at lists.osmocom.org
Envoy?: Lundi 6 Ao?t 2012 18:20:30
Objet: Re: gr-ais with osmosdr

Looking forward to seeing it. Would be very nice to have ACARS data alongside ADS-B. 


--n 


On Mon, Aug 6, 2012 at 3:05 PM, < friedtj at free.fr > wrote: 


not sure what "I've been doing gr-air-modes development in anticipation of our ..." means, 
but since ACARS was being discussed as an addition to gr-air-modes, please let me announce that I am 
about to complete an ACARS-decoding block which was quite well tested on the rtl-sdr. 

JM 

----- Mail original ----- 
De: "Nick Foster" < nick at ettus.com > 
?: "Christian Gagneraud" < chris at techworks.ie > 
Cc: osmocom-sdr at lists.osmocom.org 
Envoy?: Dimanche 5 Ao?t 2012 17:13:14 
Objet: Re: gr-ais with osmosdr 




On Sun, Aug 5, 2012 at 11:45 AM, Christian Gagneraud < chris at techworks.ie > wrote: 


Hi there, 

I saw a message in the July archive (I wasn't subscribed yet at that date) about updating gr-ais with osmosdr support. 
I was working on the same thing recently, so i decided to publish my fixes on top of Antoine's one. 
The result can be found here: 
https://github.com/chgans/gr- ais 

I got it working with both an FCD and an RTL: 
ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0 
ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0 



Thanks for doing this. I haven't been looking at gr-ais lately as I've been doing gr-air-modes development in anticipation of our DefCon talk. Now that that's over, I'll have some time to integrate these changes and hopefully modernize a few things in gr-ais which I've been putting off. 



Strangely passing freq_err=XX parameter to the source (using -D), doesn't work, the use of --error is thus needed (which will do a set_freq_corr()). 

Antoine, if you want sample file, just let me know. 

Nick, are you willing to integrate these changing back in gr-ais, Apart from the added automatic decimation filter, the changes are not intrusive at all. 



Yep, I'll pull it back in. I'm also going to need your help vetting the changes against the FCD, as I don't have one. I do have an RTL dongle I can do some testing with. Have you had much success with AIS on RTL? 


--n 





The default settings for UHD are 256Khz sampling with decimation filter 4, with this change, the decimation is one when using FCD (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this was the minimum working frequency for me). 
Or maybe would you prefer to allow the user to set it manually, and use this technique as a fall back only. 

Please let me know what you guys think. 

Thx, 
Chris 

-- 
Christian Gagneraud, 
Embedded systems engineer. 
Techworks Marine 
1 Harbour road 
Dun Laoghaire 
Co. Dublin 
Ireland 
Tel: + 353 (0) 1 236 5990 
Web: http://www.techworks.ie/ 





From chris at techworks.ie  Tue Aug  7 13:10:21 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Tue, 07 Aug 2012 14:10:21 +0100
Subject: gr-ais with osmosdr
In-Reply-To: <690341597.67245781.1344344283959.JavaMail.root@zimbra9-e2.priv.proxad.net>
References: <690341597.67245781.1344344283959.JavaMail.root@zimbra9-e2.priv.proxad.net>
Message-ID: <502113BD.9030601@techworks.ie>

On 07/08/12 13:58, friedtj at free.fr wrote:
> actually while I complete the real time decoding functionality for ACARS, I have a request
> for the French speaking audience of this list (I believe I might have seen a couple of
> .fr posts): I am completing an article for GNU/Linux Magazine France on this topic, and
> would be grateful for a review by the experts (or actually also the non-experts to tell
> me if what I wrote is worth discussing) of this list. The manuscript is available at
>
> http://sequanux.org/jmfriedt/t/lm_sdr.pdf

Is the latex source available somewhere? That might be easier to give 
you feedback and remarks.

Chris

>
> I do try and describe there the development method I applied for writing several digital
> mode decoders (not sure the method is the right one, but at least it is the one I use :)
>
> Also if such a document might be useful for the non-French speaking community, I will
> be happy to translate it to English as soon as time allows (ie probably after Sept 15th).
>
> JM
>
> ----- Mail original -----
> De: "Nick Foster" <nick at ettus.com>
> ?: friedtj at free.fr
> Cc: osmocom-sdr at lists.osmocom.org
> Envoy?: Lundi 6 Ao?t 2012 18:20:30
> Objet: Re: gr-ais with osmosdr
>
> Looking forward to seeing it. Would be very nice to have ACARS data alongside ADS-B.
>
>
> --n
>
>
> On Mon, Aug 6, 2012 at 3:05 PM, < friedtj at free.fr > wrote:
>
>
> not sure what "I've been doing gr-air-modes development in anticipation of our ..." means,
> but since ACARS was being discussed as an addition to gr-air-modes, please let me announce that I am
> about to complete an ACARS-decoding block which was quite well tested on the rtl-sdr.
>
> JM
>
> ----- Mail original -----
> De: "Nick Foster" < nick at ettus.com >
> ?: "Christian Gagneraud" < chris at techworks.ie >
> Cc: osmocom-sdr at lists.osmocom.org
> Envoy?: Dimanche 5 Ao?t 2012 17:13:14
> Objet: Re: gr-ais with osmosdr
>
>
>
>
> On Sun, Aug 5, 2012 at 11:45 AM, Christian Gagneraud < chris at techworks.ie > wrote:
>
>
> Hi there,
>
> I saw a message in the July archive (I wasn't subscribed yet at that date) about updating gr-ais with osmosdr support.
> I was working on the same thing recently, so i decided to publish my fixes on top of Antoine's one.
> The result can be found here:
> https://github.com/chgans/gr- ais
>
> I got it working with both an FCD and an RTL:
> ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
> ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0
>
>
>
> Thanks for doing this. I haven't been looking at gr-ais lately as I've been doing gr-air-modes development in anticipation of our DefCon talk. Now that that's over, I'll have some time to integrate these changes and hopefully modernize a few things in gr-ais which I've been putting off.
>
>
>
> Strangely passing freq_err=XX parameter to the source (using -D), doesn't work, the use of --error is thus needed (which will do a set_freq_corr()).
>
> Antoine, if you want sample file, just let me know.
>
> Nick, are you willing to integrate these changing back in gr-ais, Apart from the added automatic decimation filter, the changes are not intrusive at all.
>
>
>
> Yep, I'll pull it back in. I'm also going to need your help vetting the changes against the FCD, as I don't have one. I do have an RTL dongle I can do some testing with. Have you had much success with AIS on RTL?
>
>
> --n
>
>
>
>
>
> The default settings for UHD are 256Khz sampling with decimation filter 4, with this change, the decimation is one when using FCD (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this was the minimum working frequency for me).
> Or maybe would you prefer to allow the user to set it manually, and use this technique as a fall back only.
>
> Please let me know what you guys think.
>
> Thx,
> Chris
>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From friedtj at free.fr  Tue Aug  7 13:16:40 2012
From: friedtj at free.fr (friedtj at free.fr)
Date: Tue, 7 Aug 2012 15:16:40 +0200 (CEST)
Subject: gr-ais with osmosdr
In-Reply-To: <502113BD.9030601@techworks.ie>
Message-ID: <1033380078.67272123.1344345400208.JavaMail.root@zimbra9-e2.priv.proxad.net>

> Is the latex source available somewhere? That might be easier to give 
> you feedback and remarks.

great, thanks: http://sequanux.org/jmfriedt/t/lm_sdr.tex

JM






From laforge at gnumonks.org  Tue Aug  7 11:30:00 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 7 Aug 2012 13:30:00 +0200
Subject: Bug hunting
In-Reply-To: <5020F84A.7080009@techworks.ie>
References: <5020F84A.7080009@techworks.ie>
Message-ID: <20120807113000.GU26533@prithivi.gnumonks.org>

Hi Christian,

On Tue, Aug 07, 2012 at 12:13:14PM +0100, Christian Gagneraud wrote:
> Is there any bug tracker for the gr-osmosdr somewhere?

not specifically, but feel free to put them into
http://sdr.osmocom.org/trac/query

On the other hand, the amount of bug reports is so low, that having them
here on the mailing list doesn't sound like a bad idea, either.

Regards,
	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 peter at stuge.se  Tue Aug  7 13:54:23 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 7 Aug 2012 15:54:23 +0200
Subject: Bug hunting
In-Reply-To: <5020F84A.7080009@techworks.ie>
References: <5020F84A.7080009@techworks.ie>
Message-ID: <20120807135423.11594.qmail@stuge.se>

Hi Chris,

Christian Gagneraud wrote:
> Another "bug" I discovered is that if you just do a device scan to print 
> available device and exit the python script, it will generate plenty of 
> error messages like "libusb:warning [cancel_bulk_transfer] unrecognised 
> discard errno 9", the workaround is to simply wait a bit before exiting.
> It seems that some USB packets are still pending after calling 
> osmosdr.source_c().

I'm interested in this since I'm the libusb maintainer.

Error 9 means that ioctl() returns "Invalid file descriptor" - so the
fd that came from open():ing the device has since become invalid. I
would appreciate if you can provide a short (python) program to
reproduce this error, or perhaps you can provide a debug log,
according to the http://libusb.org/wiki/debug page. It shouldn't
happen.


Thanks

//Peter



From chris at techworks.ie  Tue Aug  7 14:11:02 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Tue, 07 Aug 2012 15:11:02 +0100
Subject: Bug hunting
In-Reply-To: <20120807135423.11594.qmail@stuge.se>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se>
Message-ID: <502121F6.9020304@techworks.ie>

On 07/08/12 14:54, Peter Stuge wrote:
> Hi Chris,
>
> Christian Gagneraud wrote:
>> Another "bug" I discovered is that if you just do a device scan to print
>> available device and exit the python script, it will generate plenty of
>> error messages like "libusb:warning [cancel_bulk_transfer] unrecognised
>> discard errno 9", the workaround is to simply wait a bit before exiting.
>> It seems that some USB packets are still pending after calling
>> osmosdr.source_c().
>
> I'm interested in this since I'm the libusb maintainer.
>
> Error 9 means that ioctl() returns "Invalid file descriptor" - so the
> fd that came from open():ing the device has since become invalid. I
> would appreciate if you can provide a short (python) program to
> reproduce this error, or perhaps you can provide a debug log,
> according to the http://libusb.org/wiki/debug page. It shouldn't

Hi Peter,

Please find attached the full log. I can provide u with a simple python 
program, but it will depends on gnuradio, gr-osmosdr and you will need a 
compatible device plugged in as well.

Chris

> happen.
>
>
> Thanks
>
> //Peter
>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libusb.log
Type: text/x-log
Size: 226058 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120807/b082703f/attachment.bin>

From peter at stuge.se  Tue Aug  7 14:49:34 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 7 Aug 2012 16:49:34 +0200
Subject: Bug hunting
In-Reply-To: <502121F6.9020304@techworks.ie>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se>
	<502121F6.9020304@techworks.ie>
Message-ID: <20120807144934.16153.qmail@stuge.se>

Christian Gagneraud wrote:
> Please find attached the full log.

Thanks!


> I can provide u with a simple python program, but it will depends
> on gnuradio, gr-osmosdr and you will need a compatible device
> plugged in as well.

No problem, but I think I find the problem.


> libusb: 0.783771 debug [libusb_handle_events_timeout_completed] doing our own event handling
> libusb: 0.783793 debug [handle_events] poll() 3 fds with timeout in 1000ms
> libusb: 0.783811 debug [libusb_release_interface] interface 0
> libusb: 0.785853 debug [handle_events] poll() returned 1

The above lines show that the interface is released while event
handling is still running. The destructor was called while the IO
thread is running, and the destructor does cancel all IO, but it only
waited 200 ms for the IO to complete, before it went on to close
everything. Please try the attached patch for gr-osmosdr.

This may or may not be the appropriate fix. This should perhaps be
fixed inside rtl-sdr, or even libusb (we're already considering it)
instead.


//Peter

From peter at stuge.se  Tue Aug  7 14:42:33 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 7 Aug 2012 16:42:33 +0200
Subject: [PATCH] Wait in the destructor for all I/O to finish without a
 timeout
Message-ID: <mailman.3.1641746893.43026.osmocom-sdr@lists.osmocom.org>

Signed-off-by: Peter Stuge <peter at stuge.se>
---
 lib/rtl/rtl_source_c.cc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc
index 8839a2f..c8cc772 100644
--- a/lib/rtl/rtl_source_c.cc
+++ b/lib/rtl/rtl_source_c.cc
@@ -180,7 +180,7 @@ rtl_source_c::~rtl_source_c ()
   if (_dev) {
     _running = false;
     rtlsdr_cancel_async( _dev );
-    _thread.timed_join( boost::posix_time::milliseconds(200) );
+    _thread.join();
     rtlsdr_close( _dev );
     _dev = NULL;
   }
-- 
1.7.4.1.343.ga91df.dirty


--YZ5djTAD1cGYuMQK--



From chris at techworks.ie  Tue Aug  7 18:49:40 2012
From: chris at techworks.ie (chris at techworks.ie)
Date: Tue,  7 Aug 2012 19:49:40 +0100
Subject: [PATCH] [rtl-sdr] Relaxed async state machine
Message-ID: <1344365380-1485-1-git-send-email-chris@techworks.ie>

From: Christian Gagneraud <chris at techworks.ie>

gr-osmosdr uses the driver in a multi-thread context, as a side effect the
cancel_async() can be called before read_async(), in such a case the cancel is
"forgotten".  This patch fixed that by being a bit more relaxed with
state machine transitions.
This patch doesn't fix any race conditions, it just make an anoying one less
likely to happen.

This patch goes along this one [1]

[1] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-August/000201.html

Signed-off-by: Christian Gagneraud <chris at techworks.ie>
---
 src/librtlsdr.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 4e54d8e..d83010d 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1256,6 +1256,12 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx,
 	if (!dev)
 		return -1;
 
+	/* It can happen if cancel_async is called before read_async */
+	if (dev->async_status != RTLSDR_INACTIVE)
+	    return -1;
+
+	dev->async_status = RTLSDR_RUNNING;
+
 	dev->cb = cb;
 	dev->cb_ctx = ctx;
 
@@ -1284,8 +1290,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx,
 		libusb_submit_transfer(dev->xfer[i]);
 	}
 
-	dev->async_status = RTLSDR_RUNNING;
-
 	while (RTLSDR_INACTIVE != dev->async_status) {
 		r = libusb_handle_events_timeout(dev->ctx, &tv);
 		if (r < 0) {
@@ -1326,7 +1330,7 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev)
 	if (!dev)
 		return -1;
 
-	if (RTLSDR_RUNNING == dev->async_status) {
+	if (RTLSDR_CANCELING != dev->async_status) {
 		dev->async_status = RTLSDR_CANCELING;
 		return 0;
 	}
-- 
1.7.7




From chris at techworks.ie  Tue Aug  7 18:53:25 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Tue, 07 Aug 2012 19:53:25 +0100
Subject: Bug hunting
In-Reply-To: <20120807144934.16153.qmail@stuge.se>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se>
	<502121F6.9020304@techworks.ie>
	<20120807144934.16153.qmail@stuge.se>
Message-ID: <50216425.1070704@techworks.ie>

On 07/08/12 15:49, Peter Stuge wrote:
> Christian Gagneraud wrote:
>> Please find attached the full log.
>
> Thanks!
>
>
>> I can provide u with a simple python program, but it will depends
>> on gnuradio, gr-osmosdr and you will need a compatible device
>> plugged in as well.
>
> No problem, but I think I find the problem.
>
>
>> libusb: 0.783771 debug [libusb_handle_events_timeout_completed] doing our own event handling
>> libusb: 0.783793 debug [handle_events] poll() 3 fds with timeout in 1000ms
>> libusb: 0.783811 debug [libusb_release_interface] interface 0
>> libusb: 0.785853 debug [handle_events] poll() returned 1
>
> The above lines show that the interface is released while event
> handling is still running. The destructor was called while the IO
> thread is running, and the destructor does cancel all IO, but it only
> waited 200 ms for the IO to complete, before it went on to close
> everything. Please try the attached patch for gr-osmosdr.
>
> This may or may not be the appropriate fix. This should perhaps be
> fixed inside rtl-sdr, or even libusb (we're already considering it)
> instead.

It doesn't fix the problem alone. The script simply never exits.
I've just sent a patch for rtl-sdr that fix the issue.
I think it's still possible that a call to join() could block the app 
forever, so maybe a longer timeout would be safer here. As well the same 
apply for the osmosdr wrapper code.

Chris

>
>
> //Peter
>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From horiz0n at gmx.net  Tue Aug  7 23:23:54 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Wed, 08 Aug 2012 01:23:54 +0200
Subject: Bug hunting
In-Reply-To: <50216425.1070704@techworks.ie>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se> <502121F6.9020304@techworks.ie>
	<20120807144934.16153.qmail@stuge.se> <50216425.1070704@techworks.ie>
Message-ID: <op.wio1x4y8vay7ep@wopr.artelis.net>

Hi Christian,

could you please try the attached patch together with Peter's join patch?  
It handles async cancellation in a more graceful way.

The other problem (segfault on trow in ctor) still has to be addressed.


Best regards,
Dimitri

On Tue, 07 Aug 2012 20:53:25 +0200, Christian Gagneraud  
<chris at techworks.ie> wrote:

> On 07/08/12 15:49, Peter Stuge wrote:
>> Christian Gagneraud wrote:
>>> Please find attached the full log.
>>
>> Thanks!
>>
>>
>>> I can provide u with a simple python program, but it will depends
>>> on gnuradio, gr-osmosdr and you will need a compatible device
>>> plugged in as well.
>>
>> No problem, but I think I find the problem.
>>
>>
>>> libusb: 0.783771 debug [libusb_handle_events_timeout_completed] doing  
>>> our own event handling
>>> libusb: 0.783793 debug [handle_events] poll() 3 fds with timeout in  
>>> 1000ms
>>> libusb: 0.783811 debug [libusb_release_interface] interface 0
>>> libusb: 0.785853 debug [handle_events] poll() returned 1
>>
>> The above lines show that the interface is released while event
>> handling is still running. The destructor was called while the IO
>> thread is running, and the destructor does cancel all IO, but it only
>> waited 200 ms for the IO to complete, before it went on to close
>> everything. Please try the attached patch for gr-osmosdr.
>>
>> This may or may not be the appropriate fix. This should perhaps be
>> fixed inside rtl-sdr, or even libusb (we're already considering it)
>> instead.
>
> It doesn't fix the problem alone. The script simply never exits.
> I've just sent a patch for rtl-sdr that fix the issue.
> I think it's still possible that a call to join() could block the app  
> forever, so maybe a longer timeout would be safer here. As well the same  
> apply for the osmosdr wrapper code.
>
> Chris
>
>>
>>
>> //Peter
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleanclose.patch
Type: text/x-diff
Size: 2923 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120808/46392eef/attachment.bin>

From horiz0n at gmx.net  Tue Aug  7 23:23:55 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Wed, 08 Aug 2012 01:23:55 +0200
Subject: Bug hunting
In-Reply-To: <5020F84A.7080009@techworks.ie>
References: <5020F84A.7080009@techworks.ie>
Message-ID: <op.wio1x5qsvay7ep@wopr.artelis.net>

Hi Christian,

> It would be nice if the "audio_alsa_source[hw:X]: Device or resource  
> busy" could be fixed.
> The problem with that bug is you can't even interogate the device driver  
> for supported gain, etc... If the device is used by another application.

Not sure we can address that problem in gr-osmosdr, since the error comes  
 from gnuradio-fcd library. Its very similar to how the UHD devices behave,  
you have to open the device to be able to query available sample rates  
etc. Imagine that a user specifies a custom master clock rate via mcr=  
argument (stored in the EEPROM) in UHD, the available sample rates would  
be different from their default values. But the library has to open the  
device first, query the mcr value from the hardware and then return the  
available rates, for example.

On other words, if a device is being used, you loose.

> For example, I have permanently 2 devices plugged in, I use an FCD to  
> send AIS data to aishub.com, and a RTL to experiment with.
> The problem with this bug is that if you use python you can't even catch  
> the exception, it simply crash the script. I think that the behaviour is  
> different when using C++.

We're investigating this known issue. As always, patches are very much  
appreciated.


Best regards,
Dimitri



From peter at stuge.se  Wed Aug  8 02:44:14 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 8 Aug 2012 04:44:14 +0200
Subject: Bug hunting
In-Reply-To: <op.wio1x5qsvay7ep@wopr.artelis.net>
References: <5020F84A.7080009@techworks.ie>
	<op.wio1x5qsvay7ep@wopr.artelis.net>
Message-ID: <20120808024414.6855.qmail@stuge.se>

Dimitri Stolnikov wrote:
>> It would be nice if the "audio_alsa_source[hw:X]: Device or resource busy" 
>> could be fixed.
>> The problem with that bug is you can't even interogate the device driver 
>> for supported gain, etc... If the device is used by another application.
>
> Not sure we can address that problem in gr-osmosdr, since the error comes 
> from gnuradio-fcd library. Its very similar to how the UHD devices behave, 
> you have to open the device to be able to query available sample rates etc. 
> Imagine that a user specifies a custom master clock rate via mcr= argument 
> (stored in the EEPROM) in UHD, the available sample rates would be 
> different from their default values. But the library has to open the device 
> first, query the mcr value from the hardware and then return the available 
> rates, for example.
>
> On other words, if a device is being used, you loose.

At least on Linux it's possible for multiple applications to perform
control transfers to the same device in parallel.


//Peter



From chris at techworks.ie  Wed Aug  8 15:02:21 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Wed, 08 Aug 2012 16:02:21 +0100
Subject: FCD/Alsa bug (Re: Bug hunting)
In-Reply-To: <op.wio1x4y8vay7ep@wopr.artelis.net>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se>
	<502121F6.9020304@techworks.ie>
	<20120807144934.16153.qmail@stuge.se>
	<50216425.1070704@techworks.ie>
	<op.wio1x4y8vay7ep@wopr.artelis.net>
Message-ID: <50227F7D.90808@techworks.ie>

Cross posting to discuss-gnuradio.

The bug in question is that if you instanciate an alsa source on a busy 
device (opened by another app), then the program crashed.

On 08/08/12 00:23, Dimitri Stolnikov wrote:
> Hi Christian,
[...]
>
> The other problem (segfault on trow in ctor) still has to be addressed.

Yes, I started to investigate, and it seems to me that this is not a 
gr-osmosdr bug, but it's a gnuradio one, caused by gr-fcd.

This simple test program have the same problem, yet it only uses gr-fcd.

#include <iostream>
#include <fcd_source_c.h>
int main(int argc, char **argv)
{
     fcd_source_c_sptr fsrc;
     try {
	fsrc = fcd_make_source_c("hw:2"); // KO, from gr-fcd
     }
     catch (std::runtime_error &e) {
	std::cerr << "Error!\n";
     }
     exit(0);
}

g++ test.cc -o test -I/usr/local/include/gnuradio -lgnuradio-fcd

Here is the log:
audio_alsa_source[hw:2]: Device or resource busy
Error!
*** glibc detected *** /home/cgagneraud/sdr/gr-osmosdr/test: free(): 
invalid pointer: 0x08052e3c ***
[...]

And here is a cleaned up backtrace:
operator delete
gruel::msg_accepter::~msg_accepter
checked_delete<gr_hier_block2>
boost::detail::sp_counted_impl_p<gr_hier_block2>::dispose
[...]
const, boost::shared_ptr<gr_basic_block> > > >::~map
__cxa_finalize
__do_global_dtors_aux
[...]
main

The problem is related to 
gnuradio-core/src/lib/runtime/gr_sptr_magic.{h,cc} and the static 
std::map in there.

gr_hier_block2 ctor insert "this" in this map, but then in fcd_source 
ctor, audio_alsa_source ctor throws an exception, so "this" 
(gr_hier_block2/fcd_source) is not a valid pointer anymore.
When the program exits, the map get cleanup up and free is called on 
this pointer.

It's not possible to cleanup the map in fcd_source, because the dtor is 
not called when exception occurs in the ctor (which, btw, leads to some 
memory leaks in alsa_source: namely d_hw_params and d_sw_params).
It's a bad idea to call fetch_initial_sptr(this) before throwing in the 
ctor, because it seems the object get deleted.

Maybe one solution could be to add a function member to mark the 
hier_block2 as zombie, the gr_hier_block2 dtor could then cleanup the 
map depending on that information.

A workaround could be to catch the exception in fcd_source ctor.
and throw exceptions whenever the fcd C API returns
FCD_MODE_NONE. Well, this is kind of a dirty trick that has lot of 
drawbacks.

Maybe some gnuradio gurus could shed some light on how to address this 
issue?

Chris


>
>
> Best regards,
> Dimitri
>
> On Tue, 07 Aug 2012 20:53:25 +0200, Christian Gagneraud
> <chris at techworks.ie> wrote:
>
>> On 07/08/12 15:49, Peter Stuge wrote:
>>> Christian Gagneraud wrote:
>>>> Please find attached the full log.
>>>
>>> Thanks!
>>>
>>>
>>>> I can provide u with a simple python program, but it will depends
>>>> on gnuradio, gr-osmosdr and you will need a compatible device
>>>> plugged in as well.
>>>
>>> No problem, but I think I find the problem.
>>>
>>>
>>>> libusb: 0.783771 debug [libusb_handle_events_timeout_completed]
>>>> doing our own event handling
>>>> libusb: 0.783793 debug [handle_events] poll() 3 fds with timeout in
>>>> 1000ms
>>>> libusb: 0.783811 debug [libusb_release_interface] interface 0
>>>> libusb: 0.785853 debug [handle_events] poll() returned 1
>>>
>>> The above lines show that the interface is released while event
>>> handling is still running. The destructor was called while the IO
>>> thread is running, and the destructor does cancel all IO, but it only
>>> waited 200 ms for the IO to complete, before it went on to close
>>> everything. Please try the attached patch for gr-osmosdr.
>>>
>>> This may or may not be the appropriate fix. This should perhaps be
>>> fixed inside rtl-sdr, or even libusb (we're already considering it)
>>> instead.
>>
>> It doesn't fix the problem alone. The script simply never exits.
>> I've just sent a patch for rtl-sdr that fix the issue.
>> I think it's still possible that a call to join() could block the app
>> forever, so maybe a longer timeout would be safer here. As well the
>> same apply for the osmosdr wrapper code.
>>
>> Chris
>>
>>>
>>>
>>> //Peter
>>>
>>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From chris at techworks.ie  Wed Aug  8 15:04:19 2012
From: chris at techworks.ie (Christian Gagneraud)
Date: Wed, 08 Aug 2012 16:04:19 +0100
Subject: Bug hunting
In-Reply-To: <op.wio1x4y8vay7ep@wopr.artelis.net>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se>
	<502121F6.9020304@techworks.ie>
	<20120807144934.16153.qmail@stuge.se>
	<50216425.1070704@techworks.ie>
	<op.wio1x4y8vay7ep@wopr.artelis.net>
Message-ID: <50227FF3.9060001@techworks.ie>

On 08/08/12 00:23, Dimitri Stolnikov wrote:
> Hi Christian,
>

Hi Dimitri,

> could you please try the attached patch together with Peter's join
> patch? It handles async cancellation in a more graceful way.

Yes, it actually worked. thanks.

Chris

>
> The other problem (segfault on trow in ctor) still has to be addressed.
>
>
> Best regards,
> Dimitri
>
> On Tue, 07 Aug 2012 20:53:25 +0200, Christian Gagneraud
> <chris at techworks.ie> wrote:
>
>> On 07/08/12 15:49, Peter Stuge wrote:
>>> Christian Gagneraud wrote:
>>>> Please find attached the full log.
>>>
>>> Thanks!
>>>
>>>
>>>> I can provide u with a simple python program, but it will depends
>>>> on gnuradio, gr-osmosdr and you will need a compatible device
>>>> plugged in as well.
>>>
>>> No problem, but I think I find the problem.
>>>
>>>
>>>> libusb: 0.783771 debug [libusb_handle_events_timeout_completed]
>>>> doing our own event handling
>>>> libusb: 0.783793 debug [handle_events] poll() 3 fds with timeout in
>>>> 1000ms
>>>> libusb: 0.783811 debug [libusb_release_interface] interface 0
>>>> libusb: 0.785853 debug [handle_events] poll() returned 1
>>>
>>> The above lines show that the interface is released while event
>>> handling is still running. The destructor was called while the IO
>>> thread is running, and the destructor does cancel all IO, but it only
>>> waited 200 ms for the IO to complete, before it went on to close
>>> everything. Please try the attached patch for gr-osmosdr.
>>>
>>> This may or may not be the appropriate fix. This should perhaps be
>>> fixed inside rtl-sdr, or even libusb (we're already considering it)
>>> instead.
>>
>> It doesn't fix the problem alone. The script simply never exits.
>> I've just sent a patch for rtl-sdr that fix the issue.
>> I think it's still possible that a call to join() could block the app
>> forever, so maybe a longer timeout would be safer here. As well the
>> same apply for the osmosdr wrapper code.
>>
>> Chris
>>
>>>
>>>
>>> //Peter
>>>
>>


-- 
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



From horiz0n at gmx.net  Wed Aug  8 19:37:07 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Wed, 08 Aug 2012 21:37:07 +0200
Subject: Bug hunting
In-Reply-To: <50227FF3.9060001@techworks.ie>
References: <5020F84A.7080009@techworks.ie>
	<20120807135423.11594.qmail@stuge.se> <502121F6.9020304@techworks.ie>
	<20120807144934.16153.qmail@stuge.se> <50216425.1070704@techworks.ie>
	<op.wio1x4y8vay7ep@wopr.artelis.net> <50227FF3.9060001@techworks.ie>
Message-ID: <op.wiql35vovay7ep@wopr.artelis.net>

Hi Christian,

thank you for testing, i have pushed the fix to both, librtlsdr and  
libosmosdr as well as few small fixes to gr-osmosdr.


Best regards,
Dimitri



From cgommel at gmail.com  Thu Aug  9 12:13:47 2012
From: cgommel at gmail.com (Christoph Gommel)
Date: Thu, 9 Aug 2012 14:13:47 +0200
Subject: Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB Stick
	on Raspberry Pi
Message-ID: <CALv_rmxNmgm7AAAr=ybxcN9daKkpws2WnH5uwgndK3yuETwB4A@mail.gmail.com>

Hello Guys,

First of all: I am amazed by your project - many ideas come up in my
head what can be done with this tiny cheap SDR.

I have tested rtl_sdr with a linux-vm on my Mac successfully but
wanted to run it on my raspberry pi.

Unfortunately and thithout an explainable reason to me the tools
detect an E4000 instead of the soldered FC0013 on my stick - but only
on the PI.

To fix this issue I have changed the detection order in librtlsdr.c:

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 3a67b53..cb34f1d 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1073,13 +1073,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
        /* Probe tuners */
        rtlsdr_set_i2c_repeater(dev, 1);

-       reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR);
-       if (reg == E4K_CHECK_VAL) {
-               fprintf(stderr, "Found Elonics E4000 tuner\n");
-               dev->tuner_type = RTLSDR_TUNER_E4000;
-               goto found;
-       }
-
        reg = rtlsdr_i2c_read_reg(dev, FC0013_I2C_ADDR, FC0013_CHECK_ADDR);
        if (reg == FC0013_CHECK_VAL) {
                fprintf(stderr, "Found Fitipower FC0013 tuner\n");
@@ -1088,6 +1081,13 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
                goto found;
        }

+       reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR);
+       if (reg == E4K_CHECK_VAL) {
+               fprintf(stderr, "Found Elonics E4000 tuner\n");
+               dev->tuner_type = RTLSDR_TUNER_E4000;
+               goto found;
+       }
+
        /* initialise GPIOs */
        rtlsdr_set_gpio_output(dev, 5);

After compiling the lib the FC0013 is detected and the sticks works
great on my Pi.

Of course this is not a perfect solution and I will figure out later
in depth WHY the  E4K_CHECK_VAL comes out of the FC0013.

Anybody else who has or had the same problems?

the Hardware used is:
Bus 001 Device 004: ID 0ccd:00b3 TerraTec Electronic GmbH NOXON DAB/DAB+ Stick


regards

Christoph



From garym at teledyn.com  Thu Aug  9 18:05:32 2012
From: garym at teledyn.com (Gary Lawrence Murphy)
Date: Thu, 9 Aug 2012 14:05:32 -0400
Subject: just learning to fly with sdr ... and hit a 64-bit snag
Message-ID: <CAE=O9tZTSJWQeJi+TTAL_+WY9mX9qhmJRRKZMyUAEKAHG=eVug@mail.gmail.com>

First off, this is my first post to the group and I want to thank everyone
who has worked to get this kit as far as it is; I was deathly worried that
I might be stuck with unusable hardware, and it is still unusuable, but
there seems to be light at the end of the SDR tunnel and I'm hoping this is
the right forum for asking newbie questions :)

Here's where I am so far:  I have the Hama Nano DVB-T+DAB+FM with the
Elonics E4000 tuner and my goal is really very modest (I hope) in that I
only want to tune in one ordinary analog FM station, the FM transmitter in
the next room that supplies our house with music from our MP3 collection.
 Rather than pay $40 at walmart for a radio for my lab, I thought I'd spend
$20 on the USB device and have some fun in the process.

And it's been fun: I found the recipe for the rtl_fm using the alsa aplay,
and I assume the examples were concerned with some other sort of radio
(shortwave?) because the recommended 48k sampling sounded like a taxi
radio!  Not really Easy Listening sort of audio.

with some experimenting I found a formula that is still heavily distorted,
but recognizable as music:

rtl_fm -f 96.3e6 -s 192000 -l 5 -| aplay -t raw -f s16_le -r 192k -c 1

the trouble was that it wouldn't play continuously on my 3300-bogomips
netbook, so I moved the code over to my 64-bit dual-core laptop and that's
where a strange thing happened: when run as a regular user, the code aborts
giving strange (unicode?) gibberish as the device name, but when run as
root, the name is correctly reported although the program aborts.

~/Work/dev$ rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le
Found 1 device(s):
  0:  , mX??, SN: ??z
?

Using device 0: Generic RTL2832U (e.g. hama nano)
usb_open error -3
Failed to open rtlsdr device #0.

~/Work/dev$ sudo rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f
s16_le
Found 1 device(s):
  0:  Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U (e.g. hama nano)
usb_claim_interface error -6
Failed to open rtlsdr device #0.

on the 32-bit platform, the *Using device* line is followed by

Found Elonics E4000 tuner
Oversampling input by: 6x
Oversampling output by: 1x

is there perhaps some simple config setting that I've overlooked in the
64-bit box? Both are running Ubuntu 12.04

here are the kernel messages on loading the device on 64bit

Aug  9 13:47:58 strata kernel: [200306.632008] usb 3-1: new high-speed USB
device number 3 using xhci_hcd
Aug  9 13:47:58 strata kernel: [200306.663830] usb 3-1: ep 0x81 - rounding
interval to 32768 microframes, ep desc says 0 microframes
Aug  9 13:47:58 strata kernel: [200306.669822] dvb-usb: found a 'RTL2832U
DVB-T USB DEVICE' in warm state.
Aug  9 13:47:58 strata kernel: [200306.669840] dvb-usb: will pass the
complete MPEG2 transport stream to the software demuxer.
Aug  9 13:47:58 strata kernel: [200306.671500] DVB: registering new adapter
(RTL2832U DVB-T USB DEVICE)
Aug  9 13:47:58 strata kernel: [200306.689815] RTL2832U
usb_init_bulk_setting : USB2.0 HIGH SPEED (480Mb/s)
Aug  9 13:47:58 strata mtp-probe: checking bus 3, device 3:
"/sys/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1"
Aug  9 13:47:59 strata kernel: [200306.972506] RTL2832U check_tuner_type :
E4000 tuner on board...
Aug  9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device
Aug  9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter 0
frontend 0 (Realtek DVB-T RTL2832)...
Aug  9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside an
USB DVB receiver as
/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1/input/input15
Aug  9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote
query interval to 287 msecs.
Aug  9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T USB
DEVICE successfully initialized and connected.

I notice that it DOESN'T say "*will pass the complete MPEG2 transport
stream to the software demuxer"* as it does on the 32bit side.

Also, what is the syntax for the -g switch?  I have tried integers,
decimals and the string -3dB and in all cases I get the message *Warning:
Failed to set tuner gain* -- could the gain control simply be unsupported
by my device?

Lastly, I'd like to ask the hard question: are my goals here feasible?  Is
this an appropriate device for listening to FM broadcasts at the computer
or is this more a hobbyist's SDR playground and, like a dancing bear, the
bear doesn't dance amazingling, it is only amazing that the bear dances at
all ;)
-- 
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120809/ab91b0f9/attachment.htm>

From steve at steve-m.de  Thu Aug  9 18:31:24 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 09 Aug 2012 20:31:24 +0200
Subject: just learning to fly with sdr ... and hit a 64-bit snag
In-Reply-To: <CAE=O9tZTSJWQeJi+TTAL_+WY9mX9qhmJRRKZMyUAEKAHG=eVug@mail.gmail.com>
References: <CAE=O9tZTSJWQeJi+TTAL_+WY9mX9qhmJRRKZMyUAEKAHG=eVug@mail.gmail.com>
Message-ID: <502401FC.1070206@steve-m.de>

Hi,

On 09.08.2012 20:05, Gary Lawrence Murphy wrote:
> : E4000 tuner on board...
> Aug  9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device
> Aug  9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter
> 0 frontend 0 (Realtek DVB-T RTL2832)...
> Aug  9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside
> an USB DVB receiver as
> /devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1/input/input15
> Aug  9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote
> query interval to 287 msecs.
> Aug  9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T
> USB DEVICE successfully initialized and connected.

Seems like you have installed the RTL2832U kernel module, you need to
unload that first befor you can use rtl-sdr (rmmod dvb-usb).

Regards,
Steve



From garym at teledyn.com  Thu Aug  9 20:30:41 2012
From: garym at teledyn.com (Gary Lawrence Murphy)
Date: Thu, 9 Aug 2012 16:30:41 -0400
Subject: just learning to fly with sdr ... and hit a 64-bit snag
In-Reply-To: <502401FC.1070206@steve-m.de>
References: <CAE=O9tZTSJWQeJi+TTAL_+WY9mX9qhmJRRKZMyUAEKAHG=eVug@mail.gmail.com>
	<502401FC.1070206@steve-m.de>
Message-ID: <CAE=O9tYBK+w_G1Y-0vY2i=Bir=hv0+ktbvxBAqKAKeq6mKK6GA@mail.gmail.com>

Ah, thanks -- yes, that solves the problem of the driver name and the app
not running, and like so many things, makes sense once one knows about it
;) -- so one further step along the way!

On Thu, Aug 9, 2012 at 2:31 PM, Steve Markgraf <steve at steve-m.de> wrote:

> Hi,
>
>
> On 09.08.2012 20:05, Gary Lawrence Murphy wrote:
>
>> : E4000 tuner on board...
>> Aug  9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device
>> Aug  9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter
>> 0 frontend 0 (Realtek DVB-T RTL2832)...
>> Aug  9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside
>> an USB DVB receiver as
>> /devices/pci0000:00/0000:00:**1c.3/0000:09:00.0/usb3/3-1/**input/input15
>> Aug  9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote
>> query interval to 287 msecs.
>> Aug  9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T
>> USB DEVICE successfully initialized and connected.
>>
>
> Seems like you have installed the RTL2832U kernel module, you need to
> unload that first befor you can use rtl-sdr (rmmod dvb-usb).
>
> Regards,
> Steve
>



-- 
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120809/eafb4507/attachment.htm>

From steve at steve-m.de  Fri Aug 10 00:15:40 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 10 Aug 2012 02:15:40 +0200
Subject: Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB
	Stick on Raspberry Pi
In-Reply-To: <CALv_rmxNmgm7AAAr=ybxcN9daKkpws2WnH5uwgndK3yuETwB4A@mail.gmail.com>
References: <CALv_rmxNmgm7AAAr=ybxcN9daKkpws2WnH5uwgndK3yuETwB4A@mail.gmail.com>
Message-ID: <502452AC.1040502@steve-m.de>

Hi,

On 09.08.2012 14:13, Christoph Gommel wrote:
> Unfortunately and thithout an explainable reason to me the tools
> detect an E4000 instead of the soldered FC0013 on my stick - but only
> on the PI.

I could reproduce this issue on my raspberry pi and pushed a fix.
The I2C reads failed as expected at the E4K address, but due to a
uninitialized variable (which unluckily had the value 0x40 - the same
as the expected E4K check value) the tuner was mis-detected.

Regards,
Steve



From don.lewis at dses.org  Thu Aug  9 20:45:47 2012
From: don.lewis at dses.org (=?utf-8?B?ZG9uLmxld2lzQGRzZXMub3Jn?=)
Date: Thu, 09 Aug 2012 14:45:47 -0600
Subject: =?utf-8?B?UmU6IFtEaXNjdXNzLWdudXJhZGlvXSBGQ0QvQWxzYSBidWcgKFJlOiBCdWcgaHVu?=
	=?utf-8?B?dGluZyk=?=
Message-ID: <20120809204537.E2DD637A020@homiemail-a80.g.dreamhost.com>



Sent via the HTC V..b.livid?, anbURL: http://maps.google.com/maps?q=40.031769,-105.2;Kn)na?bks3213, 3128 Bell Dr, Boulder, CO 80301, USA AT&T 4G -3$/-)44+$LTE( (::,2mk:

----- Reply message -----
From: "Christian Gagneraud" <chris at techworks.ie>
To: "Dimitri Stolnikov" <horiz0n at gmx.net>
Cc: <discuss-gnuradio at gnu.org>, <osmocom-sdr at lists.osmocom.org>
Subject: [Discuss-gnuradio] FCD/Alsa bug (Re: Bug hunting)
Date: Wed, Aug 8, 2012 9:02 am


Cross posting to discuss-gnuradio.

The bug in question is that if you instanciate an alsa source on a busy device (opened by another app), then the program crashed.

On 08/08/12 00:23, Dimitri Stolnikov wrote:
> Hi Christian,
[...]
>
> The other problem (segfault on trow in ctor) still has to be addressed.

Yes, I started to investigate, and it seems to me that this is not a gr-osmosdr bug, but it's a gnuradio one, caused by gr-fcd.

This simple test program have the same problem, yet it only uses gr-fcd.

#include <iostream>
#include <fcd_source_c.h>
int main(int argc, char **argv)
{
    fcd_source_c_sptr fsrc;
    try {
	fsrc = fcd_make_source_c("hw:2"); // KO, from gr-fcd
    }
    catch (std::runtime_error &e) {
	std::cerr << "Error!\n";
    }
    exit(0);
}

g++ test.cc -o test -I/usr/local/include/gnuradio -lgnuradio-fcd

Here is the log:
audio_alsa_source[hw:2]: Device or resource busy
Error!
*** glibc detected *** /home/cgagneraud/sdr/gr-osmosdr/test: free(): invalid pointer: 0x08052e3c ***
[...]

And here is a cleaned up backtrace:
operator delete
gruel::msg_accepter::~msg_accepter
checked_delete<gr_hier_block2>
boost::detail::sp_counted_impl_p<gr_hier_block2>::dispose
[...]
const, boost::shared_ptr<gr_basic_block> > > >::~map
__cxa_finalize
__do_global_dtors_aux
[...]
main

The problem is related to gnuradio-core/src/lib/runtime/gr_sptr_magic.{h,cc} and the static std::map in there.

gr_hier_block2 ctor insert "this" in this map, but then in fcd_source ctor, audio_alsa_source ctor throws an exception, so "this" (gr_hier_block2/fcd_source) is not a valid pointer anymore.
When the program exits, the map get cleanup up and free is called on this pointer.

It's not possible to cleanup the map in fcd_source, because the dtor is not called when exception occurs in the ctor (which, btw, leads to some memory leaks in alsa_source: namely d_hw_params and d_sw_params).
It's a bad idea to call fetch_initial_sptr(this) before throwing in the ctor, because it seems the object get deleted.

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

From jsalsburg at bellsouth.net  Mon Aug 13 06:27:25 2012
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Mon, 13 Aug 2012 01:27:25 -0500
Subject: Why does this happen?
In-Reply-To: <502452AC.1040502@steve-m.de>
References: <CALv_rmxNmgm7AAAr=ybxcN9daKkpws2WnH5uwgndK3yuETwB4A@mail.gmail.com>
	<502452AC.1040502@steve-m.de>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAECIdeEphyNFgTu4aUvfLp0BAAAAAA==@bellsouth.net>

Perhaps someone can experiment with slowing down the stream of commands from
the ExtIO to the tuner Stick so it remains stable. 

After applying ExtIO to WinRAD and 2 different Tuner Sticks with the
E4000/RTL2832, the same unwanted behavior is exhibited by both.  The
unwanted behavior is the Tuner Stick crashing as reported in the ExtIO:
ezcap... Log as "While setting frequency: _I2CWriteArray:..." To get the
Tuner Stick back, I have to unplug it, quit WinRAD, plug in the Tuner Stick,
relaunch WinRAD.

This seems to be a consistent problem, not with the Tuner Stick but with the
ExtIO script. While I am not familiar with the ExtIO Script, it seems the
Tuner Stick is not able to receive wide or rapid changes in frequency.  





From jsalsburg at bellsouth.net  Mon Aug 13 13:11:54 2012
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Mon, 13 Aug 2012 08:11:54 -0500
Subject: The real problem with this thing
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>

I have been hacking into one of those $20 DVB-T TV Tuner Dongles. To get it
to tune to the Freq I want I use the usual method with the ExtIO Drivers.
The real problem with this thing, as far as making good use of the valuable
E4000, is the RTL2832, even though controlling the Tuner through the USB
requires the RTL2832. This clumsy Analog to Digital Converter / USB
interface Chip, does not have the Audio dynamic range needed for my
purposes. The infuriating predilection it has to crash every time you want
to shift frequency is another disadvantage. 
Since the Owners of the E4000 have gone into Bankruptcy, I am taking the
initiative to hack the Tuner. 
First, I attached a high gain audio amplifier's input directly to the
Tuner's output then to a 96K Sample per Second, 24 Bit Audio card to observe
a high quality spectral image from the tuner.
Next is to hack into and record the I2C sent to the Tuner, so it may be
controlled independent of that infuriating RTL2832. If anyone has done this,
please share your code and understanding.

Thanks

Jay Salsburg




From jsalsburg at bellsouth.net  Mon Aug 13 14:53:44 2012
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Mon, 13 Aug 2012 09:53:44 -0500
Subject: Say Enter "RTL readlen=524288" in the 'ExtIO : Device hint' edit
	field, when that is what you mean
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAALq8wVS1GaBFkdZOdIwUiygBAAAAAA==@bellsouth.net>

OK I get it. I wish those who write this stuff were not so Cryptic and
Acronymous. On this page ... http://wiki.spench.net/wiki/USRP_Interfaces the
author has an entry that looks like this "RTL readlen=524288" yet nowhere in
the immediate text is there any language stating to enter this text in the
'ExtIO : Device hint' edit field, you have to sort of guess the author
thoughts. No one is ever thinking like the one who is doing the original
thinking so to reproduce original thinking adequate references to what the
author is thinking is required to reproduce the original thoughts in the
reader's mind. Literate illustration makes everything so much easier (and a
liberal sprinkling screen shots).

Thanks

Jay Salsburg




From a.nielsen at shikadi.net  Mon Aug 13 23:58:41 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Tue, 14 Aug 2012 09:58:41 +1000
Subject: The real problem with this thing
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
Message-ID: <502994B1.6010409@shikadi.net>

> This clumsy Analog to Digital Converter / USB
> interface Chip, does not have the Audio dynamic range needed for my
> purposes.

That's because it's only designed for FM radio.  Anything more would have been 
overkill for the manufacturer's purposes.  This is still excellent value for 
$20 and hasn't been much of a stumbling block for what most people have been 
doing so far.

> The infuriating predilection it has to crash every time you want
> to shift frequency is another disadvantage.

I'm not sure where you're looking in the docs, but if you're using Balint's 
USRP ExtIO (as oppposed to the - I think - Osmocom ExtIO) then there are two 
sets of code for the tuner.  The default one offers slightly wider frequency 
range, but crashes as you have seen.  If you add "tuner=e4k" to the device 
hint then it will switch to the newer code, which doesn't crash, at the 
expense of having some gaps in the frequency coverage.

> First, I attached a high gain audio amplifier's input directly to the
> Tuner's output then to a 96K Sample per Second, 24 Bit Audio card to observe
> a high quality spectral image from the tuner.

Presumably this reduces your bandwidth from 3.2MHz to 96kHz, which is 24kHz 
too low to properly receive wideband/consumer FM radio.  Since many people are 
using the RTLSDR has a kind of glorified RF scanner, I am wondering whether 
you're trying to do something you really should be doing on a high end device 
like the USRP?

> Next is to hack into and record the I2C sent to the Tuner, so it may be
> controlled independent of that infuriating RTL2832. If anyone has done this,
> please share your code and understanding.

Don't quote me on this but AFAIK the RTL just passes the I2C commands through 
unchanged.  This is how the existing E4000 tuner code was able to be adapted 
to the RTL2832 so quickly.

This list probably isn't the best place to ask about this sort of thing - it's 
mostly developers focused on improving the hardware rather than getting people 
started with it.  I strongly recommend switching to the ultra-cheap-sdr 
list[1] instead, which has many more people able to help beginners.  Your 
question about the device crashing is answered quite often, for example. 
These people can also point you to the many 'getting started' guides, which do 
explain clearly with screenshots where to put device hints and the like.

Cheers,
Adam.

[1] https://groups.google.com/d/forum/ultra-cheap-sdr (you can subscribe via 
e-mail here if you don't want to use the web interface)



From garym at teledyn.com  Tue Aug 14 03:39:14 2012
From: garym at teledyn.com (Gary Lawrence Murphy)
Date: Mon, 13 Aug 2012 23:39:14 -0400
Subject: The real problem with this thing
In-Reply-To: <502994B1.6010409@shikadi.net>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
	<502994B1.6010409@shikadi.net>
Message-ID: <CAE=O9tbCJs2=Q1xGbw5+-rgWuRqfiZXk2v_apAhXfjMVMftHHg@mail.gmail.com>

so it is *designed* for FM?  That's encouraging because mostly that is all
I really need from it, only all my experiments so far have yielded only
AM-quality sound, but it's good to hear because it means there's *hope* and
so I'll just keep hanging in there until an FM recipe surfaces :)

On Mon, Aug 13, 2012 at 7:58 PM, Adam Nielsen <a.nielsen at shikadi.net> wrote:

> This clumsy Analog to Digital Converter / USB
>> interface Chip, does not have the Audio dynamic range needed for my
>> purposes.
>>
>
> That's because it's only designed for FM radio.  Anything more would have
> been overkill for the manufacturer's purposes.  This is still excellent
> value for $20 and hasn't been much of a stumbling block for what most
> people have been doing so far.
>
>  The infuriating predilection it has to crash every time you want
>> to shift frequency is another disadvantage.
>>
>
> I'm not sure where you're looking in the docs, but if you're using
> Balint's USRP ExtIO (as oppposed to the - I think - Osmocom ExtIO) then
> there are two sets of code for the tuner.  The default one offers slightly
> wider frequency range, but crashes as you have seen.  If you add
> "tuner=e4k" to the device hint then it will switch to the newer code, which
> doesn't crash, at the expense of having some gaps in the frequency coverage.
>
>  First, I attached a high gain audio amplifier's input directly to the
>> Tuner's output then to a 96K Sample per Second, 24 Bit Audio card to
>> observe
>> a high quality spectral image from the tuner.
>>
>
> Presumably this reduces your bandwidth from 3.2MHz to 96kHz, which is
> 24kHz too low to properly receive wideband/consumer FM radio.  Since many
> people are using the RTLSDR has a kind of glorified RF scanner, I am
> wondering whether you're trying to do something you really should be doing
> on a high end device like the USRP?
>
>  Next is to hack into and record the I2C sent to the Tuner, so it may be
>> controlled independent of that infuriating RTL2832. If anyone has done
>> this,
>> please share your code and understanding.
>>
>
> Don't quote me on this but AFAIK the RTL just passes the I2C commands
> through unchanged.  This is how the existing E4000 tuner code was able to
> be adapted to the RTL2832 so quickly.
>
> This list probably isn't the best place to ask about this sort of thing -
> it's mostly developers focused on improving the hardware rather than
> getting people started with it.  I strongly recommend switching to the
> ultra-cheap-sdr list[1] instead, which has many more people able to help
> beginners.  Your question about the device crashing is answered quite
> often, for example. These people can also point you to the many 'getting
> started' guides, which do explain clearly with screenshots where to put
> device hints and the like.
>
> Cheers,
> Adam.
>
> [1] https://groups.google.com/d/**forum/ultra-cheap-sdr<https://groups.google.com/d/forum/ultra-cheap-sdr>(you can subscribe via e-mail here if you don't want to use the web
> interface)
>
>


-- 
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120813/2c479ac1/attachment.htm>

From a.nielsen at shikadi.net  Tue Aug 14 03:44:11 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Tue, 14 Aug 2012 13:44:11 +1000
Subject: The real problem with this thing
In-Reply-To: <CAE=O9tbCJs2=Q1xGbw5+-rgWuRqfiZXk2v_apAhXfjMVMftHHg@mail.gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
	<502994B1.6010409@shikadi.net>
	<CAE=O9tbCJs2=Q1xGbw5+-rgWuRqfiZXk2v_apAhXfjMVMftHHg@mail.gmail.com>
Message-ID: <5029C98B.1080606@shikadi.net>

> so it is /designed/ for FM?  That's encouraging because mostly that is all I
> really need from it, only all my experiments so far have yielded only
> AM-quality sound, but it's good to hear because it means there's /hope/ and so
> I'll just keep hanging in there until an FM recipe surfaces :)

Yes, because the dongles provide digital TV (via hardware) and as an extra 
selling point, analogue FM radio (provided via the SDR.)

I don't know what platform you're on or what your goals are, but I hear the 
SDR# program for Windows offers excellent stereo FM support, as it's one of 
the few programs that can deal with the ~120kHz bandwidth needed for a WBFM 
signal.

Cheers,
Adam.




From garym at teledyn.com  Tue Aug 14 12:13:31 2012
From: garym at teledyn.com (Gary Lawrence Murphy)
Date: Tue, 14 Aug 2012 08:13:31 -0400
Subject: The real problem with this thing
In-Reply-To: <5029C98B.1080606@shikadi.net>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
	<502994B1.6010409@shikadi.net>
	<CAE=O9tbCJs2=Q1xGbw5+-rgWuRqfiZXk2v_apAhXfjMVMftHHg@mail.gmail.com>
	<5029C98B.1080606@shikadi.net>
Message-ID: <CAE=O9tacU69UpTBGd=+KECKjJEJ681cWa-kWu7cDk97_ZChiOg@mail.gmail.com>


From a.nielsen at shikadi.net  Wed Aug 15 01:13:24 2012
From: a.nielsen at shikadi.net (Adam Nielsen)
Date: Wed, 15 Aug 2012 11:13:24 +1000
Subject: The real problem with this thing
In-Reply-To: <CAE=O9tacU69UpTBGd=+KECKjJEJ681cWa-kWu7cDk97_ZChiOg@mail.gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
	<502994B1.6010409@shikadi.net>
	<CAE=O9tbCJs2=Q1xGbw5+-rgWuRqfiZXk2v_apAhXfjMVMftHHg@mail.gmail.com>
	<5029C98B.1080606@shikadi.net>
	<CAE=O9tacU69UpTBGd=+KECKjJEJ681cWa-kWu7cDk97_ZChiOg@mail.gmail.com>
Message-ID: <502AF7B4.5000606@shikadi.net>

>  From what I understand, the digital TV standard here in Canada is different
> from DVB-T (I am a complete neophyte at all of this) and so that particular
> feature of the device won't be of much use to me, but as for the FM, I'm on
> the Ubuntu/Linux GNU platform, so I'm awaiting on the kindness of strangers to
> perfect the kernel drivers enough to match the Windows kit performance. But
> that's okay, because I'm learning a lot in the process :)

The DVB-T option isn't much use to anyone, because we all bought the device 
for SDR purposes :-)  No disrespect, but wanting to use the device just for FM 
radio is a bit of a waste - you have the Swiss Army Knife of radio receivers, 
but you only want to use the corkscrew?

Just for the record, there are no kernel drivers for the SDR side of things, 
it's all done in userspace.  This userspace code, developed by people on this 
list, is designed to operate under Linux and it then gets ported to Windows. 
So luckily for you, running Linux means you'll always have easy access to the 
latest userspace driver code, before it gets to Windows.

Unfortunately so much SDR software is Windows only, especially the packages 
aimed at beginners like myself, who don't know enough about RF yet to get any 
GNURadio flow graphs working.

Personally the best I have done so far is to run HDSDR under Wine, and use the 
Linux BorIP server to pass data (via loopback TCP) between Wine and the RTL 
device.  This allows HDSDR to run pretty much the same as it does under Windows.

But of course HDSDR can't quite do FM radio (since it only goes up to 96kHz), 
but it does work really well for receiving other NBFM and AM broadcasts 
(police, aircraft, etc.)

Cheers,
Adam.




From garym at teledyn.com  Wed Aug 15 02:20:23 2012
From: garym at teledyn.com (Gary Lawrence Murphy)
Date: Tue, 14 Aug 2012 22:20:23 -0400
Subject: The real problem with this thing
In-Reply-To: <502AF7B4.5000606@shikadi.net>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAABIdKr3BFZJGr1awiR7ivgkBAAAAAA==@bellsouth.net>
	<502994B1.6010409@shikadi.net>
	<CAE=O9tbCJs2=Q1xGbw5+-rgWuRqfiZXk2v_apAhXfjMVMftHHg@mail.gmail.com>
	<5029C98B.1080606@shikadi.net>
	<CAE=O9tacU69UpTBGd=+KECKjJEJ681cWa-kWu7cDk97_ZChiOg@mail.gmail.com>
	<502AF7B4.5000606@shikadi.net>
Message-ID: <CAE=O9tZ=aywVAhBspCd1f51BHhjyDq-PpXF_-_RVdJmKRhDs_g@mail.gmail.com>

heh ... well it may be a waste, but it was an honest waste: it was the
cheapest PC-USB FM radio offered on an ebay auction ($14 shipping included)
and I'd already tried several USB-cable FM radios that turned out to be
completely useless for various reasons, and even wal-mart can't sell a
decent FM radio these days for even twice that price, so it seemed like a
reasonable gamble, and as it is, I've now (a) discovered the whole SDR
phenomenon and (b) learned that I might someday get FM, CB, police and
weather all from this one device that as it turns out, I didn't really need
because pulseaudio can do what I originally needed.

so I'm not complaining, I'm just looking in on wide-eyed naivity bewildered
by the great vistas that now open before me :)

and now you'll have to excuse me, I'm off to google HDSDR :)

On Tue, Aug 14, 2012 at 9:13 PM, Adam Nielsen <a.nielsen at shikadi.net> wrote:

>  From what I understand, the digital TV standard here in Canada is
>> different
>> from DVB-T (I am a complete neophyte at all of this) and so that
>> particular
>> feature of the device won't be of much use to me, but as for the FM, I'm
>> on
>> the Ubuntu/Linux GNU platform, so I'm awaiting on the kindness of
>> strangers to
>> perfect the kernel drivers enough to match the Windows kit performance.
>> But
>> that's okay, because I'm learning a lot in the process :)
>>
>
> The DVB-T option isn't much use to anyone, because we all bought the
> device for SDR purposes :-)  No disrespect, but wanting to use the device
> just for FM radio is a bit of a waste - you have the Swiss Army Knife of
> radio receivers, but you only want to use the corkscrew?
>
> Just for the record, there are no kernel drivers for the SDR side of
> things, it's all done in userspace.  This userspace code, developed by
> people on this list, is designed to operate under Linux and it then gets
> ported to Windows. So luckily for you, running Linux means you'll always
> have easy access to the latest userspace driver code, before it gets to
> Windows.
>
> Unfortunately so much SDR software is Windows only, especially the
> packages aimed at beginners like myself, who don't know enough about RF yet
> to get any GNURadio flow graphs working.
>
> Personally the best I have done so far is to run HDSDR under Wine, and use
> the Linux BorIP server to pass data (via loopback TCP) between Wine and the
> RTL device.  This allows HDSDR to run pretty much the same as it does under
> Windows.
>
> But of course HDSDR can't quite do FM radio (since it only goes up to
> 96kHz), but it does work really well for receiving other NBFM and AM
> broadcasts (police, aircraft, etc.)
>
> Cheers,
> Adam.
>
>
>


-- 
*Have Blog, Will Travel: blog.teledyn.com*
*A Serviceable Substitute: post.teledyn.com*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120814/7d51548f/attachment.htm>

From friedtj at free.fr  Fri Aug 17 06:35:02 2012
From: friedtj at free.fr (friedtj at free.fr)
Date: Fri, 17 Aug 2012 08:35:02 +0200 (CEST)
Subject: RTL2832U: 7 or 8-bits ?
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAALq8wVS1GaBFkdZOdIwUiygBAAAAAA==@bellsouth.net>
Message-ID: <1077072837.79890795.1345185302812.JavaMail.root@zimbra9-e2.priv.proxad.net>

quick question concerning the RTL2832U ADC: is it 7 bit (as
stated on the Realtek web page in the cryptic "7-bit ADC for 
RF signals level measurement" or 8-bit as stated on the osmosdr
web page ? or is it 7 bit + sign = 8 bits ?

I am computing the gain from oversampling wrt a sound card, and
not that it matters much but I'd rather have the figures right.

Thanks, JM



From 246tnt at gmail.com  Fri Aug 17 06:43:01 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 17 Aug 2012 08:43:01 +0200
Subject: RTL2832U: 7 or 8-bits ?
In-Reply-To: <1077072837.79890795.1345185302812.JavaMail.root@zimbra9-e2.priv.proxad.net>
References: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAALq8wVS1GaBFkdZOdIwUiygBAAAAAA==@bellsouth.net>
	<1077072837.79890795.1345185302812.JavaMail.root@zimbra9-e2.priv.proxad.net>
Message-ID: <CAHL+j0-WbhYJgzSmj5=zLicVLDp80Cc2basV9H6vE75tPFHhFw@mail.gmail.com>

Hi,

> quick question concerning the RTL2832U ADC: is it 7 bit (as
> stated on the Realtek web page in the cryptic "7-bit ADC for
> RF signals level measurement" or 8-bit as stated on the osmosdr
> web page ? or is it 7 bit + sign = 8 bits ?

8 bits AFAIK.

The "7-bit ADC for RF signals level measurement" is most likely just
an RSSI measurement ADC.


Cheers,

    Sylvain



From friedtj at free.fr  Fri Aug 17 07:09:24 2012
From: friedtj at free.fr (friedtj at free.fr)
Date: Fri, 17 Aug 2012 09:09:24 +0200 (CEST)
Subject: gr-osmosdr disable RTL2832U AGC ?
In-Reply-To: <CAHL+j0-WbhYJgzSmj5=zLicVLDp80Cc2basV9H6vE75tPFHhFw@mail.gmail.com>
Message-ID: <1520580519.79939504.1345187364740.JavaMail.root@zimbra9-e2.priv.proxad.net>

another question:
all my attempts at recording signals from satellites (NOAA POES
weather satellites and ISS) have so far failed. For NOAA, I can
sometimes get a faint signal, but nothing worth decoding to get
a weather map (even with a 25 dB LNA preamp). Now, I have found
one web page (cannot remember where) associating the poor
receiver sensitivity to the RTL2832U DAGC. I remember seeing on this
list that someone had managed to disable this DAGC, but is this
functionality avaiable in the gnuradio gr-osmosdr block ? As an
option provided to the gr-osmosdr block ? should the DAGC value be
set to some specific value then ? Or kept at minimum value ?

Thanks, JM



From steve at steve-m.de  Fri Aug 17 08:30:52 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 17 Aug 2012 10:30:52 +0200
Subject: RTL2832U: 7 or 8-bits ?
In-Reply-To: <1077072837.79890795.1345185302812.JavaMail.root@zimbra9-e2.priv.proxad.net>
References: <1077072837.79890795.1345185302812.JavaMail.root@zimbra9-e2.priv.proxad.net>
Message-ID: <502E013C.8070102@steve-m.de>

Hi,

On 17.08.2012 08:35, friedtj at free.fr wrote:
> quick question concerning the RTL2832U ADC: is it 7 bit (as
> stated on the Realtek web page in the cryptic "7-bit ADC for
> RF signals level measurement" or 8-bit as stated on the osmosdr
> web page ? or is it 7 bit + sign = 8 bits ?

8 bit, the "7-bit ADC for RF signals level measurement" is the RSSi-ADC
than can be used to measure the signal power as reported by some tuners.

Regards,
Steve




From steve at steve-m.de  Fri Aug 17 08:36:20 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Fri, 17 Aug 2012 10:36:20 +0200
Subject: gr-osmosdr disable RTL2832U AGC ?
In-Reply-To: <1520580519.79939504.1345187364740.JavaMail.root@zimbra9-e2.priv.proxad.net>
References: <1520580519.79939504.1345187364740.JavaMail.root@zimbra9-e2.priv.proxad.net>
Message-ID: <502E0284.5010303@steve-m.de>

Hi,

On 17.08.2012 09:09, friedtj at free.fr wrote:
> all my attempts at recording signals from satellites (NOAA POES
> weather satellites and ISS) have so far failed. For NOAA, I can
> sometimes get a faint signal, but nothing worth decoding to get
> a weather map (even with a 25 dB LNA preamp). Now, I have found
> one web page (cannot remember where) associating the poor
> receiver sensitivity to the RTL2832U DAGC. I remember seeing on this
> list that someone had managed to disable this DAGC, but is this
> functionality avaiable in the gnuradio gr-osmosdr block ?

The DAGC is disabled by default in current librtlsdr, so if you use a 
recent version you should have no problems.
In fact, my reception was fine when I tried it (even without LNA).

See http://rof.li/pic/groundplane/

Regards,
Steve




From friedtj at free.fr  Fri Aug 17 13:17:14 2012
From: friedtj at free.fr (friedtj at free.fr)
Date: Fri, 17 Aug 2012 15:17:14 +0200 (CEST)
Subject: gr-osmosdr disable RTL2832U AGC ?
In-Reply-To: <502E0284.5010303@steve-m.de>
Message-ID: <1317648662.80385475.1345209434386.JavaMail.root@zimbra9-e2.priv.proxad.net>

wonderful pictures. What NFM settings do you use ? surprisingly I had better
results with excessively narrow settings (5 kHz bandpass, 1 kHz cutoff bandwidth)
compared to the expected 45 to 50 kHz wide setting expected for this mode. I am
leaving mid-september for some remote northern area and would love to take the EZCAP
with me to demonstrate satellite reception using lightweight equipment (as opposed
to a dedicated receiver + car battery).

JM


----- Mail original -----
De: "Steve Markgraf" <steve at steve-m.de>
?: osmocom-sdr at lists.osmocom.org
Envoy?: Vendredi 17 Ao?t 2012 10:36:20
Objet: Re: gr-osmosdr disable RTL2832U AGC ?

Hi,

On 17.08.2012 09:09, friedtj at free.fr wrote:
> all my attempts at recording signals from satellites (NOAA POES
> weather satellites and ISS) have so far failed. For NOAA, I can
> sometimes get a faint signal, but nothing worth decoding to get
> a weather map (even with a 25 dB LNA preamp). Now, I have found
> one web page (cannot remember where) associating the poor
> receiver sensitivity to the RTL2832U DAGC. I remember seeing on this
> list that someone had managed to disable this DAGC, but is this
> functionality avaiable in the gnuradio gr-osmosdr block ?

The DAGC is disabled by default in current librtlsdr, so if you use a 
recent version you should have no problems.
In fact, my reception was fine when I tried it (even without LNA).

See http://rof.li/pic/groundplane/

Regards,
Steve





From laforge at gnumonks.org  Fri Aug 17 19:36:13 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Aug 2012 21:36:13 +0200
Subject: [jarribas@cttc.es: GNSS-SDR now supports the RTLSDR signal source]
Message-ID: <20120817193613.GO29525@prithivi.gnumonks.org>

Hi all!

I'm forwarding this announcement from the GNSS-SDR developers.  I will
also put it on the sdr.osmocom.org site.

Congratulations to steve-m, horizon, hoernchen and the team!

Regards,
	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)
-------------- next part --------------
An embedded message was scrubbed...
From: =?ISO-8859-1?Q?Javier_Arribas_L=E1zaro?= <jarribas at cttc.es>
Subject: GNSS-SDR now supports the RTLSDR signal source
Date: Fri, 17 Aug 2012 21:09:35 +0200
Size: 31791
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120817/8a36d2aa/attachment.eml>

From laforge at gnumonks.org  Tue Aug 21 06:57:47 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 21 Aug 2012 08:57:47 +0200
Subject: [benzandstra@caiway.nl: Small comment about the rtl-sdr wiki]
Message-ID: <20120821065747.GZ16295@prithivi.gnumonks.org>

FYI,
-- 
- 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: Ben Zandstra <benzandstra at caiway.nl>
Subject: Small comment about the rtl-sdr wiki
Date: Tue, 07 Aug 2012 20:15:29 +0200
Size: 3058
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120821/38528666/attachment.eml>

From james at peroulas.com  Tue Aug 21 20:44:58 2012
From: james at peroulas.com (James Peroulas)
Date: Tue, 21 Aug 2012 15:44:58 -0500
Subject: LTE Cell Scanner
Message-ID: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>

I just released an LTE cell scanner based on the rtlsdr library. If
you're interested, the code is available on github:
https://github.com/Evrytania/LTE-Cell-Scanner

This code will search for all the LTE cells in your area and will also
report the frequency error of your dongle.

BR,
James

P.S. Many thanks for the rtlsdr library!

-- 
Integrity is a binary state - either you have it or you don?t. - John Doerr



From horiz0n at gmx.net  Tue Aug 21 22:39:51 2012
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Wed, 22 Aug 2012 00:39:51 +0200
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <op.wjew8pa8vay7ep@wopr.artelis.net>

Hi James,

> I just released an LTE cell scanner based on the rtlsdr library. If
> you're interested, the code is available on github:
> https://github.com/Evrytania/LTE-Cell-Scanner

This is exciting stuff, thank you for sharing! I had to change few lines  
(patch attached) for it to compile on my system, not sure it is the proper  
way, though.

> This code will search for all the LTE cells in your area and will also
> report the frequency error of your dongle.

Works for me, found one carrier so far.


Best regards,

Dimitri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltescan.patch
Type: text/x-diff
Size: 930 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120822/afd4b7d3/attachment.bin>

From friedtj at free.fr  Wed Aug 22 06:37:42 2012
From: friedtj at free.fr (friedtj)
Date: Wed, 22 Aug 2012 08:37:42 +0200
Subject: ACARS decoder for rtl-sdr
In-Reply-To: <op.wjew8pa8vay7ep@wopr.artelis.net>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
	<op.wjew8pa8vay7ep@wopr.artelis.net>
Message-ID: <20120822083742.0805cc56@dhcp-221.lpmo.priv>

I have just uploaded to

http://jmfriedt.free.fr/gr-acars.tar.gz

the first version of the ACARS message decoder I have written for gnuradio operating with
RTL-compatible dongles. I have included an example directory with a WAV file for testing the
decoder, and the log of last night's reception.
The decoder is far from perfect, but I think it behaves no worse than the sound-card based 
decoder I have used (e.g kracars and wacars). It is also, to the best of my knowledge, the
only opensource ACARS decoder since acarsdec does not seem functional (at least not with the
provided example file), so someone might find it useful, and maybe even inspiring for
improvement.

I hope to learn by next week to add parameter passing from grc to the C++ program so that
two parameters -- the log file which is currently hardcoded to be located in /tmp/log_file.txt,
and a threshold value which is currently hardcoded but should be user-tunable (or ideally
automagically adapted to received power levels, but so far such attempts have failed) -- can be
provided through the gnuradio-companion interface. This will provide a minor update of the archive.

This is my very first attempt at grc block programming, so any feedback is welcome. I have
updated the manuscript describing the development method -- still in French unfortunately,
hoping to translate to English sometimes in the coming month -- and uploaded the PDF
document at http://jmfriedt.free.fr/lm_sdr.pdf for any French speaking audience to comment on.

Jean-Michel

-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France



From alexander.chemeris at gmail.com  Wed Aug 22 06:15:42 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Wed, 22 Aug 2012 10:15:42 +0400
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <CABmJbFVKqAZOqDwFWMAAQ5gajPtFH-ibcDtHi96WOYOb-r+BHQ@mail.gmail.com>

Hi James,

Very interesting code. I have to try to run it here - I know we have
few LTE carriers around.

Have you seen this project which is going in a similar direction?
http://sourceforge.net/p/openlte/home/Home/

On Wed, Aug 22, 2012 at 12:44 AM, James Peroulas <james at peroulas.com> wrote:
> I just released an LTE cell scanner based on the rtlsdr library. If
> you're interested, the code is available on github:
> https://github.com/Evrytania/LTE-Cell-Scanner
>
> This code will search for all the LTE cells in your area and will also
> report the frequency error of your dongle.
>
> BR,
> James
>
> P.S. Many thanks for the rtlsdr library!
>
> --
> Integrity is a binary state - either you have it or you don?t. - John Doerr
>



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From james at peroulas.com  Wed Aug 22 13:15:37 2012
From: james at peroulas.com (James Peroulas)
Date: Wed, 22 Aug 2012 08:15:37 -0500
Subject: LTE Cell Scanner
In-Reply-To: <CABmJbFVKqAZOqDwFWMAAQ5gajPtFH-ibcDtHi96WOYOb-r+BHQ@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
	<CABmJbFVKqAZOqDwFWMAAQ5gajPtFH-ibcDtHi96WOYOb-r+BHQ@mail.gmail.com>
Message-ID: <CA+XcqA5HS-bbPpo9SkLmQt+_xXaLgjGkCjA-rwiVzgwZPf4_dA@mail.gmail.com>

Thanks everyone for all the initial comments and feedback! I've
updated the code to fix the two small problems that were reported to
me.

> Have you seen this project which is going in a similar direction?
> http://sourceforge.net/p/openlte/home/Home/

Actually, I've exchanged a few emails with Ben and his code helped me
with several parts of my code. I've now added a link back to his
project in the README.

BR,
James



From benryanau at hotmail.com  Wed Aug 22 14:00:25 2012
From: benryanau at hotmail.com (Ben Ryan)
Date: Thu, 23 Aug 2012 00:00:25 +1000
Subject: BONANZA - The e4000 *complete* reference document :)
Message-ID: <SNT139-W3254665698832A3D393E70B6BF0@phx.gbl>



Hey all,
Got some gold for ya's. Registers, the works. Even a reference design schematic.
Grab it while it's hot, before the lawyers catch on.. and thanks guys for all your hard work with RTLSDR!

https://skydrive.live.com/redir?resid=E55F3F5F75B5A7BB!1160
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20120823/18a68363/attachment.htm>

From christian.buchner at gmail.com  Fri Aug 24 16:11:59 2012
From: christian.buchner at gmail.com (Christian Buchner)
Date: Fri, 24 Aug 2012 18:11:59 +0200
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <CALm6U+pZd8Ufmu1UCOQ_+0ebMc_joDOh9_dFW0g=1QW=M2p02A@mail.gmail.com>

I was able to build it on Ubuntu 9.04 (Jaunty Jackalope) with a little
upgrading of some dependencies.

CellSearch is now crashing in the static initializer for the
ROM_TABLES object. *sigh*

Would anyone have an idea what may be is causing it?

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb773b910 (LWP 21087)]
0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from
/usr/local/lib/libitpp.so.7
Current language:  auto; currently asm
(gdb) where
#0  0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from
/usr/local/lib/libitpp.so.7
#1  0x00f74ada in itpp::Vec<std::complex<double> >::operator= () from
/usr/local/lib/libitpp.so.7
#2  0x0808b0cd in PSS_fd::PSS_fd ()
#3  0x08094444 in global constructors keyed to ROM_TABLES ()

Christian



From cgommel at gmail.com  Sat Aug 25 08:47:52 2012
From: cgommel at gmail.com (Christoph Gommel)
Date: Sat, 25 Aug 2012 10:47:52 +0200
Subject: RTL_FM fails on OS X
Message-ID: <CALv_rmwqPRwUPMxzp+g77OZun8=4sQbLzciNGENYQ1gVYMMXtQ@mail.gmail.com>

Hello,

I was completely happy that rtl-sdr builds without any problems in my
iMac (with OSX 10.8.1 and latest Macports).

Using a RLT2832-Dongle that is plugged into my mac on other machines
via rtl_tcp works well, also recording data is working.

What fails is running rtl_fm:

iGommel:build chg$ rtl_fm -f 97300000 -s 44100 test.raw
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000291

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Elonics E4000 tuner
Oversampling input by: 23x.
Oversampling output by: 1x.
Buffer size: 8.08ms
Tuned to 97553575 Hz.
Sampling at 1014300 Hz.
Exact sample rate is: 1014300.020041 Hz
Tuner gain set to -1.00 dB.
Floating point exception: 8

Unfortunately i don't have the debugging skills to find the position
of the Floating point exception without a high-level GUI ;)

Any idea what can be done by me to help chasing the bug?

Christoph



From james at peroulas.com  Sun Aug 26 02:11:10 2012
From: james at peroulas.com (James Peroulas)
Date: Sat, 25 Aug 2012 21:11:10 -0500
Subject: osmocom-sdr Digest, Vol 9, Issue 16
In-Reply-To: <mailman.5.1345888803.29189.osmocom-sdr@lists.osmocom.org>
References: <mailman.5.1345888803.29189.osmocom-sdr@lists.osmocom.org>
Message-ID: <CA+XcqA4HBts1C=fJBuVuZtvzytKk8x80auX8rg9=RYq0ebRvyQ@mail.gmail.com>

> Message: 1
> Date: Fri, 24 Aug 2012 18:11:59 +0200
> From: Christian Buchner <christian.buchner at gmail.com>
> To: osmocom-sdr at lists.osmocom.org
> Subject: Re: LTE Cell Scanner
> Message-ID:
>         <CALm6U+pZd8Ufmu1UCOQ_+0ebMc_joDOh9_dFW0g=1QW=M2p02A at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I was able to build it on Ubuntu 9.04 (Jaunty Jackalope) with a little
> upgrading of some dependencies.
>
> CellSearch is now crashing in the static initializer for the
> ROM_TABLES object. *sigh*
>
> Would anyone have an idea what may be is causing it?
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb773b910 (LWP 21087)]
> 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from
> /usr/local/lib/libitpp.so.7
> Current language:  auto; currently asm
> (gdb) where
> #0  0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from
> /usr/local/lib/libitpp.so.7
> #1  0x00f74ada in itpp::Vec<std::complex<double> >::operator= () from
> /usr/local/lib/libitpp.so.7
> #2  0x0808b0cd in PSS_fd::PSS_fd ()
> #3  0x08094444 in global constructors keyed to ROM_TABLES ()
>
> Christian

Are you still having problems with this? Can you try upgrading to the
latest github code? I changed the initialization sequence for the
ROM_TABLES and it might fix your problem too.

BR,
James



From christian.buchner at gmail.com  Mon Aug 27 08:54:10 2012
From: christian.buchner at gmail.com (Christian Buchner)
Date: Mon, 27 Aug 2012 10:54:10 +0200
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <CALm6U+qy2Z2EsBfnaXCS1SE-KC=yxG4kQupA1ShOmEabJqt82w@mail.gmail.com>

Maybe this is a n00b question, but what am I doing wrong when I try to
access the git repository?

git clone https://github.com/Evrytania/LTE-Cell-Scanner.git
Initialized empty Git repository in
/home/buchner/lte_scan/LTE-Cell-Scanner/.git/
fatal: https://github.com/Evrytania/LTE-Cell-Scanner.git/info/refs
download error - The requested URL returned error: 403

Fortunately I can download the tarball as well, but it's more work to
keep in sync with the repository.

Christian



From christian.buchner at gmail.com  Mon Aug 27 09:10:44 2012
From: christian.buchner at gmail.com (Christian Buchner)
Date: Mon, 27 Aug 2012 11:10:44 +0200
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <CALm6U+pvnYgYJdLCVoZv0f_R7ZGjYZf9-7Be05V2wYaf0einCg@mail.gmail.com>

Now I am really close, the latest fix for ROM_TABLES did the trick!
I am having an issue with tuning the frequency, following the PLL not
locked messages.

Is this also happening to anyone else? The rtl_test tool also shows
the same messages,
but I also see other people's forum postings who run the rtl-sdr
software successfully, even
with this kind of error message appearing.

# CellSearch --freq-start 791e6 --freq-end 821e6
LTE CellSearch v0.1.0 (release) beginning
  Search frequency range: 791-821 MHz
  PPM: 100
  correction: 1
Found Elonics E4000 tuner
[E4K] PLL not locked for 791000000 Hz!
Error: unable to set center frequency


# rtl_test -t
Found 1 device(s):
  0:  Terratec T Stick PLUS

Using device 0: Terratec T Stick PLUS
Found Elonics E4000 tuner
Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0
21.5 24.0 29.0 34.0 42.0
Benchmarking E4000 PLL...
[E4K] PLL not locked for 51000000 Hz!
[E4K] PLL not locked for 2175000000 Hz!
[E4K] PLL not locked for 1088000000 Hz!
[E4K] PLL not locked for 1232000000 Hz!
E4K range: 52 to 2174 MHz
E4K L-band gap: 1088 to 1232 MHz



From christian.buchner at gmail.com  Mon Aug 27 10:27:21 2012
From: christian.buchner at gmail.com (Christian Buchner)
Date: Mon, 27 Aug 2012 12:27:21 +0200
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <CALm6U+oRLobj-SF7ZSU0XstCs74MaVgoP7tvhxFGaWhciRctnA@mail.gmail.com>

For some reason, your CellSearch software worked the second time I ran
it. Here's the result for a scan in Munich. The two frequencies found
correspond to the operators O2 and Vodafone. Deutsche Telekom is
either not using the 800 MHz band here, or I happen to be out of the
reception range for this dongle.

Detected the following cells:
C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
449    796M -13.2k -47.7 N  50 N one 0.99998344473785039099
372    806M -13.2k -43.7 N  50 N one 0.99998362964129883235

This software project is way cool! I am surprised how precise my crystal is.

Now who's willing to extend the code to combine several dongles to
scan the full 10 MHz band and to analyze the allocated resources
signalled on the PDCCH so we can generate statistics on cell load and
number of UEs served?

Christian



From christian.buchner at gmail.com  Tue Aug 28 10:18:55 2012
From: christian.buchner at gmail.com (Christian Buchner)
Date: Tue, 28 Aug 2012 12:18:55 +0200
Subject: LTE Cell Scanner
In-Reply-To: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
References: <CA+XcqA75jRqUUa27cQxb=_P-YfWAVcs20imvO68duKcfOW6YiA@mail.gmail.com>
Message-ID: <CALm6U+ot23ojHkGXBNyELxex3hfP_E1Eyy=9Gg8hAVykz2uUhQ@mail.gmail.com>

A couple of suggestions for improvement of this tool:

- detect and report number of Tx antennas used by each cell (1,2 or
4). This should be detectable from the CRC part of the MIB.
- report whether the LTE system uses TDD or FDD.

I am surprised that today I find 4 cells on 796 MHz and 5 cells on 806
MHz. I did not expect this dongle to be so sensitive.

Detected the following cells:
C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
388    796M   369h   -44 N  50 N one 0.99998386356929225283
449    796M   349h   -48 N  50 N one 0.9999838380560712725
389    796M   358h -48.3 N  50 N one 0.99998384936395678935
 52    796M   359h -49.2 N  50 N one 0.99998385073518580857

Detected the following cells:
C: CP type ; P: PHICH duration ; PR: PHICH resource type
CID      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
108    806M   359h -42.3 N  50 N one 0.999983844979292269
372    806M   255h -42.9 N  50 N one 0.99998371629218352208
109    806M   215h -44.1 N  50 N one 0.99998366727140031163
235    806M   244h -44.6 N  50 N one 0.9999837021424591299
365    806M   849h   -48 N  50 N one 0.99998445366580002158

I would now like to log the received power for each cell ID in a log
file, and later plot it. I am interested how this power changes over
time, especially under varying weather conditions.

Christian



From james at peroulas.com  Tue Aug 28 20:10:06 2012
From: james at peroulas.com (James Peroulas)
Date: Tue, 28 Aug 2012 15:10:06 -0500
Subject: LTE Cell Scanner
Message-ID: <CA+XcqA4K8fvf=cZtUnSKhuayHMhVfkjw1XtXkRtK=g7rQnkPHw@mail.gmail.com>

> Date: Mon, 27 Aug 2012 12:27:21 +0200
> From: Christian Buchner <christian.buchner at gmail.com>
>
> For some reason, your CellSearch software worked the second time I ran
> it. Here's the result for a scan in Munich. The two frequencies found
> correspond to the operators O2 and Vodafone. Deutsche Telekom is
> either not using the 800 MHz band here, or I happen to be out of the
> reception range for this dongle.
>
> Detected the following cells:
> C: CP type ; P: PHICH duration ; PR: PHICH resource type
> CID      fc   foff RXPWR C nRB P  PR CrystalCorrectionFactor
> 449    796M -13.2k -47.7 N  50 N one 0.99998344473785039099
> 372    806M -13.2k -43.7 N  50 N one 0.99998362964129883235

I see that the received signal power is very low at -44dB, so it kind
of makes sense that these cells would not be detected every time you
run the program. I suspect that if you moved outdoors or used a tuned
LTE antenna, these cells would be detectable more reliably.

> This software project is way cool! I am surprised how precise my crystal is.
>
> Now who's willing to extend the code to combine several dongles to
> scan the full 10 MHz band and to analyze the allocated resources
> signalled on the PDCCH so we can generate statistics on cell load and
> number of UEs served?

Wow, I think that would be a major undertaking for these dongles! I
think that's a task best suited for the USRP and the OpenLTE project
:)

JP



From cgommel at gmail.com  Thu Aug 30 22:11:05 2012
From: cgommel at gmail.com (Christoph Gommel)
Date: Fri, 31 Aug 2012 00:11:05 +0200
Subject: Fixed a division by zero bug in rtl_fm that appears on OS X
Message-ID: <CALv_rmyz4iAJNMsqEF7rr7mnUMiZqeuBcHfkD2-rtsRmRXyaiA@mail.gmail.com>

Hallo guys,

I tried to isolate the Floating point exception that prevents rtl_fm
from running on my OS X Machine. XCode's code analysis mechanism
showed pointed out a location of some code that not only might bring
up a division by zero but brought this on my machine.
After adding some basic handling rtl_fm runs now on my Mac but does
not deliver appropiate sound. It's chopped and not understandable.
Despite the fact that gnuradio performs great on the same machine
there seem to be more bugs present I do not understand at the moment.

But first of all this small patch should be added to the main code base.

Sorry for not knowing more about git than executing "git diff" ;( I am
a daily svn user who does not understand the non-linear anarchistic
version management behind git by now...

diff --git a/src/rtl_fm.c b/src/rtl_fm.c
index 0350d8b..d00ef2d 100644
--- a/src/rtl_fm.c
+++ b/src/rtl_fm.c
@@ -313,13 +313,17 @@ int mad(int *samples, int len, int step)
        int i=0, sum=0, ave=0;
        for (i=0; i<len; i+=step) {
                sum += samples[i];
-       }
-       ave = sum / (len * step);
+       }
+       if (len * step) //Avoid Division by zero errors
+               ave = sum / (len * step);
        sum = 0;
        for (i=0; i<len; i+=step) {
                sum += abs(samples[i] - ave);
-       }
-       return sum / (len * step);
+       }
+       if (len * step) //Avoid Division by zero errors
+               return sum / (len * step);
+       else
+               return (0);
 }

 int post_squelch(struct fm_state *fm)