Magnetic Deviation

[tkurki]

For example HDG NMEA 0183 has heading, I believe we are missing it.

A bit tricky, as it is associated with the sensor and current heading, so where should it go?

[JonRowe]

Yes sorry, I meant variation :)

[rob42]

@JonRowe you have nicely identified an important distinction. In signalk headingMagnetic is the compass heading corrected for deviation (if we know it). Its not headingCompass. We could add headingCompass as well as (or instead of) magneticDeviation but thats possibly just clutter? Lets leave storing the deviation table in meta out of this issue and deal with data error correction separately.

[sarfata]

Adding my opinion to this very interesting discussion ;) First looking at the standards and what we do today, then trying to pick what I like best in the thread and summarize what I would like to see and finally taking a look at my equipment on my boat.

1 - Standards and code we have today

According to catb.org, NMEA HDG already sends "compass heading", deviation and variation. And PGN 127250 also includes both.

We currently ignore deviation in the NMEA parser and in the NMEA2000 parser.

This seems to be a bug :

• we define navigation.headingMagnetic as "Current magnetic heading of the vessel"
• so when a deviation is provided, and assuming it's not been already added to the heading by the sensor (but we would need the spec to be sure of what they are supposed to do here)
• we should add the deviation before sending it as headingMagnetic.

Also note that the NMEA2000 conversion code already sends navigation.magneticDeviation if it finds it (but does not do any correction).

2 - Picking what I like best from the thread

@sumps said (and I agree):

As a general principle, I think we should always have a Signal K key for all NMEA data so that there is clear and accurate conversion of the data, with no further ambiguity or introduction of errors.

I support the idea of adding navigation.magneticDeviation but I do not think we should change the definition of headingMagnetic which clearly should be corrected for deviation from its current definition.

So when using magneticDeviation, we should store the "measured" or "compass" heading in a new key as well. This way we could properly translate 127250 and HDG. And just like today we can use the headingMagnetic and the magneticVariation to calculate a headingTrue, a client or a server could take magneticDeviation and headingCompass to calculate and send headingMagnetic.

So to be clear we would have:

• navigation.headingCompass raw heading measurement from magnetic sensor or compass.
• navigation.headingMagnetic heading corrected for deviation
• navigation.headingTrue heading corrected for variation
• navigation.magneticDeviation heading deviation at the current heading (calibrated for this boat)
• navigation.magneticVariation heading variation at the current location

In terms of code change:

• When parsing HDG and 127250, if the deviation is provided, send the raw value as headingCompass, send the deviation as headingCompass. In the conversion code or in the server, add the deviation to the heading and send it as headingMagnetic.
• When deviation is not provided, continue to do what we do today and send the value as headingMagnetic, assuming the sensor has been calibrated for deviation.

<cynical mode on> Remark that this is equivalent to doing nothing if there are no equipments out there that do send the deviation ;) </cynical>

And I also agree that the table discussion can be held separately, in a different PR.

3 - Data from my boat

Extra info: I just checked my logs and my B&G ZG100 GPS+Heading sensor does not include deviation:

$PCDIN,01F112,5AF4FCB6,80,00345DFF7FDC07FD*5F

Which via canboatjs is: {"pgn":127250,"timestamp":"1970-01-18T15:53:24.918Z","src":128,"dst":255,"prio":0,"fields":{"SID":0,"Heading":2.386,"Variation":0.2012,"Reference":"Magnetic"},"description":"Vessel Heading"}

[sumps]

I agree with your methodology @sarfata but I would change navigation.headingCompass to navigation.headingRaw to make it clearer that the heading is "raw" with no variation and deviation. Perhaps we can apply this "raw" naming convention to other values in the future as more SK sensors are developed and we need a method of transmitting raw and calibrated values.

[JonRowe]

headingCompass would be headingRaw with deviation applied, but not variation.

[rob42]

@JonRowe no I think headingCompass just gets renamed headingRaw. So: headingRaw is the value the compass sends out. headingMagnetic = headingRaw corrected for magneticDeviation if known headingTrue = headingMagnetic corrected for magneticVariation

Current NMEA conversions should be corrected to match this. I will do a schema PR.

Lets close on that, before my heading starts to spin :-)

[JonRowe]

The value the compass sending out is usually already corrected for deviation.

[rob42]

In that case (and most cases) the magneticDeviation will be unknown, hence 0. So headingRaw will equal headingMagnetic

[sbender9]

So, are we going to add "Raw" for every single key in the schema? Is this the only key that might need adjustment? (like a wind vane that's not right?)

I'm not convinced that this is the correct solution.

[tkurki]

See my comment in the PR.

[rob42]

I prefer headingCompass as well, and I agree with @timmathews reservations about headingRaw as a solution.

Since headingRaw can be derived from headingMagnetic and magneticDeviation the real reason for including it in the main schema (rather than meta) is that its a very visible value, eg its on the compass in front of the helmsman, and in the NMEA messages. Hence it useful to have it easily available to clients, rather than assume they will calculate it when needed.

Lets call it headingCompass, and make the raw values a separate issue.

[sumps]

The original issue was about deviation and where to put it and we do seem to have been dragged off in another direction. I actually think headingCompass is worse and more confusing than headingRaw and I would prefer to close this issue with the creation of a new key magneticDeviation and leave it at that.

I think we should stick with headingMagnetic and headingTrue which are clear data types and then handle the nature of the data in the metadata i.e. Raw, Damped, Calibrated, etc.

[tvr256]

Dragging this one up from the past...

From what I can see, the schema was updated to add magneticDeviation and headingCompass, but the code was never updated to populate them correctly.

If I send the following sentence $INHDG,180,5,W,10,W*6D

navigation.magneticDeviation is not set (should be -5) navigation.magneticVariation is set to -10 (correct) navigation.headingCompass is not set (should be 180) navigation.headingMagnetic is set to 180 (should be 175) navigation.headingTrue is not set (should be 165)

Incidentally, the NMEA spec clearly states that the first value in the HDG sentence is the magnetic sensor reading before any deviation correction is applied.