Re: [gpsd-dev] Trimble tweaks (parity, time offset)

[Eric]

Oliver Jowett <address@hidden>:
> I have some patches to support the particular trimble chip I'm working with
> which wants to run at 115200, odd parity, 1 stop bit.
> Specifically:
> 
>  * don't stomp on the original port parity/stop bit settings, so if you
> wish you can configure them with stty beforehand. This may indirectly break
> other setups as the hunt loop doesn't know anything about parity settings.
>  * support a FIXED_PARITY option like FIXED_PORT_SPEED et al for using only
> a single parity setting
> 
> Without this I can't reliably talk to this chip as gpsd will force no
> parity regardless of any manual stty settings I make.
> It's basically the same thing that Lee ran into here:
> https://lists.gnu.org/archive/html/gpsd-users/2015-11/msg00000.html
> 
> Also
> 
>  * don't assume a 75ms time offset (this value seems like a guess and it's
> wildly inaccurate in my case, I see an offset of <20ms)
> 
> The changes are currently on github here: https://github.com/mutability/gpsd
> 
> What do I need to do to get these patches integrated into the main tree?

I'll take the FIXED_PARITY patch right away if you'll email it to me.

The others I'm a little hesitant about - the Trimble is a gnarly beast and
I'd like to hear devs who understand that driver better than I do opine
as to whether the change will break existing installations.

> (on a slightly related topic, I couldn't get the hunt loop to work
> usefully; how fast is this meant to converge? it was taking minutes per
> speed setting..)

That varies for reasons I don't understand and which seem to relate to
quirks in the OS tty layer. It's very fast under Linux, we typically
get sync in less than a second and the worst I've seen is around three
seconds.  It's slower on BSDs.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>