summaryrefslogtreecommitdiff
path: root/test/sample.aivdm
Commit message (Collapse)AuthorAgeFilesLines
* [aivdm] Disable some mis-behaving sample entriesJon Schlueter2016-01-051-0/+19
| | | | | | | | | | | | Moved some sample entries from ais-nmea-sample.log to sample.aivdm and commented them out. these were generating warning/errors in gpsd Likely malformed but would like to stash them away to be looked into more when someone with specs or other sample data can look for similar types of data
* [aivdm] Make type=1 more permissive of short dataJon Schlueter2016-01-051-0/+8
| | | | | | | | | | | | | | | | | | | | 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
* [aivdm] Expand driver type=20 to handle length 186Jon Schlueter2016-01-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [aivdm] Expand driver type 16 to handle 168 bitsJon Schlueter2016-01-051-0/+4
| | | | | | | | | | | | | | | | | 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}
* additional type 21 message with 368 bits long messageJon Schlueter2016-01-041-0/+6
| | | | | had to extend check to include extra size Also tweaked devtools/ais.py
* AIS:refine parsing of type 8 DAC 1 FID 16 messagesJon Schlueter2015-10-071-0/+8
| | | | | | | | | | | | | | | - 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
* AIS: Add better handling of non byte aligned data blobsJon Schlueter2015-10-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* better handling of type 6 unhandled FID entriesJon Schlueter2015-10-071-0/+3
| | | | | | | | | | | | | | | | | | 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>
* Fix json_aivdm_dump for bad temp scalingJon Schlueter2015-10-061-0/+21
| | | | | | | | | | | | | - Type 8, DAC = 1 FID = 11: airtemp, dewpoint and watertemp calculations go wrong due to unsigned ints. Identified by: Stefan Roels <sroels-gpsd-dev@42solutions.nl> unsigned/signed subtraction was causing math to go wonky. new sample data added to sample.aivdm which exibits the conversion errors Also identified watertemp that was failing from same data Regenerated the corresponding check files from current code
* add an ais type9 sample which has speedJon Schlueter2015-10-051-0/+19
| | | | | | Type 9: the ais->type9.speed field should be used instead of the type1 field Identifed by: Stefan Roels <sroels-gpsd-dev@42solutions.nl>
* Fix Savannah bug #44619: Bad latitude value for message type 17Eric S. Raymond2015-03-241-6/+15
| | | | | Required one checkfile rebuild to integrate the sentence that triggered the error. All regression tests pass.
* Prevent false matching of the Inland AIS shape on unstructured Type 8s.Eric S. Raymond2014-08-191-0/+14
| | | | Also, add a regression test for this.
* Cirresct specification annd processing of Inland AIS Type 10 message.Eric S. Raymond2014-08-181-0/+22
|
* Check various test sentences against the Maritec decoder.Eric S. Raymond2013-10-181-5/+14
|
* Address Savannah bug #40298: AIS type 27 too strict size checkEric S. Raymond2013-10-181-0/+4
|
* Typo fixes.Eric S. Raymond2013-10-141-5/+5
|
* [AIS] Fix previous AIS mergeChristian Gagneraud2012-06-201-2/+0
| | | | | Some modifications were lost during last merge, fix that. Regression pass except for ait250.
* [AIS] Fix plenty of small bugs unveiled by aishub test campaign.Christian Gagneraud2012-06-201-1/+87
| | | | | | | | | | | | | | | | | | | | | | A test campaign was run with live data from aishub.net (ca. 25 millions sentence, 1.2 GB of logs), the goal was to check the decoding and the JSON parsing and dumping code. On all the AIS data, the following tests were done: - AIVDM decoding - JSON scaled dump - JSON validity check on scaled dump. - JSON unscaled dump - JSON validity check on unscaled dump - JSON unscaled idempotency check - JSON unscaled/scaled idempotency check The last check consisted of: - parsing the unscaled dump - dumping it back in scaled mode - compare it with the original scaled dump. This test campaign has unveiled plenty of small bugs all around the AIS code. This patch fixes all of them and adds new sentences in the regression tests.
* [AIS] Met/Hydro: fixes and improvementsChristian Gagneraud2012-06-051-4/+55
|
* [AIS] Add UK/ROI AtoN monitoring data message testsChristian Gagneraud2012-05-231-0/+27
| | | | scons check pass
* Comment typo fix.Eric S. Raymond2012-05-201-5/+6
|
* [AIS] Add 2 regression testcases for IMO236 met/hydro messageChristian Gagneraud2012-05-201-0/+105
| | | | scons check pass
* Handle up to 16 interleaved Type 24A and 24B messages.Eric S. Raymond2012-03-051-2/+1
| | | | All regression tests pass.
* Make sure 24A and 24B aivdm sentences are correctly aggregated.Nirgal2010-05-221-22/+52
| | | | | | | | Patch adds unit tests for all the collision cases. All regression tests pass. Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
* Update some status comments.Eric S. Raymond2010-05-211-10/+10
|
* Clarification of some message length and padding issues.Eric S. Raymond2010-05-121-4/+4
|
* Document some needs.Eric S. Raymond2010-05-121-1/+3
|
* Fix AIS type 15 decoding and add a new test from Kurt Schwehr.Eric S. Raymond2010-05-121-1/+18
|
* In AIS message types 6 and 8, split app_id into DAC and FID per ITU-1371.Eric S. Raymond2010-05-101-8/+14
| | | | | | | | | | | | Wire protocol and API minor versions get bumped. All changes are as documented in AIVDM.txt, which now describes known message 6 and 8 subtypes. Involved rebuilding a couple of AIS regression tests. All regression tests pass. Also includes various typo fixes for AIVDM.txt discovered by Baylink while we were reviewing these changes.
* Add Nirgal's tests for bad packet and AIS channel multiplexing.Eric S. Raymond2010-05-091-0/+12
|
* Complete privious change. Required rebuilding of three regressin tests.Eric S. Raymond2010-05-091-1/+1
|
* Replace a broken AIS type 8 test with a known-good one from Kut Schwehr.Eric S. Raymond2010-05-091-8/+9
|
* FIXME -> FIX-ME, so I can walk through these without tripping over autotools.Eric S. Raymond2010-04-261-2/+2
|
* Three bits have to be removed from the data vector, too.Eric S. Raymond2010-03-291-1/+1
|
* devtools/ais.py had a Type 17 bug, too - wrong length of spare field.Eric S. Raymond2010-03-291-1/+1
|
* Address Debian bug #573752 (mode sometimes missing from JSON.Eric S. Raymond2010-03-141-0/+3
| | | | | Also, include some additions of copyrights on the test logs that somehow wint missing from the last commit (probably git operator error).
* More test load documentation. All regression tests pass.Eric S. Raymond2010-02-051-48/+48
|
* More documentation of AIVDM test loads.Eric S. Raymond2010-02-051-10/+12
|
* Clarify the status of a number of test sentences.Eric S. Raymond2010-02-051-16/+26
|
* A verified pair of AIS type 6 and type 7 messages for the regression test.Eric S. Raymond2010-02-041-1/+22
|
* Add an AIS Type 17 regression test.Eric S. Raymond2010-02-021-31/+30
|
* Make the decoders use the pad fields as seems to be intended.Eric S. Raymond2010-02-011-1/+1
|
* Correction and test case for two-MMSI case of message 16.Eric S. Raymond2010-01-311-3/+15
|
* Documentation improvements. Eric S. Raymond2010-01-311-2/+4
| | | | Aso addition of a length ranges array for integrity checking.
* Regression test and proper field conditionalization for AIS Type 16Eric S. Raymond2010-01-301-0/+11
|
* Add AIS type 23 regression test.Eric S. Raymond2010-01-301-0/+19
| | | | Also fix type 16 interpretation in the Python decoder.
* Improved handling and documentation of AIS type 22 messages.Eric S. Raymond2010-01-301-0/+23
|
* Filename change and some typo tweaks. Eric S. Raymond2010-01-291-0/+523
Not everything in the AIVDM test load is from Kurt Schwehr any more.
View Lorry Controller Status