Hal Murray :
>
> e...@thyrsus.com said:
> >> hp58503a should probably be hpgps. It works for several devices.
> > OK. Can you enumerate some other devices so I can list them in the header
> > comment and on the driver page?
>
> The documentation already mentions the Z3801A. There are a lot of
e...@thyrsus.com said:
> An argument for "json", maybe. But not a really compelling one, because
> GPSD defined the protocol and anything else emitting it would probably be
> emulating GPSD deliberately.
I think I prefer JSON for the same reason I like SHM.
I think the real question is does the
Clark B. Wierda :
> IIRC, GPSD NG uses JSON over a socket. Is this restricted to GPSD, or is
> the JSON general enough to be used by any similar source?
It's general enough to be used by any similar source. While that wasn't one
of my design objectives, it's almost implied by something else I was
On Mon, Jun 27, 2016 at 2:49 AM, Gary E. Miller wrote:
>
> Since you opened the door...
>
> > |shm| T | Shared Memory Driver
> > |gpsd | T | GPSD NG client protocol
>
> I think that leads to confusion since they both, at least for now,
> come from gpsd. And until the gpsd_j
On Mon, Jun 27, 2016 at 12:21 AM, Eric S. Raymond wrote:
> The new refclock directive is implemented and documented. This has
> had some large consequences.
>
>
Great!
I'll echo Hal on the desirability to be less specific when we can.
I think we should try to have
e...@thyrsus.com said:
>> hp58503a should probably be hpgps. It works for several devices.
> OK. Can you enumerate some other devices so I can list them in the header
> comment and on the driver page?
The documentation already mentions the Z3801A. There are a lot of them in
the ham/hacker co
Yo Eric!
On Mon, 27 Jun 2016 05:16:15 -0400
"Eric S. Raymond" wrote:
> > Maybe: gpsd_shm, and gpsd_json. Or: shm and json.
> There is in theory a better case for calling "gpsd"
> something else, but in practice I think JSON is sufficiently flexible
> that we'll never have a variant that's truly
Eric S. Raymond writes:
> Which reminds me: an addition I'm considering is adding "offset" as a
> synonym for time1 or time2, whichever one usually sets an offset for
> time reported from the unit.
The documentation is quite unclear on this and I'm not sure I'd trust
each driver to do exactly the
e...@thyrsus.com said:
> I don't think shm needs to change at all. It says what it is - data coming
> over System V shm, which defines its own format by the shared structure
I like SHM. I think there are non-gpsd sources of SHM data.
I have no strong preferences for gpsd vs json.
--
These a
Gary E. Miller :
> Since you opened the door...
>
> > |shm| T | Shared Memory Driver
> > |gpsd | T | GPSD NG client protocol
>
> I think that leads to confusion since they both, at least for now,
> come from gpsd. And until the gpsd_json driver has sane, documented,
> defa
Hal Murray :
> e...@thyrsus.com said:
> > and the
> > noun/verb "fudge" is reserved for the two time offset options.
>
> Why? What's the difference between a flag that gets set to 0 or 1 and a time
> that gets set to a number?
When I hear the term "fudge factor" I think of a number used to ad
e...@thyrsus.com said:
> and the
> noun/verb "fudge" is reserved for the two time offset options.
Why? What's the difference between a flag that gets set to 0 or 1 and a time
that gets set to a number?
> There will be a *limited* open period for bikeshedding about the driver
> names.
hp58
Yo Eric!
On Mon, 27 Jun 2016 00:21:45 -0400
"Eric S. Raymond" wrote:
> The new refclock directive is implemented and documented.
Cool.
> There will be a *limited* open period for bikeshedding about the
> driver names.
Since you opened the door...
> |shm|
The new refclock directive is implemented and documented. This has
had some large consequences.
* Driver numbers and 127.127.t.u addresses are no longer used in the
documentation anywhere but in clockstat file examples - and I may
change that shortly. Some historical mentions of 127.127.t.u
14 matches
Mail list logo
