Device Settings Panel

Log Format
Defines the fields that you want the logger to store for the positions that meet the log conditions.
You can log more values than you actually need and use BT747 to extract only those values that you want. This is particularly usefull to filter out invalid positions : you can log the HDOP value to get an idea on position accuracy and then set a limit on HDOP to select only positions that are precise enough without writing the HDOP value to the output file.
Time: The time information is logged through the UTC field and the Milliseconds field. The UTC field corresponds to the date and time in second precision. You can achieve milliseconds precision through the millisecond field.
Even though you can log the milliseconds field without logging the UTC field, that normally does not make a lot of sense since it will be impossible to know how many seconds your positions are apart.
Position: The latitude field and the longitude field will need to be selected if you want to know your 2D position at all on the globe. This is normally what you got your logger for.
The height field field will allow you to know what altitude you were at. The logger actually logs the WGS84 altitude expressed in meters which is a very different value from the one you use in day-to-day life: the mean sea level (MSL) altitude. BT747 will help you to get the MSL value from the logged value (through the conversion options).
The speed is logged in km/h and is presumably determined through a doppler measurement in the logger. It obviously needs to be logged by setting the speed field and it represents the instantaneous speed that you had at the logged position.
The heading field enables logging the direction that you were moving in. When not moving this direction is pretty meaningless. The heading is not determined magnetically but again persumably determined through doppler effect observation.

Finally, distance will indicate the measured track distance of the new position with the previously logged position. In between two logged positions, the device will have performed other position measurements and these positions are taken into account too for the distance calculation. The distance value becomes pretty meaningless if intermediate positions were invalid. It is generally valid your device has a permanent fix.


The precision fields will help you determine the accuracy of the logged position. One other field can help you determine the precision too, but it is categorized elsewhere: the NSAT field. Indeed: the number of satellites in use also gives a good idea about precision

GPS Fix Type: The GPX Fix Type field or in some softwares the VALID field indicates the kind of fix that was achieved. This includes 'no fix' or invalid, 2D fix, 3D fix and DGPS fix. Other types exist as well but should not be observed by most mortels. You do not really need this field if you also log at least one of the HDOP, VDOP or PDOP fields.
HDOP, VDOP, PDOP: These three fields respectively log the horizontal, vertical and positional (read 3D) precision indicators. Their value turns to 99.99 if the position is invalid and you can use them as a filter too in BT747. Personally I use HDOP because the vertical precision does not interest me that much. You can consider the PDOP value to be some kind of mix between the HDOP and VDOP value. My limit in the BT747 filter is set to 1.98
DSTA, DAGE: The DSTA field and the DAGE field provide information regarding the DGPS satellite that is supposed to provide differential correction data to compute a more precise position from the measured position. The DSTA field will provide the satellite number providing the data and the DAGE field indicates how old that data is. These two fields could also be be labeled as satellite data but as they are related to precision, they were added to the precision group.
Reason: The RCR field stand for ReCord Reason (I suppose) and indicates why the position was logged. This is intimitally related to the log conditions that you defined for the device. If the set time has elapsed, the RCR field will be T (for Time). If the minimum speed was exceeded the field will be 'S'. The distance condition being met will result in 'D' and finally if you pressed the devices Button, it will be be. In practice several conditions may be met at the same time and you get a mixture of T, S, D and B

BT747 also allows you to log for other reasons through the application. These reasons are also logged in the RCR field and take other forms in the output formats.

Other: The Valid Fix Only is not actually a field, but this configuration is also set through the log format. This is only taken into account on some devices and it is actually a log condition. When activated, the compatible loggers will only log positions for which the valid field is something else than 'No Fix'. It will result in a reduced consumption of memory.
GPS Start
Hot start: Reuses all recently known information.
Warm start: Keep almanac information, but looks for satellites again.
Cold start: Forgets about alamnac information and looks for satellites again too.
Factory reset: Will reset some more values internally to the device and the proceed with a cold start. The effect of this is not very documented, so you'll get some extra warning messages to confirm that you really want to do this.
Erasing and setting the log format
Set format and erase: Sets the format and then erases the logger memory. This is the same operation as the one done when you change the log format with the original application and ensures compatibility with it (except for Holux where the original application does (or did) not support other log formats).
Set Format Only: Will change the log format, but not erase the memory. The original applications will no longer be capable of treating your log.
Erase Only: Despite of your manual changes to the log format, the log format currently set in the device will not be changed and the log will simply be erased.
Try to recover faulty memory: This is a specific procedure that will erase the logger's memory and 'recover' memory blocks that were labeled as faulty. You can compare this to bad blocks on a hard disk. When the OS discovers one of the HD blocks gives a bad checksum or some other bad operation, the block will be labeled as bad and no longer be used. A hard disk format will usually reset this condition.

Flash memory is also organised in blocks. When your logger detects that one of these blocks did not respond well, it will be labeled as bad and no longer be used. This reduces your effectively available memory. This bad block condition is stored in some other non-volatile memory of your logger.

Bad blocks can be the result of a low battery value resulting in a bad write (or read?) and do not represent a permanent condition. But sometimes these blocks may really be bad

This procedure will reset the bad block condition to valid and erase all the blocks of your memory. In most cases this will help.

Log by ...
Fix every:

This is the time between GPS fixes.
Usually this is set to 1000ms (1 second), but if you want to have 5Hz fixes, then you set this to 200ms.

Each of the conditions below (time, speed, distance) is evaluated independently on every fix (valid fixes only if you have 'Valid Only' checked).

In other word, the time, speed and distance conditions are OR'ed - only one of these conditions has to be met for the position.  And, for instance, the 'RCR' (ReCord Reason) field will be represented as TD if both the Time and Distance condition were met. 

Time every:

Define the time logging condition.
This is the maximum time delay between two logged positions expressed in seconds.
When you set this to 1s, then a position will be logged every second.  If 'valid fix' only is checked, then this time can be exceeded on the recent devices if there no GPS fix.

To achieve 5Hz logging, you have to set 'Fix every' to 200ms and this field ('time every') to 0.2s . 

When the value is 0, the condition is disabled.

Speed above:

Define the speed logging condition.

When speed is higher than the indicated speed, the position will be recorded.

As with 'Time', 5Hz logging is possible and will be active as long as the actual speed exceeds the condition and the 'Fix period' is set to 200 ms.

Distance every:

Define the distance logging condition.

When the travelled distance since the previously logged position is higher than the programmed distance limit, the new position will be logged.

As with 'Time' and 'Speed', 5Hz logging is possible and will be active as long as you move fast enough to exceed the distance every 200ms.  So if you require distance to be 1m, then you need to move faster than 5m/s to have a position logged every 200ms.  A distance condition of 1 meter @ 5Hz corresponds to 5*3600m/hour = 18km/h .

Setting the distance condition (in stead of the other conditions) is pretty much preferable because:

  • You avoid logging when you are not moving;
  • You pretty much determine the distance between positions before hand.

In addition you could add a time condition which ensures you that you get a position when you are not moving, for instance, every 5 minutes (300 seconds).  That time condition of 300s would require about 288 positions each day when you are not moving which is a reasonable 'overhead'.

... when full: Element description.
Element: Element description.
Holux M241 specific
Holux name: Element description.
Element: Element description.
Use SBAS: Element description.
Incl. test SBAS: Element description.