Parsing a new NMEA device.
Traccar logs?
Here's the line I pulled it from:
2021-02-10 00:56:09 INFO: [b6906481: t55 < xxx.xxx.xxx.xxx] HEX: 244944454e542c313234352a37632447504747412c3030353630362e302c333934312e3832383838382c4e2c31303434382e3834313732342c572c312c30392c302e392c313638332e392c4d2c2d32312e302c4d2c2c2a35302447504753412c412c322c30322c30362c31332c31342c31372c31392c32342c32382c33302c2c2c2c312e322c302e392c302e382a33332447504753562c342c312c31352c30312c30392c3033362c32312c30322c31362c3139392c32352c30332c31302c3037332c32332c30362c34372c3137322c33302a37302447504753562c342c322c31352c31332c30362c3232342c32392c31342c34302c3039392c32362c31352c30312c3235382c32312c31372c36332c3032392c33342a37332447504753562c342c332c31352c31392c37342c3330392c33372c32322c30362c3034392c32342c32342c33352c3239392c33312c32382c34392c3039312c32342a37422447504753562c342c342c31352c33302c31302c3136302c32392c34362c2c2c33322c31322c30372c3239382c2a3737244750524d432c3030353630362e302c412c333934312e3832383838382c4e2c31303434382e3834313732342c572c302e302c302e302c3130303232312c372e352c452c412a31302447505654472c302e302c542c3335322e352c4d2c302e302c4e2c302e302c4b2c412a32322447505a44412c3030353630362e30302c31302c30322c323032312c30302c35362a3632And here's what the decoder outputs:
$IDENT,1245*7c$GPGGA,005606.0,3941.828888,N,10448.841724,W,1,09,0.9,1683.9,M,-21.0,M,,*50$GPGSA,A,2,02,06,13,14,17,19,24,28,30,,,,1.2,0.9,0.8*33$GPGSV,4,1,15,01,09,036,21,02,16,199,25,03,10,073,23,06,47,172,30*70$GPGSV,4,2,15,13,06,224,29,14,40,099,26,15,01,258,21,17,63,029,34*73$GPGSV,4,3,15,19,74,309,37,22,06,049,24,24,35,299,31,28,49,091,24*7B$GPGSV,4,4,15,30,10,160,29,46,,,32,12,07,298,*77$GPRMC,005606.0,A,3941.828888,N,10448.841724,W,0.0,0.0,100221,7.5,E,A*10$GPVTG,0.0,T,352.5,M,0.0,N,0.0,K,A*22$GPZDA,005606.00,10,02,2021,00,56*62I think the biggest issue here is that the messages are not divided by line breaks.
Oh, joy!
I'm not great with NMEA, I'm more used to dealing with the freematics devices and mucking about with their output. I assume that line breaks are going to be important, then?
Yes, line breaks are needed to know where one message ends and the other begins.
Right, separating out the sentences.
I'm reading specs now. I'm guessing that the *<hex number> at the end of each sentence is supposed to be the checksum that's mentioned?
Yes, that's a checksum.
ROIGHT THEN! Time to go chew some manufacturer behind!
"Yes, line breaks are needed to know where one message ends and the other begins."
Would it be possible to be forgiving, and accept $ or ! as the start of a message, and thereby the end of the previous message?
It's not as easy as that. It will break some other formats that we already support.
As far as I can see, all messages start with $GP.
I think that should be possible to, if processing fail, then replace $GP with \n$GP and try again.
Also, if number of \n = 1 then do the insert of \n,
But I haven't examined the code, so I could be wrong ;-)
That would put traccar out of spec with the standard. NMEA standard requires that each line start with the starting marker of $ or !, yes, but they must also end with an <LF> signifying the termination of the NMEA Sentence. As $ or ! can be used in other parts of the sentence, you could end up with corrupted sentences and cause unforeseeable problems within traccar or another application.
In addition, it's often a developer "being forgiving" that leads to software having security holes. See for reference: https://xkcd.com/327/
Matt and anyone else sho are seeing this as the only search result for Skyus and Traccar. NMEA isn't working for me but I put the SKYUS 160 into taip mode and got data flowing to port 5031.
Doesn't quite answer your question but for what I need this worked fine. I have a handful of these devices in vehicles and just wanted basic location reporting.
I have the following HEX from an Inseego Skyus 160 reporting NMEA. Can anyone help me get it to parse so traccar will recognize it? I've run it through the HEX Decoder and there is a valid $IDENT, but traccar doesn't seem to recognize the device ID.