Re: [RFC] get gpsd to work with gnss-share

[Gary E. Miller]

Yo Clayton!

On Mon, 9 Jan 2023 12:47:38 -0800
Clayton Craft <clayton@craftyguy.net> wrote:

> On Mon, 09 Jan 2023 12:27:52 -0800 "Gary E. Miller" <gem@rellim.com>
> wrote:
> > Where do I find the gnss-share source and doc?
> > 
> > Is this it?  https://gitlab.com/postmarketOS/gnss-share  
> 
> Yes.

Thanks.

> > > It's currently RO, gnss-share ignores any writes to it. This might
> > > change in the future, but currently gnss-share controls the
> > > underlying device if, e.g., a-gps needs to be uploaded or
> > > whatever. gnss-share can be controlled at runtime by using
> > > signals.  
> > 
> > How many different GNSS protocols?  
> 
> Doesn't matter, gnss-share isn't doing anything with the data it gets
> from the module, from gpsd's standpoint (and other things like
> geoclue), it's just a proxy for it.

Sad.

> > > What gnss-share does is open some underlying gnss device (e.g.
> > > connected over serial) and just passes through any data from it
> > > directly to the socket.  
> > 
> > So it does not configure the data to be sent?  Just rely on the
> > defaults?  
> 
> Nope. I mean, it *could*, but currently it doesn't configure what
> data the module is going to shout out at whatever interval it wants.

The gpsd users always want more data.

> 
> > > The real value in gnss-share is that it can
> > > perform any arbitrary setup for specific devices, or interrupt
> > > them to do things like load a-gps, etc. It also supports any
> > > number of clients connected to the socket at once all receiving
> > > the same unaltered data from the module.  
> > 
> > I find A-GPS near useless with the most modern devices.  Until
> > recently the vendors refused to even document the process.  
> 
> I find it crucial for some modern devices, like the STM module in the
> Librem 5. Agree to disagree?

I'd rather see real tests.  I can't (not at the Librem 5 prices!).  But
if can spare the time: I'm listening.

> > > I know that for the Librem 5, gpsd is capable of "using" the data
> > > from it's gps module as-is.  
> > 
> > Googling around, I see opinions differ on that.  
> 
> /shrug
> 
> It worked for me at the time. Maybe it doesn't anymore?

I don't put stock in random internet comments.  I happy to wait for
data.  In the case of gpsd over gnss-share that may be soon.  After
the release.


> > > A couple of years ago I was using gpsd on
> > > the L5, and it was fine, but decided to make gnss-share to allow
> > > for loading/storing a-gps -related data,  
> > 
> > I wish you had sent gpsd patches instead.  
> 
> Everyone else seem to be moving to geoclue for aggregating location
> data from multiple sources for apps to use. That was my primary
> target.

Seems reasonable, but more than one way to skin that cat.

> > > and doing other things to
> > > improve lock times,  
> > 
> > Modern GNSS are pretty fast at that.  
> 
> ... Except the Librem 5's GNSS module.

I'd love to see some test results.  But given the other bad reviews on
the Librem 5, it would not be surprising.

> > Any doc on how to do that?  
> 
> It's a unix socket, open it and read.

As I said, I'm annoying about following standards, not just seeing what
stick to the walls.  If this patch works, that gives me a window.

> > Umm.  Char by char?  Packet by packet?  Multiple packets per
> > message? How does the client know data is available?  Any
> > buffering?  Any checksumming?  
> 
> Line by line. No buffering. No checksumming, beyond what the module
> does in NMEA.

With the \r\n?  Somebody has to buffer.  If only the kernel.

> > > $PSTMCPU,60.50,-1,49*4C  
> > 
> > Proprietary sentence.  Got any doc on that?  ST Micro?  
> 
> Yeah ST Micro. Ignore it.

gpsd ignores little.  Less and less over time.  There's gold in that
rubble pile.  But my problem now, not yours.

> > > $GPRMC,xxxxx,V,xxxx.xxxx,N,xxxxx.xxxx,W,0.0,0.0,090123,,,N*6A  
> > 
> > Pre NMEA 4.1.  Suboptimal.  
> 
> File a bug with STM :D

Since I do not have a part, I can't.  My luck getting vendors to fix
their firmware is slim.

> > > $GPGGA,xxxxxx,xxxx.xxxxx,N,xxxx.xxxxxx,W,0,00,99.0,025.15,M,0.0,M,,*7B
> > >  
> > 
> > I can't run tests on corrupted data like that.  
> 
> But at least you have some idea what the sentences are, and you can
> fill in the blanks with your own location (and recompute the
> checksums).

I don't work on doctored data.  Too many problems there.

> > > $GPVTG,0.0,T,,M,0.0,N,0.0,K,N*02  
> >   
> > > $GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0*1E
> > > $GNGSA,A,1,,,,,,,,,,,,,99.0,99.0,99.0*1E  
> > 
> > Duplicate sentences?  A buffer failure?

This one really bugs me.

> > > $GLGSV,3,3,10,69,16,146,,82,06,078,,,,,,,,,*6C
> > > $GPGLL,xxxx.xxxxx,N,xxxx.xxxx,W,xxxxxx,V,N*54  
> > Odd to get lat/lon/alt on an invalid fix...

> I'm literally just echo'ing what the module writes to the serial
> connection. Any problems you see with the output are, not my problem?
> This works great with geoclue.

Just reading about geoclue, hard to say if it is dumber than a stick
when evaluating NMEA.  It only uses GGA or RMC.  And it is so dumb it
does not specify if Altitude is MSL or HAE.

I do see geoclue looking for proprietary info in GPTXT messages that
your sample did not have.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpH0KJ3i47Un.pgp
Description: OpenPGP digital signature