[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] ppsthread.c broken for FreeBSD gpio
From: |
Tony Hain |
Subject: |
Re: [gpsd-users] ppsthread.c broken for FreeBSD gpio |
Date: |
Mon, 13 Mar 2017 17:01:12 -0700 |
> -----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