gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Space removal problems in AIS messages


From: Jon Schlueter
Subject: Re: [gpsd-dev] Space removal problems in AIS messages
Date: Sat, 3 Oct 2015 08:04:24 -0400

fix pushed to master

Jon

On Sat, Oct 3, 2015 at 5:03 AM, Stefan Roels <address@hidden> wrote:
Jon,

I found out what happened with that last message. It was the second part of a type 24 message. I checked my input data for the first message.

Please apply the following patch to fix this:


diff --git a/test/daemon/ais_unpack_sixbit.log b/test/daemon/ais_unpack_sixbit.log
index 6f0fe5f..f459024 100644
--- a/test/daemon/ais_unpack_sixbit.log
+++ b/test/daemon/ais_unpack_sixbit.log
@@ -16,5 +16,5 @@
 !AIVDM,1,1,,B,ENk`sBG37a:@address@hidden,0*6C
 !AIVDM,1,1,,B,C6:W26h00:address@hidden,0*71
 !AIVDM,1,1,,B,C6:kuiP0021mUQSCHwAvKwk2>bB>2L?0>2L>`2C1iik0S38351P7,0*06
+!AIVDM,1,1,,A,H7lca<@P5<qE9w3F22222222220,2*2F
 !AIVDM,1,1,,A,H7lca<DlPPPPPPPI4koloP1h>550,0*0E
-
diff --git a/test/daemon/ais_unpack_sixbit.log.chk b/test/daemon/ais_unpack_sixbit.log.chk
index e8c5f32..450390a 100644
--- a/test/daemon/ais_unpack_sixbit.log.chk
+++ b/test/daemon/ais_unpack_sixbit.log.chk
@@ -27,4 +27,6 @@

{"class":"AIS","type":19,"repeat":0,"mmsi":413778459,"scaled":false,"reserved":0,"speed":0,"accuracy":true,"lon":72108276,"lat":19162033,"course":697,"heading":69,"second":60,"regional":0,"shipname":"YUXINHUO10388","shiptype":70,"shiptype_text":"Cargo - all ships of this type","to_bow":66,"to_stern":12,"to_port":5,"to_starboard":6,"epfd":0,"epfd_text":"Undefined","raim":false,"dte":1,"assigned":false}
 !AIVDM,1,1,,B,C6:kuiP0021mUQSCHwAvKwk2>bB>2L?0>2L>`2C1iik0S38351P7,0*06

{"class":"AIS","type":19,"repeat":0,"mmsi":413990342,"scaled":false,"reserved":0,"speed":0,"accuracy":false,"lon":68072131,"lat":13853684,"course":2022,"heading":511,"second":38,"regional":1,"shipname":"GUIGANG GANGTAI 889","shiptype":70,"shiptype_text":"Cargo - all ships of this type","to_bow":50,"to_stern":6,"to_port":10,"to_starboard":3,"epfd":0,"epfd_text":"Undefined","raim":false,"dte":0,"assigned":false}
+!AIVDM,1,1,,A,H7lca<@P5<qE9w3F22222222220,2*2F
 !AIVDM,1,1,,A,H7lca<DlPPPPPPPI4koloP1h>550,0*0E
+{"class":"AIS","type":24,"repeat":0,"mmsi":525003057,"scaled":false,"shipname":"HASNUR_05","shiptype":52,"shiptype_text":"Tug","vendorid":"","model":8,"serial":133152,"callsign":"YD3747","to_bow":14,"to_stern":14,"to_port":5,"to_starboard":5}


Regards,
Stefan


On 03-10-15 04:18, Jon Schlueter wrote:
Stefan,

Looks clean

I staged a patch for master here

https://github.com/yazug/gpsd/commit/8bfa8424af815d4d4f3606b657df9925b73d1469

can you please review this change I was able to generate what I think
was clean output that matched the sample data you provided but the last
test case didn't seem to come through, so not sure what happened there.

any feedback or input would be appreciated.

Jon


On Fri, Oct 2, 2015 at 1:22 AM, Stefan Roels
<address@hidden <mailto:address@hidden>>

wrote:

    Dear All,

    I am currently working on a AIS message decoder (AIVDM/AIVDO) for a
    project at work. Rather than using the existing gpsd library, I am
    writing my own decoder. I am using the
    http://catb.org/gpsd/AIVDM.html documentation as guideling for my
    decoder and I use the gpsdecoder output for validation purposes,
    confirming that my decoder provides the same results. Obviously,
    most of the problems I am running into are due to my own mistakes,
    but I am also running into some problems that seem to be on the gpsd
    side.

    One of these problems has to do with the removal of spaces at the
    end of the six bits ascii strings. According to the documentation,
    the following steps should be taken:
    - Remove everything from the first @ sign (including the @ sign itself)
    - Strip trailing spaces from the result

    The existing code however fails to do so properly in certain
    circumstances.

    Consider the following scenarios (all assuming count = 20, e.g. type
    5 field shipname):
    1) The input string: "ALPHA @@@@@@@@@@@@@@" (single space before
    first @ character)
    The from_sixbit function will take i from 0 up to and including 6,
    where it will see the @ and break. to[6] will then be set to \0. Now
    the second part of the algorithm kicks in and starts at i=18. I
    could not find where the field was initialised, so I am not sure
    whether the field would be zero-filled, @ or space filled or random
    junk, but in any case either we find spaces or @ signs until we
    reach i=6, or we break at i>6. This would leave us with:
    "ALPHA \0..." The space at to[5] will not be cleared.
    2) The input string: "ALPHA BRAVO CHARLIE " (single space at the end)
    The from_sixbit function will take i from 0 up to and including 20,
    the break condition of the for loop will be met and we set to[20] to
    \0. At that moment we get to the second part of the algorithm which
    would look at to[18] which is 'E' and break without removing the
    trailing space.
    3) The input string: "ALPHA BRAVO CHARLI E" (space as character
    before the last one)
    The from_sixbit function will take i from 0 up to and including 20,
    the break condition of the for loop will be met and we set to[20] to
    \0. At that moment we get to the second part of the algorithm which
    would look at to[18] which is ' ' and will replace it with a \0,
    dropping the E at the end.


    Another spacing problem lies within the type 21 name/name extension
    field. If the name field would be trimmed, but there is data in the
    name extension field, the name extension would not be taken into
    account. Take for instance the following examples:
    name:"ALPHA BRAVO CHARLI E" name extension:"CHO" (assuming the
    incorrect space removal) result: "ALPHA BRAVO CHARLI" instead of
    "ALPHA BRAVO CHARLI ECHO"
    name:"ALPHA BRAVO CHARLIE " name extension:"DELTA" (assuming removal
    of the trailing space of name) result "ALPHA BRAVO CHARLIE" instead
    of "ALPHA BRAVO CHARLIE DELTA"

    I have created a patch to solve the problems mentioned above. You
    can find the patch and some examples of real world messages going
    wrong below.

    Best regards,
    Stefan Roels



    !AIVDM,2,1,7,B,53aDpaT000010;CKKB0h4Q8TpLDr222222222216<P:656rd07Tai0CKk5hD,0*74
      !AIVDM,2,2,7,B,Q1C`8888880,2*63
    -"callsign":"PB4664 "
    +"callsign":"PB4664"
    @@ -61,12 +61,12 @@

    !AIVDM,2,1,2,B,address@hidden>1=Dq8U<F222220V1pR847<:0<hCDm1DQ0CH8888,0*0B
      !AIVDM,2,2,2,B,8888882,2*27
    -"callsign":"PE6851 "
    +"callsign":"PE6851"
      !AIVDM,2,1,2,B,address@hidden;address@hidden<P4m0Ttr0O10C,0*5D
      !AIVDM,2,2,2,B,2640Ht043lU30CQ8888888888880,2*06
    -"shipname":"WILLAMETTE CHAMPION "
    +"shipname":"WILLAMETTE CHAMPION"

    !AIVDM,2,1,9,A,53<@V;@220A8E8qF2204hU`F2222222222222216000004I1093SmSlSlljF,0*68
      !AIVDM,2,2,9,A,address@hidden,2*06
    -"destination":"NOVOROSSIYSK;RUSSIA "
    +"destination":"NOVOROSSIYSK;RUSSIA"
      !AIVDM,2,1,5,B,ENk`sBG37a:@address@hidden,0*1A
      !AIVDM,2,2,5,B,000003vP08=P,0*50
    -"name":"FORT PIERCE INLET LB"
    +"name":"FORT PIERCE INLET LB 6"

    !AIVDM,2,1,0,1,53aI9sl000010WCC;@1LTh`t000000000000001S0h;41vqa00PCDm1DQ0CO,0*55
      !AIVDM,2,2,0,1,`8800000000,2*04
    -"destination":"AMSTERDAM>   "
    +"destination":"AMSTERDAM>"
      !AIVDM,1,1,,A,address@hidden@address@hidden<Mh0,2*4A
    -"name":"HILLSBRGH CUT C CH"
    +"name":"HILLSBRGH CUT C CH LB 17"

    !AIVDM,2,1,5,B,53aC2TT000010GK;address@hidden@T62220000001?78825w?os0K`88888888,0*4A
      !AIVDM,2,2,5,B,88888888800,2*2A
    -callsign":"PE6235 ","shipname":"DILIGENTIA    "
    +callsign":"PE6235","shipname":"DILIGENTIA"
      !AIVDM,1,1,,B,ENk`sBG37a:@address@hidden,0*6C
    -"name":"FORT PIERCE INLET LB"
    +"name":"FORT PIERCE INLET LB 6"
      !AIVDM,1,1,,B,C6:W26h00:address@hidden,0*71
    -"shipname":"YUXINHUO10388 "
    +"shipname":"YUXINHUO10388"
      !AIVDM,1,1,,B,C6:kuiP0021mUQSCHwAvKwk2>bB>2L?0>2L>`2C1iik0S38351P7,0*06
    -"shipname":"GUIGANG GANGTAI 889 "
    +"shipname":"GUIGANG GANGTAI 889"
      !AIVDM,1,1,,A,H7lca<DlPPPPPPPI4koloP1h>550,0*0E
    -"callsign":"YD3747 "
    +"callsign":"YD3747"


    diff --git a/driver_ais.c b/driver_ais.c
    index 953d352..4f488ce 100644
    --- a/driver_ais.c
    +++ b/driver_ais.c
    @@ -26,7 +26,7 @@
       * Parse the data from the device
       */

    -static void from_sixbit(unsigned char *bitvec, uint start, int
    count, char *to)
    +static void from_sixbit_untrimmed(unsigned char *bitvec, uint
    start, int count, char *to)
      /* beginning at bitvec bit start, unpack count sixbit characters */
      {
          const char sixchr[64] =
    @@ -43,14 +43,29 @@ static void from_sixbit(unsigned char *bitvec,
    uint start, int count, char *to)
                 to[i] = newchar;
          }
          to[i] = '\0';
    -    /* trim spaces on right end */
    -    for (i = count - 2; i >= 0; i--)
    -       if (to[i] == ' ' || to[i] == '@')
    -           to[i] = '\0';
    -       else
    -           break;
      }

    +static void trim_spaces_on_right_end(char* to)
    +/* trim spaces on right end */
    +{
    +       int i;
    +       for (i = strlen(to) - 1; i >= 0; i--)
    +               if (to[i] == ' ' || to[i] == '@')
    +                       to[i] = '\0';
    +               else
    +                       break;
    +}
    +
    +static void from_sixbit(unsigned char *bitvec, uint start, int
    count, char *to)
    +/* beginning at bitvec bit start, unpack count sixbit characters
    and remove trailing
    + * spaces */
    +{
    +       from_sixbit_untrimmed(bitvec, start, count, to);
    +       trim_spaces_on_right_end(to);
    +}
    +
    +
    +
      bool ais_binary_decode(const struct gpsd_errout_t *errout,
                            struct ais_t *ais,
                            const unsigned char *bits, size_t bitlen,
    @@ -870,7 +885,7 @@ bool ais_binary_decode(const struct
    gpsd_errout_t *errout,
          case 21:   /* Aid-to-Navigation Report */
             RANGE_CHECK(272, 360);
             ais->type21.aid_type = UBITS(38, 5);
    -       from_sixbit((unsigned char *)bits,
    +       from_sixbit_untrimmed((unsigned char *)bits,
                         43, 20, ais->type21.name <http://type21.name>);
             ais->type21.accuracy     = UBITS(163, 1);
             ais->type21.lon          = SBITS(164, 28);
    @@ -889,6 +904,7 @@ bool ais_binary_decode(const struct
    gpsd_errout_t *errout,
             //ais->type21.spare      = UBITS(271, 1);
             if (strlen(ais->type21.name <http://type21.name>) == 20 &&
    bitlen > 272)
                 ENDCHARS(272, ais->type21.name <http://type21.name>+20);
    +       trim_spaces_on_right_end(ais->type21.name <http://type21.name>);
             break;
          case 22:   /* Channel Management */
             PERMISSIVE_LENGTH_CHECK(168)




reply via email to

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