Auto-naming downloaded files?

neilbryant's picture

I'm regularly downloading the contents of my bt747. Yesterday, for the first time, I neglected to change the logfile name, and overwrote the previous-day's file. What I'm wondering is if there is a way to automatically change the root log file name.

Ideally, I would be able to change the setting in the option box to something like "bt747%YYYYMMDD%log.bin", since that is essentially what I do manually, but if there's a way to get it to take I haven't found it.

Alternately, I could use something like the -f option from the command-line, but I'm using the online jnlp link, and can't seem to find a way to pass a command-line option to it.

If anybody has a pointer, I would appreciate it.


mdeweerd's picture

I guess I need to up this on

I guess I need to up this on my list of things to implement.

I hate to 'reinvent the wheel', so I propose to use an existing kind of encoding (more or less).  BT747 could follow the PHP date function scheme:

This still leaves us with two options (at least):

  1. use % before every letter (the nice thing about the PHP date function parameters is that all encodings are a single letter);
  2. use %% and everything in between is for the date.

I prefer the first method.


Now that being said, the encoding would be used in two places:

a) The raw log file;

b) The output file.

a) Regarding the raw log file: it is a bit more complex to get the date from the recorder first and then download to a named file, so I would be using the current date (at least for a start) of the device BT747 is running on (desktop, mobile phone, ...).  That might reduce the benefit of smart download if downloading a file on different days.
An in between method could be that I store the previous filename (with the settings) and use the template only in case the content is different.

b) The output file would use the time in the log.

neilbryant's picture

That is excellent beyond my

That is excellent beyond my expectations =]

I think the php function scheme would be just fine. I agree with you on the first method being better; or at least, I like it.

Perhaps just dropping the date pieces, in the case that smart download is selected (or just map them all to "") might answer that issue?

Your mention of the Smart Download triggered a further question... Right now, I am doing a full download and then erasing the device memory every time my trip stops; which is fine, and gives me discreet tracks, as I want.

If I did a smart download, instead, and erased the memory after; would the logs append each other in the case that I forgot to change the names? If so, that would give me a failsafe until things are implemented.

mdeweerd's picture

In case you do a smart

In case you do a smart download, BT747 'appends' the data to the same file if the data already in the file corresponds to the data in the logger.  If not you would get a warning that the data is different with a request to overwrite or not.

Maybe I should add another failsafe, a 'never overwrite' option which would result in not asking the question, just saying that the data is not overwritten (but then some people would erase before actually downloading).

Personally, I try to fill my memory as much as possible.  The number of erase cycles for flash memory is limited.  Normally you should not reach that limit (modern memories have 100000 cycles which would make it last for 274 years with one erasure each day), but nevertheless.  I also get less files to manage ;-).  But that is purely personal.


neilbryant's picture

So, as I read that; if I've

So, as I read that; if I've erased the flash between downloads, the smart option won't have anything to match to the file, so it would not append it. That makes sense. That may work as a failsafe, in its' own right--if it will prompt me to overwrite, and give me a chance to go back and change the name.

In one of the earlier versions, I was having trouble loading a bunch of pictures to geocode. At the time, I settled on smaller files, and smaller sets of photos as being a partial fix. I haven't gone back and geocoded anything for a while, so I couldn't say if it still happens (and it was probably just my old laptop, since it was pretty weak.) It has also been convenient to download pictures into date-named folders, and just pull up the tracks according to their date. I could probably get a better workflow, if I spent more time on it, but it's been working very well (thank you for that, btw. The application is brilliant.)

Plus, the files would be pretty huge, by now (I've been driving for two years, and logging each leg).

I don't know whether you have

I don't know whether you have a fix for it or not, but the solution I use was to run from the command line. I run linux, which is an advantage, if you are a windows user, then this ain't gonna work.

I have a cron job set up so that as soon as the bluetooth GPS comes into range of my laptop, it downloads the data, and erases. Each file is uniquely named, and it doesn't download a new log unless the GPS has gone out of range and come back again

After downloading the binary data, the script converts the binary data into gpx form, and as in this version, automatically removes 5 hours from UTC time to put it in a specific timezone. Each of the output files is listed by the day they were downloaded, plus the day they were recorded, this makes geotagging via exiftool easy (CR2 wasn't supported when I wrote these, and having both times means I can fix problems if I forget to change the camera time). The GPS data is erased from the device.

Important. In order for this to work, you must remove the & from the last line of the file

Hope this might be of some help.



Script "scanit"

scanitrunning=`ps -ef |grep -c \[s\]canit`

if [ "$scanitrunning" -lt 4 ]
found=`hcitool scan |grep iBT-GPS`

if [ "x$found" != "x" ]
if [ -a "/tmp/searchdone" ]
#echo "Already downloaded"
touch /tmp/searchdone
#echo "Device available"
bash rfcomm-cmd &
sleep 2
bash bt747-cmd
rfcomm release /dev/rfcomm1
#echo "Hardware missing"
rm  -f /tmp/searchdone
echo "Scanit running"
echo -n
echo $scanitrunning
ps -ef |grep \[s\]canit

Script rfcomm-cmd, edit for your MAC

rfcomm connect rfcomm1 00:1C:88:10:DB:40

Script bt747-cmd

cd ~/bt747/
mbase="`date +%Y_%m_%d`"
while [ -a GPS-$base.bin ]; do let count=$count+1;base=$mbase-$count; done
success=`./ -p /dev/rfcomm1 -f GPS-$base --download-method SMART -a 2>&1 `
osuccess=`echo $success |grep SUCCESS`
if [ "x$osuccess" != "x" ]
success=`./ -b GPS-$base.bin --outtype gpx -f GPS-$base --splittype day --UTC -5 2>&1 `
osuccess=`echo $success |grep "Conversion done"`
if [ "x$osuccess" != "x" ]
./ -p /dev/rfcomm1 -E
echo "Error occurred converting data to gpx"
echo $success
echo "Error occurred Downloading data"
echo $success
./ -p /dev/rfcomm1 -l on

mdeweerd's picture

Hi Thanks for sharing


Thanks for sharing this.

Ok if I put this in the distribution


mdeweerd's picture

Back to the original question

Back to the original question in this thread: I've added the functionality as I indicated further above.

It is now possible to specify the output filename using the 'php' like tokens:

I've implemented most of these '%*' tokens.

As soon as a '%' is present in the output filename, BT747 will stop doing its usual filename magic and suppose that the '%*' specification is unique enough - if you only specify the weekday for instance and the file splitting is set such that you have more than one file for that weekday, the created files will be 'rubbish' (because the same filename will be used for supposedly different files).