The file to which the data is saved when downloading, or read when converting. The extension should be '.bin', except for Phototrackr and similar devices where it should be '.sr'.

it is important that the extension is '.bin' for raw log formats!

The basename of the files that will be written. This does not include the filename extension. The path is relative to the output directory. The basename will be post-fixed with date and time information as well as the appropriate file extension for the chosen output format.

It is possible to have a customised based name by using '%*' tokens.  Please see http://php.net/manual/en/function.date.php for details - most of the 'php' formatting options are available.  As soon as you specify a '%' token in your filename, BT747 will no longer do its magic and you assume the entire responsibility that the resulting filename is unique (for instance, if you have more than one file for the same day, make sure that you include the hour and minutes - not just the day).

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.

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.

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.

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. 

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.

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.

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'.