Re: QTMoko website
On Thursday, October 04, 2012 08:10:51 PM Neil Jerram wrote: > 1. If two applications each use NeoGpsPlugin+QNmeaWhereabouts to access > GPS, there will be two instances of NeoGpsPlugin, and they will both try > to open /dev/ttyO1, which (for me) hangs the whole system. Therefore, > even if we modify every GPS application to use QWhereabouts, we still > can't run more than one of those applications at the same time. Oki, this sound like a big flaw in QWhereabouts - i thought they had solved such a basic thing when they implemented it - btw older qtopia was using gpsd. > With my patch, you still get all that for applications like NeronGPS > that use QWhereabouts - except I don't know about AGPS, because we don't > yet have that on GTA04. Hmm maybe we could use the gpsd hooks for this. Or we can stick with Nmea whereabouts on GTA02 and use gpsd on GTA04. > I agree you wouldn't get it if, say, the Bluetooth GPS export function > was running on its own. That wouldn't be a problem for me, though, > because the device that I'm trying to export GPS to has it own good UI > for showing fix status, satellites and so on. Oki > Also in practice I expect > that I'll usually be running NeronGPS at the same time, and that will > activate QWhereabouts and so give me all those UI indications on the > GTA04. This is good idea. > I agree that's annoying - for example because it prevents me from trying > out the QGpsdWhereabouts code - but I don't understand how it might > affect your wheezy/armhf experiment. As long as there's a version of > gpspipe that matches the version of gpsd, I don't think we need anything > else. I think we could try it for next GTA04 release then - or whenever you are finished with it, just send me the final patch... Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
Radek Polak writes: > On Tuesday, October 02, 2012 08:01:03 PM Neil Jerram wrote: > >> 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. > > Nice, i was trying to do something like this too, but without any results. > > But I wonder how much is gpsd useful for us now. We have lightweight > Whereabouts framework which now works good on GTA02 and GTA04. On GTA02 it > even handles supplying AGPS data. > > I wonder what GPSD can do for us. Well, I've been using it because I'd like to export GPS from my GTA04 to another device, over Bluetooth, at the same time as running NeronGPS on the GTA04. I believe there are two problems with using NeoGpsPlugin+QNmeaWhereabouts for that, both of which are solved by using gpsd instead (with the patch that I posted). 1. If two applications each use NeoGpsPlugin+QNmeaWhereabouts to access GPS, there will be two instances of NeoGpsPlugin, and they will both try to open /dev/ttyO1, which (for me) hangs the whole system. Therefore, even if we modify every GPS application to use QWhereabouts, we still can't run more than one of those applications at the same time. 2. For Bluetooth export I need the NMEA stream, and QWhereabouts doesn't provide that. To get the NMEA stream I need either to read /dev/ttyO1 directly - which means I can't run any other GPS application at the same time - or to use gpsd and gpspipe. > It's another program running in background eating system resources. I haven't done any measurements, but it doesn't seem that bad. I believe it doesn't do anything at all - even access /dev/ttyO1 - until an application connects to its port, and I didn't notice any impact while actually using GPS. > The programs that will use GPSD will be poorly integrated in QtMoko - > i.e. not showing the fix status in title bar, no blinking with LED to > indicated NMEA activity, no AGPS. With my patch, you still get all that for applications like NeronGPS that use QWhereabouts - except I don't know about AGPS, because we don't yet have that on GTA04. I agree you wouldn't get it if, say, the Bluetooth GPS export function was running on its own. That wouldn't be a problem for me, though, because the device that I'm trying to export GPS to has it own good UI for showing fix status, satellites and so on. Also in practice I expect that I'll usually be running NeronGPS at the same time, and that will activate QWhereabouts and so give me all those UI indications on the GTA04. > And one more thing - i hate GPSD because they are breaking API compatibility > and we have no control of it. I want now to do some wheezy/armhf experimental > release for GTA04 and if wheezy/sqeeze gpsd are not compatible then it's > quite > problem... I agree that's annoying - for example because it prevents me from trying out the QGpsdWhereabouts code - but I don't understand how it might affect your wheezy/armhf experiment. As long as there's a version of gpspipe that matches the version of gpsd, I don't think we need anything else. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
Hi, GPSD is usefull for dealing with many kinds of differenet devices etc. In case of one specific GPS device in GTAxx, full potential of GPSD cannot be utilised. But GPSD still have few very usseful features, one of them is data export trought socket/network. This way can be GPS data easilly accessible by other applications (eg. experimental application in python or tunneled trought network into PC). I have in past did some dirty hack wich create socket and when someone start reading it QWhereabouts starts GPS and act as proxy (and close GPS again when noone reads anny more). This code is not usable now, but this feature might be ussefull for hacking. Pinky. On 10/03/2012 12:03 PM, Radek Polak wrote: On Tuesday, October 02, 2012 08:01:03 PM Neil Jerram wrote: 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. Nice, i was trying to do something like this too, but without any results. But I wonder how much is gpsd useful for us now. We have lightweight Whereabouts framework which now works good on GTA02 and GTA04. On GTA02 it even handles supplying AGPS data. I wonder what GPSD can do for us. It's another program running in background eating system resources. The programs that will use GPSD will be poorly integrated in QtMoko - i.e. not showing the fix status in title bar, no blinking with LED to indicated NMEA activity, no AGPS. This leads us to question - how many programs will use the GPSD. Navit can be quite easily adjusted to use QWereabouts, i think the same can be done with Monav and Marble. And one more thing - i hate GPSD because they are breaking API compatibility and we have no control of it. I want now to do some wheezy/armhf experimental release for GTA04 and if wheezy/sqeeze gpsd are not compatible then it's quite problem... Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
On Tuesday, October 02, 2012 08:01:03 PM Neil Jerram wrote: > 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. Nice, i was trying to do something like this too, but without any results. But I wonder how much is gpsd useful for us now. We have lightweight Whereabouts framework which now works good on GTA02 and GTA04. On GTA02 it even handles supplying AGPS data. I wonder what GPSD can do for us. It's another program running in background eating system resources. The programs that will use GPSD will be poorly integrated in QtMoko - i.e. not showing the fix status in title bar, no blinking with LED to indicated NMEA activity, no AGPS. This leads us to question - how many programs will use the GPSD. Navit can be quite easily adjusted to use QWereabouts, i think the same can be done with Monav and Marble. And one more thing - i hate GPSD because they are breaking API compatibility and we have no control of it. I want now to do some wheezy/armhf experimental release for GTA04 and if wheezy/sqeeze gpsd are not compatible then it's quite problem... Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
Neil Jerram 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 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 /* - 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
Re: QTMoko website
On Tuesday, October 2, 2012 12:25:31, Radek Polak wrote: > On Tuesday, October 02, 2012 10:08:02 AM matthsch...@arcor.de wrote: > > > Hi Radek, > > > > OK, i installed it with apt-get install qtmoko-navit. Now I'm about to > > assign maps, onscreen buttons and so on, I will figure it out. Whta I didd > > not find until now is how navit turns the GPS on. Neither I found how > > Nerongps turns it on - here it works, but I dont know how. > > 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. > > > BTW, > > http://qtmoko.sourceforge.net/apps/qtmoko-qtopiagps.html > > gives an error message about the package not present. > > Yup, the app needs someone to adapt it make it working. > > Regards > > Radek > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > 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. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QTMoko website
On Tuesday, October 02, 2012 10:08:02 AM matthsch...@arcor.de wrote: > Hi Radek, > > OK, i installed it with apt-get install qtmoko-navit. Now I'm about to > assign maps, onscreen buttons and so on, I will figure it out. Whta I didd > not find until now is how navit turns the GPS on. Neither I found how > Nerongps turns it on - here it works, but I dont know how. 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. > BTW, > http://qtmoko.sourceforge.net/apps/qtmoko-qtopiagps.html > gives an error message about the package not present. Yup, the app needs someone to adapt it make it working. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] WebSite opens to images :)
I'm glad to announce that since this moment every user registered on the qtmoko.org website will be able to upload images :). Other things are under work to improve everything is around such a great project :) -- Fabio A Locati Home: Segrate, Milan, Italy (GMT +1) Phone: +39-328-3799681 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Key: 9EF6 3C79 F6DF 76CD 770A 43A1 DCCB 415C 9656 3334 Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia Sent from Sesto San Giovanni, MI, Italy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community