extraTemp and extraHumid precision

[GCC Observatory]

Greetings group,

Just joined with what I hope will be a simple question.  I purchased an additional temperature and humidity sensor for my Vantage Pro and have the sensors reporting just fine in weewx.  But, I'm confused as to why the data for temperature is only showing to the nearest integer unlike the temperature from my main sensor.  I checked all my config files and see no reason why the temperature from the second sensor shouldn't be reporting to one decimal precision.  Is this a limitation of the hardware?

[vince]

On Monday, June 17, 2019 at 1:09:30 PM UTC-7, GCC Observatory wrote:

Just joined with what I hope will be a simple question.  I purchased an additional temperature and humidity sensor for my Vantage Pro and have the sensors reporting just fine in weewx.  But, I'm confused as to why the data for temperature is only showing to the nearest integer unlike the temperature from my main sensor.  I checked all my config files and see no reason why the temperature from the second sensor shouldn't be reporting to one decimal precision.  Is this a limitation of the hardware?

Impossible to answer from your minimal problem description.

What is in your database for those elements ?  What is in your LOOP packets for those elements ?

[GCC Observatory]

My database is showing both extraTemp1 and extraHumid1 with 1 decimal place precision, but it appears the values are rounded to the nearest integer.  For example, the temperature increases from 78.0 to 79.0.  The loop packets show the same thing.

[gjr80]

Hi,

My understanding is that extra temperature sensors only provide 1 degree Fahrenheit resolution on the console and that is what is passed onto WeeWX. WeeWX users who display or record Celsius may see data to the right of the decimal point but this is simply the result of conversion of integer Fahrenheit values.

Easily found on various forums but couldn’t easily put my finger on the authoritative Davis documentation, though I think this one covers it: https://www.davisinstruments.com/product_documents/weather/spec_sheets/6380_spec.pdf

Gary

[GCC Observatory]

Hi Gary,

Thanks for the information - makes sense and it would appear that I'm stuck with 1 degree resolution.

[vince]

On Monday, June 17, 2019 at 2:44:33 PM UTC-7, GCC Observatory wrote:

My database is showing both extraTemp1 and extraHumid1 with 1 decimal place precision, but it appears the values are rounded to the nearest integer.  For example, the temperature increases from 78.0 to 79.0.  The loop packets show the same thing.

ok, that makes sense. It wasn't clear what specific kind of sensors you were referring to in your original question.  Sounds like you hit a limitation in the Davis sensors (odd to have that limitation, eh).

 

[gjr80]

Should have remembered to look at the Davis Serial Communications Reference Manual. Extra temperatures in loop packets are covered at page 22, with whole degrees F clearly stated (note the 90 degree F offset and 1 byte field size per sensor compared to 2 bytes for outside temperature). Archive records are covered at pages 32 (rev A) and 33 (rev B) and whilst not stated as whole degrees, the fact the data is stored in a single byte with a 90 degree F offset (same as loop packets) means the extra temperatures in the archive records are also whole degrees F.

I thought I had read something somewhere (not from Davis) about a way around this, can't recall where or what though - may have been dreaming. Maybe an odd limitation but who knows what constraints/backwards compatibility issues Davis may have been working under. May have been just not enough bytes/bits to go around in a fixed length message format.

Gary