| Age | Commit message (Collapse) | Author |
|---|
|
The old comment only mentioned that tty_nmea was used for time, but
subsequently position data was added to this line discipline.
|
|
|
|
|
|
and provide them as nmea(4) distance & velocity sensors.
With my 'u-blox GNSS receiver' that gives:
hw.sensors.nmea0.distance0=335.600 m (Altitude), OK
hw.sensors.nmea0.velocity0=18.337 m/s (Ground speed), OK
ok deraadt@
|
|
The NMEA 0183 standard says that the first two chars correspond to the
'source' of the message, right now we were only looking for 'GP' prefix
for 'GPS', but this can also be 'GL' for Glonass, 'BD' for BeiDou, 'GA'
for Galileo, or 'GN' for a generic GNSS source.
Match the RMC messages from all those variants, with this i'm able to
use my navilock nl-8002u (which uses GNRMC) as a timedelta sensor for
ntpd, and i have my GPS position in the nmea(4) sensors.
ok deraadt@
|
|
The account flag `ASU' will no longer be set but that makes suser()
mpsafe since it no longer mess with a per-process field.
No objection from millert@, ok tedu@, bluhm@
|
|
Fix inconsistent arguments for pppopen/pppclose/pppstart.
Use passed in argument p in pppopen instead of curproc.
"Looks good to me" deraadt@
|
|
ok doug tedu
|
|
ok mpi@ kspillner@
|
|
after discussions with beck deraadt kettenis.
|
|
nmea_timeout() is triggered introduced in rev 1.37.
ok sthen@
|
|
ok sthen@
|
|
hardcoded(!), over to an "indicator" sensor type, value depending
on whether the GPS has fix. ok deraadt@
|
|
|
|
Use SENSOR_FINVALID until we have good data, suggested by deraadt@
"i am happy" deraadt@
|
|
a process instead of using curproc. ok deraadt
|
|
|
|
M_ZERO; ok deraadt
|
|
CVS ---------------------------------------------------------------------
|
|
|
|
Really just the low-hanging fruit of (hopefully) forthcoming timeout
conversions.
ok art@, krw@
|
|
|
|
only when they are needed. Makes locations like -123d45m,-123d45m fit.
|
|
discussed with otto, sthen, ckuethe. ok otto
|
|
with sensors with the same name. The sensor name is now ever increasing
unless the reference count drops to zero, in which case the naming restarts
at zero as well.
|
|
signal sensor that reflects the status of the receiver.
tested by and ok ckuethe
|
|
|
|
suggested by otto.
|
|
ten minutes (or if a serial GPS is disconnect and we get no NMEA sentences
at all).
ok otto
|
|
eyeballed and ok dlg@
|
|
of new fields in the future is less disruptive. This is done similar
to how struct proc is handled for ps(1). ok jmc (man page changes)
tested fkr simon, and more suggestions from millert
|
|
|
|
the timedelta sensor when no PPS signal is available.
Previously, the timestamp was taken at the leading '$' character
of a GPRMC message, which was not always correct, as some GPS units
send other messages first; we do not know when the GPRMC message
is sent within a data block (we refer to a data block as the set
of NMEA messages that are sent by a GPS unit in one go, usually
once per second).
nmea(4) now takes the timestamp at the first '$' character received
after the start of a new seconds. Since GPS units transmit a data
block every second, the first message can be found by measuring the
gap between consecutive messages: after the longest gap, the first
message of the next second follows. And it is at the leading '$'
character of this message that we take the timestamp.
$GPGGA,..... <- take timestamp here
$GPGSA,.....
$GPRMC,..... <- decode time here
... <- possibly more messages
<- longer gap till start of next second
$GPGGA,..... <- it starts all over, take next timestamp
This code has been designed to work independent of the baudrate and
the rate at which the GPS sends out it's data blocks (usually 1 Hz,
but 5 Hz units are common as well):
With this change, precision is greatly improved in the absence of a
PPS signal and as a side effect, jitter is reduced.
Note that while this is much better than before, there is still a
slight offset to the real time, as calculating the fix in the GPS unit
and transmitting the '$' character takes a short, but unpredictable
amount of time.
When tty timestamping is enabled, but there is no PPS signal available,
the sensor status will be degraded to CRITICAL, which means "check your
hardware".
Thanks to Chris Kuethe for testing and feedback. ok ckuethe.
|
|
warning message and unconditionally set the sensor state to WARNING.
discussed with otto, ckuethe; ok otto, "i like it" ckuethe
|
|
|
|
|
|
|
|
Spotted by Constantine A. Murenin <cnst+openbsd@bugmail.mojo.ru>; thanks.
|
|
diff received from matthieu.
ok matthieu
|
|
that provides a PPS signal, more precision and less jitter can be expected.
With my test setting (a Garmin GPS 18 LVC hooked up to a i386 machine) I
observed a skew of 0.03 to 0.05 seconds between the tty timestamp and the soft
timestamp.
"put it in" deraadt
|
|
|
|
the value if it gets overwritten by other events.
|
|
|
|
|
|
a simpler function that splits the nmea sentence into fields, verifies the
checksum and eventually decodes the data (if it's a GPRMC sentence).
Ignore Loran-C for the moment, no one has such a receiver. Loran-C can
easily be added later if we have a receiver to test with.
|
|
information can be passed.
|
|
|
|
description.
- create the timedelta sensors as early as possible, but mark them invalid
as long as there is no real data.
- update docs accordingly
|
|
ok mbalmber
|
|
- fixed debug printfs
- cope with nmea0183 or nmea 2.3
- allow multiple receivers at the same time
Hacked in the park in downtown...
"commit this right away" mbalmer
|
