Re: Strange troubles with emulation

[Gary E. Miller]

Yo Владимир!

> > so I created a file from message 
> > https://lists.nongnu.org/archive/html/gpsd-users/2021-01/msg00127.html
> > by gpspipe from previous.  

I don't like work on manipulated captures, but I took another look at
that derived nmea file.  regress-driver can read it.

regress-driver calls gpsfake
gpsfake call gpsd
gpsd sends its ouput back to regress-driver.

This is used for regession tests, but is also handy to chek capture files.

This builds a .chk file, the can be used for regressions:

spidey ~ # ./regress-driver -b txt8JNasDnUM_.txt
Rebuilding daemon regressions...
Processing txt8JNasDnUM_.txt
Elapsed time: 1.85

There is now a file txt8JNasDnUM_.txt.chk that contains the NMEA and the
JSON created by gpsd.

Here are two cycles, reporting no fix:

$GPVTG,22.564,T,0,M,5.293,N,9.803,K*68
$GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
$GPRMC,185003.000,A,6108.221,N,02820.532,E,5.29,22.37,130719,,*39
$GPGGA,185003.000,6108.221,N,02820.532,E,1,00,0.0,54.960,M,0.0,M,,*5F
{"class":"TPV","mode":1,"time":"2019-07-13T18:50:03.000Z","ept":0.005}
$GPVTG,22.368,T,0,M,5.288,N,9.794,K*69
$GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
$GPRMC,185012.000,A,6108.232,N,02820.546,E,5.11,33.01,130719,,*36
$GPGGA,185012.000,6108.232,N,02820.546,E,1,00,0.0,54.850,M,0.0,M,,*5C
{"class":"TPV","mode":1,"time":"2019-07-13T18:50:12.000Z","ept":0.005}

GPGSA starts the cycle, and reports 3D fix.

$GPGSA,A,3,,,,,,,,,,,,,0.0,0.0,0.0*32
       ^^^

GPGSA is kinda explained here:

https://gpsd.io/NMEA.html#_gsa_gps_dop_and_active_satellites

Then comes GPRMC, which does not report a fix mode.

$GPRMC,185012.000,A,6108.232,N,02820.546,E,5.11,33.01,130719,,*36
                 ^^^

That says the data is valid, but gives no fix mode.  Debatable if
the decode should assume it is at least 2D since there is "valid" lat
and lon.

GPRMC is kinda explained here:Y

https://gpsd.io/NMEA.html#_rmc_recommended_minimum_navigation_information

Last in the cycle is GPGGA

This shows another data problem with your "emulated" NMEA.

$GPGGA,185012.000,6108.232,N,02820.546,E,1,00,0.0,54.850,M,0.0,M,,*5C
                                         ^^^^

Field 6 says you have a GPS fix (1), but does not specify what kind.
There is lat/lon/altMSL so maybe we can assume a 3D fix, except...

Field 7 shows zero (00) satellites in use.

gpsd knows that you can not have any fix at all with zero satellites
in use, so gpsd sets "No Fix" ("mode":1).

GPGGA is kinda explained here:

https://gpsd.io/NMEA.html#_gga_global_positioning_system_fix_data

So it looks to me on the face of conflicting data that gpsd made a
judgement call.  If you want gpsd to believe you have a good fix, then
do not give it conflicting data.  One fix may be to set sats seend to 
4.

Using regress-driver it is possible to peek under the hood and
see a bit of what is happening.  I have regress-driver pass -D 4 to
gpsd, and watch the logs:

spidey ~ # ./regress-driver -o "-D 5" txt8JNasDnUM_.txt

In this fragment we see GPGGA set mode 1 and ends the cycle, so has the
last worD:

gpsd:IO: <= GPS: 
$GPGGA,185738.000,6108.782,N,02820.976,E,1,00,0.0,57.040,M,0.0,M,,*58
gpsd:DATA: NMEA0183: GPGGA: registers fractional time  185738.000000000
gpsd:DATA: NMEA0183: GGA: hhmmss=185738.000 lat=61.15 lon=28.35 altMSL=57.04 
mode=1 status=1
gpsd:DATA: NMEA0183: GPGGA newtime is  1563044258.000000000 = 
2019-07-13T18:57:38.000Z
gpsd:DATA: NMEA0183: GPGGA time  185738.000000000 last  185738.000000000 latch 
1 cont 0
gpsd:PROG: NMEA0183: GPGGA ends a reporting cycle.


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

pgpLZpuKgiIdj.pgp
Description: OpenPGP digital signature