summaryrefslogtreecommitdiff
path: root/test/sample.aivdm.js.chk
Commit message (Collapse)AuthorAgeFilesLines
* AIS: Rebuild regressions tests for new precision.Gary E. Miller2018-09-211-36/+36
| | | | scons check needs to complain when AIS regression tests fail.
* [aivdm] Make type=1 more permissive of short dataJon Schlueter2016-01-051-0/+2
| | | | | | | | | | | | | | | | | | | | 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/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | | | | | 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/+1
| | | | | 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/+2
| | | | | | | | | | | | | | | - 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/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | | | | | | 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/+8
| | | | | | | | | | | | | - 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/+1
| | | | | | 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 broken regression tests with aivdm from_sixbitJon Schlueter2015-10-051-1/+1
| | | | | Missed 2 test regression check files for whitespace cleanup
* Fix Savannah bug #44619: Bad latitude value for message type 17Eric S. Raymond2015-03-241-0/+1
| | | | | Required one checkfile rebuild to integrate the sentence that triggered the error. All regression tests pass.
* Zbigniew Chyla's last change fixed a previously-unnoticed bug in AIS dumping.Eric S. Raymond2015-03-221-1/+1
| | | | Required rebuild of two check files. All regression tests pass.
* Fix a formatting error in AIS JSON generation (client library get it right).Eric S. Raymond2015-01-301-4/+4
| | | | Required one test rebuild.
* AIS fixes required three check file rebuilds. All regression tests pass.Eric S. Raymond2015-01-081-1/+1
|
* Type 25 and 26 improvements required a rebuild of the AIS regression tests.Eric S. Raymond2014-08-291-4/+4
|
* Prevent false matching of the Inland AIS shape on unstructured Type 8s.Eric S. Raymond2014-08-191-0/+1
| | | | Also, add a regression test for this.
* Cirresct specification annd processing of Inland AIS Type 10 message.Eric S. Raymond2014-08-181-0/+1
|
* One test rebuild is required to go with the last JSON fix.Eric S. Raymond2014-05-171-1/+1
|
* Address Savannah bug #40298: AIS type 27 too strict size checkEric S. Raymond2013-10-181-0/+1
|
* Address Savannah tracker issue #40297: AIS type 19 decoding bug.Eric S. Raymond2013-10-181-1/+1
|
* New-style dumping (numeric and text both) for two more fields.Eric S. Raymond2013-10-011-2/+2
| | | | All regression tests pass.
* Rebuild the regression test loads so they dump in the new style.Eric S. Raymond2013-10-011-20/+20
| | | | All regression tests pass.
* Updare AIVDM regression tests for previous commit.Eric S. Raymond2013-09-151-2/+2
|
* Minor fix to AIS type 1,2,3 radio field decoding.Eric S. Raymond2013-07-051-3/+3
|
* [AIS] Fixed EPFD display in scaled JSONChristian Gagneraud2012-08-231-1/+1
| | | | aivdm-regress passed
* Fix scaling of AIS navigation message 'course' member.Eric S. Raymond2012-08-221-4/+4
|
* Sigh. Repair regressipon tests after signedness change. All tests pass.Eric S. Raymond2012-06-241-1/+1
|
* Always wemit ISO8601 timestamps with the same length.Eric S. Raymond2012-06-211-2/+2
| | | | Someday, this will prevent a nasty surprise for a client programmer.
* [AIS] Fix previous AIS mergeChristian Gagneraud2012-06-201-3/+3
| | | | | 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/+25
| | | | | | | | | | | | | | | | | | | | | | 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] Add scaled and unscaled JSON dump to regression testsChristian Gagneraud2012-06-201-0/+49
The unscaled and scaled JSON dump code was not exerted with sample.aivdm, only the CSV code was. Fix that. PS: The idempotency test only validates parsing/dumping, and only in unscaled mode.
View Lorry Controller Status