| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
...messages - AIVDM.txt
|
| | |
|
| | |
|
| |
|
|
|
| |
gpsd now compiles, and runs scons check, with no warnings on
FreeBSD.
|
| |
|
|
| |
vsnprintf() and strlcmp() are happier now.
|
| | |
|
| |
|
|
| |
uint is now unsigned int.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
saw in live data type=1 records with length of 163
right after 168 with same data payload except for
padding bits
type=1 length=163
!AIVDM,1,1,,A,13aIkM@P00PJ@qPNL=e@0?wJ28JO,5*63
1|0|244740981|0|-128|0|1|3442480|31919541|0|511|45|0x0|1|0x434
type=1 length=168
!AIVDM,1,1,,A,13aIkM@P00PJ@qPNL=e@0?wJ28JO,0*66
1|0|244740981|0|-128|0|1|3442480|31919541|0|511|45|0x0|1|0x869f
This could make sense for re-broadcast data but
there may be other issues with type=1,2,3 because the message
lengths vary from 163 up to 700 some bits long and logic
only parses first 168 bits
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Full parsing not guarenteed but it at least parses more of
the data that is pressent for several of these messages
there are 28 bits not being processed out of this message
but it doesn't match up with the 12+4+3+11=30 bits that
the repeated data set is currently using
Looks like other messages of type 20 have data in the
last 28 bits but it's not decoded anywhere right now
186 bits long
!AIVDM,1,1,,2,D02E34iFTg6D000000000000002gjG2,0*75
20|0|002442003|1385|2|7|1125|0|0|0|0|0|0|0|0|0|0|0|0
186 bits long
!AIVDM,1,1,,2,D02=VVA8`N?`>4N01L=Nfp1>AA0,0*75
20|0|002320025|1162|1|7|250|225|1|7|0|1475|5|7|750|19|9|0|1296
shorter
!AIVDM,1,1,,A,D028rqP<QNfp000000000000000,2*0C
20|0|002243302|200|5|7|750|0|0|0|0|0|0|0|0|0|0|0|0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found a live sample that was not handled
right by the ais driver for type=16
max size had to be increased to 168 bits from 144
this looks sane as the samples of this type of message
as follows shows that the increment1, mmsi2, offset2,
and increment2 have a value.
It also matches results from http://www.aggsoft.com/ais-decoder.htm
test/sample.aivdm.js.chk
42:{"class":"AIS","device":"stdin","type":16,"repeat":0,"mmsi":2053501,"scaled":true,"mmsi1":224251000,"offset1":200,"increment1":0,"mmsi2":0,"offset2":0,"increment2":0}
92:{"class":"AIS","device":"stdin","type":16,"repeat":0,"mmsi":439952844,"scaled":true,"mmsi1":315920,"offset1":2049,"increment1":681,"mmsi2":230137673,"offset2":424,"increment2":419}
|
| |
|
|
|
| |
had to extend check to include extra size
Also tweaked devtools/ais.py
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Type 8, DAC = 1 FID = 16: This should only be decoded as "Persons on board" if the message length is either 72 or 136 bits long (if even then).
- Type 8, DAC = 1 FID = 16: If decoded, the json output should use the ais->type8.dac1fid16.persons field and not the type6 field
Was not able to locate entry that had persons actually populated in AISHub sample data file
added sample data that should not be decoded to sample.aivdm
had to regenerate large sample file as it had multiple entries for this
Identified by: Stefan Roels <sroels-gpsd-dev@42solutions.nl>
type 8 dac 1 fid 16 can have either data or persons
had to add logic to detect structured vs not structured for type 8 FID 16 messages
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I ran into a problem with the type 8 unstructured data. When the number
of bits available is not dividable by 8, the last byte may contain
random bits. I would expect the bits beyond the valid range to be 0.
An example of this can be found in the following message:
!AIVDM,3,1,4,A,85PH6TAKfDOkp95`nCRt5w<:qFUiaihFhBc7s4AHGsQ,0*40
!AIVDM,3,2,4,A,DcMJM18k6<=m7rwVm3b5RRWEskwJWej8uP<0:W5K6PA,0*61
!AIVDM,3,3,4,A,gPs<dwulp,4*14
The current version decodes this to:
{"class":"AIS","device":"stdin","type":8,"repeat":0,"mmsi":369493649,"scaled":true,"dac":366,"fid":57,"data":"510:47f3e09168d938bc17f30ae56971a71c16c12ac7ec44585fb854add69d048cc630dd47ebf9b50ea1628a757bcff6a7b7223d80c00a9c56c6811be0eccb3ff74e"}
The 510 bits of data are 63 full bytes and then 6 remaining bits. The
last byte has value: 4e, which is 0100 1110. I would expect 4c, 0100 1100.
To fix this, the following patch could be applied. Please note that the
problem might also be present in other message types, but I have not
encountered any problems in other message types in the 1 million
messages I have in my test dataset. Message types that could be impacted
are: 6, 17, 25 and 26, as they all use the same memcpy to get
unstructured data.
Identified by: Stefan Roels <sroels-gpsd-dev@42solutions.nl>
Added new sample entry to sample.aivdm that exercises this case
Had to regenerate large ais test data log
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When there are unknown FID values in type 6 messages for DAC values that
have some known FIDs (DAC 200, 235 and 250), the data is not read (and
thus printed as all zeros). I have added some example AIVDM messages
which exhibit this problem, some that did not have the problem in the
existing version and a patch for the problem.
Added sample
!AIVDM,1,1,,A,601uEPprEH2@<P<j00,4*32
-{"class":"AIS","device":"stdin","type":6,"repeat":0,"mmsi":2053507,"scaled":true,"seqno":2,"dest_mmsi":244670500,"retransmit":false,"dac":200,"fid":3,"data":"16:0000"}
+{"class":"AIS","device":"stdin","type":6,"repeat":0,"mmsi":2053507,"scaled":true,"seqno":2,"dest_mmsi":244670500,"retransmit":false,"dac":200,"fid":3,"data":"16:3200"}
adjusted loop logic to allow it to continue to process other types
Identified by: Stefan Roels <sroels-gpsd-dev@42solutions.nl>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
Added sample data from email and applied provided patch
Signed-off-by: Jon Schlueter <jschlueter@redhat.com>
|
| |
|
|
|
| |
158 -> 168; without this, the decoder would reject 4-segment
acknowledges. Fortunately these seem to be highly unusual.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The proximate cause was that we've been seing emission of error
messages that were randomly and disturbingly variable across different
environments - notably Raspbian and Gentoo splint gave nontrivially
different results than Ubuntu 14.10 splint. And this was *not* due to
Ubuntu patches! A pristine splint built from the 3.1.2 tarball on
Ubuntu didn't match the Raspbian and Gentoo results either.
But this has been coming for a while. Easy access to more modern
static analyzers such as coverity, scan-build and cppcheck has been
decreasing the utility of splint, which is unmaintained and somewhat
buggy and not easy to use.
Only file not cleaned is ppsthread.c, because Gary has been working
on it during this cleanup.
All regression tests pass. PPS observed live on GR601-W.
|
| |
|
|
|
| |
Required one checkfile rebuild to integrate the sentence that triggered
the error. All regression tests pass.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is done so we can add a "log" hook to the pps_thread_t
structure (this is not done yet) and harmonize with the name of the
outer logging function. If that name had been left as gpsd_report()
there would have been scope for bad confusion with the report_hook
member.
Also, remove two stray duplicative printf calls from the NMEA2000 driver
(drivers shouldn't have printfs!) and fix one typo.
This is a step towards factoring out ntplib. For that to happen, the
PPS thread code needs to be decoupled from the core session structure.
No logic changes. Object compatibility preserved. All regression tests pass.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
All regression tests pass.
|
| |
|
|
| |
All regression tests pass.
|
| |
|
|
|
|
| |
Next, implement labeled reporting and fix up gpson to do the right thing.
All regression tests pass.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
All regression tests pass.
|
| | |
|
| |
|
|
| |
This is an attempt to prevent false matches on unstructured type 8s.
|
| |
|
|
| |
Prevent a false match to an Inland AIS sentence.
|
| | |
|
| |
|
|
| |
All regression tests pass. PPS is live in both gpsd and gpsmon.
|
| | |
|
| |
|
|
|
|
|
| |
Be permissive about various length checks. Longer is OK, shorter is
not. Longer is a not-uncommon error because these messages are
formatted to fit in TDMA message slots; if a sender ships extra
data past the nominal message end it may not even be noticed.
|
| | |
|
| |
|
|
|
|
|
|
| |
This involved moving some out of the AIS driver. There is a related
small change in behavior; now, if split24 is on, the Type B half of
a matched pair will be shipped with type 'both'.
All regression tests pass. PPS is live.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
