[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-users] gpsd and shared memory

From: Roger Oberholtzer
Subject: [gpsd-users] gpsd and shared memory
Date: Thu, 1 Oct 2015 05:38:16 +0000

I have an application that currently parses NMEA strings it reads from a serial port. Amongst other things, it uses the locations discovered there to decide when a moving vehicle is as close as it is going to get to a pre-determined location. When it it determined that the vehicle is at the location (or as near as it will be based in the current trajectory), it initiates some activity. Our goal is to have this action be as close as possible to the location as it can be.

This application has been modified to obtain NMEA strings via the gpsd RAW stream (chrony and Navit are also clients of gpsd). This seems to be working as expected. But I am wondering...

Our application has a heart beat. Each meter of vehicle movement (from a wheel-mounted pulse transducer) it decides if it should initiate said activity. So the decision is really based on the last GPS idea of how far we are from the location, combined with meters of vehicle movement.

Would I be wasting my time to use the gpsd shared memory segment each meter to decide where the vehicle is? I have these concerns:

  -  When parsing a 10 Hz NMEA stream (i.e., GGA records at 10 Hz), what kind of delay might there be from when the NMEA record became available on the serial port and when information about location is updated in shared memory? Would there be an update pretty much at the frequency of the GGA records? I know that gpsd looks at a number of records when deciding some things.

 - Even though I could read the shared memory segment each meter, I guess I would need to know the UTC time that the location in memory applies to. Are the locations and UTC time so connected in memory? I am not totally certain I need to know this. But I would imagine if there is a location in memory, I need to know when that location applies to. It is not when I read it. OTOH, if the shared memory location is updated at the frequency of the GGA records, perhaps I don't need to worry about the time. Our current NMEA solution considers the last GGA record to be 'now'.

I often read that the JSON stream is the preferred one. In my application, using the JSON stream would not really get me much over the existing NMEA method that is working. I have been interested in the shared memory approach because the application would not need to parse the GPS data (NMEA or JSON).

Roger Oberholtzer
RST Systems
Office: +46 (0)10-615 6020
Mobile: +46 (0)70-815 1696
Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]