gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2 separate positions pass through gpsd


From: Filip Kubicz
Subject: 2 separate positions pass through gpsd
Date: Thu, 13 Oct 2022 12:11:45 +0200

Hi!

First of all, thank you for adding passing the control commands to the
receiver through gpsd. It was really a big improvement and a
simplification to our application!

I have a question:
>From 1 receiver, I need to pass 2 separate positions
1. final Dead Reckoning-computed position (GNRMC, GNGNS, PQTMINS and others)
2. GNSS-only position (coming from a receiver debug command PQTMGPS)

These 2 might differ, and the position 1. might be very very wrong in
some cases. Chip supplier is working on improvements (Quectel LC29D),
however I need to gather more data and be able to tell how big are
differences, and for the time being add logic in the application that
discards position 1. if it's too far away from the GNSS-only.

For the GNSS-only position, I tried to distinguish it by assigning it
a different status - e.g. STATUS_SIM that will never be used in this
application.

The problem with using status field is that it is cached by gpsd. If
there occurs a higher status in the beginning of the reporting cycle,
it will be also used for all TPV reports in this cycle:

$PQTMGPS,1134357,229674.000,50.047556500,19.959433300,249.5590,207.6340,0.0030,11.9758,0.8850,0.9600,1.5600,3,20,62
{"class":"TPV","device":"/dev/ttyGPS0","status":8,"mode":3,"time":"2022-10-11T15:47:36.000Z","ept":0.005,"lat":50.047556500,"lon":19.959433300,"epx":9.586,"epy":9.482,"epv":27.600,"track":12.0000,"magtrack":17.4879,"magvar":5.5,"speed":0.000,"eps":19.18,"epc":55.20,"geoidSep":39.636,"eph":19.000,"sep":30.400}
$PQTMINS,1134363,2,50.047544049,19.959408632,244.315312,0.000000,0.000000,0.000000,2.641004,3.079449,24.3108994D
{"class":"TPV","device":"/dev/ttyGPS0","status":8,"mode":3,"time":"2022-10-11T15:47:36.000Z","ept":0.005,"lat":50.047544049,"lon":19.959408632,"epx":9.586,"epy":9.482,"epv":27.600,"track":12.0000,"magtrack":17.4879,"magvar":5.5,"speed":0.000,"eps":19.18,"epc":55.20,"geoidSep":39.636,"eph":19.000,"sep":30.400}
$PQTMINS,1134485,2,50.047544049,19.959408632,244.315312,0.000000,0.000000,0.000000,2.635570,3.082669,24.31089943
{"class":"TPV","device":"/dev/ttyGPS0","status":8,"mode":3,"time":"2022-10-11T15:47:36.000Z","ept":0.005,"lat":50.047544049,"lon":19.959408632,"epx":9.586,"epy":9.482,"epv":27.600,"track":12.0000,"magtrack":17.4879,"magvar":5.5,"speed":0.000,"eps":19.18,"epc":55.20,"geoidSep":39.636,"eph":19.000,"sep":30.400}

I used lower status (e.g. 4 - not used in our application) with
success when the DR is active (DR position status 5 or 6, GNSS-only
debug position status 4), but this also can mangle the TPVs that come
with lower status (0,1,2 or 3) and doesn't allow for reliable
distinction. So this approach, after some testing, looks naive.

Implementation of PQTMINS is here, if needed:
https://github.com/TierMobility/gpsd/blob/main/drivers/driver_nmea0183.c#L3694
If it will look good in testing, we can open a PR to gpsd. And a very
dirty implementation of PQTMGPS:
https://github.com/TierMobility/gpsd/pull/4/files

I also tried using unused variables in the gps_fix_t struct, but this
is also not a perfect solution, as wanglem and wangler get rounded:

// Push debug GNSS-only position as unused gpsd wind angle variables
in gps_fix_t struct.
session->newdata.wanglem = safe_atof(field[3]);
session->newdata.wangler = safe_atof(field[4]);
mask |= NAVDATA_SET;

{"class":"TPV","device":"/dev/pts/4","mode":3,"time":"2022-10-11T15:55:52.000Z","ept":0.005,"lat":50.047539350,"lon":19.959369733,"epx":11.473,"epy":10.584,"epv":25.300,"track":159.1000,"magtrack":164.5879,"magvar":5.5,"speed":0.000,"eps":20.12,"epc":50.60,"geoidSep":39.636,"eph":15.200,"sep":26.600,"wanglem":50.0,"wangler":20.0}

What is the best way to work it around, and be able to reliably
distinguish these 2 types of positions, without merging them?

Kind regards,
Filip



reply via email to

[Prev in Thread] Current Thread [Next in Thread]