Author Topic: A simple GPS data API structure?  (Read 475 times)

0 Members and 1 Guest are viewing this topic.

Online peter-h

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: gb
  • Doing electronics since the 1960s...
A simple GPS data API structure?
« on: April 18, 2021, 09:24:56 am »
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 missing :)

I 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.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 90S1200 32F417
 

Online peter-h

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: gb
  • Doing electronics since the 1960s...
Re: A simple GPS data API structure?
« Reply #1 on: April 18, 2021, 01:04:09 pm »
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.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 90S1200 32F417
 

Offline jc101

  • Frequent Contributor
  • **
  • Posts: 387
  • Country: gb
Re: A simple GPS data API structure?
« Reply #2 on: April 18, 2021, 06:42:09 pm »
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.
 

Online peter-h

  • Frequent Contributor
  • **
  • Posts: 994
  • Country: gb
  • Doing electronics since the 1960s...
Re: A simple GPS data API structure?
« Reply #3 on: April 18, 2021, 07:24:43 pm »
Yeah... I have spent a few months this year doing the UBLOX PUBX stuff :) There 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.

« Last Edit: April 18, 2021, 07:39:35 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 90S1200 32F417
 

Offline radiogeek381

  • Regular Contributor
  • *
  • Posts: 93
  • Country: us
    • SoDaRadio
Re: A simple GPS data API structure?
« Reply #4 on: April 28, 2021, 06:41:13 pm »
If you're working with Linux, have you looked at https://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.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf