How to start gpsd with fix baud rate of serial interface

[Kai Klenke]

Hello,

i am using the ublox "Antaris LEA-4H"-GPS-Receiver and it is via RS232
connected to the
gpsd on a Linux-Debian-Lenny machine.

The GPS-Receiver is configured to 38400 baud 8-N-1 with standard NMEA
output.

With debug level 5 of the gpsd i can see that there is an autobauding which
starts
with 9600baud -> 4800baud -> 19200baud -> 38400baud. This takes much time
and
so it will be nice if there is a possibility to start the gpsd with a fix
baudrate.

Is it possible via default file /etc/default/gpsd?

I don't find any description about this file.

Who can help?

Kai

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

[Eric S. Raymond-2]

Kai Klenke <klenke@...>:

> i am using the ublox "Antaris LEA-4H"-GPS-Receiver and it is via RS232
> connected to the
> gpsd on a Linux-Debian-Lenny machine.
>
> The GPS-Receiver is configured to 38400 baud 8-N-1 with standard NMEA
> output.
>
> With debug level 5 of the gpsd i can see that there is an autobauding which
> starts
> with 9600baud -> 4800baud -> 19200baud -> 38400baud. This takes much time
> and
> so it will be nice if there is a possibility to start the gpsd with a fix
> baudrate.
>
> Is it possible via default file /etc/default/gpsd?
>
> I don't find any description about this file.
>
> Who can help?

There is no such file. and one of my design goals is that there never will be.

The first speed tried by the hunt loop is the one already set by the
hardware (this is why 0 comes first in the hunt group list, to tell
gpsd not to change sppeds).  So, unless the hardware oport speed has
been changed since gpsd lasted opened it, gpsd spends no time at all
baud-hunting.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Paul Fox-3]

eric s. raymond wrote:
 > Kai Klenke <klenke@...>:
 > > i am using the ublox "Antaris LEA-4H"-GPS-Receiver and it is via RS232
 > > connected to the
 > > gpsd on a Linux-Debian-Lenny machine.
 > >
 > > The GPS-Receiver is configured to 38400 baud 8-N-1 with standard NMEA
 > > output.
 > >
 > > With debug level 5 of the gpsd i can see that there is an autobauding which
 > > starts
 > > with 9600baud -> 4800baud -> 19200baud -> 38400baud. This takes much time
 > > and
 > > so it will be nice if there is a possibility to start the gpsd with a fix
 > > baudrate.
 > >
 > > Is it possible via default file /etc/default/gpsd?
 > >
 > > I don't find any description about this file.
 > >
 > > Who can help?
 >
 > There is no such file.  and one of my design goals is that
 > there never will be.
 >
 > The first speed tried by the hunt loop is the one already set by the
 > hardware (this is why 0 comes first in the hunt group list, to tell
 > gpsd not to change sppeds).  So, unless the hardware oport speed has
 > been changed since gpsd lasted opened it, gpsd spends no time at all
 > baud-hunting.

but on a hand-held device, or even a laptop, the first use after
boot will likely hit the search phase, right?  i suppose one
could do an "stty 4800 < /dev/ttyGPS" before starting gpsd, but i
think that depends on linux tty semantics.  (in fact, so does the
'try 0 first' trick, right?).  i applaud your goal of minimum
config, but a "use this baudrate" option would be useful, in my
opinion.

if nothing else, it would work around a problem i saw a while ago
(which i'm not equipped to re-verify at the moment -- sorry -- i
hope i'm remembering right).  i believe that it's possible to set
a baudrate with the 'b' command which will not be searched for in
the hunt loop.  at the time i was doing gpsd recompiles for other
reasons, so i simply extended the hunt loop.  (i didn't know
about the "try current speed first" behavior at the time -- nor
would i have likely remembered it, it's not a very traditional
mechanism.)

paul
=---------------------
 paul fox, pgf@... (arlington, ma, where it's 55.6 degrees)
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Eric S. Raymond-2]

Paul Fox <pgf@...>:
> but on a hand-held device, or even a laptop, the first use after
> boot will likely hit the search phase, right?

Yeah, but why care?  It's not like the entire hunt loop takes more
than a maximum of about 1.5 seconds anyway.  I've tested and I know
this -- people who whinge about it taking "a long time" are, frankly,
talking utter horseshit.  One overhead of not more than a second and a
half per host-machine boot is a tiny price for avoiding all the nasty
issues surrounding a baud-rate switch.

>                                                  i suppose one
> could do an "stty 4800 < /dev/ttyGPS" before starting gpsd, but i
> think that depends on linux tty semantics.  (in fact, so does the
> 'try 0 first' trick, right?).

No.  The interpretation of 0 as "don't change speed" is done by gpsd
itself, not Unix. Unix interprets a change to baud rate 0 as a request
to close the device...I think.  It's not a behavior I would rely on.

>   i applaud your goal of minimum
> config, but a "use this baudrate" option would be useful, in my
> opinion.

No, it wouldn't.  It would be surrendering to one of the most
dysfunctional habits Unix programmers have, which is to bolt on
configuration switches when they're unwilling or unable to figure out
what the Right Thing is. In this case, the Right Thing is to write gpsd
so it correctly, automatically, adapts to its environment and *doesn't
bother the user to tell it things it can figure out itself*.

I have had to refuse such a request for a baud-rate switch approximately
once every nine months since I took the lead of this project, and I
expect to continue doing so as long as I keep running it.  If you are
on an SBC where the hunt loop isn't useful, you can compile for a fixed port
speed and that's the end of the argument.

> if nothing else, it would work around a problem i saw a while ago
> (which i'm not equipped to re-verify at the moment -- sorry -- i
> hope i'm remembering right).  i believe that it's possible to set
> a baudrate with the 'b' command which will not be searched for in
> the hunt loop.  at the time i was doing gpsd recompiles for other
> reasons, so i simply extended the hunt loop.  (i didn't know
> about the "try current speed first" behavior at the time -- nor
> would i have likely remembered it, it's not a very traditional
> mechanism.)

So, what you've described isn't even a bug.  You hacked the code to fix
your "problem" before you realized that gpsd would cheerfully reconnect to the
device and *just work*.

I love the Unix culture.  But this particular "tradition" (bolting on
configuration options as a substitute for autoconfiguration) should die
a swift and horrible death. It's not gpsd that is defective here, it's
your habits of thought.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Chris Kuethe]

On Wed, Sep 16, 2009 at 11:22 AM, Eric S. Raymond <esr@...> wrote:
> Yeah, but why care?  It's not like the entire hunt loop takes more
> than a maximum of about 1.5 seconds anyway.  I've tested and I know
> this -- people who whinge about it taking "a long time" are, frankly,
> talking utter horseshit.  One overhead of not more than a second and a
> half per host-machine boot is a tiny price for avoiding all the nasty
> issues surrounding a baud-rate switch.

It can take considerably longer than that. One of these days I'll post
some syslogs of detection taking the better part of a minute.



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

[Eric S. Raymond-2]

Chris Kuethe <chris.kuethe@...>:

> On Wed, Sep 16, 2009 at 11:22 AM, Eric S. Raymond <esr@...> wrote:
> > Yeah, but why care?  It's not like the entire hunt loop takes more
> > than a maximum of about 1.5 seconds anyway.  I've tested and I know
> > this -- people who whinge about it taking "a long time" are, frankly,
> > talking utter horseshit.  One overhead of not more than a second and a
> > half per host-machine boot is a tiny price for avoiding all the nasty
> > issues surrounding a baud-rate switch.
>
> It can take considerably longer than that. One of these days I'll post
> some syslogs of detection taking the better part of a minute.

That's still not "a long time".  If the overhead rises to on the order
of *ten* minutes, then I might concede we have a problem.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Paul Fox-3]

eric s. raymond wrote:
 > Paul Fox <pgf@...>:
 >
 > >                                                  i suppose one
 > > could do an "stty 4800 < /dev/ttyGPS" before starting gpsd, but i
 > > think that depends on linux tty semantics.  (in fact, so does the
 > > 'try 0 first' trick, right?).
 >
 > No.  The interpretation of 0 as "don't change speed" is done by gpsd
 > itself, not Unix. Unix interprets a change to baud rate 0 as a request
 > to close the device...I think.  It's not a behavior I would rely on.

sorry, i certainly wasn't clear.  it's the behavior of preserving
the current baud rate across a device close/open which i believe is
a linux-ism.  at least, it was definitely a change from unix tty
behavior that i first observed in linux -- perhaps it's customary
behavior everywhere (or perhaps even specified by posix) now.  i've
never viewed it as more than a convenience before this.

...
 > > if nothing else, it would work around a problem i saw a while ago
 > > (which i'm not equipped to re-verify at the moment -- sorry -- i
 > > hope i'm remembering right).  i believe that it's possible to set
 > > a baudrate with the 'b' command which will not be searched for in
 > > the hunt loop.  at the time i was doing gpsd recompiles for other
 > > reasons, so i simply extended the hunt loop.  (i didn't know
 > > about the "try current speed first" behavior at the time -- nor
 > > would i have likely remembered it, it's not a very traditional
 > > mechanism.)
 >
 > So, what you've described isn't even a bug.  You hacked the code to fix
 > your "problem" before you realized that gpsd would cheerfully
 > reconnect to the device and *just work*.

if it it had "just worked", i wouldn't have had to hack.  in
general i don't modify code needlessly.  gpsd wouldn't find my
device because my device was running at a speed not in the hunt
loop.  how would "preserve previous baud rate" help there?  you're
making assumptions that the device is only used for gpsd, perhaps?
or that no reboots were involved?  again, apologies for not being
able to recreate this right now, in order to be more confident in
what i'm remembering.

 >
 > I love the Unix culture.  But this particular "tradition" (bolting on
 > configuration options as a substitute for autoconfiguration) should die
 > a swift and horrible death. It's not gpsd that is defective here, it's
 > your habits of thought.

please.  lose the condescension.

paul
=---------------------
 paul fox, pgf@... (arlington, ma, where it's 59.4 degrees)
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Eric S. Raymond-2]

Paul Fox <pgf@...>:
> sorry, i certainly wasn't clear.  it's the behavior of preserving
> the current baud rate across a device close/open which i believe is
> a linux-ism.  at least, it was definitely a change from unix tty
> behavior that i first observed in linux -- perhaps it's customary
> behavior everywhere (or perhaps even specified by posix) now.  i've
> never viewed it as more than a convenience before this.

This can be checked; we have developers running under OpenBSD and MacOS X.
Can anyone report whether baud rate is preserved across device closes on these
systems?  

>  > So, what you've described isn't even a bug.  You hacked the code to fix
>  > your "problem" before you realized that gpsd would cheerfully
>  > reconnect to the device and *just work*.
>
> if it it had "just worked", i wouldn't have had to hack.

Then I don't understand your bug scenario.  If you set the port to 2317 bad,
then gpsd closed the port because there were no clients, then gpsd reopened
it later, gpsd should simply have continued reading bytes at that speed.

> in general i don't modify code needlessly.  gpsd wouldn't find my
> device because my device was running at a speed not in the hunt
> loop.  how would "preserve previous baud rate" help there?

It wouldn't. You're making a pretty good argument that I should remove
bspeed changes from the command set, or at least make them a privileged
command that can only be sent over the control port.

>  > I love the Unix culture.  But this particular "tradition" (bolting on
>  > configuration options as a substitute for autoconfiguration) should die
>  > a swift and horrible death. It's not gpsd that is defective here, it's
>  > your habits of thought.
>
> please.  lose the condescension.

I'll lose the "condescension" within ten seconds of when Unix programmers
as a culture get a clue about autoconfiguration.  And *not before then*.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Chris Kuethe]

On Wed, Sep 16, 2009 at 12:33 PM, Eric S. Raymond <esr@...> wrote:
> This can be checked; we have developers running under OpenBSD and MacOS X.
> Can anyone report whether baud rate is preserved across device closes on these
> systems?

Neither OpenBSD or OS X preserve speed across close.

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

[Paul Fox-3]

eric s. raymond wrote:
 > Paul Fox <pgf@...>:
 >
 > Then I don't understand your bug scenario.  If you set the port to 2317 bad,
 > then gpsd closed the port because there were no clients, then gpsd reopened
 > it later, gpsd should simply have continued reading bytes at that speed.

i used the 'b' command to set a baud rate that my device _did_
support (1200?  300?  i was idly investigating whether my 15
second latency issues were affected by baud rate).  as i recall,
gpsd continued to be able to talk to the device, though i can't
be sure of that.  then, when i terminated gpsd -- and, now that
i think of, possibly removed/inserted the USB receiver (i think
that would reset the baud rate to default), gpsd could no longer
find it.

 > > in general i don't modify code needlessly.  gpsd wouldn't find my
 > > device because my device was running at a speed not in the hunt
 > > loop.  how would "preserve previous baud rate" help there?
 >
 > It wouldn't. You're making a pretty good argument that I should remove
 > bspeed changes from the command set, or at least make them a privileged
 > command that can only be sent over the control port.

perhaps.  or don't allow setting a rate that's not supported in the
hunt list.

paul
=---------------------
 paul fox, pgf@... (arlington, ma, where it's 58.6 degrees)
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Eric S. Raymond-2]

Chris Kuethe <chris.kuethe@...>:
> On Wed, Sep 16, 2009 at 12:33 PM, Eric S. Raymond <esr@...> wrote:
> > This can be checked; we have developers running under OpenBSD and MacOS X.
> > Can anyone report whether baud rate is preserved across device closes on these
> > systems?
>
> Neither OpenBSD or OS X preserve speed across close.

Crap. That's why your hunt takes "the better part of a minute", then.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Kai Klenke]

Ok, thank for these fast responses. I don't want to anger somebody. It was
only
a question.

If i understand it correctly: There is the possibility to set the baudrate
of the serial port e.g. with the "setserial" command line tool in a shell
script
and then startig the gpsd. So gpsd starts at first with the preconfigured
baudrate.

Kai

-----Ursprüngliche Nachricht-----
Von: gpsd-users-bounces@...
[mailto:gpsd-users-bounces@...] Im Auftrag von Eric S. Raymond
Gesendet: Mittwoch, 16. September 2009 22:00
An: Chris Kuethe
Cc: gpsd-users@...
Betreff: Re: [Gpsd-users] How to start gpsd with fix baud rate ofserial
interface

Chris Kuethe <chris.kuethe@...>:
> On Wed, Sep 16, 2009 at 12:33 PM, Eric S. Raymond <esr@...> wrote:
> > This can be checked; we have developers running under OpenBSD and MacOS
X.
> > Can anyone report whether baud rate is preserved across device
> > closes on these systems?
>
> Neither OpenBSD or OS X preserve speed across close.

Crap. That's why your hunt takes "the better part of a minute", then.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

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

[Eric S. Raymond-2]

Kai Klenke <klenke@...>:
> If i understand it correctly: There is the possibility to set the baudrate
> of the serial port e.g. with the "setserial" command line tool in a shell
> script
> and then startig the gpsd. So gpsd starts at first with the preconfigured
> baudrate.

Yes, that would work fine under Linux.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[hamish_b]

Eric wrote:
> I love the Unix culture.  But this particular "tradition" (bolting on
> configuration options as a substitute for autoconfiguration) should
> die a swift and horrible death. It's not gpsd that is defective here,
> it's your habits of thought.


Or maybe it is a desire not to bind the end user to the limits of the
programmer's finite imagination? (a high ratio of control freaks and
gear heads might explain it too.. :)

I agree that an explosion of options is often used as a programmer's
cop out as opposed to really sitting down and taking the time to choose
good defaults or whatever; thus shifting the work load from the programmer
to the users. This is after all the legend of why Macs still ship with a
one button mouse - it forces the app developers not to be so lazy with
their program design interface.

I can understand the slippery-slope and lead-by-example arguments, even
if I don't really buy into those philosophies completely myself. At the
same time though there is no shame in accepting sage advice and taking
advantage of tip-offs. Quite the opposite actually - at some point it
just becomes plain old bloody-mindedness to ignore those gifts.

My "classic unix programmer" solution would be to have the program check
at search-time for two getenv() enviro variables called for example
GPSD_BAUD_HINT and GPSD_PROTOCOL_HINT:
  GPSD_BAUD_HINT="4800,N81"
  GPSD_PROTOCOL_HINT="NMEA"
If present and valid they'd be tried as the first iteration of the search
loop. They don't have to be well advertised, they could be buried down
the bottom of the protocol or debugging help pages. But they would be a
useful debugging tool.

Asking the end-users of the Mac OSX package to recompile just to get
it to work well with their hardware starts to cause more harm than it
solves IMO. The only savior from a 60sec search time is the fact that
the GPS itself might take that long to find a valid fix once powered
up by the USB port. Otherwise it would be ridiculous if the correct
values were known by the human in advance by they had no easy way of
communicating it.

Q: I never could figure out how to run "stty" successfully on OSX, the
example in the Gpsd help pages only works on Linux. Anyone know?
(see ML archives of this list for details of my previous attempts)


As a final point, folks may well be asking for this option because
they have seen it in every other terminal program they've ever used
and can't figure out where it has gone. But there is often deep truth
to be found in "the customer is always right". They may be totally
mistaken in their expectations or why the 'need' the widget, but the
query itself belies the fact that something, somewhere, is amiss.


regards,
Hamish



     

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

[Eric S. Raymond-2]

Hamish <hamish_b@...>:
> Eric wrote:
> > I love the Unix culture.  But this particular "tradition" (bolting on
> > configuration options as a substitute for autoconfiguration) should
> > die a swift and horrible death. It's not gpsd that is defective here,
> > it's your habits of thought.
>
> Or maybe it is a desire not to bind the end user to the limits of the
> programmer's finite imagination? (a high ratio of control freaks and
> gear heads might explain it too.. :)

"A desire not to bind the end user to the limits of the programmer's
finite imagination" is both the soundest and the most frequently cited
reason for many Unix traditions, yes.  I endorsed it as a general
argument myself in my book "The Art Of Unix Programming" (TAOUP).  I
think in general, acting on this desire is a good thing and to be
encouraged.

But I said "as a substitute for autoconfiguration". That makes a much
more specific claim about a very specific kind of situation, one where
an option switch is used to tell a program something that it can and
should deduce for itself.  If autoconfiguration "binds the end user to
limits", then the right way to think about it is that *it's being done
wrong and should be fixed*, not that autoconfiguration should be
discarded in favor of a hasty, thoughtless grab for an option switch.
 
> I agree that an explosion of options is often used as a programmer's
> cop out as opposed to really sitting down and taking the time to choose
> good defaults or whatever; thus shifting the work load from the programmer
> to the users.

While that's true, it's actually not the sort of design error that is
provoking my ire.  Good choice of defaults is often disputable.  Many
other possible options of the what-background-color-do-you-want kind
are matters of taste.  In these situations giving users lots of
flavor options is readily defensible.

What baud rate and protocol gpsd should set to make sense of incoming
data are not like this -- these are not "flavor" options, these are
"drop-dead" options. There is only one right baud rate and protocol;
if you choose wrongly, you lose - you don't just get an unpleasant
taste, *nothing works at all*.  And gpsd can figure out the right
values in less than a minute - on a Linux box, not more than two
seconds, and normally the time overhead is close to zero (fewer
than three packet transits).

It's that combination - errors being fatal plus discoverability - that
makes the case for autoconfiguration open and shut.  It's not like
choosing the style of your window decorations!

> I can understand the slippery-slope and lead-by-example arguments, even
> if I don't really buy into those philosophies completely myself. At the
> same time though there is no shame in accepting sage advice and taking
> advantage of tip-offs. Quite the opposite actually - at some point it
> just becomes plain old bloody-mindedness to ignore those gifts.

Yes?  Riddle me this, Batman...you've been around, you know how
frequently end users will screw up and misconfigure critical knobs
like baud rates and protocol selectors if there's any way for that to
happen.  Over the last five years, how many stupid pilot errors would
you suppose I've avoided by *not* having these switches?

If it's bloody-mindedness for me to prefer shipping a tool that just
works in 99.9% of cases to one where there are drop-dead options
sticking out all over that end-users routinely fuck themselves up
with, I accept the indictment and plead for more bloody-mindedness in
the world.

Applying the kind of thinking that defends flavor options to drop-dead
options is a bad mental habit, an overgeneralization, a category
error that Unix programmers need to unlearn.  Yes, this means *you*,
Hamish!  And you, Paul Fox.  

Your Unix-tradition reflexes are blinding you to significant
life-cycle costs.  Here's another one besides users shooting
themselves in the foot: when you have n drop-dead options, test
complexity rises on the order of 2**n.

> My "classic unix programmer" solution would be to have the program check
> at search-time for two getenv() enviro variables called for example
> GPSD_BAUD_HINT and GPSD_PROTOCOL_HINT:
>   GPSD_BAUD_HINT="4800,N81"
>   GPSD_PROTOCOL_HINT="NMEA"
> If present and valid they'd be tried as the first iteration of the search
> loop. They don't have to be well advertised, they could be buried down
> the bottom of the protocol or debugging help pages. But they would be a
> useful debugging tool.

And if I ever circumvent our autoconfiguration at runtime, that's very
likely how I'll do it.  You've proposed about the most subtle and
understated way to address the problem that fits within Unix
tradition.

But now my problem is exactly that the gravitational pull of that
tradition is so strong.  Once I've conceded that we're going to fall
back into option-switch-as-band-aid behavior even once, where does it
stop?
 
> As a final point, folks may well be asking for this option because
> they have seen it in every other terminal program they've ever used
> and can't figure out where it has gone. But there is often deep truth
> to be found in "the customer is always right". They may be totally
> mistaken in their expectations or why the 'need' the widget, but the
> query itself belies the fact that something, somewhere, is amiss.

Yeah.  Blame it on RS-232.  But arguing that gpsd should be brain-dead because
RS-232 is won't get you anywhere with me.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Kai Klenke]

 
The main reason for starting this thread about the fix baudrate was that
sometimes gpsd does not found the correct baudrate.
In this case the output of gpsd shows:...

gpsd: packet sniff finds type 0

and this never ends.

Normally i can see

gpsd: packet sniff finds type -1

and every 30 seconds the gpsd starts with a new baudrate.

What are the reason for this behaviour?

Kai

-----Ursprüngliche Nachricht-----
Von: gpsd-users-bounces@...
[mailto:gpsd-users-bounces@...] Im Auftrag von Eric S. Raymond
Gesendet: Donnerstag, 17. September 2009 20:03
An: Hamish
Cc: gpsd-users@...
Betreff: Re: [Gpsd-users] How to start gpsd with fix baud rate ofserial
interface

Hamish <hamish_b@...>:
> Eric wrote:
> > I love the Unix culture.  But this particular "tradition" (bolting
> > on configuration options as a substitute for autoconfiguration)
> > should die a swift and horrible death. It's not gpsd that is
> > defective here, it's your habits of thought.
>
> Or maybe it is a desire not to bind the end user to the limits of the
> programmer's finite imagination? (a high ratio of control freaks and
> gear heads might explain it too.. :)

"A desire not to bind the end user to the limits of the programmer's finite
imagination" is both the soundest and the most frequently cited reason for
many Unix traditions, yes.  I endorsed it as a general argument myself in my
book "The Art Of Unix Programming" (TAOUP).  I think in general, acting on
this desire is a good thing and to be encouraged.

But I said "as a substitute for autoconfiguration". That makes a much more
specific claim about a very specific kind of situation, one where an option
switch is used to tell a program something that it can and should deduce for
itself.  If autoconfiguration "binds the end user to limits", then the right
way to think about it is that *it's being done wrong and should be fixed*,
not that autoconfiguration should be discarded in favor of a hasty,
thoughtless grab for an option switch.
 
> I agree that an explosion of options is often used as a programmer's
> cop out as opposed to really sitting down and taking the time to
> choose good defaults or whatever; thus shifting the work load from the
> programmer to the users.

While that's true, it's actually not the sort of design error that is
provoking my ire.  Good choice of defaults is often disputable.  Many other
possible options of the what-background-color-do-you-want kind are matters
of taste.  In these situations giving users lots of flavor options is
readily defensible.

What baud rate and protocol gpsd should set to make sense of incoming data
are not like this -- these are not "flavor" options, these are "drop-dead"
options. There is only one right baud rate and protocol; if you choose
wrongly, you lose - you don't just get an unpleasant taste, *nothing works
at all*.  And gpsd can figure out the right values in less than a minute -
on a Linux box, not more than two seconds, and normally the time overhead is
close to zero (fewer than three packet transits).

It's that combination - errors being fatal plus discoverability - that makes
the case for autoconfiguration open and shut.  It's not like choosing the
style of your window decorations!

> I can understand the slippery-slope and lead-by-example arguments,
> even if I don't really buy into those philosophies completely myself.
> At the same time though there is no shame in accepting sage advice and
> taking advantage of tip-offs. Quite the opposite actually - at some
> point it just becomes plain old bloody-mindedness to ignore those gifts.

Yes?  Riddle me this, Batman...you've been around, you know how frequently
end users will screw up and misconfigure critical knobs like baud rates and
protocol selectors if there's any way for that to happen.  Over the last
five years, how many stupid pilot errors would you suppose I've avoided by
*not* having these switches?

If it's bloody-mindedness for me to prefer shipping a tool that just works
in 99.9% of cases to one where there are drop-dead options sticking out all
over that end-users routinely fuck themselves up with, I accept the
indictment and plead for more bloody-mindedness in the world.

Applying the kind of thinking that defends flavor options to drop-dead
options is a bad mental habit, an overgeneralization, a category error that
Unix programmers need to unlearn.  Yes, this means *you*, Hamish!  And you,
Paul Fox.  

Your Unix-tradition reflexes are blinding you to significant life-cycle
costs.  Here's another one besides users shooting themselves in the foot:
when you have n drop-dead options, test complexity rises on the order of
2**n.

> My "classic unix programmer" solution would be to have the program
> check at search-time for two getenv() enviro variables called for
> example GPSD_BAUD_HINT and GPSD_PROTOCOL_HINT:
>   GPSD_BAUD_HINT="4800,N81"
>   GPSD_PROTOCOL_HINT="NMEA"
> If present and valid they'd be tried as the first iteration of the
> search loop. They don't have to be well advertised, they could be
> buried down the bottom of the protocol or debugging help pages. But
> they would be a useful debugging tool.

And if I ever circumvent our autoconfiguration at runtime, that's very
likely how I'll do it.  You've proposed about the most subtle and
understated way to address the problem that fits within Unix tradition.

But now my problem is exactly that the gravitational pull of that tradition
is so strong.  Once I've conceded that we're going to fall back into
option-switch-as-band-aid behavior even once, where does it stop?
 
> As a final point, folks may well be asking for this option because
> they have seen it in every other terminal program they've ever used
> and can't figure out where it has gone. But there is often deep truth
> to be found in "the customer is always right". They may be totally
> mistaken in their expectations or why the 'need' the widget, but the
> query itself belies the fact that something, somewhere, is amiss.

Yeah.  Blame it on RS-232.  But arguing that gpsd should be brain-dead
because
RS-232 is won't get you anywhere with me.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

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

[Chris Kuethe]

Try "gpsd -n -N -D7 /dev/gps >& gpsd.out" - this will emit a huge amount of
debug spew including the contents of the port buffer and all the sniffer
state machine transitions. You may find some hints therein.

On Sep 17, 2009 10:08 PM, "Kai Klenke" <klenke@...> wrote:


The main reason for starting this thread about the fix baudrate was that
sometimes gpsd does not found the correct baudrate.
In this case the output of gpsd shows:...

gpsd: packet sniff finds type 0

and this never ends.

Normally i can see

gpsd: packet sniff finds type -1

and every 30 seconds the gpsd starts with a new baudrate.

What are the reason for this behaviour?

Kai -----Ursprüngliche Nachricht----- Von:
gpsd-users-bounces@... [mailto:gpsd-users-...
Gesendet: Donnerstag, 17. September 2009 20:03
An: Hamish

Cc: gpsd-users@... Betreff: Re: [Gpsd-users] How to start gpsd
with fix baud rate ofser...

Hamish <hamish_b@...>: > Eric wrote: > > I love the Unix culture. But
this particular "tradit...
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Eric S. Raymond-2]

Chris Kuethe <chris.kuethe@...>:
> Try "gpsd -n -N -D7 /dev/gps >& gpsd.out" - this will emit a huge amount of
> debug spew including the contents of the port buffer and all the sniffer
> state machine transitions. You may find some hints therein.

Actually, -D 5 should be good enough.  Got to -D 7 if the -D 5 messages
don't reveal the problem.

Packet type 0 means the daemon thinks it's seeing #-led comments comment.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-users mailing list
Gpsd-users@...
https://lists.berlios.de/mailman/listinfo/gpsd-users

[Ed Wildgoose-2]

Eric,

I find it curious that you are so keen on autoconfiguration (which I
wholly agree is a great goal!), yet you were apparently dismissive of my
suggestions to add detection of AT serial modems to gpsd (with the goal
of then avoiding using them as a gps)?

I don't mean to hijack this thread, but perhaps I could suggest this
autoconfiguration goal could be taken even futher with a view to
figuring out when we *don't* have a gps?

All the best

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

[Ed Wildgoose-2]

Actually, that comment came out and read a lot more provocatively than I
intended.

To rephrase as intended: I whole heartedly buy autoconfiguration....
Could we take it even further though?

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