Neil Jerram <n...@ossau.homelinux.net> writes:
> On Tuesday, October 2, 2012 12:25:31, Radek Polak wrote:
>> Navit currently does not support QtMoko's GPS framework. You will have to
>> edit
>> navit configuration file and give it /dev/ttyO1 as serial NMEA port and you
>> will
>> also need to do "rfkill unblock gps" to power on GPS antenna. Or on
>> Freerunner
>> the port will be something like /dev/ttySAC1.
>>
>> It's one of things i have in plan to add QtMoko's GPS framework support to
>> navit. No idea when i have time to do it, but it's quite big priority for me.
Alternatively, one could install gpsd and gpsd-clients and run Navit
using gpsd (which I think is its default). You'd still have to do the
"rfkill unblock gps" somehow, because the gpsd in Debian Squeeze doesn't
have a hook for doing that. (The gpsd in Wheezy does.)
The only problem then is that QtMoko apps wouldn't be able to access the
GPS at the same time, but for that...
> I'm not sure if it's relevant for Navit but I've integrated gpsd usage
> in QtMoko. I'll write more about that this evening.
Attached is a patch to make QtMoko's GPS framework (Q*Whereabouts) use
gpsd instead of reading directly from /dev/ttyO1. The benefit of that
is that multiple clients, both Qt and non-Qt, can all use GPS at the
same time.
>From edb97c45be3e36b91fbd4bc8836d4cab56046ac3 Mon Sep 17 00:00:00 2001
From: Neil Jerram <n...@ossau.homelinux.net>
Date: Sun, 30 Sep 2012 23:35:15 +0100
Subject: [PATCH] NeoGpsPlugin - use "gpspipe -r" instead of "cat /dev/ttyO1".
This allows us to have multiple GPS clients at the same time.
Specifically, to have NeronGPS running on the GTA04, and also using
gpspipe to export the GPS NMEA stream over Bluetooth.
(An alternative approach is to use QGpsdWhereabouts instead of
NeoGpsPlugin, but this doesn't work because the QGpsdWhereabouts code
assumes the old GPSD protocol which has now been replaced by JSON. To
use QGpsdWhereabouts successfully, that code would need updating for
the new protocol, probably by using libgps.
Using "gpspipe -r" at the bottom of NeoGpsPlugin should be equally
effective, and doesn't require such a complex code change.)
---
.../src/plugins/whereabouts/neo/neogpsplugin.cpp | 21 ++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp b/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
index 7737c17..f6e55fc 100644
--- a/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
+++ b/devices/gta04/src/plugins/whereabouts/neo/neogpsplugin.cpp
@@ -31,7 +31,20 @@
#include <qtopialog.h>
/*
- This plugin only works for Goldelico's GTA04
+ This plugin uses "gpspipe -r" to get NMEA sentences out of GPSD,
+ then feeds those to QNmeaWhereabouts. It should work on any
+ distribution where GPSD is running and successfully accessing the
+ GPS device.
+
+ The benefit of using GPSD, instead of reading the GPS device
+ directly, is that multiple clients can access GPS information at the
+ same time. For example, GPS can be simultaneously used by a local
+ application such as NeronGPS, and exported over Bluetooth to another
+ device.
+
+ An alternative GPSD-based solution would be to use QGpsdWhereabouts
+ instead of QNmeaWhereabouts, but that would require updating
+ QGpsdWhereabouts for GPSD's new JSON-based protocol.
*/
NeoGpsPlugin::NeoGpsPlugin(QObject * parent)
: QWhereaboutsPlugin(parent)
@@ -56,12 +69,12 @@ QWhereabouts *NeoGpsPlugin::create(const QString &)
qLog(Hardware) << __PRETTY_FUNCTION__;
reader = new QProcess(this);
- reader->start("cat", QStringList() << "/dev/ttyO1", QIODevice::ReadWrite);
+ reader->start("gpspipe", QStringList() << "-r", QIODevice::ReadWrite);
if (!reader->waitForStarted()) {
- qWarning() << "couldnt start cat /dev/ttyO1: " + reader->errorString();
+ qWarning() << "Couldn't start gpspipe -r: " + reader->errorString();
QMessageBox::warning(0, tr("GPS"),
- tr("Cannot open GPS device at /dev/ttyO1"),
+ tr("Couldn't start gpspipe -r"),
QMessageBox::Ok, QMessageBox::Ok);
delete reader;
reader = 0;
--
1.7.10.4
I don't think this patch is ready for inclusion yet, because it would be
better if it handled both gpsd usage and direct access gracefully -
i.e. try using gpspipe, and fall back to opening /dev/ttyO1 if that
fails. But it would be interesting to hear if people think this is the
right longterm approach.
Regards,
Neil
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
