Giters

canboat / canboat

CAN Boat provides NMEA 2000 and NMEA 0183 utilities. It contains a NMEA 2000 PGN decoder and can read and write N2K messages. It is not meant as an end-user tool but as a discovery mechanism for delving into NMEA 2000 networks.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

FieldType FIELDTYPE_LOOKUP defined but not used

inquestruss opened this issue · comments

commented

A few issues with the modifications made to PGNs 130824, 130833, 130845, 130846

  • Fields that have LookupFieldTypeEnumeration defined use a field type of "LOOKUP" not "FIELDTYPE_LOOKUP." Other specialized lookups use the field type to identify which list of enumerations to use.
  • 130824 usefully identifies the repeating set size and start field. Others noted below don't.
  • 130824 field 5 (length) provides the length of field 7. There is no field 7. Perhaps these are reserved bits?
  • 130834 I don't understand the semantic intent of this at all, but for now the current definition allows me to recognize it and pass it on to something that might.
  • 130834, 130845, 130846 It might make sense to treat these as repeating sets to tie the key, length, and value fields together; if they always include only a single set that's fine. Otherwise my recognizer will have to treat them each specially. (The best I can do with a strongly typed language is provide a map containing these fields).
  • I don't understand the length (or minlength) field. The FIELDTYPE_LOOKUP definitions include a "bits" key. Should a recognizer validate length == "bits"?
commented

Hmm, yes, the XML is not yet complete for these, I see that now. More work needed. Thanks for the input. Some comments below -- note that this is not a full answer yet.

Fields that have LookupFieldTypeEnumeration defined use a field type of "LOOKUP" not "FIELDTYPE_LOOKUP." Other specialized lookups use the field type to identify which list of enumerations to use.

Need to look into that. For now, look at the pgn.h base version to make sense of it -- any comments appreciated to how to represent this in XML/JSON.

For instance, 130845 "Simnet: Key Value":
LOOKUP_FIELDTYPE_FIELD("Key", BYTES(2), SIMNET_KEY_VALUE),
SPARE_FIELD(BYTES(1)),
SIMPLE_DESC_FIELD("MinLength", BYTES(1), "Length of data field"),
KEY_VALUE_FIELD("Value", "Data value"),

So the LOOKUP_FIELDTYPE_FIELD says that the following KEY_VALUE_FIELD has a particular length and meaning, including its datatype. There are two "useless" fields in between: the SPARE and the MinLength field.

130824 usefully identifies the repeating set size and start field. Others noted below don't.

Yes, some only contain one set of (key, value) so there is no repeating set.

130824 field 5 (length) provides the length of field 7. There is no field 7. Perhaps these are reserved bits?

Sorry, should be "field 6".

130834 I don't understand the semantic intent of this at all, but for now the current definition allows me to recognize it and pass it on to something that might.

I don't think anything has changed regarding 130834? It's unknown to me -- we only know of this because of a reference in some manual.

130834, 130845, 130846 It might make sense to treat these as repeating sets to tie the key, length, and value fields together; if they always include only a single set that's fine. Otherwise my recognizer will have to treat them each specially. (The best I can do with a strongly typed language is provide a map containing these fields).

Yes, I can see now how you need some indication in the XML that ties together the lookup field and the data field more strongly together. I don't think your proposed solution is it though.

I don't understand the length (or minlength) field. The FIELDTYPE_LOOKUP definitions include a "bits" key. Should a recognizer validate length == "bits"?

Yes, they should. Although it is hard to follow, that is what the C analyzer code does. The problem seems to be that the implementers are being a bit "loose" here and the PGNs are less well defined than what could be. I'm guessing at the meaning of the "min length" field.

For now, I would just ignore these -- they are only relevant for Navico users (unless you are one of them :-) )

commented

A few clarifications/corrections on my side:

  • I think a field definition including "LookupFieldTypeEnumeration" should have a FieldType of "FIELDTYPE_LOOKUP" in the same way that one that defines "LookupBitEnumeration" has a FieldType of "BITLOOKUP". I guess it's redundant and I could just use the enumeration reference to set the field type (and have as a workaround in this case).
  • I mistyped 130834. I meant 130833. My comment is of little use anyway--I find the definition confusing but haven't dug into it deeply. It came up because field 4 includes "LookupFieldTypeEnumeration" (but a FieldType of "LOOKUP").
  • I agree the issue is grouping of fields and treating them as a repeating set length 1 is a hack. I don't think there are other instances of such grouped fields?

I'm ignoring as much as I can :), doing the minimum to produce a golang source file that enables converting golang structured data to/from the wire format (as exposed by some device). More effort goes into what we actually see on our networks, and what we need to understand for our current use cases. Getting to canboat completeness will be a long journey...

commented

One possibility is to add a key_field attribute to each key_value field. And perhaps a bitlengthfield attribute (though in at least one case it's a minimum length).

commented

For the canboat.json I think something like:
{"key": 0, "value": {"name": "Heading Offset", "FieldType": "NUMBER", "Resolution": 0.0001, "Unit": "rad", "Bits": "16"}}
would be better than the current:
{"name": "Heading Offset", "value": 0, "FieldType": "NUMBER", "Resolution": 0.0001, "Unit": "rad", "Bits": "16"},
I would then create a map of SimnetKeyConst and SimnetValue objects or some such.

commented

Resolved in latest update.