| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Andre Naujoks informed me of this.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is more global context that really needed to be per-device state. Instead,
create a per-devicd servicetype member to carry this information. Practically
apeaking, this means gpsd can now watch multiple NTRIP and DGPS sessions without
getting confused.
All regressuin tests pass.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Another step towards integrating NTRIP support in a way that's
actually correct for the daemon architecture. This involved
conditioning out code for DGPSIP server lookups, a feature which was
never documented and has probably been broken forever.
It's actually not even clear there are still any DGPSIP servers still running;
the dgpsip package was removed from Debiann at maintainer request in 2008
(see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392666). I may
yet just rip out that code entirely.
|
|
|
|
|
|
|
| |
The flap over probes revealed that the NTRIP support is bolted onto the daemon
in a very awkward way that is likely to cause problems now that it's actually
being, like, *used*. This is a step towards making it behave more like a
normal driver.
|
| |
|
|
|
|
| |
I fixed them up to splint clean.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
in gpsd.c context,devices and subscribers were global in scope, but
only ever used in gpsd.c. Made them static scope
|
|
|
|
|
|
| |
All regression tests pass. Live-tested in both -n mode and without -n.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
What's going in with this commit, and the last one, is that I'm
disentangling the logic for JSON reporting of device state from the
daemon dispatcher layer. This means that other programs that use
libgpsd *without* necessarily going through the dispatcher layer will
be able to do so.
No logic changes.
|
| |
|
| |
|
|
|
|
| |
All regression tests pass.
|
|
|
|
| |
All regression tests pass.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first thing I had to do to make RTCM work at all, was to remove
the separate poll for the socket (the change in gpsd.c). The same
stuff is done in consume_packet, so there is no loss here. In fact the
duplicated read caused constant lock losses on the RTCM stream because
of missing data, which was already read by the now removed read.
Add RTCM2 passthrough to the UBX driver: versions of the firmware since 7.0
can handle this.
The change in net_ntrip.c adds another string to the valid strings for
rtcm2 to be recognized. See:
http://www.sapos-ni-ntrip.de:2101/sourcetable.htm for the sourcetable
of the server. The mountpoint I am using is EPS_NI. The problem is
the RTCM1_ data format. The people from sapos confirmed, that this is
a RTCM2 stream and so far it works.
All regression tests pass.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
|
|
|
|
| |
All regression tests pass.
|
|
|
|
| |
Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
|
|
|
|
|
|
|
|
| |
Protocol version number is bumped. Python and C test clients are known
to work; interfaces of the C and Python client bindings are
unchanged. Third-party client-side bindings which rely on naively
copying JSON members will break (implementers have been repeatedly
warned not to do this).
|
| |
|
|
|
|
| |
Experimental. Not documented.
|
| |
|
|
|
|
| |
All regression tests pass.
|
|
|
|
| |
All regression tests pass.
|
| |
|
|
|
|
|
| |
I thought I could avoid this, but it turns out SiRF chips before firmware
rev 2.3.2 don't reliably get a leap-second report either. Sigh...
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gains: the stored leap-second offset we used for this could go stale,
breaking our regression tests in the process - itr's just dumb luck
that it hasn't since done so since 2008.
Losses: If the receiver doesn't have leap-second cached in NVRAM (e.g,
between cold boot and the next subframe message) time will be inaccurate
by a few more seconds.
10 regression test outputs of 66 had to be rebuilt.
|
| |
|
|
|
|
|
| |
Now that we're reporting subframe data, we no longer want to avoid getting
it. Renoving this gets rid of one dependency on release time.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This will help prevent gpsd from consuming data from devices such as USB modems
that happen to look like GPSes because they use a USB-to-serial adapter thar
we have whitelisted. Relies on there being a /proc filesystem with Linux-like
semantics.
|
|
|
|
|
| |
Some consumers of gpsd subframes will want the raw values. Plus the
floating point make regression tests almost useless.
|
| |
|
| |
|
| |
|