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 [email protected] http://lists.openmoko.org/mailman/listinfo/community
