Time based filtering of records
Brought to you by:
mdeweerd
Menu
▾
▴
#14 Time based filtering of records
For the DT version I would like to have the following options during 'Convert':
#1. Filtering of records based on elapsed time since previous record (available for all formats).
#2. Available for NMEA only: the same as #1, but different settings for the type of sentence.
Some explanation why I want to "optimize" the size and contents of output files.
When I log at a rather high (fix) rate and during a long time (e.g. a full day of skiing without taking care for the GPS logger), it results in large log files. But there are programs where the file size (number of TP's) has a negative impact on the performance. And especially when such a program don't benefit of the detailed logging, I want to reduce the number of records.
Some programs (e.g. 'GPS Tuner') needs satellite data in the NMEA files. But that sentences (GSV and GSA) may appear in a (much) lower frequency than the positional and speed data (RMC and GGA sentences).
Option #1 should be available at the 'Log operations' tab as a "one for all formats" setting.
For option #2 it is no problem (I think) if the current 'NMEA Output Settings' are applicable as a ratio setting (multiple to 'elapsed time') during a 'Convert' too. The only disadvantage or consequence is, that you must connect to the GPS to get the advanced device settings. And if you set other values for the conversion manually, they will be lost if you connect to the GPS.
Note. I would like to have these options in the PPC version too. But apart from the programming and the device performance, the menu/interface will make the implementation perhaps more difficult than for the DT version.
I strongly support this request, e.g. for following a week-long travel track in Google Earth, having Trackpoint tags only every 1-5 minutes instead of 5 seconds seem to be enough and would save likely 80% of KML file size. The RCR=B (Buttonpress) points should however not be reduced. Maybe the path for non-"T" RCRs could be thinned as well "Keep every n-th point". The first thinning would be however most necessary. Else, the program is very good!