--- In "jywmpg" <> wrote:
>
> I did some more debugging, and have the following:
>
> 1. It was not readily apparent to me how to cross-compile GPSD on my
> dev machine, so I am building it on the target 7260 (I know it's slow,
> but it should be valid, nonetheless)
>
> 2. I got the statserial application (apt-get install statserial) and
> ran it on the GPS port (/dev/ttyAM0), and it clearly sees the DCD line
> toggling once per second. This indicates the presence of the PPS
> signal coming from the GPS
>
> I ran statserial with the following:
> while [ "X" ]; do statserial /dev/ttyAM0 -x; done
>
> The output toggled between 0x06 and 0x46 once per second, which was
> about every 30-40 samples. There are 2-3 samples of 0x46 followed by
> 30 or so 0x06 values.
>
> Based on the statserial help page, I take bit 6 (0x40) to be the DCD
> bit. This is the expected behavior for the PPS signal
>
> 2. The problem is that, even though the DCD bit is toggling, the
> following TIOCMIGET call in gpsd_ppsmonitor never completes:
>
> while (ioctl(session->gpsdata.gps_fd, TIOCMIWAIT, pps_device) ==
0) {
>
> where pps_device is set to TIOCM_CAR
Apparently TIOCMIWAIT call may relay on interrupts (is hardware
dependent) and it is possible that the serial port is not generating
interrupts on DCD. This is just a theory thou.
> I take this to mean that, for whatever reason, this call is not seeing
> the DCD line toggling, or else it would complete.
>
> I added a debug call to dump out the ioctl parameter values, and the
> call boils down to:
>
> while (ioctl(4, 21596, 64) == 0)
>
> This seems reasonable to me, and yet the call does not complete. I
> have a debug call below the loop, as well as one immediately following
> the while statement, at the top of the loop, and neither gets called.
>
> So, the question is: Why would statserial see the DCD line toggling,
> but the TIOCMIWAIT call does not?
Loking at the statserial source code, it uses the TIOCMGET call,
polling the port from am infinite for loop, it doesn't use interrupts.
> Otherwise, GPSD works well enough, supplyg position fixes, as well
> as the low precision clock to NTPD.
>
> Seems like this is really close to working, except for this one little
> problem (famous last words?)
>
>
> Thanks for any help,
>
> jw
>
>
> --- In "jywmpg" <jywmpg@> wrote:
> >
> > Hi Charlie,
> >
> > Thanks for the suggestions.
> >
> > Yes, I ran gpsd at a high debug levels (5, 6, 19), and have never seen
> > any indication of pps activity in the resulting log file. The string
> > pps does not appear (e.g. grep -i pps gpsd.log). That seems a little
> > odd; not even in a start up message.
> >
> > If I hadn't built it myself, I would question whether pps was enabled
> > during the build.
> >
> > I was browsing the source code as well, and came to similar
> > conclusions about TIOCMIWAIT. I am going to add a few debug calls in
> > the area your mention and see what is happening.
> >
> > Not familiar with setserial, other than to know it exists. Will check
> > it out.
> >
> > Don't think I need the pps kernel patch. gpsd documentation is pretty
> > clear it is solely a user land program.
> >
> > I also thought about CTS, sort of as a last resort, just in case there
> > is something odd about DCD on COM1 on the 7260 (seems unlikely as the
> > docs say there is full handshaking on COM1). Would need to rewire the
> > plug to reroute the pps signal to CTS, rebuild with the 'PPS on CTS'
> > flag and off you go. Well, as I said, if all else fails.
> >
> >
> > Thanks again for the tips and taking the time to write. I'll let you
> > know what I find.
> >
> >
> > Regards
> >
> >
> > jw
> >
> >
> > --- In "charliem_1216" <charliem_1216@>
wrote:
> > >
> > > Hi JW --
> > >
> > > --- In "jywmpg" <jywmpg@> wrote:
> > > >
> > > > Has anyone got GPSD running using the PPS (Pulse Per Second)
> > > signal to
> > > > synchronize NTP?
> > > >
> > > > I have a Garmin 18LVC connected to COM1 on a 7260, with the PPS
> > > line
> > > > connected to the DCD pin of COM1. Using a scope, I can tell
that
> > > the
> > > > Garmin is supplying a 100 ms pulse to DCD once a second.
> > > >
> > > > GPSD is supposed to detect the transitions on DCD and use that
> > > > information to provide a clock to NTP, via shared memory.
> > > >
> > > > Unfortunately, running GPSD at a high debug level shows no
> > > indication
> > > > that GPSD sees the PPS transitions on DCD. If the transitions are
> > > > detected, debug messages should be generated
> > > >
> > > > I have removed /dev/ttyAM0 from /etc/inittab, and redirected the
> > > > console output to COM2 via JP4 and JP2.
> > > >
> > > > I have downloaded the GPSD 2.34 and built from scratch, making
> > > sure
> > > > that both SHM and PPS are enabled, and that PPS is input on DCD.
> > > >
> > > > GPSD is capable of producing both a low resolution clock (derived
> > > fro
> > > > m characters arriving on the serial line) and a high resolution
> > > clock
> > > > (derived from the PPS signal). The low precision clock works,
but
> > > the
> > > > high precision one does not.
> > > >
> > > > This is demonstrated in the following:
> > > >
> > > > # ntpq -p
> > >
> > > Before bringing ntpd into the picture, I'd verify that gpsd is
> > > getting the pps OK. I think there is a level 5 or 6 debug log for
> > > gpsd that will tell you more details about gpsd finding (or not
.. )
> > > the pps signal.
> > >
> > > > remote refid st t when poll reach delay
> > > offset
> > > > jitter
> > > >
> > >
> >
>
==============================================================================
> > > > *SHM(0) .GPSa. 0 l 7 16 377
> > > 0.000 -198.66
> > > > 37.583
> > > > SHM(1) .PPSa. 0 l - 16 0 0.000
> > > 0.000
> > > > 0.061
> > > > tss1 .STEP. 16 u - 64 0 0.000
> > > 0.000
> > > > 0.000
> > > > tss6 .STEP. 16 u - 64 0 0.000
> > > 0.000
> > > > 0.000
> > > > LOCAL(0) .LOCL. 10 l 8 64 377 0.000
> > > 0.000
> > > > 0.061
> > > >
> > > >
> > > > Questions:
> > > >
> > > > 1. Does anyone have this setup working?
> > >
> > > No (haven't tried), but I'd like to someday ....
> > >
> > > > 2. Is there some other way to monitor the DCD line to see if it is
> > > > actually getting into the 7260?
> > >
> > > Try the oldie-but-goody statserial to monitor it; there is a debian
> > > package for it.
> > >
> > > >
> > > > Any suggestions would be appreciated.
> > >
> > > A few things to try:
> > >
> > > * There is a patch for "setserial" program that adds a 'hardpps'
> > > command option and does the needed ioctl on the port. See:
> > > http://wiki.enneenne.com/index.php/LinuxPPS_support#setserial
> > >
> > > * Reading through the gpsd sources, I see that it needs or at least
> > > wants TIOCMIWAIT to be defined, so it can 'wait for a change on
> > > serial input lines'. Can you check to be sure this define is
> > > picked up when compiling gpsd? Maybe it is missed in a
> > > cross-compile; gpsd skips pps entirely if TIOCMIWAIT is not
> > > available.
> > >
> > > * There was a pps patch for linux 2.4 kerenls maintained for a long
> > > time. Google for 'ppskit' (assuming here you use a 2.4 kernel; if
> > > not, see the 2.6 pps stuff at
> > > http://wiki.enneenne.com/index.php/LinuxPPS_support).
> > >
> > > * There's a gpsd build option to use CTS instead of DCD, maybe give
> > > that a shot. Unlikely though.
> > >
> > > HTH, ......... Charlie
> > >
> > > >
> > > >
> > > > jw
> > > >
> > >
> >
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|