[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gpsd and ublox
From: |
Gary E. Miller |
Subject: |
Re: gpsd and ublox |
Date: |
Fri, 8 Mar 2024 12:33:06 -0800 |
Yo joebeis64@duck.com!
On Thu, 07 Mar 2024 14:50:29 -0500
joebeis64@duck.com wrote:
> As stated in an earlier message, we are interfacing with a UBLOX M8
> device and would love to start using GPSD.
Good.
> With respect to UBX messages. We configure the receiver to send 3
> messages (UBX-NAV-STATUS, UBX-NAV-TIMEGPS and UMX-TIM-TP).
Except for TIM-TP, gpsd will automagically turn those, and a lot more, on
for you. Unless you are controlling an oven controlled oscillator, TIM-TP
has no value.
> Is there
> a way for a GPSD Client to get to bent these UBX messages?
Yes. You can configure the receiver in BBR, cat a file before gpsd
starts up, use gpsctl, use ubxtool, write a python client, modify
drivers/driver_ubx.c etc. Many, many ways. But you likely need not do
so. gpsd usually just does "The Right Thing".
> Or are
> they consumed by GPSD?
Depends.
> I understand that GPSD handles several
> different flavors of receivers behind the scenes
Way more than several.
> but wants to present
> a common look and feel to all users of GPSP. Do you have any
> suggestion on how we can get those messages?
Connect to gpsd, and ask for them. James already sent a letter with
some ideas. Not exhaustive, and maybe not optimal, but a start.
gpsd also include many examples. Try some of those.
With luck and skill, you should never need to look at any ubx or
NMEA ever again.
> A second general question is about leap seconds. Is it expected that
> the receiver handles leap seconds and it is transparent to GPSD?
The receiver does what it must, and gpsd does the rest. Depends wildly
on the receiver. In the case of u-blox, you can assume it "Just Works".
> Or
> does GPSD do something with leap seconds?
And. Use the power of "and".
> Things like leap seconds
> are reported in the UBX messages mentioned above so that is why we
> use them. The following was taken from the ublox documentation:
We all have to use leap seconds since we all want UTC. The
gpsd_json man page answers this, and a thousand other qustions, about
what is in the gpsd JSON.
> u-blox receivers are designed to handle leap seconds in their UTC
> output and consequently users processing UTC times from either NMEA
> and UBX messages should be prepared to handle minutes that are either
> 59 or 61 seconds long. Leap second information can be polled from the
> u-blox receiver with the message UBX-NAV-TIMELS for Protocol Version
> 18 and above.
Yeah, so? When in doubt, assume gpsd just doe the "Right Thing".
> One other question is if time always reported as UTC Time by GPSD
> (WATCH_JSON)? Or is it sometimes in GPS Seconds?
Once again, RTFM, and embrace the power of "and". The u-blox manual
will tell you the many cases when UTC is just not possible. gpsd
can't invent data that the receiver does not give it.
> I hope I am clear with the above. It not then please ask questions.
It feels like you have not just installed gpsd and played with it, that
will be the fastest way to educate you on what gpsd can do.
> We are experimenting with writing a GPSD Client such that we can use
> it as a shim between GPSD and our current application as well as
> support others who want to directly interface with GPSD.
Very common.
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
pgpp_masTTqGN.pgp
Description: OpenPGP digital signature