| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Most drivers now have a control_send method that takes a
payload. provides whatever checksuming and leader/trailer bytes are
needed, and ships it to a specified active device.
This change should not alter any behavior. All regression tests pass.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
...and copying ascii strings around when they're not going to be printed.
This saves quite a lot of CPU. I processed a 50MB ubx binary file. With
no "-D" options, this saved nearly 2.2M calls to gpsd_hexdump and the
processing time for this file went from 84 seconds to 35 seconds.
|
| | |
|
| | |
|
| |
|
|
|
| |
...mostly from Wayne Knowles on time-nuts. I still haven't figured out
a good way to autodetect parity of a serial line.
|
| | |
|
| | |
|
| |
|
|
|
| |
Change to 'type_name' so gpsd pieces can be used with C++. Reported
by Matt Roberds <mattroberds@cox.net>.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Note that the implementation is now somewhat different. Before, this
flag prevented low-level writes to the device. Now it prevents operations
that could *cause* low-level writes -- notably subtype probes, mode
changes, and baud-rate changes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big, super-intrusive patch but changes no logic at all --
it's all about ripping out some of the gps_device_t structure members
into a new gps_packet_t structure. Even the driver API doesn't change
at all, this is all libgpsd(3) internals being rearranged.
The motivation here is that we want to kill off the ad-hoc Python
implementation of a packet-sniffer in gpsfake. To do that we need to
be able to write a "pure" packet sniffer that uses the same C code as
the daemon's but without being welded to the rest of the libgpsd(3)
code. This is the first step towards that.
|
| |
|
|
| |
...the same way probe_subtype does, and for the same reason.
|
| | |
|
| |
|
|
|
|
|
|
| |
my Lassen iQ outputs 64-byte 8F-20 superpackets, not 56-byte like the
manual says. If I allow these oversized packets to come in, the TSIP
parser seems to cope, and I get fixes. I'm not sure about 8F-23 yet;
I haven't seen any of these from the receiver, but I will entertain
the possibility that they too could be oversized.
|
| |
|
|
| |
...so I don't have to wade through all the packet sniffer output.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
if configuration is enabled.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch defines a uniform set of log levels and changes all gpsd_report()
instances to use them. In most cases (I'd say about 80%) this will make
no observable difference, as the numeric log levels the code was using were
not too badly inconsistent anyway. The new log level macros are defined
and described in gpsd.h.
The main thing I wanted was to be able to consistently force dumping
of all I/O to devices and clients with -D 4. Some drivers didn't honor
this. One or two still may not through lack of an internal write() wrapper
that does logging; there will need to be some followup changes.
Level 0 messages are always displayed, but to make the semantics clearer
there are two defines LOG_ERR and LOG_SHOUT.
Level 5 is still super-raw I/O reporting. Level 6 and 7 messages are
tagged RAW_LOG+1 and RAW_LOG+2; I was particularly careful about these
because we have one report of a user who is getting good results from
Garmin serial only at -D 7 or up, and perish forbid I should interfere
with that bug being found.
|
| |
|
|
|
| |
...whether or not they actually do anything. Otherwise it may not
have the right value when somebody queries it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
There is now a new method, "configurator". The initializer method
probes the driver for subtype information (such as a firmware rev)
without changing any device settings. The configurator method does
things like selecting which packets should send.
At the moment, these two methods are always called in tandem, so there
has been effectively no change in behavior. Soon, though, gpsctrl
will call the initializer method but *not* the configurator.
|
| |
|
|
|
| |
While investigating this I discovered that part of a previous cange (moving an
ntpshm_put() call out of the NMEA driver) was incorrect and reverted it.
|
| |
|
|
|
|
| |
...for those who want to build their own apps linked against libgps and
want the headers to work. Works on OpenBSD, tested by Jeff Francis on
OS X and Linux
|
| |
|
|
|
|
|
|
|
|
| |
...a function to be called just after the autobaud hunt sets the line
speed each time. Use this to get rid of the internal baud hunt loop
in the True North driver; instead, the ID query and rate-setting
strings will be sent by the wakeup hook.
Note: this patch is untested. I'm pretty certain it will work, but
somebody needs to try it on live hardware.
|
| | |
|
| |
|
|
| |
First line where possible, second line for scripts called with #!
|
| |
|
|
| |
All regression tests pass.
|
| | |
|
| |
|
|
| |
..and a type fix that unbreaks the TSIP build.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It's not compiled in by default, but it does require one architecture
change -- device channels is now a driver- specific capability, since
the Thales GPS our TrueNorth user is working with has 14 channels.
|
| | |
|
| |
|
|
| |
(and then recovers)
|
| | |
|
