Re: GPS logger / field data collection
Brian Wilson wrote: IMO, just use the raw Ublox binary format. It's rather simple to decode. I have already implemented a binary decoder for the Ublox binary format based on Ublox open documentation of the protocol. My plan is to release this code under the GPL at some point. The only GPS receiver that I have that does u-blox binary format is the one in the Freerunner, and the others are Trimble and Garmin and SiRF and NMEA. So I'd be limited to using only one receiver out of my collection. No, I also plan to support a number of other receivers. I defined a simple virtual interface for that. My point is that there is no need to create an intermediate format for storing. The original binary format is just fine. I plan to support RINEX at some point too but just as another format, not as the base format. My ublox decoder is just 500 loc and half of it is the binary structure definitions. The framework python decoder (ubx.py) is about the same size. Anyway, this is just vaporware for now as I didn't release anything :-) Especially I'd love to be able to use the fancy Trimble ProXH via bluetooth and not be forced to use the Windows Mobile device they expect you to use. (Trimble Recon) Is there some documentation of the format? If yes I guess the gpsd project already supports it and it should be easy for me to support it too. So I was looking for a more general solution. Well, I consider my solution as a general one. But it's a starting point anyway, and hey, I work on this about 10 minutes a day so I'd say dive in! That's what I said once before getting addicted to open source development ;-) Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Hello Brian, Brian Wilson wrote: Jim wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing I tried to used gpsd with my GPS base station my recollection was that it was totally useless for that. I assume that it will be useless for this project too but it's a starting point. No need for gpsd for a binary logger, see below. XML would be able to do that but I agree probably too verbose, how about tokenized XML? Very interesting idea, could be the way to go, I will look at it. On Mon, Aug 18, 2008 at 4:21 PM, Bert Hartmann[EMAIL PROTECTED] wrote: In my toyings with TangoGPS, I know it can produce logs, I don't know the format at all, it may just be the raw GPS output or not. I do know it does all the pedometer functions you were asking about (maybe not min speed, but definitely max and avg.). Perhaps you should look into that project. I will, thank you. I have no interest in inventing a new binary format. There should be something out there that is open and compact. (There should be, he said. Ha) IMO, just use the raw Ublox binary format. It's rather simple to decode. I have already implemented a binary decoder for the Ublox binary format based on Ublox open documentation of the protocol. My plan is to release this code under the GPL at some point. Once I receive my free runner I will start by releasing a binary decoder. In the time being I can probably release a Windows only converter from this Ublox format to a csv format if you are interested. I've tried TangoGPS, it's a nice program. I've read about it on its web site and looked at the source code. Problem is that the GUI source code is GTK and very hard to follow IMHO. I am personally proficient in Qt4 so I am interested in participating in a project that will create a GPS navigation app in C++ using Qt4. Here is my roadmap more or less: 1) port my Ublox decoder to linux and openmoko. I plan to use CMake as the build system. 2) add some logger functionality to the program above so that some Ublox logs can be requested. 3) implement an ephemeris and almanac saving and restoring solution 4) do the same as above for some SBAS messages if possible (not sure it is) 5) implement a simple Qt4 navigation program using openmap. I hope I have something to show next month. Cheers, Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Michael 'Mickey' Lauer wrote: Am Sonntag 24 August 2008 14:34:13 schrieb Abdelrazak Younes: Here is my roadmap more or less: 1) port my Ublox decoder to linux and openmoko. I plan to use CMake as the build system. 2) add some logger functionality to the program above so that some Ublox logs can be requested. 3) implement an ephemeris and almanac saving and restoring solution 4) do the same as above for some SBAS messages if possible (not sure it is) 5) implement a simple Qt4 navigation program using openmap. Sounds like a good plan. Let me note that by just using ogspd from the FSO framework, you could skip 1)-3) Ah? It seems I don't know yet about this... Could you point me to the source code please? and go right to 5) (dunno about 4). There's a number of SBAS messages that are worth saving so that the receiver can provider an SBAS solution quicker. But I am not sure it is possible to give back these messages to the ublox receiver as is possible for the GPS ephemerises and almanacs. P.S. I love LyX. ;-) Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Am Sonntag 24 August 2008 16:15:46 schrieb Abdelrazak Younes: Michael 'Mickey' Lauer wrote: Am Sonntag 24 August 2008 14:34:13 schrieb Abdelrazak Younes: Here is my roadmap more or less: 1) port my Ublox decoder to linux and openmoko. I plan to use CMake as the build system. 2) add some logger functionality to the program above so that some Ublox logs can be requested. 3) implement an ephemeris and almanac saving and restoring solution 4) do the same as above for some SBAS messages if possible (not sure it is) 5) implement a simple Qt4 navigation program using openmap. Sounds like a good plan. Let me note that by just using ogspd from the FSO framework, you could skip 1)-3) Ah? It seems I don't know yet about this... Could you point me to the source code please? git.freesmartphone.org and go right to 5) (dunno about 4). There's a number of SBAS messages that are worth saving so that the receiver can provider an SBAS solution quicker. But I am not sure it is possible to give back these messages to the ublox receiver as is possible for the GPS ephemerises and almanacs. Daniel? -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Michael 'Mickey' Lauer wrote: Sounds like a good plan. Let me note that by just using ogspd from the FSO framework, you could skip 1)-3) and go right to 5) (dunno about 4). I just ported xgps to Qtopia, this was of course using the client for gpsd. Qtopia does not currently use frameworkd, do you know if there are plans for qtopis to use it? (I'm not switching to FSO yet) If not can I install ogpsd standalone? I'd be happy to port my qtgps test app to use that instead of gpds, although the only thing I like about gpsd is the ability to connect to it from my destopk so I can develop the UI there, but I guess I can do an tcp daemon that talks to dbus, unless there is already one. The code and executable for the current qtgps which seems to gun on Qtopia ok with gpsd is here, if it helps anyone. http://blog.wolfman.com/files/qtgps.tar.gz -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Abdelrazak Younes wrote: IMO, just use the raw Ublox binary format. It's rather simple to decode. I have already implemented a binary decoder for the Ublox binary format based on Ublox open documentation of the protocol. My plan is to release this code under the GPL at some point. I agree if there is already a compact binary format then we should use that. Is there currently a way to capture that raw format? Here is my roadmap more or less: 1) port my Ublox decoder to linux and openmoko. I plan to use CMake as the build system. 2) add some logger functionality to the program above so that some Ublox logs can be requested. 3) implement an ephemeris and almanac saving and restoring solution 4) do the same as above for some SBAS messages if possible (not sure it is) 5) implement a simple Qt4 navigation program using openmap. Sounds good, I made a start with a Qtopia port of xgps, the fact it gets its data from gpsd at the moment is irrelvant as it could just as easily get the raw data and parse it. Code is here... (Its needs a bit of work to replace the sprintfs xpgs used to the equivalent Qt, but I simply copied/pasted that code from xgps). http://blog.wolfman.com/files/qtgps.tar.gz -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Jim Morris wrote: Abdelrazak Younes wrote: IMO, just use the raw Ublox binary format. It's rather simple to decode. I have already implemented a binary decoder for the Ublox binary format based on Ublox open documentation of the protocol. My plan is to release this code under the GPL at some point. I agree if there is already a compact binary format then we should use that. Is there currently a way to capture that raw format? I don't know which device represents the ublox but, provided that it is properly configured, a simple 'cat /dev/ublox ~/log.ubx' Here is my roadmap more or less: 1) port my Ublox decoder to linux and openmoko. I plan to use CMake as the build system. 2) add some logger functionality to the program above so that some Ublox logs can be requested. 3) implement an ephemeris and almanac saving and restoring solution 4) do the same as above for some SBAS messages if possible (not sure it is) 5) implement a simple Qt4 navigation program using openmap. Sounds good, I made a start with a Qtopia port of xgps, the fact it gets its data from gpsd at the moment is irrelvant as it could just as easily get the raw data and parse it. For this we could just send the binary message in a socket to some configurable IP address. I also suggest that you add the ability to parse a file. This will offer you replay functionality. Code is here... (Its needs a bit of work to replace the sprintfs xpgs used to the equivalent Qt, but I simply copied/pasted that code from xgps). http://blog.wolfman.com/files/qtgps.tar.gz I'll try to have a look next week. You should probably put this in some SCM. git seems to be in widespread use around here. What about github? Abdel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Am Sonntag 24 August 2008 22:34:16 schrieb Jim Morris: Michael 'Mickey' Lauer wrote: Sounds like a good plan. Let me note that by just using ogspd from the FSO framework, you could skip 1)-3) and go right to 5) (dunno about 4). I just ported xgps to Qtopia, this was of course using the client for gpsd. Qtopia does not currently use frameworkd, do you know if there are plans for qtopis to use it? For pure Qtopia (i.e. not 2008.8) unlikely. Trolltech is satisfied with their own integrated backend, I don't see any motivation for them to switch to anything else. (I'm not switching to FSO yet) If not can I install ogpsd standalone? Most portions of the frameworkd work fine in parallel with Qtopia. Just install frameworkd and edit its init script to launch it with -s ogspd,odeviced,ousaged. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
On Sun, Aug 24, 2008 at 6:02 AM, Timo Juhani Lindfors [EMAIL PROTECTED] wrote: For editing openstreetmap it is also useful to capture short audio comments. This can be easily done by starting recording when AUX is pressed and stopping it when it is released. I think this is a good idea for any field data collector. I added it to the wiki page. Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
IMO, just use the raw Ublox binary format. It's rather simple to decode. I have already implemented a binary decoder for the Ublox binary format based on Ublox open documentation of the protocol. My plan is to release this code under the GPL at some point. The only GPS receiver that I have that does u-blox binary format is the one in the Freerunner, and the others are Trimble and Garmin and SiRF and NMEA. So I'd be limited to using only one receiver out of my collection. Especially I'd love to be able to use the fancy Trimble ProXH via bluetooth and not be forced to use the Windows Mobile device they expect you to use. (Trimble Recon) So I was looking for a more general solution. But it's a starting point anyway, and hey, I work on this about 10 minutes a day so I'd say dive in! Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Jim Morris wrote: Brian Wilson wrote: Jim wrote: I tried to used gpsd with my GPS base station my recollection was that it was totally useless for that. I assume that it will be useless for this project too but it's a starting point. gpsd seems to work fine for me, and I can develop my app on my host, and connect to it over the USB connection, or over the wifi. Other than the documented problems with the 5 reads to get the fix. Hmm I am losing faith in gpsd, I've run into the problem where it seems to be running and I can connect to it but there is no fix data. Restarting it doesn't fix it but poweroff and on the gps, and I get fixes again. Not sure if that is gpsd or the gps itself. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Hi Brian, I like this idea, I just added gpsd to my Qtopia build, and added some simple code to my Qtopia based sunset calculator I wrote eons ago for my Zaurus, the GPS part simply gets current lat and long to calculate sunset/sunrise at your current location. Previously I had a city selector for that. I also wanted a pedometer, and I like the idea of a data logger, because I can post process the data with numerous things. I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. I think the first thing to answer is the log format, any progress on defining that? I'll work on code to extract the log info for a simple pedometer, also if you can define the log format I may be able to write an initial logger. I think the logger needs to be platform independent as I will be writing all my code for Qtopia, but obviously we have 3 of 4 platforms to deal with, and only the graphical part will be different. (GTK/X vs QT/FB). I also write in Ruby whenever possible, so we probably need a library that can read the log format from c/c++/python/ruby etc. (XML would be able to do that but I agree probably too verbose, how about tokenized XML?) BTW my pedometer should be able to tell me the average , max min speed I walked, and the total time and distance pretty simple stuff. Brian Wilson wrote: One of the main reasons I got my Freerunner was to play with its GPS features. I want to be able to use it as a replacement for closed-source applications like TDS Solo Field and ESRI ArcPad. Especially I want something that would facilitate my volunteer citizen scientist work At the rate I am going I will probably never have more than 15 minutes a day to work towards this. In spite of this I decided to spell out what I have been thinking about in a wiki page because it would take too much space here and I think the interest might not be high enough to clutter up this very busy list with yet another very involved topic. I have a GPS in my pocket most of the time. I use a Garmin on my bicycles and on hikes. I have used various TDS and Trimble and ESRI products. Being a software developer I want something that I can tweak and tune and none of these commercial products even comes close to what I have in mind. Therefore I started this page: http://wiki.openmoko.org/wiki/GPS_Data_Logger to talk about it and the intro there says this: -- This page was created to address the use cases mentioned in GTA02 GPS, including * I want to log GPS data for later analysis. * I want to collect GPS data for scientific field work (forestry, biology, etc) The page was started on 17 August 2008 mostly as a thought exercise. Please jump in and add to it. Cheers, Brian Wilson Corvallis Oregon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Jim, Brian, In my toyings with TangoGPS, I know it can produce logs, I don't know the format at all, it may just be the raw GPS output or not. I do know it does all the pedometer functions you were asking about (maybe not min speed, but definitely max and avg.). Perhaps you should look into that project. --Bert Jim Morris wrote: Hi Brian, I like this idea, I just added gpsd to my Qtopia build, and added some simple code to my Qtopia based sunset calculator I wrote eons ago for my Zaurus, the GPS part simply gets current lat and long to calculate sunset/sunrise at your current location. Previously I had a city selector for that. I also wanted a pedometer, and I like the idea of a data logger, because I can post process the data with numerous things. I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. I think the first thing to answer is the log format, any progress on defining that? I'll work on code to extract the log info for a simple pedometer, also if you can define the log format I may be able to write an initial logger. I think the logger needs to be platform independent as I will be writing all my code for Qtopia, but obviously we have 3 of 4 platforms to deal with, and only the graphical part will be different. (GTK/X vs QT/FB). I also write in Ruby whenever possible, so we probably need a library that can read the log format from c/c++/python/ruby etc. (XML would be able to do that but I agree probably too verbose, how about tokenized XML?) BTW my pedometer should be able to tell me the average , max min speed I walked, and the total time and distance pretty simple stuff. Brian Wilson wrote: One of the main reasons I got my Freerunner was to play with its GPS features. I want to be able to use it as a replacement for closed-source applications like TDS Solo Field and ESRI ArcPad. Especially I want something that would facilitate my volunteer citizen scientist work At the rate I am going I will probably never have more than 15 minutes a day to work towards this. In spite of this I decided to spell out what I have been thinking about in a wiki page because it would take too much space here and I think the interest might not be high enough to clutter up this very busy list with yet another very involved topic. I have a GPS in my pocket most of the time. I use a Garmin on my bicycles and on hikes. I have used various TDS and Trimble and ESRI products. Being a software developer I want something that I can tweak and tune and none of these commercial products even comes close to what I have in mind. Therefore I started this page: http://wiki.openmoko.org/wiki/GPS_Data_Logger to talk about it and the intro there says this: -- This page was created to address the use cases mentioned in GTA02 GPS, including * I want to log GPS data for later analysis. * I want to collect GPS data for scientific field work (forestry, biology, etc) The page was started on 17 August 2008 mostly as a thought exercise. Please jump in and add to it. Cheers, Brian Wilson Corvallis Oregon ___ 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: GPS logger / field data collection
Jim wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing I tried to used gpsd with my GPS base station my recollection was that it was totally useless for that. I assume that it will be useless for this project too but it's a starting point. XML would be able to do that but I agree probably too verbose, how about tokenized XML? Very interesting idea, could be the way to go, I will look at it. On Mon, Aug 18, 2008 at 4:21 PM, Bert Hartmann [EMAIL PROTECTED] wrote: In my toyings with TangoGPS, I know it can produce logs, I don't know the format at all, it may just be the raw GPS output or not. I do know it does all the pedometer functions you were asking about (maybe not min speed, but definitely max and avg.). Perhaps you should look into that project. I will, thank you. I have no interest in inventing a new binary format. There should be something out there that is open and compact. (There should be, he said. Ha) I've tried TangoGPS, it's a nice program. Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
On Monday August 18, [EMAIL PROTECTED] wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. from the man page for gpsd p Returns the current position in the form P=%f %f; numbers are in degrees, latitude first. $ telnet tangogps.org gpsd Trying 82.240.156.91... Connected to tangogps.org. Escape character is '^]'. p GPSD,P=43.739028 7.364333 ^] telnet q Connection closed. 43 degrees north, 7 east. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
On Tue, Aug 19, 2008 at 10:54 AM, Neil Brown [EMAIL PROTECTED] wrote: On Monday August 18, [EMAIL PROTECTED] wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. from the man page for gpsd p Returns the current position in the form P=%f %f; numbers are in degrees, latitude first. $ telnet tangogps.org gpsd Trying 82.240.156.91... Connected to tangogps.org. Escape character is '^]'. p GPSD,P=43.739028 7.364333 ^] telnet q Connection closed. 43 degrees north, 7 east. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Isn't gypsy [1] used on some builds? Perhaps build a logger to use either gpsd or gypsy. Gypsy, Python examples are available [2]. Regarding the resulting logs : Would be nice for choose what format; text, xml, yaml, sqlite Start with plain text, with the expectation that someone will want another format. What columns for store, time,long,lat. timezone, time format. ~ Matt [1] http://folks.o-hand.com/iain/gypsy/ [2] http://svn.o-hand.com/repos/gypsy/trunk/gypsy/examples/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Bert Hartmann wrote: Jim, Brian, In my toyings with TangoGPS, I know it can produce logs, I don't know the format at all, it may just be the raw GPS output or not. I do know it does all the pedometer functions you were asking about (maybe not min speed, but definitely max and avg.). Perhaps you should look into that project. --Bert TangoGPS doesn't run on Qtopia I think it is a GTK+ app. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Brian Wilson wrote: Jim wrote: I tried to used gpsd with my GPS base station my recollection was that it was totally useless for that. I assume that it will be useless for this project too but it's a starting point. gpsd seems to work fine for me, and I can develop my app on my host, and connect to it over the USB connection, or over the wifi. Other than the documented problems with the 5 reads to get the fix. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Neil Brown wrote: On Monday August 18, [EMAIL PROTECTED] wrote: I was kind of surprised that gpsd didn't give me a simple way to just get the current location, I had to capture 5 sentences to do that simple thing, but what I really wanted was to simply get the last known lat and long I was at. With the data logger I can presumably do that by getting the last entry of the log. from the man page for gpsd p Returns the current position in the form P=%f %f; numbers are in degrees, latitude first. That doesn't work if you connect, get a fix and disconnect. From the FAQ... Why does my single-shot query fail to return fix data? This is closely related to the previous item. The old-style query commands such as P and A are are safe to use with J=1 if you're polling repeatedly, but they're a dicey way to go if you're opening a channel to gpsd, doing a single-shot query, and then hanging up. Even repeating the query a few times won't necessarily work. The problem is that your queries are in a race with the daemon's logic for assigning and initializing a GPS. It won't try to assign a GPS to your channel until the first command that demands actual device information. Then the race begins. The daemon will be interleaving reads of whatever packet fragments the GPS is shipping with reads from your client socket. It is entirely possible that the rest of your commands will get processed before the daemon reads and processes enough GPS sentences to get a fix — especially if the serial device is slow and the GPS has a long initialization sequence. (A similar race existed in gpsd versions before multi-device support was added in 2.21; if you issued a query too soon after device open it would fail in exactly this way.) The right way to code your client is to set watcher mode and read a couple of O responses before trying to parse one. That way the daemon paces the action, actually telling the client when it receives packets. To be certain of having full fix data, you'd need to wait for as many O responses as there are sentences that set fix data in the device's normal cycle. For SiRFs, one read will do because normally only one sentence in the cycle ships fix data. For NMEA devices you don't have a full fix before five reads, enough for an entire GPRMC/GPGGA/GPVTG/GPGLL/GPGSV cycle in whatever permutation the device ships it. In practice, three O reads will always be enough to get you some fix information — worst case is your first O came from a GPGSA and all you get is a mode, and then you get GPVTG, but you'll always get lat/lon on the next O. Clients that poll P or A repleatedly won't have a problem; the race effects will show up but be limited to noise in the first few seconds of samples. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Matt Joyce wrote: Isn't gypsy [1] used on some builds? Perhaps build a logger to use either gpsd or gypsy. Gypsy, Python examples are available [2]. Gypsy uses GTK+ (or more specifically GObject) which is not present in Qtopia which is QT based. Seeing as I use Qtopia, this is kind of important to me. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
