pgn 130306 (WindData) has the wrong bit offset for Reference about canboat

[keesverruijt]

I think you are misinterpreting bit offsets. The lowest bit in a byte is bit 0, so bit 40 to 42 are the correct ones.

The estimated PGN definition in the source code is:

{ "Wind Data", 130306, true, 6, 0,
{ { "SID", BYTES(1), 1, false, 0, "" }
, { "Wind Speed", BYTES(2), 0.01, false, "m/s", "" }
, { "Wind Angle", BYTES(2), RES_DEGREES, false, "deg", "" }
, { "Reference", 3, RES_LOOKUP, false, LOOKUP_WIND_REFERENCE, "" }
, { 0 }
}
}

Here is some output of analyzer -raw -debug -data 130306 showing output from two different sources (a Simrad IS20 wind and a Simrad AC42):

2011-04-25-10:16:42.828 2 013 255 130306 : ff 2c 01 a3 16 fa ff ff
2011-04-25-10:16:42.908 2   2 255 130306 Wind Data:  FF D1 00 7E 23 FB FF FF
2011-04-25-10:16:42.908 2   2 255 130306 Wind Data:   .  .  .  .  .  .  .  .
2011-04-25-10:16:42.908 2   2 255 130306 Wind Data:
decode SID offset=0 startBit=0 bits=8 bytes=1:(en f=SID,sb=0,b=0) (d=ff,bib=8,fb=0,msk=ff,v=ff,mag=0) (v=ff,m=ff)   SID = Unknown
decode Wind Speed offset=1 startBit=0 bits=16 bytes=2:(en f=Wind Speed,sb=0,b=0) (d=d1,bib=8,fb=0,msk=ff,v=d1,mag=0) (d=0,bib=8,fb=0,msk=ff,v=0,mag=8) (v=d1,m=ffff) ; Wind Speed = 2.09 m/s
decode Wind Angle offset=3 startBit=0 bits=16 bytes=2:(en f=Wind Angle,sb=0,b=0) (d=7e,bib=8,fb=0,msk=ff,v=7e,mag=0) (d=23,bib=8,fb=0,msk=ff,v=23,mag=8) (v=237e,m=ffff) ; Wind Angle = 52.1 deg
decode Reference offset=5 startBit=0 bits=3 bytes=1:(en f=Reference,sb=0,b=0) (d=fb,bib=3,fb=0,msk=7,v=3,mag=0) (v=3,m=7) ; Reference = True (boat referenced)
2011-04-25-10:16:42.908 2 002 255 130306 : ff d1 00 7e 23 fb ff ff
2011-04-25-10:16:42.939 2  13 255 130306 Wind Data:  FF 2C 01 6E 16 FA FF FF
2011-04-25-10:16:42.939 2  13 255 130306 Wind Data:   .  .  .  n  .  .  .  .
2011-04-25-10:16:42.939 2  13 255 130306 Wind Data:
decode SID offset=0 startBit=0 bits=8 bytes=1:(en f=SID,sb=0,b=0)(d=ff,bib=8,fb=0,msk=ff,v=ff,mag=0) (v=ff,m=ff)   SID = Unknown
decode Wind Speed offset=1 startBit=0 bits=16 bytes=2:(en f=Wind Speed,sb=0,b=0) (d=2c,bib=8,fb=0,msk=ff,v=2c,mag=0) (d=1,bib=8,fb=0,msk=ff,v=1,mag=8) (v=12c,m=ffff) ; Wind Speed = 3.00 m/s
decode Wind Angle offset=3 startBit=0 bits=16 bytes=2:(en f=Wind Angle,sb=0,b=0) (d=6e,bib=8,fb=0,msk=ff,v=6e,mag=0) (d=16,bib=8,fb=0,msk=ff,v=16,mag=8) (v=166e,m=ffff) ; Wind Angle = 32.9 deg
decode Reference offset=5 startBit=0 bits=3 bytes=1:(en f=Reference,sb=0,b=0) (d=fa,bib=3,fb=0,msk=7,v=2,mag=0) (v=2,m=7) ; Reference = Apparent
2011-04-25-10:16:42.939 2 013 255 130306 : ff 2c 01 6e 16 fa ff ff

which all looks splendid to me...

I also don't get where you get the "4 bits worth of values" from. The lookup table contains values for index value 0 through 4. That meshes with the field size of 3 bits IMO.

[alexphredorg]

I wondered about that, but it isn't consistent with how the PGNs are described in the JSON and XML. In the JSON you have the BitOffset and BitLength as both 0 based from the start of the bit vector that represents the PGN data.

In this case BitOffset is 40 and BitLength is 3, which implies that I should read the 3 bits starting at 40 bits in. Your definition below says that I should be looking at the lower 3 bits of the 6th byte, which is a very different thing. It would be clearer to have ByteOffset and BitLength to say that I should consume the full byte at that offset, then use the bottom 3 bits.

Would you prefer that I open a bug for how the JSON is being generated? Perhaps I'm the only one consuming the JSON or XML?

[keesverruijt]

NMEA bit ordering is such that it goes from LSB to MSB within a byte. This is the 'logical' representation where bit n has value 2^n. It may be that CAN uses a different ordering on the physical wire, but that is irrelevant as that is not how the fields are represented in the PGN descriptions.

For proof, just look at the defined ordering of two sequential bit fields in PGNs without any reserved bits in between. For instance, take ISO Address Claim PGN 60928. This even has "device instance lower" and "device instance higher" which together form a single 8 bit "device instance" value. Notice how the "lower" field comes first. This would not make sense with a bit ordering other than it is now.

So all that is needed is for you to flip your mental model of bits within a byte.

[alexphredorg]

I got it, I'm just saying that the JSON layout is weird. It would have made more sense to define ByteOffset for the bytes that contain the fields, then bit offsets inside of those.

It's easy enough to fix up on my end.

alex