[gpsd-dev] [AIS] validity range, scaling formulas and "not available" codes.

[Christian Gagneraud]

Hi there,

Lot of type 6 and 8 messages have some special "not available" values, 
and the information is not easily accessible in the documentation from a 
tool point of view.

I would like to allow for two forms for the table definition:
- Form#1: as it is now
- Form#2: Extended version with more columns (validity range, not 
available code, scaling)

With the extended version, tablegen.py would have all the extra 
informations needed to:
- generate a BLAH_IS_VALID(X) macro along the structure definition
- generate a BLAH_IS_AVAILABLE(X) macro along the structure definition
- generate validity check for parsing and unpacking code
- generate "not available" check for dumping code

This would mainly impact the JSON dumping in scaled mode.

The current code, doesn't bother much with the not available case:
if (scaled)
        do something
else
        do something

And usually process the fields by bunch

Taking into account the not available case, the scaled and the unscaled 
mode, and the validity checks makes the json dumping code quite heavy:
if (scaled) {
        if (is_not_available)
                do something
        else if (is_valid)
                do something
        else
                do something
}
else
        do something

And has to be done on a field by field case.

With an extended table as describe above, it is possible to update the 
tablegen.py tool to generate code that would require less hand hacking.

Now, I would like to change as well the way the "not available" cases 
are handled. The problem is that for now, the documentation says that 
not available is translated into "nan", which works for real values, but 
not for integer values, enumerations being handled differently.
My solution would be to not dump a field if the scaling mode is "scaled" 
and the availability is "not available".

On top of that, I would like to do the validity checks in the unpacking 
code, and return false if at least one field is invalid.

With these two modifications the json dumping would look like this:
if (scaled && is_available)
        print scaled value
else if (!scaled)
        print unscaled value

Additionally, I would like to enforce the following two rules in the 
AIVDM doc:
- All enum have to point to a table via 'See "something"'
- Same with integer that has some special values (hard turn, more than 
X, ...)
Again, this is to allow the code generation to be as helpful as possible.

I'm planning to add new messages, based on statistics I made from 
aishub.com, and having a better code generator would really help a lot!

In the long term I plan to stress-test the AIS code (unpacking and json 
parsing) with pseudo-randomly generated data and/or specially crafted data.

Chris

--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/