Re: [gpsd-users] ppsthread.c broken for FreeBSD gpio

[Tony Hain]

> -----Original Message-----
> From: gpsd-users [mailto:address@hidden
> On Behalf Of Gary E. Miller
> Sent: Monday, March 13, 2017 2:48 PM
> To: address@hidden
> Subject: Re: [gpsd-users] ppsthread.c broken for FreeBSD gpio
> 
> Yo Tony!
> 
> On Mon, 13 Mar 2017 14:35:17 -0700
> "Tony Hain" <address@hidden> wrote:
> 
> > So the reason that the pps is being ignored is that the edge detection
> > code is also linux specific (though I haven't traced it all yet), in
> > that it knows how to deal with a linux Rpi with a single edge pps, but
> > this being FreeBSD, it assumes both edges exist, then rejects the
> > results.
> 
> Got some code to that?  gpsd happily works with one edge or two, and that is
> not compile dependent.  Two ways to have one edge, the 'invisible puklse'
> thing, or the broken RasPI gpio driver.
> 
> 
> > I have hacked it to force the edge dector to buy in, but before it
> > gets there the invisible flag is set and other logic gives up on it.
> >
> Invisible logic is not a fence, it is a cow catcher.
> 
> > Looking at the code, my pulse shaper/driver for the MR350p would
> > likely fail anyway because it is 530/470ms, and this appears to want
> > the assert state to be shorter than 90% of half (which likely explains
> > why I have never had any luck getting gpsd to play nice with ntp).
> 
> I have a trusty MR-350p,  That is clearly not the default setting for that 
> model.
> Why do you have it set that way?  it will most likely fall into a deadband 
> that is
> rejected as hard to quantify.

The2.8v pulse coming out of it was inadequate to drive the rs232 on the 386's, 
so I stuck a driver in. That didn't do anything useful because the 2us pulse 
was too short to be seen by the ntp pps driver, so I put a 555 in. At the time 
(~10 years ago when the oncore died) I didn't know about the gpsd edge 
detector, so I shot for 50% duty cycle and picked a 470k-5% resistor and ended 
up with 530/470ms. Has been working fine on the ntp pps and nmea driver since. 
When I tapped into that for the BBB, without making any changes to gpsd I get 
.5hz messages because the FreeBSD-12 gpio driver is assert-only just like the 
Rpi linux one. When I changed the 1.1sec detector to 5.0sec to force it out of 
.5hz mode, I get

Mar 13 23:53:21 tic gpsd[76642]: gpsd:PROG: KPPS:/dev/pps0 Assert cycle: 
6999997, duration:       0 @  1489449201.999732750
Mar 13 23:53:22 tic gpsd[76642]: gpsd:PROG: PPS:/dev/pps0 Assert cycle: 
6999997, duration:       0 @  1489449201.999732750

Why it gets that kind of cycle time I can't figure out. Duration 0 makes sense 
given that this is an Assert-only pps.

> 
> > There are Rpi specific values referenced for dealing with its
> > assert-only linux behavior, so the assumption that single-edge is
> > Rpi-only would be at fault.
> 
> Rally?  Where?ode snips please.

                /* brain damaged pps-gpio sometimes never fills in clear
                *prev_clock_ts = pi.assert_timestamp;
                *prev_clock_ts = pi.clear_timestamp;
        *clock_ts = pi.assert_timestamp;

I haven't chased this down to see if those are in linux-only blocks, but the 
variable name would imply they are. 


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