No, no, no … data send by the WMR200 console is not corrupt. It is 100% perfect.
Please refer back to the [b][color=blue]3rd post[/color][/b] in this thread and you’ll understand why we’re having these problems.
OK, I see that your lost the large set of data. But I see in your Extractor log files that date/time for initializing of extracting is later than time/date of first extracting record. See, for example:
Looking for data [color=red][b]from 04:38:00 PM 20/02/10[/b][/color]USB port opened OK
**Current actual data D1
…
Decoding missed data now
Time from decode 02/13/2010 19:24:00
…
or
Looking for data from [b][color=red]05:18:00 PM 20/02/10[/color][/b]USB port opened OK
**Current actual data D1
…
Decoding missed data now
Time from decode 02/18/2010 15:33:00
baro check 1023.0
indoor temp check 25.0
indoor hum check 53
missed data time: 15:33 date: 18/2/10
Missed data Acumulate Rain= 63.49
time from data 03:33:00 PM looking from 05:18:00 PM current time 06:11:35 PM
…
But in my history file time/date for start of extarcting is early first record in console buffer, for example:
Looking for data from 6:50:00 04/08/09USB port opened OK
**Current actual data D1
**Current actual data D1
…
Decoding missed data now
Time from decode 08/04/2009 06:50:00
baro check 985.0
indoor temp check 22.4
indoor hum check 70
missed data time: 6:50 date: 4/8/9
Missed data Acumulate Rain= 34.30
time from data 6:50:00 looking from 6:50:00 current time 9:05:30
number of sensor = 1
Current Channel # =1
missed outdoor temp =23.8
missed outdoor hum =61
…
Decoding missed data now
Time from decode 08/04/2009 06:51:00
baro check 986.0
indoor temp check 22.4
indoor hum check 70
missed data time: 6:51 date: 4/8/9
Missed data Acumulate Rain= 34.30
time from data 6:51:00 looking from 6:50:00 current time 9:05:31
…
As I understand, if during transfer of historical data from console to PC the error is arise it is need to stop WD, correct date and time in section “[Davis download]” in WDISPLAY.INI with according to last right record in log-file DDYYYYlg.txt and start WD again. May be this disagreement between data in buffer of console and already available data in WD is cause of problem?
Another WMR200 having similar problems particularly with wind Gust Spikes,as rickym pointed out these are a real pain to correct as my month/year/all time may be affected.
In the last month or so I’ve also had a couple of big average wind spikes in WD (not in the data file) and a ridiculously high temp spike as well
That’s all due to WD having screwed up during the earlier runs … remember I had to do 8 runs to get all the data extracted !
Of course, the extracting of data is very slow process. 
Did you correct the date/time in WDISPLAY.INI before next running after stopping? What is the reason of your re-running of WD?
No, I did not have to set any dates in WDISPLAY.INI and I don’t think you have to.
WD history extractor did not miss one beat in extracting all the data from the WMR200 data-logger, but screwed up when analyzing and writing the data to the logs.
Analyze my history files and you’ll see that I received all the data for the 8 days i.e. 8 runs.
For the WMR200 protocol go back to this post: WD is corrupting data from WMR200 data logger - #23 by katropa - Archived Weather Display Problems - Weather-Watch Forum
I think you need to start at page 1 of this thread again.
It’ a great pity that Brian doesn’t give any comments in this thread although he was online in this forum all the last days.
I think he is overstrained with these problems and has no idea to fix them, or he isn’t interested to do this.
The consequence is that the logger of the WMR200 is unusable with WD and all owners of a WMR200
who don’t run their PC 24/7 have to use another software for storing the weather data.
May be…
Sorry, but I didn’t found why you restarted WD 8 times when it was extracted old data from logger. In the past during the extracting of data from console I controlled process and noted when old data transfer stopped and WD started to get current data. But data in log file were incomplete and restart WD after correction of date in WDISPLAY.INI allow to continue the transfer data almost without long gaps.
No, no, no again … It has taken me a few days to analyze all 8 history files to come to this conclusion. WD is indeed corrupting the data.
It did not extract old data from the data logger.
I only received data from the WMR200 data logger for the 8 days the PC was off due to the lightning strike.
That’s why I bought the WMR200 with the data logger in case of a catastrophe like this.
You wanted to know why I restarted WD 8 times?
It’s because I noticed that WD history extractor stopped after fetching around 24 hours of data only.
I immediately killed WD and restarted it. WD then continued extracting data from the WMR200 data logger from where it had stopped.
This had to be done 8 times before WD got all the data extracted for the 8 days.
Luckily I was expecting something like this and I was prepared for it and also made copies of all the history, log and datafiles in the process.
Having those I can now prove that WD and not the WMR200 is the culprit here.
Sorry, but you need to do a more in depth analysis of my data.
I do not suck these allegations from my thumb.
I do not expect Brian to jump into this problem straight away.
After all he’s a family man and needs to spend some time with them as well.
He works long hours and sets his own priorities but I would have liked him to
have at least acknowledged the existence of this thread.
I think that the receiving data from console accumulated there during period without connect to PC is just “get old data” 
Yes, I said about this. Similar problems discussed in http://discourse.weather-watch.com/t/37862
I agree with you. I analyzed your files and found:
- under 1st start WD after repair of PC you have correct date in WDISPLAY.INI (11:55PM 22.01.2010) which more early than time of last received record
WD started to extract history data since 17:24 12Feb to about 19:20 13Feb. Here WD had failure, stopped process and started to receive curent data. You stopped WD
- then you restart WD, but time in WDISPLAY.INI was 16:38 20Feb (!). I think that this time is derective for WD about received records from console and WD used this time for control and rejecting of repeated data.
In “2010-02-20 @ 16h40\wmr200history.txt” we see that WD start to receive the historical data from 19:24 13Feb and stopped on 05:15 15Feb. This show that data set in WMR200 buffer was full without gaps. But (!) this data were got to log file 22010lg.txt.
I think that is bug of WD, but this problem can be partly eliminate under CORRECT time in WDISPLAY.INI. If you change this time to 19:00 13Feb then all data from 19:24 13Feb to 05:15 15Feb were recorded to log file.
-
then situation repeated, WD received (or control) historical data from console, but didn’t write to log-files, only short fragments
-
during last restaring time in WDISPLAY.INI was correct (why?) - 06:44 20Feb. After this the data are good.
Yeah, thats another thing I noticed when extracting data. Every time the extraction process stopped for no reason and I knew it hadn’t completed, if I plugged the unit back in WD was set to extract data from the date and time that the extraction process stopped, not from where the last piece of data that came off it was.
Yes, brother. And there is nothing that I can see that causes it, such as a blackout or failure with my computer or other strange weather happenings. So I agree that WD is probably the culprit, especially after reading all the posts here. Needless to say, I am not a computer buff and don’t understand what you’re saying about “split records”. I assume Brian might.
However, I still think there are two issues and they should be kept separate. Both are probably WD failure issues as discussed in my post above.
Despite these failings, I still think WD is a bloody good program especially given the miserable funding that the owners of the software receive. 
But that is not to diminish my concerns with the program.
Hey guys, my laptop runs 24/7 and I still have these problems – well those relating to wind gust spikes anyway. Or have I misunderstood your comment here?
Yes, that is so true. I’m very grateful for what I’ve got, despite the failings discussed in this thread. If it means I have to keep deleting wind gust data, so be it. However, it would be better if I didn’t have to do that or could correct it more easily should it happen. Also, I’m pleased for the general support users have shown here – so it’s not just something happening with a few folk, but is widespread with users of WD and WMR200s.
The problems I had last year when I lost rainfall data could well have been caused by my rebooting WD. However, that is not the case this year with my problems with wind gust data. Sometimes the wind gust spikes have occurred when nothing has happened with the computer – no blackouts (anyway, it’d run on the battery) and no rebooting the computer. I have StartWatch installed and it tells me should anything of this nature occur and it didn’t.
My PC and WD are running only one or two hours a day at most.
In this time when WD gets live data I found no errors. All the problems occured when WD gets data from the logger.
Proposal how to fix this problem
Here’s what I’ve noticed in the history extraction logs where WD is recognizing split records and joining them and where things get messy.
The green part in the data below holds the correct timestamp for the history record (D2) but WD is using the red part for the date/time calculation.
The correct timestamp for the green part is 12-02-2010 @ 18h31 which is correct.
If you decode the timestamp for the red part it’s 12-01-2001 00h25 … exactly what WD gets.
So I think it’s maybe a pointer issue in the program which needs to be corrected.
Because of this the rest of the data is then also wrong i.e. baro of 1474.0 hPa.
This might also explain why there are “Invalid floating point operations” during the extraction which I’ve seen in the “programerrorlog.txt”.
There’s also an extra history record, in blue, arriving with the second packet which looks like it’s getting lost … timestamp is 12-02-2010 @ 18h32
We have received 2 history records i.e. one for 18h31 and one for 18h32.
If you look in the log entry below then the record for 18h32 is missing and record for 18h33 is duplicated.
The first packet is a live temp/hum sensor record (D7) which we’ll use for a timestamp correction proposal below.
NOTE: The history data below is actual data I received during the extraction.
[b]Data received by History Extractor:[/b]` **Current actual data D7 10 [color=maroon]04 10 14 02 0A[/color] 00 13 01 27 82 00 51 29 02 No more missed data count 1
**Current actual data D2 31 1F 12 0C 02 0A 1F 00 00 00 6C
D2 31 1F 12 0C 02 0A 1F 00 00 00 6C
**joined lines together D2 31 1F 12 0C 02 0A 1F 00 00 00 6C ** 00 03 19 00 0C 01 01 07 08 0C 00 00 00 00 20 FF 4D 13 FE 33 01 90 1A 01 28 8C 00 52 11 E5 00 38 8C 00 00 38 08 D2 31 20 12 0C 02 0A 1F 00 00 00 6C 00 03 19 00 0C 01 01 07 08 0C 00 00 00 00 20 FF 4D 13 FE 33 01 90 1A 01 28 8C 00 52 11 E4 00 38 82 00 00 2E 08
**Current actual data D2 31 1F 12 0C 02 0A 1F 00 00 00 6C 00 03 19 00 0C 01 01 07 08 0C 00 00 00 00 20 FF 4D 13 FE 33 01 90 1A 01 28 8C 00 52 11 E5 00 38 8C 00 00 38 08 D2 31 20 12 0C 02 0A 1F 00 00 00 6C 00 03 19 00 0C 01 01 07 08 0C 00 00 00 00 20 FF 4D 13 FE 33 01 90 1A 01 28 8C 00 52 11 E4 00 38 82 00 00 2E 08
D2 31 1F 12 0C 02 0A 1F 00 00 00 6C 00 03 19 00 0C 01 01 07 08 0C 00 00 00 00 20 FF 4D 13 FE 33 01 90 1A 01 28 8C 00 52 11 E5 00 38 8C 00 00 38 08 D2 31 20 12 0C 02 0A 1F 00 00 00 6C 00 03 19 00 0C 01 01 07 08 0C 00 00 00 00 20 FF 4D 13 FE 33 01 90 1A 01 28 8C 00 52 11 E4 00 38 82 00 00 2E 08
Decoding missed data now
Time from decode 01/12/2001 00:25:00
baro check 1474.0
indoor temp check 204.8
indoor hum check 8
found extra D2 18 32 12 2 10 ** 20 12 0C 02 0A
checking to use extra found D2
time/date in extra found D2 02/12/2010 18:32:00
passed to use extra D2
Time from decode 02/12/2010 18:32:00
baro check 1022.0
indoor temp check 28.2
indoor hum check 40
missed data time: 18:32 date: 12/2/10
Missed data Acumulate Rain= 0.77
time from data 06:32:00 PM looking from 11:55:00 PM current time 03:53:12 PM
Difference in rain =0.0
number of sensor = 1
Current Channel # =1
missed outdoor temp =22.8
missed outdoor hum =56
*****updating data , skip time 06:31:00 PM 12/02/10 amount skipped 2
<hr/> [b]Data in logfile recorded:[/b]
12 2 2010 18 29 23.0 58 14.3 1022.0 0 0 202 0.0 5.4 158.5 630.9 24.8
12 2 2010 18 30 22.9 57 13.9 1022.0 0 0 180 0.0 5.4 158.5 630.9 24.9
12 2 2010 18 31 22.8 56 13.6 1022.0 0 0 180 0.0 5.4 158.5 630.9 24.9
12 2 2010 18 33 22.8 56 13.6 1022.0 0 0 180 0.0 5.4 158.5 630.9 24.9
12 2 2010 18 33 22.8 56 13.6 1022.0 0 0 180 0.0 5.4 158.5 630.9 24.9
12 2 2010 18 34 22.6 56 13.4 1022.0 0 0 180 0.0 5.4 158.5 630.9 24.8
12 2 2010 18 35 22.6 56 13.4 1022.0 0 0 180 0.0 5.4 158.5 630.9 24.8
`
Handing these 2 problems above, which should not be to difficult to rectify, will already solve a lot of our problems i.e. missing and duplicate records.
The 2nd issue is the WMR200 clock being out of sync with the PC.
This results in gaps at the start of extraction (presuming the WMR is ahead in time of the PC),
and data with timestamps ahead of the PC’s clock which will be overwritten (or maybe duplicated?) in the logs.
I have mentioned a possible solution for this in this post on 1st page.
If you take the D7 packet above and decode the timestamp (maroon/brown) you get 20-02-2010 @ 16h04 (4:04 PM).
Further down you’ll see another maroon/brown part which indicates the current extraction time of 03:53:12 PM on the PC.
As you can see there’s a time difference of 11 minutes (WMR being ahead of PC). We could use this difference and
subtract it from the incoming history data timestamp to give us the correct/actual time of the records.
The 3rd issue, and I have a suspicion that WD might already be handling this, is capturing live data during the history extraction.
If not captured during the history extraction, which in my case took 3 hours for 8 days worth of data, might also mean a big hole in the logs.
If your WMR200 clock was ahead of PC time then you would probably not notice this gap. But what you’ll probably see is an abrupt drop or
rise in your graphs.
The 4th issue is that the History Extractor gives up to early when it’s not receiving any more history data.
In some cases, because of the confusion arising with the split records, WD “thinks” it’s done which is not the case.
Maybe, I don’t know how this works, issue another “reset” to the WMR after it thinks it’s done and wait a while longer
for more history data to arrive, and then only quit.
PS: My recommendation is to incorporate the history data extraction with the live data extraction and to log whatever
the WMR200 data-logger throws at WD. According to my history files the WMR200 was indeed sending all the missed data
for the duration my PC was not attached to the WMR200. It did not miss one single beat in recording data minute-for-minute
for the entire 8 days. It also did not have any data outside of this timespan. The WMR200, form what I can see, does not log data
while in live mode. This recommendation however might mean keeping at least 31 days worth of data in memory, which is 44,640
records and which translates into roughly 4MB to 5MB for all the logs. How feasible this is I don’t know.
I suddenly got this drop in indoor temperature during live data extraction early this morning.
Temperature suddenly dropped to 1.2
This evening while updating to the latest zip version(ironically improved spike protection for wmr200) I got a baro drop from 1021 to 997 hpa
WD wasn’t off for more than 5 mins.
The release note for build 22 says: “Improvements for data spike detection from irox/wmr100/200 stations”.
I did not bother installing it because it sounded to me like it’s going to dump some more perfectly good data
received from the WMR200 i.e. filtering out more bad data generated by WD.
Weather Stations with a USB/HID interfaces send their data in a buffer which can lead to split records
across buffers and multiple records in a single buffer. Until this is not handled correctly we are going
to sit with this problem forever.