Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ROT: navigation/rateOfTurn seems not to be parsed from NMEA AIVDM #178

Open
Hakansv opened this issue Sep 6, 2020 · 7 comments
Open

ROT: navigation/rateOfTurn seems not to be parsed from NMEA AIVDM #178

Hakansv opened this issue Sep 6, 2020 · 7 comments

Comments

@Hakansv
Copy link
Contributor

Hakansv commented Sep 6, 2020

Background for this issue to be found here:
SignalK/signalk-server#1116
Since the rateOfTurn path is mentioned in SK specifications I assumed it was covered also by nmea0183 parser but I may be mistaken.
Anyhow.
The "rate of turn" info from a AIVDM message is parsed by OCPN in this way:
https://github.com/OpenCPN/OpenCPN/blob/69c30afcf7be8398e092ddaff6e434707fcd2e18/src/AIS_Decoder.cpp#L1699
I'll be back when here I've cached some AIVDM messages where the ROT info is present.
Thanks
Håkan

@afischerdev
Copy link

The GeoGate encoder contains samples with ROT

please see

@Hakansv
Copy link
Contributor Author

Hakansv commented Sep 6, 2020

Very good!
And the -128 value parsed in these examples is the one used as the "none ROT" info.
@tkurki are you happy with that or should I also continue to cache some examples?
Håkan

@tkurki
Copy link
Member

tkurki commented Sep 6, 2020

This is good.

It would be much less devious if ggencoder output would be null or undefined for ’no data’, but I guess we need to work with this for now.

@afischerdev
Copy link

You get out what comes in.

The definition is
0 = not turning
128 = no turn information

The input is b10000000 (x80) and the rule of the GetInteger routine says for signed integer this is a negative value.
So a -128 comes out. We could change this to a fixed 128 value to become conform with the VDM doc.

from this page

@RooieDirk
Copy link

RooieDirk commented Sep 6, 2020

Hi,
This is correct as far as I see live data passing by.

Turn rate is encoded as follows:

0 = not turning

1…126 = turning right at up to 708 degrees per minute or higher

1…-126 = turning left at up to 708 degrees per minute or higher

127 = turning right at more than 5deg/30s (No TI available)

-127 = turning left at more than 5deg/30s (No TI available)

128 (80 hex) indicates no turn information available (default)

Values between 0 and 708 degrees/min coded by ROTAIS=4.733 * SQRT(ROTsensor) degrees/min where ROTsensor is the Rate of Turn as input by an external Rate of Turn Indicator. ROTAIS is rounded to the nearest integer value. Thus, to decode the field value, divide by 4.733 and then square it. Sign of the field value should be preserved when squaring it, otherwise the left/right indication will be lost.

For signal-K the value could be the real RoT I guess.

@RooieDirk
Copy link

In the above
128 (80 hex) indicates no turn information available (default)
this should be -128. As we are talking a signed 8 bits integer value, there can't be a +128.

@tkurki
Copy link
Member

tkurki commented Feb 14, 2024

So we should convert -128 to null on the sk side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants