Re: [gpsd-dev] SiRF IV on gpsmon

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > #----------------------------------- PPS
> > -----------------------------------#
> 
> Yes, I see that.  But still nothing in gpsmon.

This tells us that there's a very specific gpsmon issue.  It's not the 
PPS-thread loop that's broken, which was the scary possibility given 
how complicated that code is.

That being the case, there's a small to-do item I was going to hold off 
on until after 3.10 that I'm going to go ahead and do, because I suspect 
the process might flush out whatever weird bug is afflicting you.  (I
still don't get why I'm not seeing it...)

I'm going to change the PPS bar so that it's not a comment packet.
Instead it'll be a JSON PPS object.  This will have the side effect
that gpsmon will automatically parse the drift values out of it; we
can use those to update the PPS offset field, which will be a clear
indication that the data is getting to where gpsmon can see it even if
the PPS bars are successfully hiding from you.

> > Doesn't reproduce here.  This is with the BU355 (SirF III)
> > on /dev/USB0:
> 
> Been working for a day for me on SiRF III.  SiRF IV still broken.

Oh, good.  That means we have a SiRF-IV-specific problem, not some 
massively threatening driver breakage that will screw up functioning
with IIs and IIIs.  That's the best news I've had in days.
 
> Looks like ID 0x86 is still the one, the SiRF IV has two serial ports,
> can't beleive they hooked up to the secondary one.
> 
> Here is what raw gpsctl writes:
> 
> gpsctl:PROG: SiRF: sirf_speed(19200,N,1)
> gpsctl:PROG: SiRF: Writing control type 86:
> gpsctl:IO: => GPS: a0a200098600004b000801000000dab0b3
> 
> That matches the doc, except I did not check the checksum.

I suppose it's possible the firmware image in that specific product has
the baud-change capability damaged or disabled.  Did it come with any
software that's supposed to be able to change the baud rate?

> > I think I'll hack the ID sentence to include the firmware 
> > subtype if it's available.

That's done now.  Maybe we'll notice something in the firmware version
strings.  More information can't hurt.
 
> BTW, gpsd ^C handing is broken:
> 
> $GPZDA,212324.00,13,11,2013,00,00*60
> $GPGGA,212324,4404.1119,N,12118.8488,W,2,04,8.43,1135.89,M,-20.139,M,,*44
> $GPRMC,212324,A,4404.1119,N,12118.8488,W,1.8130,175.328,131113,,*31
> $GPGSA,A,3,00,00,00,00,00,00,00,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,16.5,8.4,14.2*3B
> ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
> [....]
> 
> I need to kill -9

Yet another bug I can't reproduce.  Sigh...I know it sounds silly but have
you checked that ^C is still your INT character?

Here is the current state of play as I understand it; correct me if 
I'm wrong, add what you can.

1. Direct-mode gpsctl and gpsmon baud rate changes work for both of us
   on SiRF IIs and IIIs, and on the GR601-W.  I can also confirm the
   EVK 6H.

2. Direct-mode gpsctl baud rate changes on a SiRF IV fail for you.  I
   don't have one to test with.

3. I am seeing PPS bars in gpsmon direct mode.  You are not.

4. Client-mode baud rate change attempts from either gpsctl or gpsmon fail.

5. I am seeing PPS bars in gpsmon client mode.  You are not.

6. Both of us see PPS bars in JSON over telnet when ppsbar=true.

7. ^C interrupts gpsd for me, but not for you.

8. The above includes the entire set of known pre-3.10 issues.

Note that 3 and 5 are different problems.  In direct mode, gpsmon gets the
PPS event from its own TIOCMIWAIT or KPPS watcher loop.  In client mode
it simply passes through the daemon-transmitted PPS bars of item 6.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature