Navigation
New forum topics
Syndicate
Trying to get those elusive "perfect settings"
Off skiing in a months time, and playing with my iblue 747A+ logger and BT747 and trying to get that fine balance between amount of data I am logging, and the accuracy of the data, and ability to filter out the rubbish.
These are the settings I am currently using, can someone take a look and see if there are any improvements/optimisations to be had.
http://www.markgillespie.co.uk/index.php?option=com_content&view=categor...
Many Thanks.
- Login to post comments
- You should be able to
- You should be able to upload your images here too which make them more 'linked' with your post.
- Looking at your settings, things look pretty good. With a fix at 333 ms, you should be aware that you can actually log 3 positions per second when your speed exceeds 2 km/h. That in turn means that your probably want to log 'miliseconds' too if you want to be able to differentiate the positions in a second clearly.
If you want to increase the number of positions logged, you can remove NSAT and GPS Fix Type. The latter is also contained in a way in HDOP and VDOP because these values will be 99.9 if you do not have a fix. Further you would want to not log the positions without a fix altogether (tick the 'Valid fix only' box).
- Setting Distance to 'every 2m' is a bit agressive according to me. The imprecision of the GPS's fix will make you log quite often when you are not moving. I set this value to 5m.
- Personally I do not have an excellent experience with using the SBAS (WAAS/EGNOS) correction so I leave it inactive. The correction sometimes makes more harm than good so leaving it 'off' for all positions makes sure all positions use the same 'correction' (which is no correction in my case).
- The post-filter settings are generally ok. I would add 'User' to the track filter. Also, the limits for HDOP and VDOP depend on your device, I use 1.4 there. You did not configure NSAT in the common filter which indicates that there is no real using in logging that value (you could use NSAT as another indicator of position quality).
P.S.: I agree with your feedback about configureability and complexity. I have some thoughts on how to improve that, but I'll finish my book on the Human Machine Interface first. After that it still represents some effort to implement the GUI changes.
It's unfortunate, but to get
It's unfortunate, but to get flexibility, you often have to sacrifice simplicity!
Perhaps some use-case wizards might me a good way to go. know the size of the flash, and what sort of things you will be doing and how long you want them to run for before the device is full, and you might be able to have some recommended defaults.
Thanks for the feedback, I try those things out and see how I get on.
Actually I do not agree that
Actually I do not agree that one has to sacrifice simplicity to get flexibility. Unflexible things usually are complex because they are full of guidance conditions and alike.
I do agree however that almost all users go nuts when they get this kind of flexibility merely due to the sheer number of variables they can control individually. But I actually 'love' that and I have some difficulty grasping how the average user thinks.
Anyway, the idea currently is to propose the user first with a choice of the activity he wants to do. All will be presented in one 'screen' but there are two main types: connected activity and unconnected activity.
Then for each of these activities, the interface must be limited to the essential with the advanced stuff moving to popups, some 'Reset defaults' stuff. Wizards are good for newbies, but timeconsuming to implement. Currently some of the wizard like functions would add more to the interface currently (for instance, indication the estimated log time and/or log distance).
Some of the functions have to be regrouped according to 'Use case' activity rather than 'Device functionality'.