Updating Qpegps - New Gpsd And More

[grahamj]

Following the discussion started in the topic about kdepim development ....

... I am in the process of testing Qpegps (0.9.2.3.3 codebase) updated to use the latest gpsd (currently V 2.33).

Not everything is working at the moment so I plan to wait having anything ready for wider testing (currently it crashes viewing the map, probably due to not updating everything regularly enough, and the reported speed seems to be out).

I have chosen to statically link with libgpsd to avoid having to start and stop the gpsd daemon. A few minor changes were needed to gpsd to get it to compile for the Zaurus, but nothing which should alter its behaviour.

I am able to test on Zaurus SL-C series with Sharp ROM only, and one GPS device (SysOnChip CF Plus III).

I have also added a way to add new folders holding maps, as subfolders of the main map folder, without editing the main maps.txt file. Each sub-folder has its own maps.txt with info only on those maps. I can use some of the off-line map capture tools and then drop in or remove sets of maps very easily.

The previous discussion suggests that other work is being done on qpegps as well.

More news from me later, when the code looks like it is ready.

I am interested to learn more about any other improvements people are planning for qpegps.

[ztep]

...
I am interested to learn more about any other improvements people are planning for qpegps.

I'm happy to read your lines.

As I said in the topic, I'm working mainly on suporting tiled maps (maps composed of a several images), my first job has been to create a MapSelector class as suggested in todo.txt.
I have also done some cleanup on MapDisp class and some optimizations (I think) displaying maps and tracks (in any case this modifications were needed as previous work to my tiled masp).

After the message from hvontres about gpsd 2.xx I have read the documetation and thinking as you that linking with libgpsd was a good idea and quite easy I have been working this week on that task.
I have compiled gpsd 2.33 and modified client.cpp to use libgpsd interface and at this moment I have a (more or less) working implementation. Tha main problems I have had until now are:
- gpsd 2.33 does not seen to give speed/heading information to qpegps (just like you). After reading some forums and mailing list archives I realize that the problem wasn't on my code but in that version on gpsd. I have applied a path found in one of this mailing lists (https://lists.berlios.de/pipermail/gpsd-dev...une/003694.html)and now qpegps gets all gps information. So this problem is solved.
- Instead of a timer like in the current version of qpegps, I want to use the watcher mode and a QSocketNotifier to know when there is new information from gpsd but the slot function associated with the notifier is never called. If I start qpegps from the command line to see qDebug messages I notice that if I press return on the terminal after qpegps inicialization messages, the notification messages arrive and all works fine. Any idea about why this happen or how to solve it? Do you use QSocketNotifier or how do you detects new information?

By the way, in order to work together we should coordinate our codes to work with the same files. I think that the best is to use a version system (CVS). I have contacted whit Ralf Haselmeier (the original autor of qpeGPS) and he agree to add me into the developers list of the the qpeGPS sourceforge project so I can post my changes to sourceforge CVS server (although I'm still waiting for him to include me) . I suggest you'll do the same so both can work together. Any other idea about how to work together?

Anyway I would like to see your modifications. (I think that the multiple folder for maps is a good idea, I used to have several folders and manualy switch between several maps.txt files) and how it can be mixed with mines to make a better version.

Other question, I have the same GPS than you but qpgs recognize it as 'Generic NMEA' and use NMEA messages I have tried to switch to sirf binary mode typing 'N=1' on a telnet client, but the answer is always 'GPSD, N=0' and it continue in nmea mode. Do you know how to change to sirf mode with gpsd 2.xx?

[grahamj]

...
I am interested to learn more about any other improvements people are planning for qpegps.

After the message from hvontres about gpsd 2.xx I have read the documetation and thinking as you that linking with libgpsd was a good idea and quite easy I have been working this week on that task.

Looks like we have been doing the same work almost simultaneously!

I have compiled gpsd 2.33 and modified client.cpp to use libgpsd interface and at this moment I have a (more or less) working implementation. Tha main problems I have had until now are:
- gpsd 2.33 does not seen to give speed/heading information to qpegps ....

Ah, I seem to get speed and heading, only the speed doesn't seem to be correct, I was thinking I may not have got the correct units somewhere - perhaps something had changed between old and new gpsd.

Sounds like you have found a better fix to the problem - is this the "J" fix talked about in the gpsd forums, looking like a versino of it is due to be added to the next release?

- Instead of a timer like in the current version of qpegps, I want to use the watcher mode and a QSocketNotifier to know when there is new information from gpsd <....> Do you use QSocketNotifier or how do you detects new information?

At present I am using a simple timer to call gpsd_poll, and the raw_hook function to handle the data. I was planning on aiming for the asynch version (can't remember the name off the top of my head). Since I am linking directly with libgpsd and not running a separate gpsd executable I don't have any sockets (not local network sockets anyway).

By the way, in order to work together we should coordinate our codes to work with the same files. <....> Any other idea about how to work together?

That sounds like a good idea. Somebody would have to transfer the 0.9.2.3.3 code to the CVS server (assuming everybody is happy with that as the current version). I think that code only made it to the download page, not CVS.
We will need to be careful not to check conflicting versions into CVS so some separate discussion by e-mail might be good to get things going.

Anyway I would like to see your modifications. (I think that the multiple folder for maps is a good idea, I used to have several folders and manualy switch between several maps.txt files) and how it can be mixed with mines to make a better version.

The multiple folders helps me a lot, it is so easy to drop new maps in and remove old maps without altering other files.

Other question, I have the same GPS than you but qpgs recognize it as 'Generic NMEA' and use NMEA messages <....> Do you know how to change to sirf mode with gpsd 2.xx?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144950\"][{POST_SNAPBACK}][/a][/div]

Hmm, I haven't tried switching to Sirf mode yet, but was ewondering about trying the sirf program which is part of gpsd.

[hvontres]

Following the discussion started in the topic about kdepim development ....

... I am in the process of testing Qpegps (0.9.2.3.3 codebase) updated to use the latest gpsd (currently V 2.33).

Not everything is working at the moment so I plan to wait having anything ready for wider testing (currently it crashes viewing the map, probably due to not updating everything regularly enough, and the reported speed seems to be out).

I have chosen to statically link with libgpsd to avoid having to start and stop the gpsd daemon. A few minor changes were needed to gpsd to get it to compile for the Zaurus, but nothing which should alter its behaviour.

I am able to test on Zaurus SL-C series with Sharp ROM only, and one GPS device (SysOnChip CF Plus III).

I have also added a way to add new folders holding maps, as subfolders of the main map folder, without editing the main maps.txt file. Each sub-folder has its own maps.txt with info only on those maps. I can use some of the off-line map capture tools and then drop in or remove sets of maps very easily.

The previous discussion suggests that other work is being done on qpegps as well.

More news from me later, when the code looks like it is ready.

I am interested to learn more about any other improvements people are planning for qpegps.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144931\"][{POST_SNAPBACK}][/a][/div]

I have a question about the static linking to ligbpsd:
How will this interface behave if I already have an instance of gpsd running? I also use Zroadmap and I am sure there are some kismet users out there as well. I know the current gpsd package on OpenZaurus installs the required startup scripts in /etc/init.d so it will come up at boot time, so gpsd is already running when qpegps is started.

Thank you for looking into this program some more.

I also noticed that the latest version in CVS got some updates to the interface, so we might want to look into incorporating some of those changes as well.

I would be willing to test your guys work in OpenZaurus and to make sure we get the  updated .bb files into the openembedded repo.

   

[ztep]

I have a question about the static linking to ligbpsd:
How will this interface behave if I already have an instance of gpsd running? I also use Zroadmap and I am sure there are some kismet users out there as well. I know the current gpsd package on OpenZaurus installs the required startup scripts in /etc/init.d so it will come up at boot time, so gpsd is already running when qpegps is started.

As said in gpsd faq:

The gpsd package provides two ways for C code to get data from a GPS. Both go through the libgps.a library, which supports two sets of entry points. The low-level interface talks directly to the GPS. The high-level interface communicates with an instance of gpsd, which uses its own copy of libgps.a to talk to the device.

and more important for me

You will almost always want to use the high-level interface and go through the daemon; among other things, this means more than one application will be able to query the GPS without causing confusion

That is if you have gpsd running and use the low-level interface (the one used by grahamj) it probably cause 'confusion'. So I'd prefer my approach using the high level interface.

I also noticed that the latest version in CVS got some updates to the interface, so we might want to look into incorporating some of those changes as well.

I think that the last version is 0.9.2.3.3 and the one in CVS is 0.9.2.3.1.

[grahamj]

That is if you have gpsd running and use the low-level interface (the one used by grahamj) it probably cause 'confusion'. So I'd prefer my approach using the high level interface.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144998\"][{POST_SNAPBACK}][/a][/div]

Actually, I have been thinking about that - I think we can have the best of both worlds.

For my purposes and possibly many who simply want to use qpegps and aren't interested in how the communication with the device happens, the direct method is nice in the sense that nothing is left running when qpegps has quit.

For those with more complex requirements, having gpsd running in the background is fine and the only option because of the need for other apps to use it.

Why don't we do something like:

1. Start qpegps
2. Check if gpsd is running
3. If yes, connect to the gpsd daemon using the high-level interface
4. If no, use the low-level interface

We can use the same function to transfer data from gpsd to qpegps, since the same structures are used by the high and low level interfaces. Sub-classing Client to provide the two methods of connection should be relatively simple, and we link with the same library so code size is the same.

Qpegps is released of the need to start (and preferably stop, which it doesn't do at the moment) a separate gpsd process just for itself, which I have never liked anyway.

[ztep]

That is if you have gpsd running and use the low-level interface (the one used by grahamj) it probably cause 'confusion'. So I'd prefer my approach using the high level interface.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144998\"][{POST_SNAPBACK}][/a][/div]

Actually, I have been thinking about that - I think we can have the best of both worlds.

For my purposes and possibly many who simply want to use qpegps and aren't interested in how the communication with the device happens, the direct method is nice in the sense that nothing is left running when qpegps has quit.

For those with more complex requirements, having gpsd running in the background is fine and the only option because of the need for other apps to use it.

Why don't we do something like:

1. Start qpegps
2. Check if gpsd is running
3. If yes, connect to the gpsd daemon using the high-level interface
4. If no, use the low-level interface

We can use the same function to transfer data from gpsd to qpegps, since the same structures are used by the high and low level interfaces. Sub-classing Client to provide the two methods of connection should be relatively simple, and we link with the same library so code size is the same.

Qpegps is released of the need to start (and preferably stop, which it doesn't do at the moment) a separate gpsd process just for itself, which I have never liked anyway.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=145012\"][{POST_SNAPBACK}][/a][/div]

But the inclusion of two interfaces on qpegps will increase its size and I think that is more simple something like this:

1. Start qpegps
2. Check if gpsd is running
3. If no, start gpsd and set a varible to true
4. Connect to the gpsd daemon using the high-level interface
5. Before qpegps quit, kill gpsd if the variable is true

You can even add a option in the setting to allow the user chosse if gpsd must be killed on exit.

[grahamj]

But the inclusion of two interfaces on qpegps will increase its size
[div align=\"right\"][a href=\"index.php?act=findpost&pid=145016\"][{POST_SNAPBACK}][/a][/div]

Well, not by enough to bother about since it will be a pretty small amount of glue code. The major part is the bit copying data from gpsd structures to the qpegps store.

Do any of the other apps which use gpsd start it themselves? Or do they expect it to be running already? I think we should be following the same arrangement as them regarding starting gpsd.

Starting and stopping and external app seems more risky/complex that an internal interface which can talk direct to the device.

Anyway, the main thing is to have qpegps working with the latest gpsd with other new features.
And it sounds like it will be before too long.

[grahamj]

Ah, I seem to get speed and heading, only the speed doesn't seem to be correct, I was thinking I may not have got the correct units somewhere - perhaps something had changed between old and new gpsd.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=144953\"][{POST_SNAPBACK}][/a][/div]

I worked out the speed problem I was having - gpsd used to report in Knots, it now reports in metres/second.

[hvontres]

But the inclusion of two interfaces on qpegps will increase its size
[div align=\"right\"][a href=\"index.php?act=findpost&pid=145016\"][{POST_SNAPBACK}][/a][/div]

Well, not by enough to bother about since it will be a pretty small amount of glue code. The major part is the bit copying data from gpsd structures to the qpegps store.

Do any of the other apps which use gpsd start it themselves? Or do they expect it to be running already? I think we should be following the same arrangement as them regarding starting gpsd.

Starting and stopping and external app seems more risky/complex that an internal interface which can talk direct to the device.

Anyway, the main thing is to have qpegps working with the latest gpsd with other new features.
And it sounds like it will be before too long.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=145018\"][{POST_SNAPBACK}][/a][/div]

I believe the other apps count on gpsd already being started. The latest versions of gpsd in OZ at least come with startup/shutdown scripts in /etc/init.d .

Any idea when you might be able to get a version into CVS ?

[nowhereman]

[...]
I am interested to learn more about any other improvements people are planning for qpegps.

I wonder which connections are between qpeGPS NV on http://www.ngsoft-fr.com/fr/page.php?q=fic..._Zaurus_SL_5500
as an fork and the origial qpeGPS.
I think that the idea of integration or driving directions from Google-maps, which is presented there is quite interesting.

Another thing is the idea of scalability and combining of maps. This was solved in an non-gps-map-viewer called localizer.
http://developer.kde.org/~larrosa/localizer.html
The code for this seems to be open.

Citation:

"Localizer is not yet GPL. I'll publish the source
code
under the GPL license if there's enough interest. In other
case, it will remain freeware (free to distribute, copy and
use, but just the binary, docs and examples)."

Best regards

[brycenut]

Glad to see someone working on this.  I just moved to OZ (Hentges 3.5.4.1) on a 5500, and found that my gps card & qpegps aren't seeing each other anymore with the latest qpegps and gpsd available in the feeds.  (Formerly working on Crow ROM).

I'd be happy to test if needed, too.

[ashikase]

Actually, I added support for the latest gpsd over a year ago, along with a lot of other features (non-overlapping tiled maps, etc.). As it was a major rewrite, I had planned to start a new branch in the repository; lazy as I am, though, I never got around to it.

Unfortunately I no longer use my Zaurus, but I think I still have the updated code. I'm still listed as an admin for the project; I'll try to get myself to post the code somewhere in the repository (or just submit it to one of the current active developers).

[ztep]

I have sent you a pm with my emai.
Please send me your updated code so I can continue the development.

Thanks.