RMC conversion results in 100% cpu

[tkurki]

If I have RMC conversion active in my system, with nmea0183 going out to 4800 baud 0183 connection, the cpu will go up to 100%. Deactivating RMC conversion will bring it back down, but after a while, not immediately.

[davidsanner]

Old issue but just looking through RMC.js.

To test I created a variable that is incremented every time RMC.js is called and stuck its value in the outgoing RMC sentence. Looks like only one RMC sentence is output from signalk for every 4 times the variable is incremented (RMC.js returns a valid RMC sentence for each increment).

I'm testing with a 10Hz GPS and signalk is generating roughly 10 RMC sentences per second though apparently RMC.js is being called and returning valid sentences around 40 times per second.

Not sure where to look upstream yet to find out why RMC.js is being called so rapidly or what is controlling the 1 in 4 output. Perhaps this is related to the CPU issue?

[tkurki]

A new RMC is generated every time any of the inputs needed for RMC generation gets a new value. But then the output is debounced so that a new value is output every 20 milliseconds. So when lon, lat datetime or sog change, typically together, a new rmc is generated but since the inputs change together in time only one rmc is output.

[davidsanner]

Thanks for the explanation.

I'm wondering if RMC.js is being called for every single line coming in from the n2k bus... which is roughly 38 lines/sec though only about 24/sec are RMC related (129025, 129026, 127250 & 129029, 127258). Most of the difference is from PGN 127251 / rate of turn @ 10Hz along with a couple other 1Hz or less PGNs. Could PGN 127251 be triggering it though it's only vessel heading w/o variation?

[davidsanner]

I've also been looking around for how to accurately get the RMC time in hundreds of a second when generating RMC @ 10Hz. Seems common that the time used (navigation.datetime) only has 1 second
update rate (typical rate of gnssTimeSource update).

I'd like to get a more granular navigation.datetime (gnss based) time for the rapid position updates.

Might the delta between the timestamp of navigation.datetime and its value be used to determine an accurate time of a rapid position update based on its timestamp (no matter how far the realtime clock has drifted or if years old data is being played back)?

Something like this:
timestamp of navigation.datetime - navigation.datetime value = X
timestamp of rapid position update - X = GNSS based time of rapid position update

Just not sure the best way to reference the timestamp of an event in javascript.
(This value: /signalk/v1/api/vessels/self/navigation/datetime/timestamp to start)