A simple GPS data API structure? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: April 18, 2021, 09:24:56 am
content: I am working on a little project which has a GPS (NMEA, or U-BLOX proprietary) on a serial port.I am hoping to do a useful API for the GPS.Googling around, I can see various obscure attempts, and there there is the huge gps_data_t definition which uses uint64_t for most things and I bet most implementations have most of the stuff in it missingI also wonder how to make this thread-safe, given that the GPS is running in another thread and updating the data (in another structure I currently have) asynchronously. That structure has an "data updated" flag which you clear after reading it.

author: peter-h
author_rank: Super Contributor
timestamp: April 18, 2021, 01:04:09 pm
content: Sure; no problem with uint64_t. This is a 168MHz ST32F417. But things like lat/long are much more useful as floats. In fact you want double floats for this, to make full use of the possible accuracy/resolution of GPS. Passing integers just has to make assumptions about the minimum step size. Maybe gps_data_t is something really old.

author: jc101
author_rank: Frequent Contributor
timestamp: April 18, 2021, 06:42:09 pm
content: I have been writing a parser to extract U-Blox UBX packets, which has been fairly simple to achieve. The protocol specification is clearly written and enables data to be ingested directly into structures and unions in C.I parse the incoming serial stream from the GPS in a task, and once it has picked out a UBX packet this is sent to a different task for decoding. It does this with a state machine looking for the structure that the UBX protocol adheres to. The decoder task can then send data onwards or update other structures. I ignore all the NMEA packets, as I can get all I need from the UBX protocol.

author: peter-h
author_rank: Super Contributor
timestamp: April 18, 2021, 07:24:43 pm
content: Yeah... I have spent a few months this year doing the UBLOX PUBX stuffThere is a lot to learn and a lot of weird stuff. Like the way EGNOS sats are reported... not same was WAAS ones. No support except by one guy on the UBLOX forum and he doesn't even work for them afaict. In the end I ended up parsing PUBX00, PUBX03 and one of the binary ones to get the sat status. I disabled all the other NMEA stuff. A lot of code... then I needed the DATE and that comes in the NMEA RMC packet so I had to enable that one. Also I need 5Hz and at 38400 you quickly reach some 50% of the port bandwidth at 38k, especially with 20+ sats being reported.Anyway - all working now. I even generalised the code so it works with a non-UBLOX GPS, and then it sees only the RMC packet, used for date/time. I use this for setting the RTC, at some specified hour each day.I was just looking for some standard API but there isn't anything really good. The basics are easy (date/time, lat, long, alt) but there is other stuff e.g. hdop vdop, hacc, vacc, whether SBAS is being used, and so on. So I will do my own one, which uses doubles for the coordinates and floats for much of the rest.

author: radiogeek381
author_rank: Regular Contributor
timestamp: April 28, 2021, 06:41:13 pm
content: If you're working with Linux, have you looked athttps://gpsd.gitlab.io/gpsd/? It is a gps deamon (that listens to the GPS widget) and a library interface.There are some crunchinesses to the software, but it gets run on lots and lots of different GPS units that run NMEA and other protocols.