gpsd switched to wrong driver SVN 6377

[Michael R. Davis]

Gpsd Folks,
Some how my gpsd magically switched my BU-303 from a "SiRF binary" to a "Trimble TSIP" driver at 1254665778.16 last night.

Any ideas what would have caused that? I thought that we were close to shipping.
Mike (mrdvt92)


     
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric Raymond-3]

Michael R. Davis <mrdvt92@...>:
> Gpsd Folks,
> Some how my gpsd magically switched my BU-303 from a "SiRF binary" to a "Trimble TSIP" driver at 1254665778.16 last night.
>
> Any ideas what would have caused that? I thought that we were close to shipping.

Line noise.  Those packet format's aren't much alike. It should have recovered
after a few seconds; did it?
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Michael R. Davis]

>> Some how my gpsd magically switched my BU-303 from a
>> "SiRF binary" to a "Trimble TSIP" driver
> It should have recovered after a few seconds; did it?

It never recovered.  That's how I noticed it.  I had to restart the service deamon to kick it back to working.


     
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric Raymond-3]

Michael R. Davis <mrdvt92@...>:
> >> Some how my gpsd magically switched my BU-303 from a
> >> "SiRF binary" to a "Trimble TSIP" driver
> > It should have recovered after a few seconds; did it?
>
> It never recovered.  That's how I noticed it.  I had to restart the service deamon to kick it back to working.

Tht's extremely weird.  That says gpsd never saw a SiRF packet again.
All I can guess is that you somehow found a hidden firmware mode that
completely changed the packet reporting format.  They're very different;
SiRF uses a fixed two-byte 0xa0 oxa2 header and two-byte trailer preceded by
a CRC checksum, while TSIP uses a one-byte 0x13 header and no checksum.

Chris, you have all the TSIP experience and you know SiRFs; is there
some additional checking we need to have in the packet sniffer?
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Chris Kuethe]

On Tue, Oct 6, 2009 at 7:39 AM, Eric S. Raymond <esr@...> wrote:
> Chris, you have all the TSIP experience and you know SiRFs; is there
> some additional checking we need to have in the packet sniffer?

The usual answer that everybody hates: "I have never heard of / seen
this before." - And I've run SiRF receivers for months at a time.

I suppose it could be a checksum / packet validation bug - I was
seeing superstar2 fail to detect correctly because I goofed on the
checksum computation. TSIP is one of those ugly, infix-delimited
protocols. Beyond that, we'd like to see some logs including packet
sniffer showing the failure - I know that's not going to be easy to
get.

CK

--
GDB has a 'break' feature; why doesn't it have 'fix' too?
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Michael R. Davis]

> "I have never heard of / seen this before."
> like to see some logs including packet
> sniffer showing the failure

I've had the BU-303 running ever since without a glitch.


     
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev