discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] One problem with gr-ais for 3.7 (Re: Recommended gr-a


From: Andy Walls
Subject: [Discuss-gnuradio] One problem with gr-ais for 3.7 (Re: Recommended gr-ais repo/branch/commit for GnuRadio 3.7.x (latest git) and UHD 3.7.1?)
Date: Tue, 13 May 2014 11:34:14 -0400


On Fri, 2014-04-25 at 17:22 -0400, Andy Walls wrote:
[snip]
> > On Fri, Apr 25, 2014 at 2:14 PM, Andy Walls
> > <address@hidden> wrote:
> >         Hi.
> >         
> >         What is the recommended gr-ais repo/branch/commit that yields
> >         a working
> >         gr-ais with GnuRadio 3.7.x (git commit
> >         3831dd37c8df19e25fa258db4d393ee068889dae)
> >         and the Ettus UHD 3.7.1
> >         
> >         GitHub shows this fork network:
> >         https://github.com/bistromath/gr-ais/network
> >         
> >         Right now I'm using bistromath/gr-ais commit
> >         754c13ca4f1c3fb0d079d3a42002b0dade2268ff
> >         (master HEAD, IIRC), but I'm not getting *any* !AIVDM output
> >         to the terminal window.

Well, I've identified one problem.

The "unstuff" operation is being applied before the correlator for the
start flag of 01111110 (0x7e).  The start flag, end flag, and preamble
are not subject to bit stuffing per ITU-R M.1371-4 Annex 2 Sections
3.2.2.1 through 3.2.2.4.

I suspect this causes a problem with proper detection of the start of
the message, as the unstuff, as I understand it, will change the start
flag from 01111110 to 0111110m, where m is the first bit of the message
payload.

Putting the unstuff operation after the correlators doesn't fix
everything though.  All potential message decodes still fail the CRC
check.

Bypassing the CRC check and inspecting the output !AIVDMs with gpsdecode
verifies they are junk. :(

Regards,
Andy





reply via email to

[Prev in Thread] Current Thread [Next in Thread]