Closed dookyoonhan closed 6 years ago
The values are stored post-decode as floating point numbers, which can't hold the values you state precisely like the fixedpoint AIS uses can. This is a design tradeoff that increases implementation simplicity and interoperability. Since the precision of floats is sufficiently high you can safely round to the nearest 0.1 if you want the original value. My guess is that you'll only really care about this for UI purposes, though.
Note that ROT is encoded weirdly anyway, so the value won't be a neat multiple of 0.1: http://catb.org/gpsd/AIVDM.html#_types_1_2_and_3_position_report_class_a
ais decoding shows a minute difference in RoT, CoG, and SoG. for instance, when i decode
, result is,
ais.decode("36SWOT0OhA93NqTEKg3cNDTt20qQ",0)
where SoG is : 1.7000000476837158, Rot is 720.0032348632812, and CoG is 293.70001220703125, repectivly. But SoG, Rot, and CoG should have been neat numbers; 1.7, 720.0, and 293.7. I look into code and speculate that this comes from minute error occurred in bit<->integer conversion or division operation of bit type value.
does anyone have same problem or have any idea why this happens?
following is my sys info. ( I tested in 2 PCs.)
PC1: Intel(R) Core(TM)2 Duo CPU E8400 libais 0.16 Ubuntu 14.04.5 (32bit) Python 2.7.6 (default,) [GCC 4.8.4] on linux2
PC2: Intel(R) Core(TM)2 Quad CPU Q8200 libais 0.16 Ubuntu 16.04.2 LTS (64bit) Python 3.5.2 (default) [GCC 5.4.0 20160609] on linux