jacketizer / libnmea Goto Github PK

It should be possible to select at build time which modules to build and install, for both dynamic and static mode.

It should be possible to select which parser modules to load at run time (dynamic mode). Now all of the installed modules are loaded. A work around for this is to use the environment variable NMEA_PARSER_PATH to load a different set of modules.

When building in xcode i am getting this error.

The get_parser functions are now implemented by iterating through the parser list. This could maybe be optimized by sorting the list by type ID or similar.

Hardcoded libpaths do not jive well with various environments.
Please use CMake standard install definitions and methods for installing properly.
Consider providing a pkg-config file for a shared library.

I am a coding novice. Please add a parser for $GPZDA. I am building a precision GPS Clock using an U-Blox NEO-M8N GPS Clone on a PIC18F4550 MCU with a 2004 HD44780 LCD Display. Thank you for your help.

Release version for build environments.
Some users prefer a release version number, properly stashed as a tarball, over a git hash or tag/branch.

I've ran into this more than a few times already during development, that when NMEA_PARSER_PATH is not set correctly, no modules are loaded. In this situation, parsing of any NMEA message silently fails.

This is perfectly legal, but sets one on a somewhat lengthy troubleshooting path: why didn't the message get parsed? why didn't the message type get detected? why no parsers loaded? ah, because shared libraries haven't been found!.

What doesn't help is that the parser loading happens from a constructor function, where it isn't possible to do anything about the return value of nmea_load_parsers:

In my opinion, the best solution would be to deprecate the automatic loading of parsers, and let the application call nmea_init and nmea_cleanup explicitly, as it is common for C libraries. Then an error code could be returned to the application from nmea_init, indicating for example that no parsers were loaded. This would be a breaking change for existing projects, though. Given that libnmea is pre-1.0, this might still be acceptable, assuming that semver is followed?

The next best solution seems to be to add a function nmea_get_parser_count or similar, which would return the number of parsers loaded. The application can then check if the value is zero and bail out with a human-readable error message if it is.

I can submit a PR for either of the solutions, but would like to get @jacketizer's advice and approval first.

It is stated that

 /* NMEA sentence max length (chars) */
#define NMEA_MAX_LENGTH     255 

But the standard document IEC 61162 says that max length for NMEA 0183 is 82 chars including carriage return.

It should be possible to compile with an option that loads the selected parser modules at compile time instead of run time. This disables the dynamic loader in the code. It should be investigated if this is doable in a good and simple way. The reason for this is to make the library usable in environments where a dynamic loader isn't available.

The newlib strptime() implementation on that platform is a bit too crude, and thus will parse all content into the first argument.
I have a simple fix that copies the date or time string into a token separated string that the newlib strptime() can parse correctly. However, that seems a bit messy and considering that a similar problem can occur on other platforms I was wondering if another solution would be preferable? Such as a simpler implementation not using strptime() but instead parsing the time and date fields itself?

Hi,

First of all, thanks for your work. I have compiled static version and tried to use in my project, which is for tracking vehicles. After parsing nmea just degrees and minutes is not enough, It would be good to have double precision numbers like for lat 49.164512 and for lon 21.160322

Best Regards
Marek

Hi

We have been using the libnmea library on with esp32 and compiling using gcc make.
That has been working fine.

Now I am trying to get compiling working with Cmake.
All other components are now working, except the libnmea.
From it comes lot of problems starting from the thing that it is make for really old Cmake version 2.8 and now I have 3.19 in use.

Do you happen to have newer Cmake file for libnmea ?

BR Juha T.

Now when it is possible to statically link the parser modules at build time, it would be great with support for Arduino.

If not all of the parser modules are selected at run time, the get_parser_by_x functions are not looping through the entire list of parsers, which is sorted after type and not load time, and may the miss the desired parser. This issue is fixed in the static parser loading and could be fixed in a similar way.

How can I detect if device has taken a turn using GPS location.
Is comparing previous & current azimuth value will give me a result ?
Ex:
int precision = 10;
if ( (nmeaMathRadianToDegree(azimuth[it][0]) - nmeaMathRadianToDegree(azimuth[it][1]) ) < precision * -1)
cout<<"Taken -> RIGHT"<<endl;
else if ( (nmeaMathRadianToDegree(azimuth[it][0]) - nmeaMathRadianToDegree(azimuth[it][1]) ) > precision)
cout<<"Taken -> LEFT"<<endl;

As it stands, the only way this library can be linked from C++ is to do the following:

extern "C" {
#include <nmea.h>
#include <nmea/gpgll.h>
#include <nmea/gpgga.h>
}

which is fine, except that it shouldn't be incumbent on the user to do so. Instead, the C linkage is usually taken care of within the header. Will you consider adding this to the headers so that the users do not have to spend hours figuring out why they keep getting errors like this:

...: undefined reference to `nmea_parse(char*, unsigned long, int)'
...: undefined reference to `nmea_free(nmea_s*)'

Looks like the makefile doesn't properly compile the unit-tests:

ben@bendev:~/nmea-tool/libnmea-master$ make check
export LIBRARY_PATH="build";
export C_INCLUDE_PATH="build";
export LD_LIBRARY_PATH="build";
export NMEA_PARSER_PATH="build/nmea/"
make unit-tests
make[1]: Entering directory `/home/ben/nmea-tool/libnmea-master'
cc tests/unit-tests/test_lib.c -lnmea -o utests
tests/unit-tests/test_lib.c:5:18: fatal error: nmea.h: No such file or directory
 #include <nmea.h>
                  ^
compilation terminated.
make[1]: *** [unit-tests] Error 1
make[1]: Leaving directory `/home/ben/nmea-tool/libnmea-master'
make: *** [check] Error 2

I don't think the exports under the check target in Makefile work like this:

        export LIBRARY_PATH="$(BUILD_PATH)";
        export C_INCLUDE_PATH="$(BUILD_PATH)";  
        export LD_LIBRARY_PATH="$(BUILD_PATH)";
        export NMEA_PARSER_PATH="$(BUILD_PATH)/nmea/"

Hello Jack,

First of all thank you very much for sharing this library which is pretty easy to understand even though I'm just a beginner. I'm using your library to parse nmea 0183 sentences coming from a gps and flarm module on the Raspberry PI and i have a issue which i need to fix. In the example program (minimum.c) you feed the parser with a gpggl sentence ending with "/n/n" but as you mention in the nmea.h (line 44) :

/* NMEA sentence endings, should be \r\n according the NMEA 0183 standard */

#define NMEA_END_CHAR_1		'\n'
#define NMEA_END_CHAR_2		'\n'

As my Nmea sentences end with /r/n the nmea_validate function rejects my sentence.
I've also tried to change NMEA_END_CHAR_1 to '\r' without sucess.

Please let me know how to handle this

Thank you in advance , Laurin

When I do: make && make check i get this error message:

Building build/libnmea.so
gcc -shared -fvisibility=hidden -Wl,--exclude-libs=ALL,--no-as-needed,-soname,libnmea.so -Wall -g -ldl  src/nmea/nmea.o  src/nmea/parser.o -o build/libnmea.so
ld: unknown option: --exclude-libs=ALL

This exception occurs because MacOS doesn't support --exclude libs as it does Linux.

Hi guys!

Is there a specific reason for why the "Horizontal Dilution of precision"-field is not included when the GGA sentence is parsed?

Could it possibly be added? If its possible and there is no specific reason why its not included I could try to add it myself and create a pull request if you're to busy and thats okay for you :)

The file parser.c has this towards the top of it:

/**
 * Where to find the parser modules.
 * Can be overridden by env variable NMEA_PARSER_PATH
 */
#define PARSER_PATH "/usr/lib/nmea/"

So if you are not putting your parser .so files in /usr/lib/nmea, you will need to define the variable NMEA_PARSER_PATH.

The readme should mention this.

This works:

nmea.c.txt

I got an error thrown when compiling a C/C++ project for a STM32 platform. I excluded the parser.h/c files from the compiler paths as I don't want to use the dynamic parser.
In parser_static.c I get the following error:
parser_static.c:49:30: error: 'PARSER_COUNT' undeclared here

How to fix this?

It is mentioned here https://github.com/jacketizer/libnmea/blob/master/src/nmea/nmea.h#L45

/* NMEA sentence endings, should be \r\n according the NMEA 0183 standard */
#define NMEA_END_CHAR_1		'\n'
#define NMEA_END_CHAR_2		'\n'

That the sentence ending should be \r\n, however the code and examples define it as \n\n. I'm getting nmea GPRMC sentences from my equipment as \r\n I was wondering if this changes from vendor to vendor? Maybe we can change the code to accept both \r\n and \n\n.

This doesn't work, it only prints the latitude.

	    if (nmeadata->type == NMEA_GPRMC) {
	        nmea_gprmc_s *gprmc = (nmea_gprmc_s *) nmeadata;
	        printf("Latitude: %5f\t Longitude: %5f\n", gprmc->latitude, gprmc->longitude);
	    }

However if you print the longitude with another printf call, it works.