Re: Sending commands to device while gpsd is running

[Filip Kubicz]

Hi Gary!

> 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.

I'm attaching a raw capture file so it can be added to the regression test:
https://paste.ee/p/uY1oT
It contains the $PQTMINS in it's full lifecycle, from not calibrated to 
calibrated algorithm state.

I'm now once again trying to implement feeding the GNSS device with wheel data.
Feeding the wheel tick with UART directly works, and the module responds with 
$PQTMVEHMSG to my every write - visible in the captured file.

However, I want to do it via gpsd to let it be the only program using the 
serial port.
I added the -n option as you mentioned previously.

My app:
Apr 12 17:11:36 gps_send: $PQTMVEHMSG,2,0,0,1*19\r\n
Apr 12 17:11:36 gps_send: $PQTMVEHMSG,2,0,0,1*19\r\n

gpsd with debug enabled:
# gpsd -D 2 -N /dev/ttyGPS0 -n
gpsd:WARN: This system has a 32-bit time_t. This gpsd will fail at 
2038-01-19T03:14:07Z.
gpsd:WARN: KPPS:/dev/ttyGPS0 no HAVE_SYS_TIMEPPS_H, PPS accuracy will suffer
gpsd:WARN: NMEA0183: can't use GNS time until after ZDA or RMC has supplied a 
year.
gpsd:WARN: NMEA0183: can't use GNS time until after ZDA or RMC has supplied a 
year.

gpsd:CLIENT: => client(0): 
{"class":"VERSION","release":"3.23.1","rev":"3.23.1","proto_major":3,"proto_minor":14}\x0d\x0a
gpsd:CLIENT: <= client(0): $PQTMVEHMSG,2,0,0,1*19\x0d\x0a
gpsd:CLIENT: => client(0): =
gpsd:CLIENT: <= client(0): $PQTMVEHMSG,2,0,0,1*19\x0d\x0a
gpsd:CLIENT: => client(0): =

Unfortunately, gps_send() from gps.h does not send the packets to the GNSS, or 
incorrect message is sent out and there is no response.

Code:
int wheel_tick_gpsd_connect(void)
{
    if (0 != gps_open("localhost", "2947", &gps_data)) {
        write_syslog_err("gpsd connect error\n");
        return WHEEL_TICK_CONNECT_ERROR;
    }
    return 0;
}

void wheel_tick_feed(const uint32_t wheel_tick_count)
{
    char payload[PAYLOAD_MAX_LEN];
    char message[MSG_MAX_LEN];

    // Construct the payload for checksum calculation.
    int payload_len = snprintf(payload, PAYLOAD_MAX_LEN, 
"$PQTMVEHMSG,2,0,%d,1", wheel_tick_count);
    // Construct full message with checksum.
    int msg_len = snprintf(message, MSG_MAX_LEN, "$%s*%02X\r\n", payload, 
pqtm_checksum(payload, payload_len));

    // gps_send accepts a null-terminated string.
    int n = gps_send(&gps_data, message);
    if (n < 0) {
        write_syslog_err("wheel tick write failed, n=%d\n", n);
    }
}

wheel_tick_gpsd_connect() is called once, wheel_tick_feed is called in a loop.
gps_open() and gps_send() both return 0.
Confirmed that the constructed payload and message are what the module expects 
- it works when sent over UART or via gpsctl -x.
For sending, do I need to set up a stream with gps_stream()? Tried that as well 
but the behavior is similar. Or maybe there is some other part missing?

> gps.send() in Python is not gps_send() in C. Different animals.
I can see the Python usage in ubxtool, but right now I'm using C and would need 
a C API example.

I've done a comparison with gpsctl -x. Command sent without checksum, as 
specifed in the gpsctl docs, is received by the device, which responds 
correctly. Working command:
gpsctl -x '$PQTMVEHMSG,2,0,0,1' -D 3 /dev/ttyGPS0
But before that, gpsctl -x reinitialized the device.
Also, there is no "gpsd:CLIENT: <= " in the gpsd daemon log, which means gpsctl 
-x is not meant to be used when a gpsd daemon is running (as it forces the 
"low-level access").
# gpsctl -x '$PQTMVEHMSG,2,0,0,1*19' -D 3             
gpsctl:ERROR: device must be specified for low-level access.

Looking at the gpsctl, I tried to put a payload without the NMEA checksum to 
gps_send(), but it didn't work either, gps_send() does not add the checksum. So 
it must be some other issue.
gpsd:CLIENT: <= client(0): $PQTMVEHMSG,2,0,0,1\x0a
gpsd:CLIENT: => client(0): =

Please advise how to properly do the send ;)

Kind regards,
Filip

filip@kubicz.engineer
tel. (+48) 697 088 078


 >  
 > ---- On Thu, 30 Dec 2021 23:46:44 +0100 Gary E. Miller <gem@rellim.com> 
 > wrote ---- 
 >  
 >  > 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 
 >  > 
 >