gpsd-users
[Top][All Lists]
Advanced

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

Re: [gpsd-users] gpsd and shared memory


From: Roger Oberholtzer
Subject: Re: [gpsd-users] gpsd and shared memory
Date: Fri, 2 Oct 2015 06:07:49 +0000

________________________________________
From: Gary E. Miller address@hidden
Sent: Thursday, October 01, 2015 8:53 PM
To: Roger Oberholtzer
Cc: address@hidden
Subject: Re: [gpsd-users] gpsd and shared memory

> The main component of the delay is the speed of the serial port itself.  So 
> the main thing to do is get that as fast as possible. Beyond that interrupt 
> latency in the CPU is the next biggest factor, so multi-core helps a lot.  
> Once gpsd has the data its time to process is tiny, on the order of micro 
> Seconds on any 64 bit cpu.

The delay once gpsd has the NMEA record was my real question.

> Correct, that data is the same, it is just a lot easier to parse a JSON 
> stream than a binary one.  If you use the libgps the that is all hidden from 
> you anyway.

OOC, how could the binary stream be more difficult? DBUS_TYPE_DOUBLE are IEEE 
547. Same as Linux and Windows use. So it is just to define a structure for the 
segment and access the values. No parsing is needed.

> Yeah, you just need to track the ABI, which has not been stable, and decode 
> binary structures defined by C code.  Or use libgps and not worry about it.

This would be the trickiest part...

That and properly detecting of the shared memory contents changed in the midst 
of being accessed.

Roger Oberholtzer

RST Systems

Office: +46 (0)10-615 6020
Mobile: +46 (0)70-815 1696
address@hidden
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se




reply via email to

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