Open amotl opened 2 years ago
Would be nice to get compass readings from calypso. Did you make some progress here?
Dear Simon,
thank you for writing in. Others also asked about compass
support recently. We will have to dive into a little recap to check the current state of the corresponding implementation.
Based on my findings shared below, I think compass
data should be decoded well already, and may already make it into the corresponding SignalK telemetry adapter correctly. Can you verify that? On the other hand, what others have asked about, I think compass data is not translated to NMEA0183 yet.
With kind regards, Andreas.
It looks like 8843346eb8 added decoding the compass
data already:
However, I discovered that within the backlog:
This is the current code responsible for translating compass
data to SignalK:
This is the current code responsible for translating compass
data to NMEA0183:
In order to add more information here...
Manufacturer information about the compass can be found at https://calypsoinstruments.com/web/content/884.
On the other hand, what others have asked about, I think compass data is not translated to NMEA0183 yet.
@UserMacUseface told us that the NMEA sentence for this is quite simple ^1:
HDT - Heading - True
1 2 3
| | |
$--HDT,x.x,T*hh<CR><LF>
Field Number:
1) Heading Degrees, true
2) T = True
3) Checksum
Thank you already! We will consider implementing corresponding support on the next development iteration.
@UserMacUseface may have discovered a problem with decoded compass/heading data. Thank you so much for the report!
The value for heading is a bit funny.
While tracking the processing of this value through the code the other day, I already noticed the following snippet:
SignalKDeltaItem(path="navigation.attitude.yaw", value=reading.compass), SignalKDeltaItem(path="navigation.headingMagnetic", value=reading.compass)
reading.compass
is defined in the model ascompass=360 - compass
. However, while the documentation of Calypso claims degrees ^1, the actual value seems to be radians though.Is there a log where I can see the raw data being read from the device?
However, while the documentation of Calypso claims degrees, the actual value seems to be radians though.
Ah, wow!
But the device claims to be the same as before, and there is no updated documentation about it? Maybe there has been something within the release notes of the firmware update you installed recently? (https://github.com/maritime-labs/calypso-anemometer/issues/13#issuecomment-1443508507)
Is there a log where I can see the raw data being read from the device?
The decoder implementation has been based on information from the Calypso Ultrasonic decoding cheat sheet by Fabian Tollenaar. Logging raw data would not make much sense because it is in binary format.
/cc @decipherindustries
But the device claims to be same as before, and there is no updated documentation about it? Maybe there has been something within the release notes of the firmware update you installed recently? (#13 (comment))
I cannot seem to find any release notes from calypso instruments :/
On a side note: roll
and pitch
also come from the gyro, don't they? Should we perhaps rename the reading.compass
field to reading.heading
for the sake of better "naming things"?
Regarding the "funny" readings, we discovered that all angle values should be submitted to SignalK using Radian (rad) unit, see also https://github.com/maritime-labs/calypso-anemometer/issues/14#issuecomment-1443783379.
Regarding "reading the compass at all", we may have missed the corresponding method to enable it. Currently, I can only find methods to set "mode" and "datarate".
Regarding "reading the compass at all", we may have missed the corresponding method to enable it.
The improvement GH-23 finally adds that, with a corresponding --compass=on
command line option.
Regarding the missing "Compass to NMEA0183" telemetry propagation (https://github.com/maritime-labs/calypso-anemometer/issues/12#issuecomment-1443394371), the values for pitch
and roll
shall apparently be propagated into XDR - Transducer Values
messages [^1], as suggested by @UserMacUseface.
Within that message, I also spotted a slot to transmit air temperature. Does it make sense to propagate the temperature measured by the Calypso into this slot, or would it be wrong, because, mounted on the top of the mast, it will most probably not what meteorologists understand as "air temperature"?
1 2 3 4 n
| | | | |
* $--XDR,a,x.x,a,c--c, ..... *hh<CR><LF>
Measured Value | Transducer Type | Measured Data | Unit of measure | Transducer Name |
---|---|---|---|---|
air temperature | "C" temperature | 2 decimals | "C" celsius | "TempAir" or "ENV_OUTAIR_T" |
pitch | "A" angle | -180..0 nose down 0..180 nose up | "D" degrees | "PTCH" or "PITCH" |
rolling | "A" angle | -180..0 L 0..180 R | "D" degrees | "ROLL" |
Within that message, I also spotted a slot to transmit air temperature. Does it make sense to propagate the temperature measured by the Calypso into this slot, or would it be wrong, because, mounted on the top of the mast, it will most probably not what meteorologists understand as "air temperature"?
Its surely a good idea to transmit all the values that the calypso generates. that way any future implementation can use it if needed. The temperature difference on top of the mast is very probably not too much different then on deck level. Nice gimmick to have but probably not critical to any kind of sailing activities :)
Thanks for clarifying. I've created GH-21 to discuss the topic of NMEA0183 sentences for non-compass related values seperately.
Regarding the NMEA0183 talker identifier, thank you for sharing https://github.com/maritime-labs/calypso-anemometer/issues/21#issuecomment-1444249475. On this page, I discovered another example for encoding a compass/heading value.
$HCHDM,238,M<CR><LF>
... where "HC" specifies the talker as being a magnetic compass, the "HDM" specifies the magnetic heading message follows.
In our case, it would be HCHDT
instead of HCHDM
, because we emit the "true heading" - is that correct? Or, following your suggestion at https://github.com/maritime-labs/calypso-anemometer/issues/21#issuecomment-1444249475, MLHDT
would also be a feasable name, right?
Some examples of HDT
sentences are:
$GPHDT,123.456,T
$GPHDT,274.07,T
Would those example sentences be feasible?
# Heading
$MLHDT,274.07,T
# Pitch
$MLXDR,A,-42.42,D,PITCH#CALYPSO
# Roll
$MLXDR,A,30.07,D,ROLL#CALYPSO
Optionally, "heading" could additionally be emitted as XDR
sentence as well?
# Heading
$MLXDR,A,274.07,D,HEADING#CALYPSO
P.S.: As we can see, there is apparently no way to tell XDR sentences apart, other than looking at the name field, here PITCH
vs. ROLL
vs. HEADING
. Does this make sense?
XDR sentences can also carry multiple values -- thanks, @UserMacUseface. When combining pitch and roll, and also omitting the CALYPSO
suffix, a corresponding sentence could look like that:
$MLXDR,A,-42.42,D,PTCH,A,30.07,D,ROLL
As seen at [^1][^2], the order of Pitch/Roll may also be important. [^1]:
[^2]: Airmar GH2183 GPS/Gyro Compass User Manual » Table 3: NMEA 0183 Transmitted Sentences, p. 87
GH-24 implements the most recent suggestions. Thank you so much for the support!
Dear @honigwald and @UserMacUseface,
we just released calypso-anemometer 0.6.0, including the corresponding improvements, and will be happy to hear back from you about its outcome on this matter.
You may be able to get a reading with compass turned on, using
# Get device reading(s), with compass data (roll, pitch, heading).
calypso-anemometer read --compass=on
calypso-anemometer read --compass=on --subscribe
Emitting this data to both telemetry variants NMEA-0183 and SignalK, may also work well now.
With kind regards, Andreas.
Unfortunately, with the recent 0.6.0 release, eCompass readings do not work yet, see GH-27.
Is this needed?
-- UltraSonicComponent.js#L131-L134