Any way to display the Library version number for reference?

[dagnall53]

Timo. Is there some variable in the libraries that can report the N2000 /0183 Library dates or versions used during compile?

I would like to add some text on a web page to indicate the actual version of your N2000 / 0183 libraries that have been used in the compile. Similar to the ESP_ARDUINO_VERSION_MAJOR that indicates which ESP32 compiler was used (VERY USEFUL now that V3.x.x is incompatible with previous versions!!). I looked for a "Version" #define hidden in the 0183 and N2000 libraries, but maybe you have something already set ??

Dagnall

PS: Many thanks for help with leading zeros.. I am astonished that no one has had that issue before, but I suppose there really are not many people with N2000 GNSS that convert to 0183 - and then have a 0183 product that needs the leading zero!.

I have not found a a "Version" #define hidden in the 0183 and N2000 libraries that we can access and print / use/.. Is there some variable that can report the Library date or version?

[ttlappalainen]

Not for now. NMEA2000 and NMEA0183 ibraries are not depending of versions. E.g., NMEA2000_esp32 has some depends. So that table should belong there.

I do not completely understand how they read values. If you take value between commas and read it with atof, it does not matter if it has leading 0 or not. Maybe they use some old fixed position code. So maybe others has just used simpler field reader.

Library version is on library.json. On NMEA0183 only on Arduino old style library.properties.

[dagnall53]

Regarding the dddmm. I think some (VHF) 0183 codes must look for the decimal and then take the next two left characters as the minutes, and "anything else" as the degrees. But I presume the problem VHF took the first three (most significant) characters as degrees.. and "anything left" as minutes.

Regarding "Versions" I realise your libraries are not affected by the ESP compile changes (Lucky you!! ) as you do not use any of the functions that they changed (at least I hope so). However, I did note that the ronzeiler AIS library needed some changes to keep up with you! (https://github.com/ronzeiller/NMEA0183-AIS/issues/7).

I collaborate with a colleague who prefers "proven" libraries and is reluctant to update unless a fault is discovered (an understandable and admirable view!) and it would be helpful in fault finding to be able to check which versions of your libraries we used when compiling - if and when we discover faults.

FYI: (but you probably were aware) The ESP32 compilers have three #defines, ESP_ARDUINO_VERSION_MAJOR, ESP_ARDUINO_VERSION_MINOR and ESP_ARDUINO_VERSION_PATCH that are manually modified when they update. Users can then use these to display etc as needed.

[ttlappalainen]

Just usign atof: double val=atof(s); double deg=floor(val/100); val=deg+(val-deg*100.0)/60.0; return val; Naturally needs some more checking as in NMEA0183Messages/NMEA0183GetDouble

"Proven libraries" is funny definition. I have proven libraries. Many "proven" CAN libraries does not work properly with NMEA2000, so I had to rewrite them.

[dagnall53]

Hi.. I think we are at slight cross purposes and have slight misunderstanding- but no worries!: I have no problem with your Libaries! I just think the RMC needs (updating to add?) leading zeros as per suggestion! %09.3f and %08.3f etc. We can manually check we are using your latest and corrected versions before compiling!

The (Faulty imho) decode of the RMC in the Standard Horizon VHF that started this is not under my control. I was just speculating as to possible reasons for their misinterpretation when presented with missing leading zeros. It may be due to Standard horizon not using atof (or failing to use it properly?) - but I have no idea. I use your functions for 0183<>N2k and have no problems! I still find it strange no one else had previously noted this combination of N2k GPS to 0183 gives issues with this VHF.

[ttlappalainen]

I am actually wondering should this be changed to library or not. So either it has not been used or had not caused problems for others. Question now is that if it has been used and I change it, will others work or will they use some complex reading method, which does not expect leading 0 and then brake reading.

I also tried to find is there clear definition that there should be leading 0. One definition says: $--RMC,hhmmss.ss,A,ddmm.mm,a,dddmm.mm,a,x.x,x.x,xxxx,x.x,a,m,s*hh so in a way that defines that there should be leading 0.

[ttlappalainen]

Same source says for GGA $--GGA,hhmmss.ss,ddmm.mm,a,ddmm.mm,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxxhh for GLL $--GLL,ddmm.mm,a,dddmm.mm,a,hhmmss.ss,a,mhh

So should actually have standard, where to check. Unfortunately even them has written errors.

[dagnall53]

I strongly suspect that the GGA reference is a simple typo error and should be dddmm.mm. Or else it would severely limit where in the world the GGA message could be used :-). !!! Cheers!! Dagnall