Re: [Discuss-gnuradio] Porting cgran AIS to the new cmake build system

On Sun, Aug 5, 2012 at 10:14 AM, Christian Gagneraud <address@hidden> wrote:

On 18/07/12 18:21, Nick Foster wrote:

Take a look at gr-air-modes for details on how I did it there.
gr-osmosdr follows the UHD API for the most part, so a lot of it drops
in pretty easily. I'm not going to pull in a patch which makes the
receiver depend on gr-osmosdr, but I'm happy to have a command-line
option (or even autodetect) for gr-osmosdr support for FCD and RTL.

Hi Nick,

I managed to get gr-ais working both with FCD and RTL using gr-osmosdr.
The changes to gr-ais are really straight forward.
Can you tell me why you don't want dependency on gr-osmosdr? As you said, this driver follows the UHD API, so it is very easy to use it in place of the UHD one, with the added advantage of supporting other hardware.
So using osmosdr would make the code cleaner and allow support for other hardware, but adding an option/autodetection will just add useless boilerplate.

It effectively adds an unnecessarily dependency on gr-osmosdr for UHD users. The required boilerplate is pretty minimal; since the interfaces are essentially identical, you can just wrap the import in a try/except and use gr-osmosdr if available, gr-uhd otherwise. You need the rest of the boilerplate anyway to handle the different sample rate requirements of the different dongles.

Anyway, I just found that Antoine Sirinelli already added basic support for rtl-sdr, although not tested: https://github.com/asirinelli/gr-ais
I'm gonna test it, but he's at least missing the decimation filter change (RTL can't sample at 256KHz, so I used 1.024MHz with a decimation filter factor of 16)

I haven't tried AIS on RTL at all, and I expect there to be some
filtering/LO offset tuning required to achieve decent results on it.

I don't know how decent are my results with RTL (at least as good as with FCD, but definitely not as good as a real AIS receiver), but the only "tunning" I did was to use the right sampling rate (wrong sampling rate gives you a frequency shift) and of course the the frequency correction (107 ppm in my case).

Recent versions of gr-ais incorporate a reasonably robust frequency estimator based on the square-and-FFT method. It works "okay" for GMSK modulations, especially for strong signals. There are smarter things you can do that someday I hope to have the time to implement. =) At any rate, it should have a reasonably large capture bandwidth. 17kHz (107ppm at 162MHz) might be stretching those limits, though. That's pretty bad. You sure they're not using, like, a clarinet reed as a frequency reference?

--n

Chris

--n

On Wed, Jul 18, 2012 at 2:49 AM, Christian Gagneraud <address@hidden
<mailto:address@hidden>> wrote:

On 18/07/12 09:13, Darren Long wrote:

Hi Chris,

Might I be so bold to suggest that in your efforts, you consider
using
the gr-osmosdr abstraction
(http://sdr.osmocom.org/trac/__wiki/GrOsmoSDR
<http://sdr.osmocom.org/trac/wiki/GrOsmoSDR>)

so that the RTL-SDR could be used too. In fact it supports UHD,
FCD and
RTL-SDR, and works well in gqrx for example.

Hi,

That sounds interesting, actually, that was on my plan to try the
RTL hardware once I'm happy enough. If i'm not wrong this RTL is the
related to the chip found on some cheap DVB receiver, isn't it?

AFAIU, the ais_rx.py script is half about setting up UHD, and half
about the decoding itself.
I just had a look at gr-osmosdr, and it seems so far quite straight
forward to use.

Nick has just updated his git repo with the cmake branch. I'll give
it a try tonight.

Nick, do you have any thought on this? It would be really nice to
get ais_rx.py be usable with different hardware.

Chris

Sorry for being cheeky :P

You wasn't, it sounds like a good idea indeed!

Chris

Darren

On 17/07/12 22:43, Christian Gagneraud wrote:

On 17/07/12 22:24, Nick Foster wrote:

Christian,

Are you using the version found here?

https://github.com/bistromath/__gr-ais

<https://github.com/bistromath/gr-ais>

If not, please use this version, as it is significantly
more up-to-date
than the one on CGRAN. I'm going to change the CGRAN
page to point to
the Github repository.

Interesting.

Would you be interested in getting it ported to the new
build system?
If so, I'll redo the work on your tree.
As well, I realised that ais_received.py is tailored for the
USRP.
I'm currently using a funcube dongle, so I might as well
contribute
with a dedicated script, once i start to get things working.

Chris

--n

On Tue, Jul 17, 2012 at 1:42 PM, Christian Gagneraud
<address@hidden <mailto:address@hidden>
<mailto:address@hidden <mailto:address@hidden>>>

wrote:

On 17/07/12 21:31, Josh Blum wrote:

On 07/17/2012 01:27 PM, Christian Gagneraud wrote:

Hi,

I tried to build
https://cgran.org/wiki/AIS against
gnuradio-3.6, and i
fails.
As 3.6 brings in a new build system, I
decided to give it a
go on the
AIS module. I based everything on
gr-howto-write-a-block

[...]

ImportError:

/usr/local/lib/python2.7/site-____packages/ais/_ais_swig.so:

undefined symbol: _Z14ais_make_shiftv

Just a guess, but

In gnuradio we explicitly export the library
symbols. If you
arent doing
that for libgnuradioais, make sure that the
visibility flag is
being set
to default. You can read more here:
http://gcc.gnu.org/wiki/____Visibility
<http://gcc.gnu.org/wiki/__Visibility>

<http://gcc.gnu.org/wiki/__Visibility
<http://gcc.gnu.org/wiki/Visibility>>

Hi Josh,

Actually, I've just discovered this was needed!
So, yes that was it.
No it's complaining about usrp stuff, but it's
another story. I
don't have a USRP, I'm using a FUNcube dongle.

BTW, should I make this package install in
lib/python2.7/site-packages/____gnuradio/ais
instead of
lib/python2.7/site-packages/____ais

Same with the include dir: include/gnuradio/ais
instead of
include/ais?

I would like to be able to use gnuradio-companion,
and pick up the
AIS block from the selection list, but it's not
there. This might be
due to the current install dir. Any comment?

Chris

-josh

___________________________________________________

Discuss-gnuradio mailing list
address@hidden
<mailto:address@hiddenorg>
<mailto:address@hidden__org
<mailto:address@hiddenorg>>
https://lists.gnu.org/mailman/____listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio>

<https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>

--
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>
<tel:%2B%20353%20%280%29%201%__20236%205990>
Web: http://www.techworks.ie/

___________________________________________________

Discuss-gnuradio mailing list
address@hidden
<mailto:address@hiddenorg>
<mailto:address@hidden__org
<mailto:address@hiddenorg>>
https://lists.gnu.org/mailman/____listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio>

<https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>>

_________________________________________________
Discuss-gnuradio mailing list
address@hidden <mailto:address@hiddenorg>
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>

--
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:	Nick Foster
Subject:	Re: [Discuss-gnuradio] Porting cgran AIS to the new cmake build system
Date:	Sun, 5 Aug 2012 14:18:55 -0700