Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#8 Seamless log download on overwrite

open
nobody
None
5
2008-11-13
2008-11-13
Giacomo Ciani
No

It would be very interesting to have the "smart dowload" function resuming dowload from the last one even if the memory has been filled up in the meanwhile, thus allowing for the creation of a semaless log bigger than the device memory.

Here is an example: suppose the device can store 100 poiints, and I'm starting from a fresh erased memory.

I record 40 points, then download them without erasing the memory.

Then I record 40 more points. When I dowload them, the "smart dowload" function recognize that the first 40 are already dowloaded, and dowload alny the last 40 (actual behaviour). I'm still not erasing the memory.

Then I record 40 more points, thus overwrtiting the first 20 (I had only 20 free in memory). At this point, BT747 reports the device memory as not corresponding to the log file anymore, and ask for overwriting or choosing a different filename.

It would be nice if the software can recognize (expliting the point from 20 to 80, that are present both on the device and on the log file) that it can dowload points 80 to 100 and 1 to 20 and append them to the previous log file, thus creating a 120 pints long logfile with contiguos, seamless recording.

Thanks

Giacomo

Discussion

  • Matthew Geier
    Matthew Geier
    2008-11-17

    A 'me too'
    It would be great to have the 'roll over' of the log handled gracefully. I have my logger set to 'over write' mode, and one day recently the log over ran while I was out. I got the 2nd half of my days travels - the first half 'lost'. But of course since the logger wrapped around, that data is still in the logger, up the far end of the memory, but not accessible any more.

     
  • Mario De Weerd
    Mario De Weerd
    2008-11-17

    Hi Matthew

    The problem that you mention has been solved in the latest (actually 1.61.8) release as I wrote in the forum. Your bin there had data from oct 25 'wrapping around' but is now 'unwrapped'. Try it and give me feedback! Also - in 1.61.9 - I further changed the startup script for Linux in order to better take the architecture into account as seen by java. I do not use Linux at home so I can only partially test it (I have cygwin).

    Regarding the request - it is good to log it here so that it is not forgotten + you'll also get updates in case comments are added here.
    Do note however that it is not as simple as it looks. Reading data from device memory is not immediate and somewhat 'asynchrounous' so looking for the right start in device memory to download from effectively needs some 'smart' algorithm. That is easy to imagine, but some work to implement and validate ...