It is now 2022 and the product was created 15 years ago in 2007. The source code was put onto GitHub some 3 years ago and you can find it at https://github.com/matthewgream/gps-logger-mg.
Tuesday, July 19, 2022
Monday, December 17, 2007
Update: Quiet
Just an update to let you know that I am still here, but virtually no progress made in last couple of months - mostly for business (new position, weeks abroad in other offices) and personal (birth of new child, house renovations planning, etc). In the interim I've noticed that SparkFun are no longer listing V1.0 of the GPS Logger, which is a bit of a pity since the Lassen iQ has lower power consumption than the EM-406, but the latter board design (V2.4) is more superior (as, in fact, are various other aspects of the EM-406). I hope to have some time over the holiday break to do some work and provide updates. If you are reading this and have suggestions for any priority items, please leave comments. Otherwise, Happy Holidays!
Tuesday, July 10, 2007
Release: GPS Logger MG - Release 0.94b
I've produced an interim release, this has a couple of I/O performance improvements, and allows both 'file' and 'pass' modes to be active concurrently (so you can use real-time GPS through the serial port, while also logging to flash). In addition, I've also now included a CHANGES file, taken directly from the project's svn commit log. This gives you very fine detail about what's happened between releases. Get it from the links to the side.
Wednesday, June 27, 2007
Release: GPS Logger MG - Release 0.94
Release 0.94 is available! You can read the release note to the side, and download both the release package and userguide. Feedback is welcome!
Tuesday, May 22, 2007
Testing: Output format statistics
I have just polished up code and data and run a comparative test, the results are interesting.
The large GPS sample data was first run through 'NMEA' format, selecting only GGA sentences. There are in total 2898111 sentences, which approximates 33 days, 13 hours, 1 minute and 51 seconds of positioning data if captured continuously at 1 second intervals. There are no invalid (i.e. non-lock, no position) sentences in here: they're all valid with usable data.
I then used this resulting data to test KML and CSV formats, using text and binary encoding options, and compression.
In NMEA mode, with GGA sentences: 190M file (2898111 lines).
In KML mode: 60M file (2643355 lines).
In CSV mode, with text encoding, and lon,lat,alt elements: 60M file.
In CSV mode, with binary encoding (no compress), and lon,lat,alt elements: 25M file.
In CSV mode, with binary encoding (compressed), and lon,lat,alt elements: 7.9M file.
When repeated with 'compress=true', the resulting output files are:
In NMEA mode, as above: 27M.
In KML mode, as above: 11M.
In CSV mode, with text encoding, as above: 11M.
In CSV mode, with binary encoding (no compress), as above: 12M.
In CSV mode, with binary encoding (compressed), as above: 5.8M.
I'll discuss this in further detail later, but it indicates the success of the generic and binary compression features. Consider about 1 month of data at 8M (using binary encoding, with compression, which happens to be the best-bang-for-buck), you could get 64 months on a 512M SD card, or 5.3 years. What an overkill! Remember that it's not about preserving card size, it's about preserving card writes, and thus power efficiency.
The large GPS sample data was first run through 'NMEA' format, selecting only GGA sentences. There are in total 2898111 sentences, which approximates 33 days, 13 hours, 1 minute and 51 seconds of positioning data if captured continuously at 1 second intervals. There are no invalid (i.e. non-lock, no position) sentences in here: they're all valid with usable data.
I then used this resulting data to test KML and CSV formats, using text and binary encoding options, and compression.
In NMEA mode, with GGA sentences: 190M file (2898111 lines).
In KML mode: 60M file (2643355 lines).
In CSV mode, with text encoding, and lon,lat,alt elements: 60M file.
In CSV mode, with binary encoding (no compress), and lon,lat,alt elements: 25M file.
In CSV mode, with binary encoding (compressed), and lon,lat,alt elements: 7.9M file.
When repeated with 'compress=true', the resulting output files are:
In NMEA mode, as above: 27M.
In KML mode, as above: 11M.
In CSV mode, with text encoding, as above: 11M.
In CSV mode, with binary encoding (no compress), as above: 12M.
In CSV mode, with binary encoding (compressed), as above: 5.8M.
I'll discuss this in further detail later, but it indicates the success of the generic and binary compression features. Consider about 1 month of data at 8M (using binary encoding, with compression, which happens to be the best-bang-for-buck), you could get 64 months on a 512M SD card, or 5.3 years. What an overkill! Remember that it's not about preserving card size, it's about preserving card writes, and thus power efficiency.
Thursday, May 17, 2007
Progress: update for 0.94 release
Work for the 0.94 release is coming along. Most of the main work has been completed: (a) porting emulator to Linux, to support both FreeBSD & Linux; (b) porting firmware to GPS Logger V2.4, to support both V1.0 and V2.4; (c) supporting generic and binary compression for output data; (d) PC based application testing for both V1.0 and V2.4. There are also a bunch of smaller scale additions and modifications that I won't go into here right now.
All I have to complete now are some performance cleanups (some code inlining thanks to a gprof analysis), some emulator cleanups (clean termination at end of input files) and a round of testing. The testing can't be understated: I need to (a) test code against GPS sample data, (b) produce compression statistics from same data, (c) test power consumption for this and original firmwares, (d) general code review and functional testing.
I have also decided on the roadmap for future releases: the next one, a 0.96, will focus exclusively on reworking and extending the GPS data handling, by (a) the logger programming the GPS module for specific sentence, powersave and other features; (b) support sparkfun V2.4 firmware features (hold off, etc); (c) customisable filenames with date/timestamps; (d) a separate utility tool for conversion from raw/nmea to kml/csv with binary/text encoding and using compression; (e) power/performance improvements as necessary. Beyond that, a 0.98 release will be entirely dedicated to power/performance optimisations and improvements, and additional debug/inteface features (e.g. I may add in an xmodem download feature (so you can extract logs without having to remove the SD card). After 0.98 comes 1.00, when all should be stable, working and optimal.
I hope to have a 0.94 release ready in the next 3-4 weeks. Let me know now if there's anything you're interested in.
All I have to complete now are some performance cleanups (some code inlining thanks to a gprof analysis), some emulator cleanups (clean termination at end of input files) and a round of testing. The testing can't be understated: I need to (a) test code against GPS sample data, (b) produce compression statistics from same data, (c) test power consumption for this and original firmwares, (d) general code review and functional testing.
I have also decided on the roadmap for future releases: the next one, a 0.96, will focus exclusively on reworking and extending the GPS data handling, by (a) the logger programming the GPS module for specific sentence, powersave and other features; (b) support sparkfun V2.4 firmware features (hold off, etc); (c) customisable filenames with date/timestamps; (d) a separate utility tool for conversion from raw/nmea to kml/csv with binary/text encoding and using compression; (e) power/performance improvements as necessary. Beyond that, a 0.98 release will be entirely dedicated to power/performance optimisations and improvements, and additional debug/inteface features (e.g. I may add in an xmodem download feature (so you can extract logs without having to remove the SD card). After 0.98 comes 1.00, when all should be stable, working and optimal.
I hope to have a 0.94 release ready in the next 3-4 weeks. Let me know now if there's anything you're interested in.
Discussion: to GGA or RMC
I noticed with the GPS Logger V1.0 using Trimble Lassen iQ, that the default output sentences were GGA and VTG. This provided the necessary position and velocity information. It also provide a timestamp (UTC), but not a datestamp. So, for a proper datestamp I either needed an additional RMC or ZDA sentence.
With the GPS Logger V2.4, using US Globalsat EM-406, there are a whole bunch of default sentences, one of which is RMC. Now, RMC sounds great: it has validity field, position, velocity, timestamp, datestamp, but it lacks an altitude. Just that one extra field would have made all the difference.
So, in any case, not in this version of GPS Logger MG, but in a future version, the GPS module (either Lassen iQ or EM-406) will be programmed at start up to only spit out the bare minimum sentences necessary. That's easy with the EM-406 out of the box, because it supports an inbound interface. For the Lassen iQ, it needs to be pre-configured to accepted TSIP on the port.
With the GPS Logger V2.4, using US Globalsat EM-406, there are a whole bunch of default sentences, one of which is RMC. Now, RMC sounds great: it has validity field, position, velocity, timestamp, datestamp, but it lacks an altitude. Just that one extra field would have made all the difference.
So, in any case, not in this version of GPS Logger MG, but in a future version, the GPS module (either Lassen iQ or EM-406) will be programmed at start up to only spit out the bare minimum sentences necessary. That's easy with the EM-406 out of the box, because it supports an inbound interface. For the Lassen iQ, it needs to be pre-configured to accepted TSIP on the port.
Subscribe to:
Posts (Atom)