Re: GPS drivers (was Re: [PATCH v2 0/9] Serial slave device bus)

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

Hi!

> >> In my simple opinion GPSes shound live in drivers/iio/gps simply by
> >> usecase association: streaming out a series of accelerometer readings
> >> periodically through IIOs chardevs and other data about the physical
> >> world is not any different from the GPS usecase that give you a stream
> >> of coordinates on where on this planet you are.
> >
> > That is... not quite how GPSes work. What interface would you propose?
> > It would be good to support error estimates in position/velocities and
> > AGPS data upload.
> 
> Sorry for my ignorance. I have not had the opportunity to work
> directly with a GPS hardware.

Few people have. It is CDMA corelators at the low level. 

> > Now, NMEA knows about some of the complexity (not AGPS), but gets the
> > details wrong. In particular, it would be good to have error estimates
> > and velocities from the same moment you get position estimates.
> 
> NMEA if it is this:
> https://en.wikipedia.org/wiki/NMEA_0183

Yes.

> Seems to be a high-level format such as XML or CSV or any other
> $FAVOURITE_ASCII_TRANSPORT format.
> 
> What we want to push into the ring buffer is of course the raw data
> that is produced by the GPS hardware, whatever that may be.
> If what we have is this text format we should not reverse-translate
> it back any more than modem AT commands, it doesn't make sense
> I guess.

Umm. Its hairy. Each GPS talks slightly different version of NMEA
:-(. But yes, we have userland driver called 'gpsd' that understands
most of them. Many GPSes have additional, non-NMEA protocol you can
switch them to.

> So NMEA processing would be in userspace. And if the GPS is just
> streaming this text data over to the client, like Marcel says, it is
> more reasonable to just feed that up to userspace (no policy in the
> kernel).

Well -- we normally do hardware abstraction in the kernel :-).

> I am however aware of certain hardware such as the ST
> Microelectronis STA2062 produced for Garmin, which is *not*
> connected to any external chip, and is not talking over serial
> to any RSx port, and does not have an embedded firmware running
> on another SoC in any special GPS chip. And it is unassisted.

I googled STA2062 but it does not make much sense to me.

Yes, not everything talks NMEA. Nokia N900 is an example, and it has
in-tree driver.

> Maybe that is an oddity. In the mobile phone business I guess it
> could be more common to have a separate SoC that by way
> of standards just stream NMEA data.

Sorry, I don't understand. Yes, in mobile phones GPSes that produce
something else than NMEA are pretty common.

> Fusing that with other sensor data (accelerometer, compass, etc)
> is again indeed a userspace task. I hope NMEA includes very good
> timestamps.

Umm. Timestamps are quite hard to do over serial :-(.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]