zedoude / wfrog

Automatically exported from code.google.com/p/wfrog
GNU General Public License v3.0
0 stars 0 forks source link

problem reading Outside Temperature values #137

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Hi,
I'm using the trunk version of wfrog code 
(https://code.google.com/p/wfrog/source/browse/trunk/wfdriver/station/vantagepro
2.py) on OpenWRT OS for logging on a DB values from my Davis Vantage Pro2 
station.
The only modifications I have made to the code concern adding the DB logging.

After some observation time, I have noticed that, when I use the 'LOOP' command 
for requesting the last values (in my case 25), I record some incorrect values 
for Outside Temperature.
In particular, the wrong value is always the same, and is displayed in decimal 
as 1802.61°C.
In general, I log some bursts of such records, in a number from one to six 
wrong records, about every ten minutes. After the burst, it keeps on recording 
right.
The values I read pass correctly the CRC control, so I assume it is not a 
problem due to the serial communication.

I have tried to log the raw strings and to search manually the bytes giving the 
wrong values. When I come to the 2 bytes concerning TempOut, I read FF7F, which 
corresponds to 1802.61.

The following 2 rows contain the raw strings I read: the first one presents the 
problem (ff7f in TempOut field), the second one is ok (b402).

4c4f4f0000 b104 0e75 0203 31 ff7f 
ffffff7fffffffffffffffffffffffffffffffffffffffffffffffffffffff7f0000ffff00000000
470d00000000a308ffffffffffffff0000000000000000000000000000000000002803062d890243
070a0d fa42

4c4f4f0000 b104 0e75 0203 31 b402 
ffffff7fffffffffffffffffffffffffffffff43ffffffffffffff00001e93010000ffff00000000
470d00000000a308ffffffffffffff0000000000000000000000000000000000002803062d890243
070a0d e720

Hope this is enough information to help me fixing the problem.
Thanks in advance,

Luca

Original issue reported on code.google.com by lucapil...@gmail.com on 18 Sep 2013 at 3:19

Attachments:

GoogleCodeExporter commented 9 years ago
Hi,
Thanks for reporting the problem. It is indeed strange. 

I assume that you have a datalogger attached to the Davis Station (serial or 
USB?). I wrote the driver but do not have a datalogger. I have a direct cable 
hack. The protocol is supposed to be the same with or without the datalogger.

I'll take a look at the raw strings.

Original comment by jordi.pu...@gmail.com on 19 Sep 2013 at 9:02

GoogleCodeExporter commented 9 years ago

Original comment by jordi.pu...@gmail.com on 19 Sep 2013 at 9:02

GoogleCodeExporter commented 9 years ago
The raw strings seem ok. I mean, the CRC is good and the other fields seem Ok.

Could you check the VantagePro console for errors?. I remember there is a way 
to check all errors directly on the console. It could be a sensor error which 
is being sent as is (the LOOP command sends data as it comes, not from the 
datalogger).

Original comment by jordi.pu...@gmail.com on 19 Sep 2013 at 9:20

GoogleCodeExporter commented 9 years ago
Hi,
thank you for your reply.
Yes, I have a serial data-logger but I don't have the VantagePro console. I 
only use the weather station connected to the data logger. 
Maybe this is useful: I have also checked with Davis Weatherlink software if 
there were the same issues, but it seems not to record such values (e.g. it 
shows average values, but also max and min are stored, so I guess they would be 
written in these fields in case of values out of range coming from the weather 
station).

Original comment by lucapil...@gmail.com on 23 Sep 2013 at 1:33

GoogleCodeExporter commented 9 years ago
Hi,

I've checked Davis documentation and I think I found the answer: 0x7FFF and 
0xFF indicate that the corresponding sensor has invalid data. Check page 38 of 
the following document:

http://www.davisnet.com/support/weather/downloads/software_dllsdk.asp
http://www.davisnet.com/support/weather/download/VantageSerialProtocolDocs_v261.
pdf

IMO WeatherLink just ignores these values. 

I'll leave the issue open so that when time allows, something is done when 
these values are received. Of course, any contribution is welcome!

Jordi.

Original comment by jordi.pu...@gmail.com on 23 Sep 2013 at 1:55