[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Gagneraud
Subject: [gpsd-dev] [AIS] validity range, scaling formulas and "not available" codes.
Date: Fri, 01 Jun 2012 22:23:41 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120421 Thunderbird/12.0

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, 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
        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
                do something
        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 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, 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.


Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Tel: + 353 (0) 1 236 5990

reply via email to

[Prev in Thread] Current Thread [Next in Thread]