NMEA0183 to Signal K parser
License: Other
Signal K is a modern and open data format for marine use. Built on standard web technologies including JSON, WebSockets and HTTP, Signal K provides a method for sharing information in a way that is friendly to WiFi, cellphones, tablets and the Internet. A format available to everyone, where anyone can contribute, Signal K is the first truly open data format for the marine industry and is set to revolutionize how we consume and interact with data on boats.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![greenkeeper[bot] avatar](https://avatars.githubusercontent.com/in/505?v=4 "greenkeeper[bot]")
I get no $source for current data with $IIVDR,,,,,,N*0E from plaka.log. The VDR codec seems to provide the same as DBT, but the difference is that the sentence does not contain values. It should indicate the source nevertheless. Here is an extract from the values:
"belowTransducer" : {
"sentence" : "DBT",
"value" : 15.56,
"$source" : "test_file.II",
"timestamp" : "2017-05-29T20:33:28.000Z"
}
},
"current" : {
"setMagnetic" : 0,
"setTrue" : 0,
"drift" : 0,
"timestamp" : "2017-05-29T20:33:29.000Z"
}```
Todo:
signalk.js to output delta updatesdiff algorithmSome OpenPlotter users are experimenting crashes when trying to read corrupted data due to electrical problems or any devices malfuntion:
TypeError: Cannot read property 'toUpperCase' of undefined
at NMEA0183._decoder (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/codecs/GLL.js:52:15)
at NMEA0183.decode (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/NMEA0183.js:259:26)
at Parser._decode (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:128:44)
at /home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:172:26
at arrayEach (/home/pi/.config/signalk-server-node/node_modules/lodash/lodash.js:537:11)
at Function.forEach (/home/pi/.config/signalk-server-node/node_modules/lodash/lodash.js:9359:14)
at Parser._transform (/home/pi/.config/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:169:7)
at Parser.Transform._read (_stream_transform.js:167:10)
at Parser.Transform._write (_stream_transform.js:155:12)
at doWrite (_stream_writable.js:331:12)
at writeOrBuffer (_stream_writable.js:317:5)
at Parser.Writable.write (_stream_writable.js:243:11)
at ToSignalK._transform (/home/pi/.config/signalk-server-node/providers/nmea0183-signalk.js:68:19)
at ToSignalK.Transform._read (_stream_transform.js:167:10)
at ToSignalK.Transform._write (_stream_transform.js:155:12)
at doWrite (_stream_writable.js:331:12)
Kplex and OpenCPN are digesting and showing what they are able to understand from these data but not crashing. Should not SK do the same? Attached a killer NMEA stream file.
vdrfile1.txt
Other linefeeds may work really badly, as the internal buffer is then never flushed, only appended to and the first nmea sentence keeps repeating.
Conversion is naive and does not consider significant numbers.
If the converter takes 6.11 knots (N) or 11.31 km/h and converts that to 3.143255556 m/s we’re ‘inventing’ precision.
One way to fix this is for the converter to automatically remember source precision (0.01 km/h == 0.028 m/s) so round to that.
3.143255556 - (3.143255556 % 0.027778) = 3.1414
Im new to SignalK and stuff, but would it make sense to have support for "RMB - Recommended Minimum Navigation Information" at some point ?
I would be willing to try to make a pull request if it makes sense.
My plan is to have OpenPlotter send waypoint information and display it on a web dashboard along with COG so i can make sure im going to my waypoint ! ( no fancy autopilot ;) )
See MWV and DBT tests at https://github.com/SignalK/signalk-parser-nmea0183/tree/delta-for-deep-paths/test
Talker id should be added to delta output.
Signal K specification states SI units and nmea0183 parser must be updated to produce SI units.
nmea0183-signalk crashes when processing GPRMC messages that are missing Magnetic Variation e.g.
$GPRMC,171302,A,3011.8466,N,08123.1192,W,0.5315,22.551,190215,,*08
~/signalk-server-node$ bin/nmea-from-file
signalk-server running at 0.0.0.0:3000
TypeError: Cannot call method 'toUpperCase' of undefined
at NMEA0183.magneticVariaton (/home/bobmor99/signalk-server-node/node_modules/nmea0183-signalk/lib/NMEA0183.js:116:15)
at null._decoder (/home/bobmor99/signalk-server-node/node_modules/nmea0183-signalk/codecs
... (keeping it brief)
No more crashes when I comment out the following line in
signalk-server-node/node_modules/nmea0183-signalk/codecs/RMC.js
{ path: 'magneticVariation', value: this.magneticVariaton(values[9], values[10]) },
My data source is gpspipe reading a BU-353 USB GPS.
A bunch of documentation available at SignalK/signalk-to-nmea0183#10 and for example at http://nke-marine-electronics.fr/wp-content/uploads/2017/01/28_Battery_Monitor_500_um_UK_12.pdf
The _transform method in lib/index.js doesn't work when NMEA sentences come in across multiple lines. Example: I have a GNS 1000 bluetooth GPS receiver at home, which emits NMEA sentences. However, sometimes a sentence comes in across multiple lines. The Transform stream should recognise this by detecting the beginning of a sentence ($) and the end *xx of a sentence.
I'll take a look at this tonight.
Currently, parser supports the following sentence types: APB, BWC, DBT, GGA, GLL, MWV, RMC, VTG and I started work on codecs for VDM, GBS, GSA, GSV and VDO. It doesn't take a lot of time to create codecs, but the more the merrier, so all help is welcome.
See #69
http://continuouswave.com/whaler/reference/DSC_Datagrams.html seems to provide info on the dsc expansion message DSE
/Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/codecs/DBT.js:65
value: (this.float(values[2]) - (vessel.dimensions.keel - vessel.dimensions
^
TypeError: Cannot read property 'dimensions' of undefined
at null._decoder (/Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/codecs/DBT.js:65:43)
at NMEA0183.decode (/Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/lib/NMEA0183.js:270:24)
at Parser._decode (/Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/lib/index.js:103:16)
at /Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/lib/index.js:144:23
at Function.forEach (/Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/node_modules/lodash/dist/lodash.js:3297:15)
at Parser._transform (/Users/Fabian/Dropbox/Sites/SignalK/nmea-signalk/lib/index.js:141:5)
at Parser.Transform._read (_stream_transform.js:179:10)
at Parser.Transform._write (_stream_transform.js:167:12)
at doWrite (_stream_writable.js:226:10)
at writeOrBuffer (_stream_writable.js:216:5)
Rewrite getTagBlock, GGA and GLL to avoid using moment, using code similar to var s = new Date(1331209044000).toISOString();
The parser clones the whole in memory object tree for each change event even if this data is never used by anything in the current server, as the server uses a separate Multiplexer to accumulate the tree from all sources.
The clone operation is heavy, especially so if there is a lot of data like when you have AIS data.
By changing Multiplexer.retrieve() to return the original tree I get about 10 times the throughput.
Some fix is needed for this. Everything would be a lot simpler if the parser did not use a Multiplexer at all but just emitted delta messages generated directly in the codec. If one should want to generate the tree one could just pipe the delta output to a Multiplexer, just like the server does.
Furthermore in case of AIS we will need to prune two trees, the one inside nmea0182 parser and the one in the server. Sounds like a lot of work to me.
Suggestions:
sentence and signalkevents, as I believe these are not used anywhere. This would remove the need for the retrieve() call.@fabdrol your thoughts?
Currently there is only one singleton Ais context and multiple parser instances will mess up this global state. Ais context should be per parser instance.
The parser currently outputs mmsi identities as plain numbers. They should be formatted per schema, example available at https://github.com/SignalK/specification/blob/master/test/data/identities.json#L7.
The parser feels too 'bloated' right now. Some features should be removed and others should be made smaller.
Todo:
The last comma-separated value of the sentence is not handled at all and therefore all logic such as MWV and GLL validity checks are broken. The effect is that at least MWV and GLL are not parsed.
At the moment the output are all just sub-objects of signalk, but that's not the desired behaviour. I should finish the implementation of lib/signalk.js asap to make this parser usable.
"sentence": "GGA",
"talker": "SK",
"type": "NMEA0183",
"label": "nmea0183:GGA"
}
label is off - it is for labeling a particular input and must not contain the sentence
talker must be derived from the original sentence and not be SK.
The navigational status list for hooks/VDM misses value 15, /Default or UNDEFINED)
The value would not be omitted and not reported if any of the listed alternatives is not fulfilled. Instead the default value 15 should be reported. See attached extract from IEC 61162-1
So a AIS class B would have a navigational status 15. (Now is path: "navigation.state" not present)
And not less a class A SART will report 14 if it's an active alarm but navigational status 15 if it's a test message. Rather crucial.
From hooks, VDM
const stateMapping = {
0: 'motoring',
1: 'anchored',
2: 'not under command',
3: 'restricted manouverability',
4: 'constrained by draft',
5: 'moored',
6: 'aground',
7: 'fishing',
8: 'sailing',
9: 'hazardous material high speed',
10: 'hazardous material wing in ground',
14: 'ais-sart'
};
if ( typeof data.navstatus !== 'undefined' ) {
var state = stateMapping[data.navstatus]
if ( typeof state !== 'undefined' ) {
values.push({
path: 'navigation.state',
value: state
})
}
Extract from IEC 61162-1:
Hello, complete newbie to signalk but I am stuck. This parser seems to be perfect for me as I have an AIS serving NMEA data over TCP port. Have been trying to configure this for a while but get nothing.
My source looks like this:
/ # telnet 192.168.1.11 2000
$GPRMC,115940.00,A,5950.15218,N,01028.58294,E,0.043,,120919,,,A72
!AIVDM,1,1,,B,H3mkqGQ>uV0mT00000000000000,229
!AIVDM,1,1,,A,402M3F;sW0h93PR7>T700<19,00C
!AIVDO,1,1,,,B3m6i=0008;wD2Sl59dCwl5oP06,0*4A !AIVDM,1,1,,B,H3mkqGTUDBE5847<7jonk0000000,0*19 $GPRMC,115941.00,A,5950.15213,N,01028.58299,E,0.033,,120919,,,A*72 !AIVDM,1,1,,A,33o=at0q@rPi1IHRAeTF@9q@03vC,0*01 !AIVDM,1,1,,A,33n@Kv00000hjBtR@S28Hi5D013h,0*70 $GPRMC,115942.00,A,5950.15205,N,01028.58307,E,0.069,,120919,,,A*7F !AIVDO,1,1,,,B3m6i=000H;wD3Sl55dCwm5oP06,036
!AIVDM,1,1,,A,402M3<1v>F;sa0i>S@RA<ow02<0U,05C
$GPRMC,115943.00,A,5950.15198,N,01028.58314,E,0.024,,120919,,,A72
!AIVDM,1,1,,A,H3mu5JPP5I=Dh40000000000000,251
!AIVDM,1,1,,A,13n=Mv?0000guaJR?CLE47=H0<0Q,076
$GPRMC,115944.00,A,5950.15198,N,01028.58313,E,0.025,,120919,,,A73
!AIVDM,1,1,,A,H3n?>j4UCBD69ol<7ppnm0105400,048
!AIVDM,1,1,,A,13m83KP000PiAnvRA63eG51D0<18,078
!AIVDO,1,1,,,B3m6i=0008;wD3Sl51dCwn5oP06,0*41 !AIVDM,1,1,,A,B3m7RiP008<0@SSU0nBgwn5oP06,049
!AIVDM,1,1,,B,33o=at0q0pPi1JdRAeEV@amH0000,024
$GPRMC,115945.00,A,5950.15198,N,01028.58313,E,0.034,,120919,,,A72
Just tried to set it up like this:
Do I have to install someting to get this parser to work? Thoght it was a part of the main release, but maybe it is a plugin? Is there some documentation for me to look into?
Thanks for any pointers!
For example:
$IIMWV,,,,*4C
TypeError: Cannot read property 'toUpperCase' of undefined
at null._decoder (/home/pi/signalk-server-node/node_modules/nmea0183-signalk/codecs/MWV.js:59:14)
at NMEA0183.decode (/home/pi/signalk-server-node/node_modules/nmea0183-signalk/lib/NMEA0183.js:236:24)
at Parser._decode (/home/pi/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:107:44)
at /home/pi/signalk-server-node/node_modules/nmea0183-signalk/lib/index.js:151:22
README doesn't provide any information on how to use this parser.
See for example https://gist.github.com/tkurki/4aa2795b7567ad6fd17e (from demo.signalk.org:3000).
@tkurki
The navigation state value e.g. "anchored" seems to not reflect actual status. I assume the value is not updated/released once set as long as one target is present in the "data base"?
My example here is the ship Oljaren. Here on the first shot you can see the anchorage state is set although it is not set in data coming in to SK. If I compare to what's streaming out via the TCP connection, i.e. a direct reflection of incoming data, the anchorage state is not. set.
Since the ship Oljaren was really anchored some 15 minutes before the actual shots I assume the state "anchored" is correctly set but not released when the VDM sentence no longer contain that info. Could my theory be correct?
If I let the SK data base be cleaned out from Oljaren, by another data stream, and restart the previous data stream Oljaren does not have state "anchored" until it is actually set. And then again it's never released.
Signal K connection:
TCP connection:
There is no nm => m conversion at https://github.com/SignalK/nmea0183-utilities/blob/master/index.js#L87-L88 and the conversion silently ignores missing conversions https://github.com/SignalK/nmea0183-utilities/blob/master/index.js#L136-L137.
Thus the conversions in these sentences never happen and the tests are using nautical miles.
Also related APB and BWR tests are written so that paths and values can be mixed up and the test will pass:
Readme is out of date after #11.
Furthermore the new module containing the command line utilities is missing.
STALK sentences about 0x50 (latitude) and 0x51 (longitude) datagrams are corrected parsed extracting the latitude and the longitude from the Raymarine Seatalk connection (I'm using the great Digital Yacht ST2NMEA USB converter).
The signalk-parser-nmea0183 component map SeaTalk latitude and longitude as follows:
"position": {
"meta": {
"description": "The position of the vessel in 2 or 3 dimensions (WGS84 datum)"
},
"latitude": {
"value": 40.76733333333333,
"$source": "USB0.ST",
"timestamp": "2019-08-19T11:31:30.207Z",
"sentence": "ALK"
},
"longitude": {
"value": 14.029,
"$source": "USB0.ST",
"timestamp": "2019-08-19T11:31:30.271Z",
"sentence": "ALK"
}
},
This approach worked fine with the previous version of the SK document schema (it was working in August 2018), but now the SK document schema states the following data structure for position:
"position": {
"meta": {
"description": "The position of the vessel in 2 or 3 dimensions (WGS84 datum)"
},
"value": {
"longitude": 14.029055,
"latitude": 40.767511666666664
},
"$source": "USB1.GP",
"timestamp": "2019-08-19T11:31:31.000Z",
"sentence": "RMC"
},
Apparently, with the new SK document schema it is mandatory update both latitude and longitude at the same time.
Basically the 0x50.js hook should know the value read from the previous execution if the 0x51.js hook and inject both latitude and longitude in the document and viceversa with 0x51.js and 0x50.js.
Bast regards.
Raffaele
The check in parse.js:
// The (MTK) CRC check doesn't report "invalid" if the input string contains the "<" character, even though it actually isn't valid.
if (sentence.includes('<')) {
valid = false
}
I see some VDM messages that contain this but parse fine if I remove the check, For example: !AIVDM,1,1,,A,352JPU@000JRU4<FCLvaEWOp0000,0*1B
When I run my GPS inside I get various bad RMC sentences (expected as the GPS has marginal coverage). Typical sentence has 0 for latitude and longitude, cog, etc
When the parser parses these sentences my vessel warp-drives off to Lat 0.0, Lon 0.0, just off ghana in africa :-(
Then it warps back a bit later... The vessel track shows the 'excursion' too :-(
The parser should check for 'A' or 'V' and discard bad data:
- RMC Recommended Minimum sentence C
[0] 123519 Fix taken at 12:35:19 UTC
[1] A Status A=active or V=Void.
[2][3] 4807.038,N Latitude 48 deg 07.038' N
...
It should always assume the message is void if 0.0 is in Lat and Lon. This will work for everywhere on earth but one place few of us will ever go :-)
It looks like the intent was to generate output in delta format but to be valid the data should not be encapsulated in a key called delta:
$ echo '$IIMWV,027,T,3.82,N,A*19' | ./bin/nmea0183-signalk
{"delta":{"updates":[{"source":{"sentence":"MWV","talker":"II","type":"NMEA0183"},"timestamp":"2017-11-13T01:42:15.933Z","values":[{"path":"environment.wind.speedTrue","value":1.965178275622941},{"path":"environment.wind.angleTrueWater","value":0.47123889814606673}]}]}}
This is not valid signalk per the schema.
Instead, I would expect to get:
{"updates":[{"source":{"sentence":"MWV","talker":"II","type":"NMEA0183"},"timestamp":"2017-11-13T01:34:24.641Z","values":[{"path":"environment.wind.speedTrue","value":1.965178275622941},{"path":"environment.wind.angleTrueWater","value":0.47123889814606673}]}]}
This is what the n2k-signalk parser does:
$ echo '$PCDIN,01F513,000C9F5D,23,FFFFFFFFFFFF7F3204007F320400*5C' |~/work/canboat/rel/linux-x86_64/analyzer -json |~/work/n2k-signalk/bin/n2k-signalk
INFO 2017-11-13T01:50:13.350Z [analyzer] New PGN 128275 for device 35 (heap 9973 bytes)
{"updates":[{"source":{"label":"","type":"NMEA2000","pgn":128275,"src":"35"},"timestamp":"1969-12-31T16:13:47,229","values":[{"path":"navigation.trip.log","value":275071},{"path":"navigation.log","value":275071}]}]}
PR coming up.
In the current SK spec, multiple engines reporting RPM are recorded like this:
propulsion.engine1.revolutions
propulsion.engine2.revolutions
propulsion.engine3.revolutions
etc
In the current RPM hook a delta is created with propulsion.engine1.revolutions hardcoded as the path. This is an issue, there are more than one engines. We need a way to indicate, to the hook, what source the data is coming from and how that should affect the resulting delta.
One way is to use context, and to allow the parser to be instantiated with a different context both at the global level (e.g. new Parser({ context: '...' }) and at the individual sentence-level (e.g. parser.parse(sentence, '<context>')).
The new parser is not generating the proverbial object valued position delta properly.
{
"path": "navigation.position.longitude",
"value": -122.03782631066667
},
{
"path": "navigation.position.latitude",
"value": 37.39109795066667
}
should be
{
"path": "navigation.position",
"value": {"longitude":-122.03782631066667, "latitude":37.39109795066667}
}
Running bin/nmea-from-file, /api/v1 shows most (but not all) of the dates in the date-timestamps to be exactly one month in the future. Line #159 in lib/NMEA0183.js adds 1 to the system month. Perhaps it's a development artifact for easy differentiation of the date-time sources in the JSON message. Removing the +1 from line #159 results in current month in the JSON date-time stamps.
month = dt.getUTCMonth() + 1;
{
"self": "10101010",
"version": 1,
"vessels": {
"10101010": {
"uuid": "10101010",
"navigation": {
"speedThroughWater": {
"value": 3.1416666666666666,
"source": {
"type": "NMEA0183",
"src": "VHW",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-04-08T23:38:12.000Z"
},
"courseOverGroundMagnetic": {
"value": 217.4,
"source": {
"type": "NMEA0183",
"src": "VTG",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-04-08T23:38:12.000Z"
},
"courseOverGroundTrue": {
"value": 217.4,
"source": {
"type": "NMEA0183",
"src": "VTG",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-04-08T23:38:12.000Z"
},
"speedOverGround": {
"value": 2.999211870911452,
"source": {
"type": "NMEA0183",
"src": "VTG",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-04-08T23:38:12.000Z"
},
"position": {
"source": {},
"timestamp": "2015-03-08T23:38:12.514Z",
"longitude": 23.537783333333334,
"latitude": 60.08383333333333
}
},
"environment": {
"wind": {
"angleApparent": {
"timestamp": "2015-04-08T23:38:12.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": -16
},
"speedApparent": {
"timestamp": "2015-04-08T23:38:12.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": 7.299968515992024
},
"source": {},
"timestamp": "2015-03-08T23:38:12.915Z",
"angleTrue": {
"timestamp": "2015-04-08T23:38:12.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": -30
},
"speedTrue": {
"timestamp": "2015-04-08T23:38:12.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": 4.218445513117308
}
},
"depth": {
"belowTransducer": {
"source": {
"type": "NMEA0183",
"src": "DBT",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-04-08T23:38:12.000Z",
"value": 10.79
},
"source": {},
"timestamp": "2015-03-08T23:38:12.413Z"
}
}
}
}
}
month = dt.getUTCMonth();
{
"self": "10101010",
"version": 1,
"vessels": {
"10101010": {
"uuid": "10101010",
"navigation": {
"speedThroughWater": {
"value": 3.1277777777777778,
"source": {
"type": "NMEA0183",
"src": "VHW",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-03-08T22:41:04.000Z"
},
"courseOverGroundMagnetic": {
"value": 229.43,
"source": {
"type": "NMEA0183",
"src": "VTG",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-03-08T22:41:04.000Z"
},
"courseOverGroundTrue": {
"value": 229.43,
"source": {
"type": "NMEA0183",
"src": "VTG",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-03-08T22:41:04.000Z"
},
"speedOverGround": {
"value": 3.0352229911453805,
"source": {
"type": "NMEA0183",
"src": "VTG",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-03-08T22:41:04.000Z"
},
"position": {
"source": {},
"timestamp": "2015-03-08T22:41:03.861Z",
"longitude": 23.538533333333334,
"latitude": 60.084266666666664
}
},
"environment": {
"wind": {
"angleApparent": {
"timestamp": "2015-03-08T22:41:04.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": -21
},
"speedApparent": {
"timestamp": "2015-03-08T22:41:04.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": 6.795812832717029
},
"source": {},
"timestamp": "2015-03-08T22:41:04.363Z",
"angleTrue": {
"timestamp": "2015-03-08T22:41:03.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": -42
},
"speedTrue": {
"timestamp": "2015-03-08T22:41:03.000Z",
"source": {
"type": "NMEA0183",
"src": "MWV",
"label": "signalk-parser-nmea0183"
},
"value": 4.10526770666782
}
},
"depth": {
"belowTransducer": {
"source": {
"type": "NMEA0183",
"src": "DBT",
"label": "signalk-parser-nmea0183"
},
"timestamp": "2015-03-08T22:41:03.000Z",
"value": 10.5
},
"source": {},
"timestamp": "2015-03-08T22:41:03.761Z"
}
}
}
}
}
$GPGGA,200255.00,5310.81257,N,00525.70577,E,2,09,1.12,3.5,M,45.7,M,,0000*5A
generates
{
"context": "vessels.4F443093",
"updates": [
{
"source": {},
"timestamp": "2017-09-10T18:41:29.063Z",
"values": [
{
"path": "navigation.gnss",
"value": {
"source": {
"type": "NMEA0183",
"sentence": "GGA",
"label": "signalk-parser-nmea0183",
"talker": "GP"
},
"timestamp": "2017-09-10T20:02:00.000Z",
"quality": 2,
"satellites": 9,
"antennaAltitude": 3,
"horizontalDilution": 1,
"geoidalSeparation": 45,
"differentialAge": 0,
"differentialReference": 0
}
}
]
}
]
}
where real source is empty and the source data is under value.
Ref. dd98b66#commitcomment-25275242 One solution would be to load all mappings on start like https://github.com/SignalK/n2k-signalk/blob/master/n2kMappings.js
For example
!AIVDM,2,1,5,A,53KQ<L01pv7ptTtN22059@DlU>2222222222220l1@D555V00:R0CRkp8888,0*41
!AIVDM,2,2,5,A,88888888880,2*21
is an AIS message that is two VDM lines. Current implementation assumes naively that all AIS messages are just a single NMEA message and outputs empty values in full & delta messages.
This is mostly for logged data. I have some logs of nmea0183 data from kplex with tags for source and epoch time. I would love to get these into influxdb with correct timestamp, and to produce polar diagrams with traceable input.
I'm not sure yet what this would require of changes to implement, but the presence of a tag with timestamp may have to be checked already in lib/index.js and not added in each codec as now.
Currently any sentence with a tag block is ignored, which is perhaps not ideal, since it is valid from v4 of nmea0183. http://www.stripydog.com/kplex/configuration.html#tag
From kplex:
If source identifier and timestamps are both requested for an interface, they are combined into a single TAG block, source identifier first, e.g.: \s:kplex,c:1423133048*5F\
To get proper support for XDR we could first document some of the sentences out there and then create a solution that works well for them and can be easily extended to cover other sentences.
In practice this is probably another mapping level not unlike the one we have for codecs.
RMC is producing invalid delta for position. The source and timestamp are incorrectly in value:
`$GPRMC,200309.00,A,5310.81264,N,00525.70578,E,0.009,,160414,,,D*73``
=>
{
"context": "vessels.4193B873",
"updates": [
{
"source": {},
"timestamp": "2016-12-29T06:25:33.911Z",
"values": [
{
"path": "navigation.position",
"value": {
"source": {
"type": "NMEA0183",
"sentence": "RMC",
"label": "signalk-parser-nmea0183",
"talker": "GP"
},
"timestamp": "2014-05-16T20:03:09.000Z",
"longitude": 5.428429666666666,
"latitude": 53.18021066666667
}
}
]
}
]
}
There are several explicit cases where a sensor can indicate that it is otherwise operational but can not produce vali ddata. Example cases are a depth sounder that can not discern bottom from the echo data and a GNSS that has no satellite fix.
In these cases a gateway/server will typically receive a message indicating invalid data. It must send out a delta message where the value of the data item is null and serve the value as null in the REST api.
/tmp $ npm install SignalK/signalk-parser-nmea0183
npm ERR! Darwin 13.4.0
npm ERR! argv "node" "/usr/local/bin/npm" "install" "SignalK/signalk-parser-nmea0183"
npm ERR! node v0.10.28
npm ERR! npm v2.1.1
npm ERR! path /private/tmp/node_modules/nmea0183-signalk/bin/nmea-signalk
npm ERR! code ENOENT
npm ERR! errno 34
npm ERR! ENOENT, chmod '/private/tmp/node_modules/nmea0183-signalk/bin/nmea-signalk'
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR! http://github.com/npm/npm/issues
npm ERR! Please include the following file with any support request:
npm ERR! /private/tmp/npm-debug.log
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.