I’ve been testing the download of a full VP archive on B01 (IOW when WD has been shut down longer than 42 hours). The bad timestamp issue appears to have been resolved but I am seeing some misplaced records at the beginning and end of the downloaded period. This is an example of the logfile after downloading, there are two records from the end of the downloaded period, Nov 14th 8:52 and 8:53, duplicated at the beginning of the period, and two records from the beginning of the downloaded period, Nov 12 14:15 and 14:16, repeated at the end of the download.
I have been doing some testing on this and I also find that when downloading the full contents of the VP data logger (ie when WD has been down for longer than the record capacity of the logger) that exactly what Niko shows here happens. I have run several tests and all confirm that time spans less than the max capacity work OK and the log files are correct but whenever you download the whole contents of the logger then WD creates these out of sequence records in the log files and files like misseddata.txt also contain these out of sequence records. This is using build 02 btw.
I have also noticed that when reading the full archive from the logger the progress bar for downloading the data stops at less than 100%, the second bar for processing the data runs normally up to 100%
Brian I have been wondering whether or not to re-raise this but in light of other issues with downloads I decided to do it. I have been testing this problem with builds up to Q B28 with so far no resolution. I still find that when WD attempts to download from the datalogger beyond its capacity then this problem happens and it happens with both direct serial connection to the logger and also happens when using VVP and a virtual com port. I trust this is a simple fix as it seems to me that WD is not checking to see which records are valid in the first and/or last blocks of data retrieved from the logger.
I have been holding off from raising this again but now have got to the point where I would like to update to the latest version as it fixes some minor bugs I do still see on the old version I run live but unless I can feel sure my logs will be correct when doing an archive download I have held off from updating.
Brian can I please ask that you take a look at this problem, we have been waiting patiently now since last year for this to be fixed and I have today tested for it yet again this time on 10.37Q build 35 and the problem still exists.
It only happens as far as I can tell when the last download data is earlier than the earliest date in the logger and so WD downloads the entire logger contents and places out of sequence records at the start and/or end of the period in the log file (32011lg.txt in case of today’s test)
Brian thanks very much for the fix. I have tested it and so far it is behaving perfectly now. I know Niko is going to test it this coming weekend as well as he was the first to discover this problem.
Brian I have some bad news to report on this. I have done some more tests and found that I can still get out of sequence log records this time so far it has only happened with records at the end of the archive download period. In my case the download period ended at 9:50 on 18/4/2011 and then two reords were written for 15:11 and 15:12 from the 16/04/2011.
I am on holiday at the moment so can not do any more testing/work on this
(and note the problem only occurs if a full data logger download is done ,i.e its not normaly a problem at all)
(and to be fair its a quirk of the data logger with the wrap around (ie ideally it should not be sending data out of sequence like that in the first place (in an ideal world))
but I am seeing some misplaced records at the beginning and end of the downloaded period. This is an example of the logfile after downloading, there are two records from the end of the downloaded period, Nov 14th 8:52 and 8:53, duplicated at the beginning of the period, and two records from the beginning of the downloaded period, Nov 12 14:15 and 14:16, repeated at the end of the download.