Gpredict & GPSD
Real time satellite tracking and orbit prediction
Status: Beta
Brought to you by:
csete
Menu
▾
▴
#27 Gpredict & GPSD
Please add the definition of coordinates of ground station through the GPSD.
http://gpsd.berlios.de/
gpsd would be a nice addition especially for folks wanting to go into the field. This does raise questions about what other possibilities we should consider and what an integration should look like.
There are other infrastructures that also provide geolocation. GeoIP and GeoClue both come to mind in Ubuntu. GPSD is probably more widely deployed and supported. Long term however they should be considered.
For those not using rotors it would provide enough information to make the system work. They can manually search for the satellite to account for declination. Those using rotors need to know where true north or south is to configure their rotator. A widget that computes declination would let folks use a compass to find true north.
There are several ways this might integrate. All have their tradeoffs.
A first approach might be when setting up a QTH, there is a "get gps value" button that one time reads in the gpsd information. It would leave most of the visualization and prediction code untouched. This would be annoying though for someone in a vehicle either operating on the move or wanting to know when to stop for the next pass.
A second approach could continuously update the position. This allows passes and other information to be updated continuously. Some parts of the code support this. All may not. These updates would probably assume a stationary station in the first cut. Another question is doppler from the station moving. How/whether to handle this is a real question.
There may be other possibilities that have not come to mind. Any other thoughts would be appreciated.
Thank you for your attention.
GeoIP is not accurate service, the error may be hundreds of kilometers.
GeoClue is only a proxy for other programs (gpsd, gypsy, hostip, plazes, gsmloc) and only gpsd, gypsy give the required accuracy.
I think gpsd is the best choice.
Yes, the definition of the true north is the problem, but
1. All GPS-devices determine the true north in movement.
2. Some GPS-devices have a digital compass.
but still we need to do a manual adjustment.
Than the first approach differs from the manual setting coordinate possible now? I think we need to constantly update the position at intervals specified by the user.
What to do with the doppler effect, I do not know. :(
I think it should be the version that refreshes the position regularly. It will require some changes but I think it can be implemented in a similar way to when updating TLE data.
subversion checkin 727 creates a branch for gpsd/geoclue/gpsy testing and development. This seems like a potentially large issue touching many parts of the code. The two parts that seem impacted the most are the polar views in both the module and rotator tracking. The instantaneous frequency and position estimates seem straightforward to implement. There also is the need for configuration gui's.
In the interest of understanding the possibilities, I took a deeper look at the two api's.They both have their advantages. Both have basic get position type calls with some startup and shutdown calls. If one integrates then the other should be a straightforward change should we decide to change ships.
Using the Geoclue tools over the weekend there is room for improvement especially on the IP location side. The ability of geoclue to abstract gpsd/gypsy away is a nice feature.I was hoping that geoclue would eliminate the need to maintain locations.dat. That certainly does not seem the case now. Hopefully that will change with time.
Before diving into coding, a basic outline for some consensus seemed reasonable. As the QTH is currently associated with a module, any gps service would be associated with the module as well. If it can be opened then the gps information would be used otherwise it would default back to the current location, hopefully with some notice to the user. (first cut the gps port/server information would be hard coded.) If gpsd updates the module position at each update, then most everything should be correct in terms of current az/el, doppler (excluding a car doppler) and the like for realtime operation. (What to do in non-realtime operation is another question. That can wait.) The module when it closes can close the connection.
Updating all the polar plots is needed. This may involve adding either time or position information into the passes to allow a comparison if they were based on old data. Then the code that updates the passes needs more logic. This really should only be an issue for moving stations.
Overtime, better error handling would be introduced. Examples include detecting if the GPS does not have lock, better handling of loss of socket connection.... Most of this would occur at the module level. Probable solutions to this are to fall back to either the hard coded value or the last known and notify the user.
The GUI for configuration also need development but it can wait until other proof of concept work is done.
In summary, there is a branch for gpsd integration, An initial approach suggests changes in the module code to update the information. Over time error checks, a gui, and polar plot updates should come forward. gpsd versus geoclue offer similar api's so an integration with one should allow abstraction to the other.
if you haven't got GPS device it's no problem.
http://gpsd.berlios.de/gpsfake.html
http://git.berlios.de/cgi-bin/cgit.cgi/gpsd/tree/test/daemon
I strongly recommend keeping GPS-related code away from the modules. The modules need a location, whether it is a static location or something that comes from a GPS shouldn't matter. It is just like with satellite TLE - the modules don't care whether TLE comes from Celestrak or AMSAT - all they need is the data and to know when it has changed (gtk_sat_module_reload_sats()).
It can be the same with the location. Whenever the location changes - be that due to GPS or the user editing the location) there should be an API call gtk_sat_module_reload_qth() which reloads the location data from the file and makes sure that all views are brought up to date. In fact, I think much of the logic will be the same as with reloading the satellites except that we reload the location instead of the satellites and make sure that the relevant functions are called.
As for how to implement the gpsd client, maybe it should be a global task/thread that polls gpsd and stores the data in an associated .qth file. When an update has taken place it triggers the reload_qth event. Alternatively, the modules could monitor the .qth files themselves checking when they were last modified and update the data at their own convenience.
Starting at the far end, updating the QTH files with every update of the GPS seems dangerous. GPS's tend to give positions on the order of once a second. Updating the file once a second seems a good way to test a SSD's wear leveling. Having the update only occur in ram seem safer.
This begs the question of what will be in QTH files/structures in the GPSd enabled era. My expectation was the current fields lat, long, alt,description would remain. Added would be a server and port to interface with gpsd and a field to indicate whether this was a static or dynamic QTH. (Lists of servers and ports may also be more appropriate for folks using their laptop at home, in the car, at the summer house, where gps is part of their infrastructure.) For a dynamic QTH the lat long alt can store the last long alt from the GPS. These may also be stored in a last lat, lon, alt set of fields in the qth file or a cache (saved once a session.) With this in mind the QTH file does not need to change except when changed byt the user which is more in line the frequency of tle updates. This is predicated on the possibility of making the QTH file backwards compatible which should be straightfoward if we only add parameters.
The earlier comments suggest that the qth file/structure is the data of the location. There is another interpretation or extension of this structure. The TLE file is a description of the orbit but not a complete definition of the satellite position as it is right now. This does not occur until the module is updated and time is added. Taking a related interpretation of the "new" qth file, there is a default position, if no GPS is available this can be used. There also is metadata to get info from the GPS. If gps was available in the past and is no longer, time dependence can allow for dead reckoning of the QTH.
This also allows the future possibility of a trip planner that allows someone to sketch out a trip and run sky at a glance for their two week trip across the Outback/desert southwest/atlantic ocean or any other trip. As someone uses the clock controller the positions are also moving and the clock controller only works within a module.
What if we want to have our QTH be a satellite? The qth file would contain the TLE's for the satellite. It's position would be a function of time (that comes from the module). When we get the station to station stuff working, we can ask the question, when can I work ISS through AO-51? (This may be far fetched but it is illustrative.)
At a another level, updating only the "active" qth's sound reasonable. This prevents someone from creating more QTH's than usable ports at the same time. (This is a pathology but it points to scalability.) To do this the modules would either need to do the update themselves or notify the master updater on what to update. A mechanism is needed to prevent the master updater from stopping the update if one of multiple modules using one qth closes.
Letting the module query gpsd directly eliminates management problems. GPSD can support multiple connection. It allows dead reckoning and other time based position calculations to be possible in the future without a code rework.Yes this may be wasteful if multiple modules use the same qth but there is no management overhead.
To address the concerns of the earlier comment, a compute_qth_position call at the start of module creation and updates will give the module a position. It might be the static position from the file. It might be the default hardcoded position, or it might be the most recent gps reading. Satellite position is computed inside the module. Why not the QTH?
This is a different take on the same source code regarding where to update the position.
Please whatever happens, do not let the qth files be rewritten every gps/module/satellite update.
SVN version 728 contains a very unpolished not ready for prime time, not agreed to by anyone, implementation of a gpsd integration in branches/gpsd_testing. It shows what such a scenario might look like and what things might need fixing. It is not intended as the best software.
The version checked in connects to a gpsd on the local machine on the default port. This will need to be configurable. It clobbers the QTH file contents. It does no error handling if gpsd fails.
It does make the qth marker on the satmap a dynamic rather than static element.
If someone wants to test but does not have a GPS, I am using the gpsfake command with the logs from the test/daemon directory of the gpsd git tree.
Thanks for the initial implementation Charles - it's good to have something concrete to look at.
My only concern is that gtk_sat_module becomes more complex and bloated than it has to be. Adding new features and functionality is always exciting for both developers and users; however, we have to keep in mind that gtk_sat_module is one of the most central pieces in Gpredict and changes made here can have significant impact on the overall behaviour of the program. New code, which is only relevant for a small fraction of users might be better put somewhere else.
I got concerned when I took an initial look at gpsd - the website shows the "simplest example" as a 500 lines long C program. Looking at your initial implementation it seems it can be done much simpler, which is good. But there are still several areas of concern:
(1) Can we ensure that gps related function calls will not block the module?
(2) What do we do about update frequency? Even when travelling in a fast vehicle updating more often than once every few minutes does not seem to be necessary.
(3) What do we do when several modules share the same location?
(4) GPS code must be optional. At this point we can only have gpsd as an optional dependency and the code will have to be surrounded by #ifdefs. Having this in gtk_sat_module will not be pretty.
Having said that, I have nothing against giving it a fair chance. If it can be done safe and simple, fine with me!
Eventually, a compromise between the two options may turn out to be the best solution: Have the GPS code be a logical part of gtk_sat_module but in separate files/objects.
> What if we want to have our QTH be a satellite? The qth file would contain
> the TLE's for the satellite. It's position would be a function of time
> (that comes from the module). When we get the station to station stuff
> working, we can ask the question, when can I work ISS through AO-51? (This
> may be far fetched but it is illustrative.)
This is a very reasonable use case; however, considering a satellite as QTH will generate incorrect results because the fundamental condition of EL > 0.0 deg does not longer apply. Two satellites can be within range of each other regardless of "elevation" - btw. the concept of elevation is not very useful in space.
Let me see if I can address the concerns. Some were itemized and some were not.
Regarding the complexity of the gtk-sat-module, it is not clear to me how to avoid it. The major extension here is that the location of the qth is time varying. The place where time exists and is controlled is in gtk-sat-module. While not technically needed for gpsd/gypsy/geoclue, there are many things having access to time would enable. Any suggestions would be appreciated.
My initial concern with gpsd was that they discouraged a polling mode. Instead they had a method that setup callback functions when data became available. While doable, it raised mutex problems with yet another thread running. This appears to not be the case. In fact I might submit my simple test program to gpsd as an example of polling usage. The actual gpsd call is probably only 15 lines.
As for the blocking concern, if gpsd works as advertised, then there should be no problem. The gps_open and close routine seem to work non-blocking with or without a gpsd instance present. Currently the code uses a gps_waiting call to check if data is available. This call is supposed to be non-blocking. If data is available, it uses a gps_poll call to get the data. This call may block in the current configuration. However it can be modified to mitigate blocking at the cost of more data checking it may be changed. There is a POLL_NONBLOCK option that may be passed forward.
Regarding the update rate with gpsd, there appear to be two factors, one the gps and the second is the vehicle the qth is in. Right now if qth data is available it is consumed. My quick understanding is that the gps updates at about 1Hz. If faster is needed an interpolation may be necessary. Right now, leaving interpolation out sounds the easiest way to make progress. Limiting the updates for the qth as the satellite are now could result be done. At first glance a 1hz update is on the order of the 1/3 hz update applied to the satellites by default. The next question is how fast we need to update based on the vehicle motion. Probably the fastest vehicle that would run gpredict is the ISS. If we say 1/3 is ok for the iss update for other purposes it is probably ok for the QTH update as well.
A related question is what does it cost to do a QTH update. Right now it is fairly minimal. The map qth icon is updated. Everything else looks at the qth information as it always has. Frequencies and the like are recomputed when predict_calc is called. When the qth update is protected by the same mutex as the satellite update, the risk of a race condition disappears. Ultimately there may be some additional cost to update the path's in the polar views but those should also be minimal. This may change if doppler is added but it should not be much, just another dot product operation.
Regarding 3 what happens when several modules share the same information, this should definitely be on the punch list of testing. If gpredict establishes multiple connections to gpsd, this should work. Yes it could be more socket efficient but at what cost.
gpsd code being optional is definitely a plus. Yes it will be messy. My current vision is to have qth_update in qth_data.c, this will move the pain but still have pain. The GPSd folks also recommend checking some API versions as well and only work with recognized api versions.
Most distributions these day include gpsd so it is not clear having it as a dependency would be bad.
typo fix:
Index: src/qth-data.c
--- src/qth-data.c (revision 729)
+++ src/qth-data.c (working copy)
@@ -28,9 +28,6 @@
#include <glib.h>
#include <glib/gi18n.h>
-#if HAS_LIBGPS
-#include <gps.h>
-#endif
#include "sgpsdp/sgp4sdp4.h"
#include "qth-data.h"
#include "sat-log.h"
@@ -38,6 +35,9 @@
#ifdef HAVE_CONFIG_H
# include <build-config.h>
#endif
+#ifdef HAS_LIBGPS
+# include <gps.h>
+#endif
#include "orbit-tools.h"
#include "time-tools.h"
Index: configure.ac
--- configure.ac (revision 729)
+++ configure.ac (working copy)
@@ -30,7 +30,7 @@
AC_SUBST(PACKAGE_LIBS)
dnl optional check for libgps
-PKG_CHECK_MODULES(LIBGPS, [ libgps >= 2.90 ],
+PKG_CHECK_MODULES(LIBGPS, [ libgps >= 2.90 ], [
CFLAGS="$CFLAGS $LIBGPS_CFLAGS";
LIBS="$LIBS $LIBGPS_LIBS";
havelibgps=true;
hm... may correctly HAVE_LIBGPS
Why you use libgps API? I think libgpsd API simpler and more suitable.
Thanks for the patch.
Regarding the choice of library, the short answer is at the end.
The reason I picked libgps over libgpsd is the description on the gpsd website. libgps is described as "An interface library that manages communication with the daemon." libgpsd is described as "The low-level library used by gpsd to talk to a GPS." I interpreted this as libgps is the library for clients and libgpsd is the library for the server. This may not be technically correct but it was a place to start. It also was not clear that libgpsd was able to explicitly manage multiple concurent accesses to the same gps. Additionally it was not clear that libgpsd was non-blocking. Additionally the gpsd-ng page <http://gpsd.berlios.de/protocol-transition.html> used libgps calls and not libgpsd calls. To me this implied that libgps was a more stable supported interface.
In terms of libgps being too complicated, I thought the same myself. My simple test program is about 30 lines long. Most of them are print statements and header lines. After this it became clear that simple was possible.
Additionally, using libgps gave me access to gpsfake for debugging purposes. It was not clear libgpsd did.
There are things about libgps that I do not yet understand. Most of these deal with error handling.
Did I make the right choice? I don't know. These API's are all new to me. That is part of the reason why this is in a testing tree.
Long term, all location services should work just fine if the code is correct. Ideally I now envision a variety of qth types that get data from a variety of sources depending on what is installed and supported. For testing a libgps and libgpsd implementation may be worthwhile to exercise the interfaces and internal gpredict functions.
The short answer really then is that libgps was the first thing I made work after looking at documentation and trying other tools.
Gpsd may be available on all linux but we also have to keep windows and mac users in mind.
As I wrote earlier, considering a satellite as QTH makes no sense because the conditions for "being in range" are completely different and also Doppler calculations would need to consider the velocity of the QTH in addition to the velocity of the satellite! So we should stick to considering location closer to Earth. An aeroplane is probably as far as we can go, but even at 10-20km altitude satellites below 0 deg elevation will be visible.
Roger on the windows/mac. That code is already in svn.
Positions updates should trigger some events. The AOS calculation for modules is accounting now. Recomputing every position update is a bit much.
The current thought is to do a catesian measurement based on an earth centered earth fixed coordinate system with an update threshold of 10 to 20km. An advantage of this is that it works near the poles. A disadvantage of this is that it requires calls to trig functions. Does anyone have any lighter weight approaches that work around the world?
As for a satellite qth, the threshhold angle for has_aos can be changed. It is probably a straightforward function for a spherical earth approximation. Time to practice trig.
The locator.c file has a function called qrb which returns the distance (short path) between two locations.
TU the qrb call was just what was needed. A few more questions have popped up.
At this point, the number of places in the code that need qth position update knowledge seems near the end. These were all handled with adding small position tags to appropriate data structures. All the modules views appear to work now, single sat, list, polarview, and map. If the qth moves too far, they update. Also sky at a glance does so as well. The only places that still needs some attention is the rotator controller for updating the sky trace.
If anyone can think of anything else that may need attention, please advise.
Also, gpsd seems to be going through some significant API changes right now. Between 2.90 and 2.95 some calls came in and out. There will need to be preprocessor logic to use the right calls. What are people using? (2.94 from ubuntu 10.04 in use here.)
Finally, what should the gui look like for the new "QTH" style? Two more slots with a gpsd server and port are the minimum. Also a combo box seemed the right way to deal with whether to use gpsd or not and allow for future expansion. Finally, the less pressing concerns included a save last known position position check box. (this seems a ways away as we would need to add saving qth files to the closing of the module.) Is there anything else missing?
Corresponding entries would be added to the qth file IO. Given these are new features, it seems easy to make the files backwards compatible. If the entries are not there then substitute default values.
Long term, adding other user tweaks seem possible. (Hey your computer clock is not synced with gps/ntp. Hey your gps went down. Some sort of indicator on the module screen that GPS is working/activated, consistent way of making position based updates user configurable.) Also the gpsd infrastructure needs some work, (the socket went down. switch over to something else. Doing a timer based reconnect. (fixed time, exponential backoff, what is the right answer.) accepting velocity information for better computation of doppler. (ok this may only matter for bullet trains at 2.4Ghz)
Once the gui/IO/gpsd API thrashing/everything getting basic updates seems solid, it would seem this might be ready for the main trunk. The risk area right now seems to the the gpsd API tracking and testing.
Hi Charles,
Sounds good with the implementation and bad with the changing API in GPSD. Hope it will not cause too much trouble.
Concerning the QTH editor, I think it makes sense to hide the GPSD related details in the main editor window the same way the "city selector" is hidden behind a mouse click. Something like this:
http://twitpic.com/3owozu
Clicking the "GPS" button would pop up a dialog with whatever widgets are necessary for configuring GPSD interface. The other advantage of separate dialog is that we can add more than what absolutely necessary, e.g. there could be a button to test the connection to GPSD (something like could be useful for the radio and rotator configuration too ;-)
Maybe the button should be placed somewhere else, or maybe it should fill both lines.
Just an update, the gpsd interface is coming along and is more mature than a few weeks ago.
There is a working gui but it is not the final one. GPS health can be determined by how old the last update is.
It appears to work on ubuntu 10.04.
Any information on other platforms would be appreciated.
gredict r743 works on Fedora 14
gredict r743 works on Fedora 14 with gpsd 2.95 (GPSD_API_MAJOR_VERSION 4) and doesn't work with 2.96~dev (GPSD_API_MAJOR_VERSION 5).
make[3]: Leaving directory `/home/mike/src/gpredict/src/sgpsdp'
make[3]: Entering directory `/home/mike/src/gpredict/src'
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -o gpredict sgp4sdp4.o sgp_in.o sgp_math.o sgp_obs.o sgp_time.o solar.o about.o compat.o first-time.o gpredict-help.o gpredict-url-hook.o gpredict-utils.o gtk-azel-plot.o gtk-event-list.o gtk-event-list-popup.o gtk-freq-knob.o gtk-polar-plot.o gtk-polar-view.o gtk-polar-view-popup.o gtk-rig-ctrl.o gtk-rot-ctrl.o gtk-rot-knob.o gtk-sat-data.o gtk-sat-list.o gtk-sat-list-col-sel.o gtk-sat-list-popup.o gtk-sat-map.o gtk-sat-map-popup.o gtk-sat-map-ground-track.o gtk-sat-module.o gtk-sat-module-popup.o gtk-sat-module-tmg.o gtk-sat-selector.o gtk-single-sat.o gtk-sky-glance.o gui.o loc-tree.o locator.o main.o map-selector.o menubar.o mod-cfg.o mod-cfg-get-param.o mod-mgr.o orbit-tools.o pass-popup-menu.o pass-to-txt.o predict-tools.o print-pass.o qth-data.o qth-editor.o radio-conf.o rotor-conf.o trsp-conf.o sat-cfg.o sat-info.o sat-log.o sat-log-browser.o sat-monitor.o sat-pass-dialogs.o sat-pref.o sat-pref-general.o sat-pref-formats.o sat-pref-qth.o sat-pref-qth-editor.o sat-pref-tle.o sat-pref-debug.o sat-pref-help.o sat-pref-modules.o sat-pref-layout.o sat-pref-layout-utils.o sat-pref-refresh.o sat-pref-map-view.o sat-pref-list-view.o sat-pref-polar-view.o sat-pref-single-sat.o sat-pref-interfaces.o sat-pref-rig.o sat-pref-rig-editor.o sat-pref-rot.o sat-pref-rot-editor.o sat-pref-predict.o sat-pref-conditions.o sat-pref-multi-pass.o sat-pref-single-pass.o sat-pref-sky-at-glance.o sat-vis.o save-pass.o time-tools.o tle-tools.o tle-update.o sat-debugger.o -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl -lm -L/opt/gpsd/lib -lgps
libtool: link: gcc -g -O2 -Wall -o gpredict sgp4sdp4.o sgp_in.o sgp_math.o sgp_obs.o sgp_time.o solar.o about.o compat.o first-time.o gpredict-help.o gpredict-url-hook.o gpredict-utils.o gtk-azel-plot.o gtk-event-list.o gtk-event-list-popup.o gtk-freq-knob.o gtk-polar-plot.o gtk-polar-view.o gtk-polar-view-popup.o gtk-rig-ctrl.o gtk-rot-ctrl.o gtk-rot-knob.o gtk-sat-data.o gtk-sat-list.o gtk-sat-list-col-sel.o gtk-sat-list-popup.o gtk-sat-map.o gtk-sat-map-popup.o gtk-sat-map-ground-track.o gtk-sat-module.o gtk-sat-module-popup.o gtk-sat-module-tmg.o gtk-sat-selector.o gtk-single-sat.o gtk-sky-glance.o gui.o loc-tree.o locator.o main.o map-selector.o menubar.o mod-cfg.o mod-cfg-get-param.o mod-mgr.o orbit-tools.o pass-popup-menu.o pass-to-txt.o predict-tools.o print-pass.o qth-data.o qth-editor.o radio-conf.o rotor-conf.o trsp-conf.o sat-cfg.o sat-info.o sat-log.o sat-log-browser.o sat-monitor.o sat-pass-dialogs.o sat-pref.o sat-pref-general.o sat-pref-formats.o sat-pref-qth.o sat-pref-qth-editor.o sat-pref-tle.o sat-pref-debug.o sat-pref-help.o sat-pref-modules.o sat-pref-layout.o sat-pref-layout-utils.o sat-pref-refresh.o sat-pref-map-view.o sat-pref-list-view.o sat-pref-polar-view.o sat-pref-single-sat.o sat-pref-interfaces.o sat-pref-rig.o sat-pref-rig-editor.o sat-pref-rot.o sat-pref-rot-editor.o sat-pref-predict.o sat-pref-conditions.o sat-pref-multi-pass.o sat-pref-single-pass.o sat-pref-sky-at-glance.o sat-vis.o save-pass.o time-tools.o tle-tools.o tle-update.o sat-debugger.o -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl -lm -L/opt/gpsd/lib /opt/gpsd/lib/libgps.so -lnsl -lpthread -pthread -Wl,-rpath -Wl,/opt/gpsd/lib -Wl,-rpath -Wl,/opt/gpsd/lib
qth-data.o: In function `qth_data_update_init':
/home/mike/src/gpredict/src/qth-data.c:629: undefined reference to `gps_open_r'
qth-data.o: In function `qth_data_update':
/home/mike/src/gpredict/src/qth-data.c:517: undefined reference to `gps_poll'
collect2: ld returned 1 exit status
make[3]: *** [gpredict] Error 1
make[3]: Leaving directory `/home/mike/src/gpredict/src'
see "Client API cleanup" on http://gpsd.berlios.de/future.html
sorry, it's a bug in gpsd 2.96~dev . "Cflags: -I${includedir}" wasn't declared in libgps.pc and libgpsd.pc
gredict r743 works on Fedora 14 with gpsd 2.95 and 2.96~dev :).
Thank you kindly for the feedback. I did not have a Version 5 API box to test on.
I assume you are using a gps and can comment on how responsive it is, if you notice things getting out of sync or anything else I would appreciate the feedback.
Also if the 2.96~dev feedback could get back to the fedora organization, it would be appreciated.