Porting cgran AIS to the new cmake build system

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

I can build and install everything, here is what get installed:
cgagneraud@pluton:~/Downloads/gr-ais-ng/build> sudo make install
[ 22%] Built target gnuradio-ais
[ 27%] Built target _ais_swig_swig_tag
[ 31%] Built target _ais_swig_doc_tag
[ 54%] Built target _ais_swig
[ 81%] Built target pygen_swig_a8cc0
[ 90%] Built target pygen_python_a8569
[100%] Built target pygen_apps_4b161
Linking CXX shared module CMakeFiles/CMakeRelink.dir/_ais_swig.so
Install the project…

– Install configuration: “Release”

– Up-to-date: /usr/local/include/ais/ais_unstuff.h
– Up-to-date: /usr/local/include/ais/ais_shift.h
– Up-to-date: /usr/local/include/ais/ais_parse.h
– Up-to-date: /usr/local/include/ais/ais_invert.h
– Up-to-date: /usr/local/include/ais/ais_extended_lms_dfe_ff.h
– Up-to-date: /usr/local/lib/libgnuradio-ais.so
– Installing: /usr/local/lib/python2.7/site-packages/ais/_ais_swig.so
– Installing: /usr/local/lib/python2.7/site-packages/ais/ais_swig.py
– Installing: /usr/local/lib/python2.7/site-packages/ais/ais_swig.pyc
– Installing: /usr/local/lib/python2.7/site-packages/ais/ais_swig.pyo
– Installing: /usr/local/include/ais/swig/ais_swig.i
– Up-to-date: /usr/local/include/ais/swig/ais_swig_doc.i
– Up-to-date: /usr/local/lib/python2.7/site-packages/ais/init.py
– Up-to-date: /usr/local/lib/python2.7/site-packages/ais/init.pyc
– Up-to-date: /usr/local/lib/python2.7/site-packages/ais/init.pyo
– Up-to-date: /usr/local/bin/ais_decode.py
– Up-to-date: /usr/local/bin/ais_demod.py

But now, if I want to test one of the “app”, this is what i get:
cgagneraud@pluton:~/Downloads/gnuradio-3.6.0> ais_decode.py
Traceback (most recent call last):
File “/usr/local/bin/ais_decode.py”, line 13, in
import ais
File “/usr/local/lib/python2.7/site-packages/ais/init.py”, line
46, in
from ais_swig import *
File “/usr/local/lib/python2.7/site-packages/ais/ais_swig.py”, line
26, in
_ais_swig = swig_import_helper()
File “/usr/local/lib/python2.7/site-packages/ais/ais_swig.py”, line
22, in swig_import_helper
_mod = imp.load_module(‘_ais_swig’, fp, pathname, description)
ImportError: /usr/local/lib/python2.7/site-packages/ais/_ais_swig.so:
undefined symbol: _Z14ais_make_shiftv

I have the same result if i try to “import ais” within a python console.

now ldd tells me that:
cgagneraud@pluton:~/Downloads/gnuradio-3.6.0> ldd
/usr/local/lib/python2.7/site-packages/ais/_ais_swig.so
linux-gate.so.1 => (0xffffe000)
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0
(0xb75c4000)
libgnuradio-ais.so => /usr/local/lib/libgnuradio-ais.so
(0xb75bb000)
libgruel-3.6.0.so.0.0.0 =>
/usr/local/lib/libgruel-3.6.0.so.0.0.0 (0xb7580000)
libgnuradio-core-3.6.0.so.0.0.0 =>
/usr/local/lib/libgnuradio-core-3.6.0.so.0.0.0 (0xb73c7000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb72d8000)
libm.so.6 => /lib/libm.so.6 (0xb72ad000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb728f000)
libc.so.6 => /lib/libc.so.6 (0xb7122000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7107000)
libdl.so.2 => /lib/libdl.so.2 (0xb7102000)
libutil.so.1 => /lib/libutil.so.1 (0xb70fd000)
libboost_date_time.so.1.46.1 =>
/usr/lib/libboost_date_time.so.1.46.1 (0xb70ec000)
libboost_program_options.so.1.46.1 =>
/usr/lib/libboost_program_options.so.1.46.1 (0xb708c000)
libboost_filesystem.so.1.46.1 =>
/usr/lib/libboost_filesystem.so.1.46.1 (0xb706e000)
libboost_system.so.1.46.1 => /usr/lib/libboost_system.so.1.46.1
(0xb706a000)
libboost_thread.so.1.46.1 => /usr/lib/libboost_thread.so.1.46.1
(0xb7051000)
libfftw3f.so.3 => /usr/lib/libfftw3f.so.3 (0xb6efe000)
librt.so.1 => /lib/librt.so.1 (0xb6ef5000)
libvolk.so.0.0.0 => /usr/local/lib/libvolk.so.0.0.0
(0xb6dfb000)
/lib/ld-linux.so.2 (0xb7798000)

And a dirty grep for the symbol gives:
cgagneraud@pluton:~/Downloads/gr-ais-ng/build> grep _Z14ais_make_shiftv
/usr/local/lib/libgnuradio-ais.so
/usr/local/lib/python2.7/site-packages/ais/_ais_swig.so
Binary file /usr/local/lib/libgnuradio-ais.so matches
Binary file /usr/local/lib/python2.7/site-packages/ais/_ais_swig.so
matches

So, /lib/python2.7/site-packages/ais/_ais_swig.so really depends on
/usr/local/lib/libgnuradio-ais.so (which is, I guess, where the missing
symbol is). but python can’t load the module due to unresolved symbol…

Note: I have /usr/local/lib in my LD_LIBRARY_PATH and
/usr/local/lib/python2.7/site-packages/ in my PYTHONPATH

The only change in the source code I had to do was to replace in
ais_decode.py:
from gnuradio import ais
with:
import ais

Does anyone has an idea on what is goin on here? I certainly did
something wrong, or fogot something, but I can’t see it.

Regards,
Chris


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

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

[ 27%] Built target _ais_swig_swig_tag
– Up-to-date: /usr/local/include/ais/ais_parse.h
– Up-to-date: /usr/local/lib/python2.7/site-packages/ais/init.pyc
46, in
from ais_swig import *
File “/usr/local/lib/python2.7/site-packages/ais/ais_swig.py”, line
26, in
_ais_swig = swig_import_helper()
File “/usr/local/lib/python2.7/site-packages/ais/ais_swig.py”, line
22, in swig_import_helper
_mod = imp.load_module(‘_ais_swig’, fp, pathname, description)
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: Visibility - GCC Wiki

-josh

On 17/07/12 21:31, Josh B. wrote:

On 07/17/2012 01:27 PM, Christian G. 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: Visibility - GCC Wiki

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
[email protected]
Discuss-gnuradio Info Page


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

On 07/17/2012 01:42 PM, Christian G. wrote:

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?

It should just be a matter of setting the desired install directory in
the CMakeLists.txt

On 17/07/12 22:24, Nick F. wrote:

Christian,

Are you using the version found here?

GitHub - bistromath/gr-ais: Automatic Information System decoder for shipborne position reporting for the Gnuradio project

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

    On 07/17/2012 01:27 PM, Christian G. wrote:
[...]
    that for libgnuradioais, make sure that the visibility flag is
don't have a USRP, I'm using a FUNcube dongle.
Chris
    https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
Co. Dublin
<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>


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

Christian,

Are you using the version found here?

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.

–n

Hi Chris,

Might I be so bold to suggest that in your efforts, you consider using
the gr-osmosdr abstraction (GrOsmoSDR - gr-osmosdr - Open Source Mobile Communications)
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.

Sorry for being cheeky :stuck_out_tongue:

Darren

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.

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.

–n

On 18/07/12 18:21, Nick F. 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.

Anyway, I just found that Antoine Sirinelli already added basic support
for rtl-sdr, although not tested: GitHub - asirinelli/gr-ais: Automatic Information System decoder for shipborne position reporting for the Gnuradio project
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).

Chris

    Might I be so bold to suggest that in your efforts, you consider

it a try tonight.

        On 17/07/12 22:24, Nick F. wrote:
            than the one on CGRAN. I'm going to change the CGRAN
        USRP.
            On Tue, Jul 17, 2012 at 1:42 PM, Christian G.
                          Hi,

                      In gnuradio we explicitly export the library

                  lib/python2.7/site-packages/____gnuradio/ais
                  due to the current install dir. Any comment?
              ___________________________________________________

            <tel:%2B%20353%20%280%29%201%20236%205990>
            <mailto:[email protected]>>

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 G.,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/

On 18/07/12 09:13, Darren L. wrote:

Hi Chris,

Might I be so bold to suggest that in your efforts, you consider using
the gr-osmosdr abstraction (GrOsmoSDR - gr-osmosdr - Open Source Mobile Communications)
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 :stuck_out_tongue:

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

Chris

with a dedicated script, once i start to get things working.

 On 17/07/12 21:31, Josh B. wrote:
         As 3.6 brings in a new build system, I decided to give it a
     Just a guess, but
 Hi Josh,

     -josh
 Christian G.,

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page


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

On Sun, Aug 5, 2012 at 10:14 AM, Christian G.
[email protected]wrote:

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.

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