HansT - @Teppo Kurki Asking here for others to ...
@Teppo Kurki Asking here for others to read/see. On GPS rollover fix, my current approach is in n2k-signalk/pgns/129029.js. The downside is that this means it will do it for any source and always. This breaks the test cases and e.g. prevents running old n2k captures through it, as it will correct them as well.
Is it possible to make it a plugin and correct the value as it comes it, that way possibly making a filter for the source id, or at least easily turning it on/off when needed? Like signalk-calibration.
But it's unclear to me if this approach will avoid the wrong date to be seen by the system or any other plugin (like set-system-time).
13 Replies
So this would need to be per source? We can pretty easily add parameters to a connection’s internals, like verify Checksum for nmea 0183
A plugin can intercept and modify incoming sk deltas, but that is a pretty awkward solution to this problem, not exactly user friendly
It doesn't have to be per source. It's more that one could want it not to happen (e.g. with old logs). So being able to switch it on/off would be nice. A 'old-gps-week-rollover-fix-plugin' doesn't sound too user unfriendly to me. But I'll go with anything that works.
How would the 'add parameters to a connection's internals' work?
Sorry, did not understand your question - like the verify checksum switch for 0183 connections?
This PR did something similar to give an idea https://github.com/SignalK/signalk-server/pull/1050/files
GitHub
feature: add recalculate NMEA0183 checksum option by marcelrv · Pul...
Adding recalculation of checksums as discussed in #1044
requires SignalK/nmea0183-utilities#12
Closes #1044.
Ok, so since it's pgn, it would go in streams/canboatjs.js ?
if pgnData == pgn 129029 && fixOption == true { fixDate }
Yes
Ok, the code in https://github.com/htool/signalk-server/blob/fix_gps_rollover_in_pgn_129029/packages/streams/canboatjs.js is working.
But the UI code I find highly confusing.
(to add a switch)
Would you mind doing that bit?
sure, i can do that, just not sure when...
sorry, i have given you false advice. canboatjs is not the correct spot, n2k-signalk.js is the place where n2k in json format from the various sources is converted to signalk
...but...
adding the logic you coded is kinda stupid: for each pgn that has date convert the date value meticulously to a Date, do the day math, then convert it back to a string...only to convert with a bit of search and replace and concatenation to a datetime in n2k-signalk. so a lot of string processing and mucking about
and what is most stupid is that the next date coming from the pipeline is most likely to be the exact same value, that will do the exact same dance
what if instead we add the rollover correction logic where the string conversion from period limited format to hyphen delimited format takes place https://github.com/SignalK/n2k-signalk/blob/master/pgns/129029.js#L15-L17
....and add a bit of logic that checks if the next input is the same as the previous value and without and Date conversions & addition just outputs the same output as for the previous value
GitHub
n2k-signalk/pgns/129029.js at master · SignalK/n2k-signalk
NMEA 2000 to Signal K transformer. Contribute to SignalK/n2k-signalk development by creating an account on GitHub.
then the remaining problem is that there is no convenient way to pass any parameters from the server settings to this place in the code
would it be sufficient to have this conversion run always by default and just provide an optional environment variable to disable it?
(naturally the same for 129033)
For me always on is fine. The 129029 test cases would need to be changed though.
Another thing I was thinking is that it would be a lot cleaner if we would have the epoch field.
So when creating the pgn info in the canboatjs and there is a date, add the epoch field to pgndata as well. That way, in 129029 there's only a very cheap epoch value check and if needed a new date creation.
@Scott Bender thoughts?
So in pgns.json, the date is expressed as nr of days:
{
"Order":2,
"Id":"date",
"Name":"Date",
"BitLength":16,
"BitOffset":8,
"BitStart":0,
"Units":"d",
"Type":"Date",
"Resolution":1,
"Signed":false,
"RangeMin":0,
"RangeMax":65533},
For GPS dates specifically, this can be changed to Type: GPSDate and then in the place where Date in days is converted to Date format, a duplicate function can be made that does the check on nr of days to ensure it makes sense and otherwise add 7196.