diff options
| -rw-r--r-- | TODO | 51 | ||||
| -rw-r--r-- | configure.ac | 2 | ||||
| -rw-r--r-- | gpsd.spec.in | 6 |
3 files changed, 58 insertions, 1 deletions
@@ -4,6 +4,12 @@ will unfold them again. ** Bugs in gpsd and its clients: +*** Nail down Daryl Ross's SiRF bugs + +Daryl Ross is reporting some very odd bugs on the BU-303 that I can't +reproduce with my almost identical test setup. This bothers me, and +I want to understand why it is happening. + *** EPH and EPV reports are zeroed too often in the TSIP driver There is some bad interaction between the policy code in @@ -69,6 +75,51 @@ system("free t") at the end of each handle_input() call. ** To do: +*** Evermore driver + +Petr Slansky wants Evermore chipset support. His email reads as +though he is competent to write it. An unanswered question is whether +there is a probe string that can elicit a PEMT or other unique +response from the Evermore chipset. + +*** SiRF firmware uploader + +Chris Kuethe appears to be well along on this. It is not yet +resolved whether SiRF Technology will allow us to ship the +binary loader code needed to do it. + +*** Decide what to do about RTCM support. + +With WAAS and EGNOS delivering differential-GPS corrections in-band +to most modern GPSes (and, in particular, to SiRF GPSses) there may +no longer be any point to supporting out-of-band RTCM104 and DGPSIP. + +If there is still a point to this, here is the elegant way to do it: + +1) Add code to packet.c that can recognize RTCM104 data packets. This + would be the hard part -- that format is *nasty*. + +2) Write a trivial RTCM104 driver that just copies recognized packets + into a save buffer. Now we have RTCM104 sessions integrated into + the gpsd architecture; we can hand RTCM104 sources like DGPS radios + to gpsd on the command line or via the control socket, just like GPSes. + +3) Arrange for packets from any attached RTCM104 sessions to get + automatically copied from their save buffers to any GPSes attached. + +4) When there are attached RTCM104 sources, tell the daemon to serve + these packets on port 2101. At this point we will have replaced + dgpsip's server function, through not yet its RTCM dumper function. + +5) Get rid of the -d option by hacking open_device() so that when it + sees a command-line option of the form server:port (with no + embedded backslashes) it opens a socket to read from that server. + Now any GPS-packet and RTCM data sources given on the command line + can be remote as well as local. + +6) Write a rtcmmon equivalent to sirfmon that disassembles and dumps + RTCM packets. + *** Hotplug interface problems The hotplug interface works pretty nicely for telling gpsd which diff --git a/configure.ac b/configure.ac index 7e955b23..5f9f68b6 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_INIT -AM_INIT_AUTOMAKE(gpsd, 2.27) +AM_INIT_AUTOMAKE(gpsd, 2.28) AC_PREFIX_PROGRAM(gcc) AM_CONFIG_HEADER(config.h) AC_LANG([C]) diff --git a/gpsd.spec.in b/gpsd.spec.in index f68cb6ca..e2c3fcae 100644 --- a/gpsd.spec.in +++ b/gpsd.spec.in @@ -126,6 +126,12 @@ cp gps.py gpsfake.py "$RPM_BUILD_ROOT"%{_libdir}/python${PYVERSION}/site-package %{_libdir}/X11/app-defaults/xgpsspeed %changelog +* Wed Jul 6 2005 Eric S. Raymond <esr@snark.thyrsus.com> - 2.28-1 +- The 2.27 source tarball somehow got truncated on upload. + Due to procedural mechanics at berlios.de, shipping a new release + seems to be the least painful way to recover. This release is + identical to 2.27 except the roadmap stuff has been added to TODO. + * Wed Jul 06 2005 Eric S. Raymond <esr@snark.thyrsus.com> - 2.27 - Arrange for the daemon to remove its pid file on exit. Fix some buffering problems with the Python side of the hotplug interface. |