Re: [gpsd-users] Is GPSD receiving PPS?

[Jon Brase]

On Tue, 05 Apr 2016 17:45:55 -0500, Gary E. Miller <address@hidden> wrote:

> Yo Jon!
>
> Always Cc: gpsd-dev.  I'm not always around and others know a lot of
> things I do not.

Actually, this thread started out on gpsd-users. I thought I had copied  
that list on my last reply, but somehow it got dropped. Probably  
fat-fingered it and hit Reply instead of Reply-all.

> > >> > Also provide the command line that you use to start gpsd.
> > >> >
> > >>
> > >> In this case:
> > >>
> > >> :~# /usr/local/sbin/gpsd -F /var/run/gpsd.sock -nND 5 /dev/ttyAMA0
> > >> /dev/pps0
> > >
> > > Why are you using -the -F ?
> > >
> >
> > Because it's in the command line that the Raspbian GPSD package uses
> > to launch GSPD  at startup and I wasn't sure if it was needed or not
> > so I decided to play it safe and leave it in when doing testing at
> > the console.
>
> Not needed, even bad for debugging.  The '-F /var/run/gopsd.sock' hooks
> up udevd/systemd hot plugging.  The last thing you want when debugging
> is something happening in the background you did not see.

OK. I started a new debug run with that bit removed. Still seeing the same  
messages about not getting anything on /dev/pps0

> > >> gpsd:INFO: reconnection attempt on device 1
> > >> gpsd:PROG: no etc/gpsd/device-hook present, skipped running
> > >> ACTIVATE hook gpsd:INFO: opening GPS data source type 2 at
> > >> '/dev/pps0' gpsd:PROG: Probing "Garmin USB binary" driver...
> > >> gpsd:PROG: Probe not found "Garmin USB binary" driver...
> > >> gpsd:PROG: Probing "GeoStar binary" driver...
> > >> gpsd:IO: Sent GeoStar packet id 0xc1
> > >> gpsd:IO: => GPS: 5053474700c100010000000050924746 FAILED
> > >> gpsd:PROG: Probe not found "GeoStar binary" driver...
> > >> gpsd:PROG: Probing "Trimble TSIP" driver...
> > >> gpsd:PROG: Probe not found "Trimble TSIP" driver...
> > >> gpsd:PROG: no probe matched...
> > >> gpsd:INFO: gpsd_activate(): activated GPS (fd 6)
> > >> gpsd:INFO: GPS on /dev/pps0 returned error -1 (0.000685 sec since
> > >> data) gpsd:WARN: device read of /dev/pps0 returned error or packet
> > >> sniffer failed sync (flags {ERROR})
> > >> gpsd:INFO: closing GPS=/dev/pps0 (6)
> > >
> > > I do not see any problem there.  That ust says you are not getting
> > > any serial data on/dev/pps0.  Which is correct, you only get PPS on
> > > it, but you have no logging here of te PPS thread.
> > >
> >
> > How would I go about logging that? Is there a debug level I need?
>
> Nothing more for you to do.  There is nothing on /dev/pps0, so nothing
> to log.

I realize that GPSD is not seeing anything on /dev/pps0, the problem is  
that ppstest is, and I'm trying to figure out what the disconnect is.

> BTW, from the gpsd INSTALL file:
>
>     "Only two specific changes need to be made to make the HAT
>     work.  First in the file /boot/cmdline.txt, remove this part
>     "console=ttyAMA0,115200 kgdboc=ttyAMA0,115200)".  That frees the
>     serial port from console use so the GPS can use it.
>
>     Second you need to tell the boot process to load the pps_gpio module
>     and attach /dev/pps0 to GPIO pin 4.  Do that by adding this line to
>     the bottom of /boot/config.txt: dtoverlay=pps-gpio,gpiopin=4"
>
> Can you confirm you did that?

Yes and yes. The pin in question is different, but I get output on  
/dev/pps0, and I've made sure that the pin listed in config.txt matches  
the physical pin connected.

> > >> Regression test FAILED: 10 errors in 78 tests total (0 not found).
> > >> The following test Failed:
> > >> ================================================================
> > >> "test/daemon/bu303-climbing.log"
> > >
> > > Not much anyone can do without the actual errors.
> >
> > Pastebin links to the logs are below:
> >
> > http://pastebin.com/aVTC8gf3
>
> That is the input, not the output.  We both have the same input, it
> is your output that is different.  The output would have + and - at
> the line head, like any other diff.

I assumed that the bit about failed tests at the end of the testregress  
output indicated failure logs for each test, not the input data to the  
tests. Where would the actual failure logs be stored?

> > Also, the terminal output from scons testregress:
> >
> > http://pastebin.com/MwFwNtEM
>
> That is better.  Remember when troubleshooting, the FIRST error
> is the error to fix FIRST.  Here is your first error:
>
>
> test_bits.c:71:52: warning: pointer targets in passing argument 1 of
> 'getbef32' differ in signedness [-Wpointer-sign]
> (void)printf("getbef32: %f %f\n", f1, getbef32(buf, 24)); ^
> Looking at errors after that are a waste of time.

Recall that I'm an end user. I'm reporting the failed regression tests for  
informational purposes because they appeared when I tried compiling from  
source, but I do not have the skillset or knowledge of the codebase  
required to do anything about them.

> > > My guess is that endian errors creeped in.  Most of the the
> > > maintainers are using big endian.
>
> Yes, but I also do regressions on a RasPi (ARM).  I do not see that
> problem.  So endianness is not the problem.

You're responding to yourself here. The "My guess is that endian errors  
creeped in" bit is something you said, not me. I probably should have  
stripped off everything after the last bit I was actually responding to.

> And first things first, your line numbers are nothing like I see.  Here
> is the git head test_bits.c line 72:
>
>     static void ledumpall(void)
>
> So you need to get on git head, your problem may have already been
> fixed.


I thought I was on git head. Frankly, though, I don't have a lot of  
experience with Git or any other version control system, so I may have  
screwed something up.

I got the sources with:

git clone https://github.com/ukyg9e5r6k7gubiekd6/gpsd.git

...and then followed the directions under build.txt. Do I need to do  
something else?


--
Jon Brase