Re: [gpsd-dev] SiRF IV on gpsmon

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > 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.
> 
> Looking forward to it.

It's mostly working now; there are PPS bars in client mode and the 
PPS offset field lights up, but it's stuck on zero for some reason.
I expect I'll figure out why and fix it in the next few hours.

Getting to this point was a lot of hard work.  First, I had to
refactor and rebuild about half of gpsmon so I can make it run in a
fully line-oriented mode when I want it to (the new, still
undocumented -a option). Because trying to embed progress messages in
curses programs doesn't work very well.

Then I had to dig for a couple of days because (a) a buggy gpsmon
initialization sequence was silently suppressing my attempt to turn
up the debugging level so I could see what the packet getter was doing.
(b) that turned out to be masking two subtle bugs in the packet getter,
qnd (c) those were making it look like I/O between the daemon and gpsmon
was being lost.

It was ugly, but I fought my way out of that swamp early this morning.
With -a any future problems in gpsmon will be far easier to diagnose.

> > > 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 was able to change the speed before.  I compared some more to the
> doc and when I use gpsctl to go to 9600 baud the sentence gpsctl
> send matches the doc exactly, including the checksum.
> 
> Afer digging some more, it looks like none of the SiRF command
> are working on the SiRF IV, even thought it is supposed to be
> compatible with SiRF III commands.
> 
> For example, we turn off ID 0x29 messages, but I still get them.
> 
> I even used usbmon to confirm that the proper data is going to the USB
> device.

Bizarre.  So gpsd is doing the right thing, unless there has been an 
undocumented change in the control strings.

When you say "before", do you mean on *this* SiRF-IV unit, a
different SiRF-IV unit, or a SiRF-{I,II,II} unit?  Makes a big
difference; we need to figure out whether your individual unit
is defective or there has been a design change.

> I notice that gpsd is not waiting for the ACK's for each command.  Maybe
> we need to do that?

We never have on any SiRF I, II, or III device.  Besides, how would the
device know we're not going to wait on the response at message arrival time?

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

I take that to mean you are not seeing bugs...
  
> > 2. Direct-mode gpsctl baud rate changes on a SiRF IV fail for you.  I
> >    don't have one to test with.
> 
> Certainly, and all control writes seem to fail.

Discussed above.  I don't think we're going to fix this before 3.10.
The best we can hope for is to discover whether this is a problem with
SiRF-IV in general or your individual unit.

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

They're still there for me.  Still absent for you?  Please test - gpsmon
has changed considerably while I was working on this.

> > 4. Client-mode baud rate change attempts from either gpsctl or gpsmon
> > fail.
> 
> I have not tried gpsmon.  How would I do that?

Sorry, that was my error.  Those commands are disabled in client-mode
gpsmon.  It is theoretically possible they could be, but I'm not
going to try this before 3.10.  I've added an item about this to the TO-DO.

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

I am seeing them now, but am unable to explain my earlier observation.
The packet-getter bug should have prevented them from being seen,
unless there was some subtle timing-dependent way they could have
leaked through.  Which is not a reassuring thought.

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

Now they're JSON PPS objects.  You should be able to see them too.

> > 7. ^C interrupts gpsd for me, but not for you.
> 
> That depends.  It usually works, but there are some specific cases when it
> does not work for me.  I suspect because gpsd is catching the ^C then
> waiting for the ppsthread to end.

Aha.  I've just pushed a changed that nulls all the session thread hook 
slots and the single context hook slot when a signal is received.  That
may fix the problem.

> > 8. The above includes the entire set of known pre-3.10 issues.
> 
> AFAIK.  Plus doc checking.

My still open pre-3.10 issues:

1. gpsmon's PPS offset display shows zero when I think it should not.

2. gpsmon display flashing.  I keep thinking I have this fixed only
   to have it come back.  I think I know what causes it, but my 
   attempts to fix it keep leaking.

3. gpsctl client mode baud-rate changes don't work.

4. I need to follow the Time Service HOWTO instructions through.

5. I should document gpsmon's -a option.

Please test for previously discussed problems which may now be
solved and tell me if I'm missing anything.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature