gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] SiRF IV on gpsmon


From: Gary E. Miller
Subject: Re: [gpsd-dev] SiRF IV on gpsmon
Date: Wed, 13 Nov 2013 23:53:08 -0800

Yo Eric!

On Wed, 13 Nov 2013 19:46:23 -0500
"Eric S. Raymond" <address@hidden> wrote:

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

And not just me.

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

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

> > 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?

Yup, I use ^C all day. :-)

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

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

Yup.

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

I have not tried gpsmon.  How would I do that?

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

Yup.

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

Yup.

> 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.
 
> 8. The above includes the entire set of known pre-3.10 issues.

AFAIK.  Plus doc checking.

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

Yeah, but neither a blocker for me, just a niec new feature.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]