Re: [gpsd-users] After RELEASE_TIME device closed, gpsd reports error on next open

[Gary E. Miller]

Yo Bin!

On Mon, 9 Sep 2019 20:30:52 +0000
Bin Guo <address@hidden> wrote:

> First check: "ppscheck /dev/pps0".  Does that work?
> 
> Then run "gpsd -nND 5 /dev/PS1 |& fgrep PPS" and copy this list
> on the results.
> 
> Thanks, will test once I got access to the board again. But in our
> case the PPS output from GPS is not connected to the CPU system at
> all but to other hardware component, but I imagine fgrep PPS should
> still work with D 5?

If PPS is not connected, then gpsd can not see it.

> Yes, funny name, but that still does not tell us what device driver.
> The device driver is key here.
> 
> From kernel message:
>  [   17.939836] ff010000.serial: ttyPS1 at MMIO 0xff010000 (irq = 41,
> base_baud = 6249999) is a xuartps ttyPS1 is provided by
> drivers/tty/serial/xilinx_uartps.c for  Cadence UART driver (found in
> Xilinx Zynq)

That driver supports full modem control signals.  Why do you not attach
your PPS to that port?

> "-n" and SHM are totally unrelated.
> OK, will check to see if I can check shm for GPS status without a
> monitoring program/thread.

We're still not on the same page.  I'm talking about "-n" and you
are talking about SHM.  Totally unrelated.

Why do you keep brining up SHM?

> > That can happen, so use "-n" to avoid it.  Might be related to
> > whatever /dev/PS1 is.  How long did you wait?  resync can take
> > minutes.  
> 
> You did not answer the above questions.
> 
> I believe it's only a couple of seconds, but my experience of gps
> test is limited (not sure if it's really a resync): original I was
> only using cgps to check, and found for 3.16 build, cgps stopped
> updating its messages totally; that didn't occur for 3.19 or git.

3.16 is years old.  Ignore it.  If 3.19 and git are working then
what is the problem?

> > I did make a patch attached to handle reactive event inside ubx
> > driver which seems to fix this mode issue.  
> 
> What is a "reactive" event?  Can you share your patch?
> [...]
> I can only guess without your source code.
> 
> Patch seems to be removed, here is it pasted (duplicated
> event_identified for event_reactivate in driver_ubx.c):
> 
> cat z020-ublox-reactivate-hook.patch
> Index: git/driver_ubx.c
> ===================================================================
> --- git.orig/driver_ubx.c
> +++ git/driver_ubx.c
> @@ -2136,6 +2136,22 @@ static void ubx_event_hook(struct gps_de
>           * Bad.  Don't do that anymore...
>           */
>      }
> +    else if (event == event_reactivate) {
> +        gpsd_log(&session->context->errout, LOG_INF, "UBX
> reactivated\n"); +
> +        /* no longer set UBX-CFG-SBAS here, u-blox 9 does not have
> it */ +
> +#ifdef RECONFIGURE_ENABLE
> +        /*
> +         * Turn off NMEA output, turn on UBX on this port.
> +         */
> +        if (session->mode == O_OPTIMIZE) {
> +            ubx_mode(session, MODE_BINARY);
> +        } else {
> +            ubx_mode(session, MODE_NMEA);
> +        }
> +#endif /* RECONFIGURE_ENABLE */
> +    }
>  }

Why would you want to do that?  It just sets some settings that were
recently set in the u-blox that would not have gone away.

>  #ifdef RECONFIGURE_ENABLE
> @@ -2455,6 +2471,8 @@ static void ubx_cfg_prt(struct gps_devic
> 
>  static void ubx_mode(struct gps_device_t *session, int mode)
>  {
> +    gpsd_log(&session->context->errout, LOG_INF,
> +             "ubx_mode(%d)\n", mode);
>      ubx_cfg_prt(session,
>                  gpsd_get_speed(session),
>                  gpsd_get_parity(session),

Mode is an obsolete conept on the ubx.  Way to inflexible for the newer
parts.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpg5TYfZLkwH.pgp
Description: OpenPGP digital signature