[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sending commands to device while gpsd is running
From: |
Gary E. Miller |
Subject: |
Re: Sending commands to device while gpsd is running |
Date: |
Thu, 30 Dec 2021 14:46:44 -0800 |
Yo Filip!
I'm replying to the list. I only take offlist email from paying
clients.
On Thu, 30 Dec 2021 23:28:14 +0100
Filip Kubicz <filip@kubicz.engineer> wrote:
> > You are skipping a lot of details. What version gpsd? How are
> > you starting gpsd? Are you using the "-n" option? Was gpsd
> > running when you did the below?
> >
>
> gpsd 3.21. I understand that I should update to 3.23.1 whenever
> possible.
Yup. A lot of "Quectel Querks" fixed in the newer version.
> You are right, there is no -n option. I'll add it to allow gpsd to
> get the data before the client connects.
It does a lot more than that. Just do it.
> In the above situation, both
> gpsd and client are running. Command in this case is
> "$PQTMCFGEINSMSG,1,1,0,0,10*3F\r\n". Which may not be correct NMEA,
> but it's only for the receiver. Not for gpsd to worry about.
Yes, but gpsd has to worry about the response. Not sure what gpsd
would do with $COMMANDACKOK.
> > > When I just send the command over UART, the command succeeds and
> > > the device sends back $COMMANDACKOK*16
> >
> > Which, of course, is invalid NMEA... We can deal with that
> > "querk" later.
> >
>
> In this case it doesn't matter if this is valid NMEA, because gpsd
> doesn't need to parse it.
Yes, and no. If it confuses the packetizer, then there will be problems.
> Best case would be to let the client
> program receive it. But probably it's not that simple, as gpsd would
> have to know that it should just pass certain commands, and parse all
> the other usual NMEA sentences.
gpsd passes back all receiver NMEA already. Not sure if that is
detected as NMEA.
> > > What would be the best way to send a command to a device while
> > > gpsd is running?
> >
> > Besst depends a lot on what language you prefer. gpsctl works, or
> > you can code up a bit of Python, C, etc. The protocol is simple.
> >
>
> I have a Python client, which does session.stream(gps.WATCH_ENABLE |
> gps.WATCH_NEWSTYLE) and then session.next(). From what you say I
> guess you mean using gps.send()? Isn't it "Deprecated and unstable"
> according to https://gpsd.gitlab.io/gpsd/client-howto.html ?
gps.send() in Python is not gps_send() in C. Different animals.
> I don't want to do any of the magic that gpsctl performs here:
> gpsctl:PROG: switching to match packet type 1:
> $GNRMC,105549.43,V,,,,,,,301221,,,N,V*11\x0d\x0a [...]
> gpsctl:PROG: => Probing for Garmin NMEA
Nor will you have to, once "-n" is working. That is not even gpsctl, that
is from libgps.
> I only want to shuttle a command to the receiver over UART, without
> competing with gpsd for the serial port access. I can use python API
> or command line.
If you look at ubxtool, it does a lot of gps.send(). Pretty easy
once you have the boilerplate set. or gpsctl.
> > > The commands are NMEA-like text. The commands are
> > > independent from the daemon operation.
> >
> > Yeah. "NMEA like". Just enough like NMEA to confuse things. A
> > lot.
>
> That's another story, that I will add support in gpsd for parsing
> position from $PQTMINS message. But let's leave it for now and take
> care of the commands first.
If you do that, send it here, and I'll add it to drivers/driver_nmea0183.c
Another "Quectel Querk". You will find many more of those...
IF you have a raw capture with some $PQTMINS then send it here. That
can be used for a regression test and to validate its decode.
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
pgpHizmbWC8mk.pgp
Description: OpenPGP digital signature