Wrong results from sealevel variables

[cgn]

I have meteohub data from my WMR200 since 2009/12.
The monthly averages of press (sealevel) are as followed (in file thb0-month1):

2009-12 1007,8
2010-01 1013,3
2010-02 999,8
2010-03 1011,2
2010-04 1018,0
2010-05 1013,6
2010-06 1016,2
2010-07 1015,2
2010-08 1012,6
2010-09 1014,4
2010-10 1014,7
2010-11 1009,6
2010-12 1017,3
2011-01 1022,2
2011-02 1018,8
2011-03 1021,4
2011-04 1016,8
2011-05 1017,5
2011-06 1016,1
2011-07 1013,4
2011-08 1013,3
2011-09 1020,0
2011-10 1019,3

The average of 2010 is 1013,0 and of 2011 (1-10) is 1017,8
The average sealevel of 2011-11 till now is 1018,8.

But the variable "alltime_thb0_sealevel_hpa" returns 1020.3
and the variable "year1_thb0_sealevel_hpa" returns 1020.3 too, both are wrong!

What is the reason?

meteohub version is 4.8g
Recomputation was done.

Version 4.6k which I had till last week showed the same effect.

[admin]

did you change the weather station during that period?

does "press" report correct values?
Did you choose "height plus th0 temperature" as sea-level calculation method?
could you please post your "sensors" page, to allow me to see how "th0" is mapped?

[cgn]

I didn't change the station.
"Press" reports the same values because the baro correction is an offset in meteohub settings (since 2010-10).
I don't use an offset in the console.
Sea-level calculation is "aus der Wetterstation verwenden".

The values of sealevel (year1 and alltime) are increasing very quickly now, they are now 1020.6 (from 1020.3 yesterday).
All values are here: http://koelnerwetter.de/meteohub/all-sensors.txt

[admin]

Please try update 4.8h and do a recomputation.

[cgn]

Update to 4.8h is done and recomputation is running ...

[cgn]

No change after recomputation.

But in meteohub log there are errors noticed:
loggereval (20.11.2011 00:22:04): illegal data record in line 134547 while reading from file /data/weather/201109/raw: 20110906032226 (>100 entries like this with the same date).
Some entries of them are:
loggereval (20.11.2011 00:22:04): illegal data record in line 134548 while reading from file /data/weather/201109/raw: "�L��@���

In the raw data file are a lot of entries from wind0 with the same time and two lines with wrong data:

20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032223 wind0 202 12 7 0144
20110906032226 wind0 202 12 7 0144
20110906032226 wind0 202 12 7 0144
20110906032226 wind0 202 12 7 0144
20110906032226 wind0 202 12 7 0144
20110906032226 wind0 202 12 7 0144
20110906032226 wind0 202 12 7 0144
20110906032226_r"�L��@���20110906032226 wind0 202 12 7 0144
20110906032226 wind0 202 12 � � �� 20110906032233 thb0 218 36 0061 10150 1 10150
20110906032233 rain0 0 0 536
20110906032233 th0 144 59 0065
20110906032233 thb0 218 36 0061 10150 1 10150
20110906032243 thb0 218 36 0061 10150 1 10150
20110906032247 wind0 202 15 9 0144
20110906032253 thb0 218 36 0061 10150 1 10150
20110906032301 data0 336
20110906032301 data1 177314000

Could this cause the wrong averages of press?

I think I should delete these lines and do a recomputation.

[admin]

You have a corrupted file or file system. 99% this happens when USB stick or SD card has worn out.
Most typical for a NSLU2 with failing USB stick. Are you using a SLC based flash media as recommended?

You might try to cleanup the data with corresponding function on "inspect data" page and should switch to a new flash media.

Unless this is fxed, recomputations will not succeed at all.

[cgn]

I have a sheeva-plug with a new SD-card (6 days old!), it's a Sandisk Extreme Pro 8 GB 45 MB/s. Is this card ok?
I had the problem that nowhere is mentioned if a card runs with SLC or not. How can I see it?
Old card was a 4 GB SanDisk Extreme III "30 MB/s Edition". It didn't work after last update.

Now I looked to the backup data from the old sd-card.
There were the corrupted data too, so I had imported corrupt data from my old card to the new.

I have deleted the part of corrupted data with a hex-editor and started a recomputation.
When it is finished I give a message.

[cgn]

Recomputation was done, but press/sealevel for alltime and year1 is still at 1020.6 hPa

In meteohub log is shown:

wmr928fulleval(20.11.2011 20:19:25): recomputation of weather data finished: 15631710 records processed in 20928 seconds (746 records per second)
logger (20.11.2011 21:25:25): parent process received termination signal (15).
logger (20.11.2011 21:25:25): child process received termination signal (15).
logger (20.11.2011 21:25:30): data logger (version 4.8h, build 890) started.
logger (20.11.2011 21:25:30): connect station 0 (WMR-200 via USB HID).
logger (20.11.2011 21:25:30): connect station 1 (System Data via Plug-in).
logger (20.11.2011 21:25:59): parent process received termination signal (15).
logger (20.11.2011 21:25:59): child process received termination signal (15).
logger (20.11.2011 21:26:00): disconnect station 0 (WMR-200).
logger (20.11.2011 21:26:00): disconnect station 1 (System Data).
logger (20.11.2011 21:26:01): data logger stopped.
logger (20.11.2011 21:26:05): data logger (version 4.8h, build 890) started.
logger (20.11.2011 21:26:06): connect station 0 (WMR-200 via USB HID).
logger (20.11.2011 21:26:06): connect station 1 (System Data via Plug-in).
logger (20.11.2011 21:27:17): station 0 (WMR-200), wrong checksum (2100 vs computed 2221) for sensor model d7 in byte sequence: d7 d7 10 1b 15 14 0b 0b 00 c2 00 21 1e 00 00 42 02 d9 08 00 00 00 00 e1 00 d7 10 1c 15 14 0b 0b 00 c2 00 21 1e 00 00 43 02 d3 10 1c 15 14 0b 0b 0b 0c 00 00 00 00 20 75 01 d3 10 1c 15 14 0b 0b 0b 0c 00 00 00 00 20 75 01 d7 10 1c 15 14 0b 0b 81 33 00 55 1e 00 00 69 02 d7 10 1c 15 14 0b 0b 00 c2 00 21 1e 00 00 43 02 d4 16 1c 15 14 0b 0b 00 00 00 00 00 00 11 00 00 0c 01 01 07 6b 01 d3 10 1c 15 14 0b 0b 0b 0c 00 00 00 00 20 75 01 d7 10 1c 15 14 0b 0b 00 c2 00 21 1e 00 00 43 02 d7 10 1c 15 14 0b 0b 00 c2 00 21 1e 00 00 43 02 d3 10 1c 15 14 0b 0b 0b 0c 00 00 00 00 20 75 01 d6 0d 1c 15 14 0b 0b f7 63 f7 33 c2 03 d7 10 1c 15 14 0b 0b 00 c2 00 21
logger (20.11.2011 21:27:47): station 0 (WMR-200), wrong checksum (000b vs computed 0281) for sensor model d3 in byte sequence: d3 10 1c 15 14 0b 0b 0b d7 10 1d 15 14 0b 0b 00
logger (20.11.2011 21:28:45): station 0 (WMR-200), wrong checksum (0c0b vs computed 027f) for sensor model d3 in byte sequence: d3 10 1d 15 14 0b 0b d3 10 1e 15 14 0b 0b 0b 0c

Are there any errors in the last 3 lines (wrong checksum)?
What else can I do?

[cgn]

Update:

I found the record which caused the wrong checksum.
Record deleted, new recomputation: no errors logged, but still press/sealevel averages of 1020.6 hPa.

[cgn]

The results of press/sealevel in year1 and alltime are still wrong.

I deleted all data before 2011/07, so only 2011/01 to 2011/11 are calculated.

month values are:
2011-07 1013,4
2011-08 1013,3
2011-09 1020,0
2011-10 1019,3
2011-11 1021,6

year1_thb0_sealevel_hPa and alltime_thb0_sealevel_hPa give 1021,7 which is too high (more than the highest month value).
The average of these 5 months is only 1017,5 hPa.

All values you can see here: http://koelnerwetter.de/meteohub/all-sensors.txt

[admin]

Looks like something very special on your system. As you are suffering from corrupted data caused by a defective USB stick, it might be a bit tricky to find the error hidden somewhere in your data.

Can you please give me access (ports 7777 and 22, please).

[admin]

Thanks for giving me login details.

Your station does send indoor temp and pressure data very often (10 times my station does), so that a lot of 1/10 hpa values (9600 to 10500) have to be summed up for average value computation. Looks like this results for longer periods (year, alltime) into a 4 byte integer overrun. I changed to 8 byte integers and results on your system seem to look ok now. Please check. If this fixes it, it will also be part of the next official update. As it only affects "aggregated" data a recomputation run, which is automatically initiated after the next update, will fix it for all users.

Thanks for finding out this hidden issue.

[cgn]

The results for year and alltime are ok now.

Thanks for your help!