[weewx-development] Pressure resolution and BMP280

[Craig Thom]

I'm working an a RPi SPI service to read a BMP280.

The BMP280 can produce 16 to 20 bit values for pressure, depending on how 
it's configured.  With the default 16 bits it says it is accurate to within 
2.62 Pa.

That's a lot finer resolution than anything I've seen reported.  Is weewx 
going to use the extra data going from 2.62 Pa to 0.16 Pa accuracy, or is 
it just going to be rounded off?

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

Thanks. In the MySQL database it's a double, so the resolution is there.

My weewx is using American measures and putting inHg in the database. Do i need 
to convert from Pascals before handing the data back?

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

My goal is to use the existing SDR driver and to use a service to read the 
pressure from the BMP280 and add it to the data the SDR driver is collecting.

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

Perfect. Thanks.

[weewx-development] Re: Pressure resolution and BMP280

[Craig Thom]

Thanks.  I may take you up on that if I can't get it to work.  I've done 
enough work that I want to try it myself first.

I get my sensor tomorrow, but I've been learning and playing and writing 
with Python today.  I wrote and tested the calibration code, using the 
sample data on the data sheet, and I get the right answers!  That's a lot 
of calculation, and it was great of them to provide test data and 
intermediate answers so I could make sure my code was working.  

I want to use the SPI interface, and everybody else is using i2c,  I am 
also going to try running it in Normal rather than Forced mode, since that 
allows the filter to work better and still uses power in the microamps.  

On Sunday, April 2, 2017 at 2:02:53 PM UTC-4, py4...@gmail.com wrote:
>
> I have already integrated bmp280 and si7021 with my weewx weather station.
>
> Code is based upon a piece of code I have found on  
> https://www.controleverything.com/ 
> 
>
> I can share the code if you want it.
>
>
>
>

[weewx-development] Re: Pressure resolution and BMP280

[Craig Thom]

I have given up on trying to use the SPI interface with my own code.  It 
works using code I found using pigpio, but, ultimately, I decided to just 
use the i2c interface and branch the i2c pins to allow my RTC to keep 
working.

It works using i2c and the Adafruit software.  This weekends project, 
assuming I don't get called out for work, is to write a service.  I've been 
reading through the service examples (in particular the Alarm and 
Electricity ones), and I think I've got a grip on the concept.

On Sunday, April 2, 2017 at 2:02:53 PM UTC-4, py4...@gmail.com wrote:
>
> I have already integrated bmp280 and si7021 with my weewx weather station.
>
> Code is based upon a piece of code I have found on  
> https://www.controleverything.com/
>
> I can share the code if you want it.
>
>
>
>

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

I know I saw, somewhere, a way to call an existing weewx method to convert 
units to whatever is needed, but I can't find it again.  It may have been 
in a service in the Wiki rather than in the documentation, because I can't 
find it there.

Is there such a thing? 

I didn't like how limited the Adafruit program was and the dependencies, so 
I have fixed my first ever Python program to read the sensor.  I'm ready to 
turn it into a service, with the options in weewx.conf and everything.  I 
think.

Anyway, I'd like to use the weewx conversion if necessary and possible.

On Saturday, April 1, 2017 at 5:38:31 PM UTC-4, mwall wrote:
>
> On Saturday, April 1, 2017 at 5:29:16 PM UTC-4, Craig Thom wrote:
>>
>> My goal is to use the existing SDR driver and to use a service to read 
>> the pressure from the BMP280 and add it to the data the SDR driver is 
>> collecting.
>
>
> craig,
>
> handling the units in a service is slightly different that in a driver.
>
> in the driver, you can specify the unit system of the packet to match the 
> units from the sensors (assuming they all emit values in the same unit 
> system).
>
> in a service, you must work with whatever unit system you find in the 
> packet.
>
> so be sure to check the value of usUnits, then convert your sensor value 
> (if necessary) to be in units that are appropriate for the unit system 
> specified by usUnits.
>
> m 
>

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

I want to convert from the native Pa and °C to whatever the user has configured 
weewx to use when I add to either the LOOP or archive data.

I'll check there. Thanks.

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

Thanks.  I found that in units.py and was reading the comments about the 
value tuples.  I assumed that the "target units" was whatever was defined 
in weewx.conf.

I am new to Python and objects, really, since it's been over twenty years 
since I wrote anything.  What it looks like to me, for the service, is that 
weewx is going to create an instance of the class I define in the service 
file and call the function that's bound to my chosen event, right?

And if I go with NEW_LOOP_PACKET rather than NEW_ARCHIVE_RECORD, do I still 
need to make sure it gets included in the archive record, or will that 
happen automatically?  Or do I bind to both?

Thanks for your help.  I'll try not to ask too many question.  

On Thursday, April 6, 2017 at 9:52:06 PM UTC-4, Tom Keffer wrote:
>
> Function weewx.units.convertStd() is what you want. For example, to 
> convert from Celsius to whatever unit system the LOOP packet is using:
>
> new_valueTuple = weewx.units.convertStd((22.5, "degree_C", 
> "group_temperature"), packet['usUnits'])
>
>
> If you haven't run into them yet, read up about "ValueTuples 
> <https://github.com/weewx/weewx/blob/v3.7.1/bin/weewx/units.py#L412>". 
> They are used throughout the unit system.
>
> -tk
>
> On Thu, Apr 6, 2017 at 3:54 PM, Craig Thom  > wrote:
>
>> I want to convert from the native Pa and °C to whatever the user has 
>> configured weewx to use when I add to either the LOOP or archive data.
>>
>> I'll check there. Thanks.
>
>
>

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

OK, just so I'm understanding this.  This starts at the bottom of the 
__init__.  col_press and col_temp are strings read from my [BMP280] section 
of weewx.conf that contain where the data should go, like "barometer" and 
"extraTemp1".  And I divide the corrected pressure by 100 because it's in 
Pascals, which are 100 mbar/hPa.

self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)


def new_loop_packet(self, event)


sensor_init()
raw_pres, raw_temp = read_raw_data()
pres_Pa, temp_C = calibrate_raw_data(raw_pres, raw_temp)

pres_tuple = weewx.units.convertStd((pres_Pa/100, "mbar", 
"group_pressure"), packet['usUnits'])
temp_tuple = weewx.units.convertStd((temp_C, "degree_C", 
"group_temperature"), packet['usUnits'])

event.record[col_pres] = pres_tuple.value
event.record[col_temp] = temp_tuple.value




On Friday, April 7, 2017 at 9:11:02 AM UTC-4, Tom Keffer wrote:
>
> I am new to Python and objects, really, since it's been over twenty years 
>> since I wrote anything.  What it looks like to me, for the service, is that 
>> weewx is going to create an instance of the class I define in the service 
>> file and call the function that's bound to my chosen event, right?
>>
>>
> ​That's correct.​
>
>  
>
>> And if I go with NEW_LOOP_PACKET rather than NEW_ARCHIVE_RECORD, do I 
>> still need to make sure it gets included in the archive record, or will 
>> that happen automatically?  Or do I bind to both?
>>
>
> Just add your new observations to the LOOP packet. 
>
> LOOP packets are compiled by the "accumulators". They keep track of mins, 
> maxes, sums, and counts. These are then used to turn the stream of LOOP 
> packets into archive records.
>
> What actually happens depends on whether the user is using software or 
> hardware record generation. If software, at the end of an archive interval, 
> all the observation types are extracted out of the accumulators and turned 
> into an archive record. If hardware, the actual archive record comes from 
> the console, however, starting with v3.7.0, this record gets augmented by 
> any additional types that can be extracted out of the accumulators. So, 
> your new types will get included that way.
>
> Either way, if it's in the LOOP packet, you're good.
>
> -tk
>
>

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

The data is sitting in six registers and I'm just reading it out, so there 
won't be a delay.  

The longest it should take to get a sample, with maximum resolution and 
filtering, according to the data sheet, is under 50ms.  The delay (in 
normal mode) between samples is configurable, but only up to 4 seconds, and 
it won't delay the function; I'll just be reading old data.  I will be 
running at 62.5 ms between samples (kicking the power consumption up to 
almost a tenth of a milliamp).

On Friday, April 7, 2017 at 9:56:59 PM UTC-4, Tom Keffer wrote:
>
> That looks right. At least in theory. :-)
>
> One thing I should note, and maybe you have already done this, but the 
> main weewx loop will block when it hits read_raw_data(). You need to make 
> sure it doesn't delay things too long. A second or two is fine, but you 
> don't want to be waiting half a minute for new data. If there's any chance 
> of this, you'll need to either figure out how to include a timeout inside 
> read_raw_data(), or do the data acquisition in a separate thread.
>
> -tk
>
>
>
> On Fri, Apr 7, 2017 at 6:37 PM, Craig Thom  > wrote:
>
>> OK, just so I'm understanding this.  This starts at the bottom of the 
>> __init__.  col_press and col_temp are strings read from my [BMP280] section 
>> of weewx.conf that contain where the data should go, like "barometer" and 
>> "extraTemp1".  And I divide the corrected pressure by 100 because it's in 
>> Pascals, which are 100 mbar/hPa.
>>
>> self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)
>>
>>
>> def new_loop_packet(self, event)
>>
>>
>> sensor_init()
>> raw_pres, raw_temp = read_raw_data()
>> pres_Pa, temp_C = calibrate_raw_data(raw_pres, raw_temp)
>> 
>> pres_tuple = weewx.units.convertStd((pres_Pa/100, "mbar", 
>> "group_pressure"), packet['usUnits'])
>> temp_tuple = weewx.units.convertStd((temp_C, "degree_C", 
>> "group_temperature"), packet['usUnits'])
>> 
>> event.record[col_pres] = pres_tuple.value
>> event.record[col_temp] = temp_tuple.value
>>
>>
>>
>>
>> On Friday, April 7, 2017 at 9:11:02 AM UTC-4, Tom Keffer wrote:
>>>
>>> I am new to Python and objects, really, since it's been over twenty 
>>>> years since I wrote anything.  What it looks like to me, for the service, 
>>>> is that weewx is going to create an instance of the class I define in the 
>>>> service file and call the function that's bound to my chosen event, right?
>>>>
>>>>
>>> ​That's correct.​
>>>
>>>  
>>>
>>>> And if I go with NEW_LOOP_PACKET rather than NEW_ARCHIVE_RECORD, do I 
>>>> still need to make sure it gets included in the archive record, or will 
>>>> that happen automatically?  Or do I bind to both?
>>>>
>>>
>>> Just add your new observations to the LOOP packet. 
>>>
>>> LOOP packets are compiled by the "accumulators". They keep track of 
>>> mins, maxes, sums, and counts. These are then used to turn the stream of 
>>> LOOP packets into archive records.
>>>
>>> What actually happens depends on whether the user is using software or 
>>> hardware record generation. If software, at the end of an archive interval, 
>>> all the observation types are extracted out of the accumulators and turned 
>>> into an archive record. If hardware, the actual archive record comes from 
>>> the console, however, starting with v3.7.0, this record gets augmented by 
>>> any additional types that can be extracted out of the accumulators. So, 
>>> your new types will get included that way.
>>>
>>> Either way, if it's in the LOOP packet, you're good.
>>>
>>> -tk
>>>
>>>
>

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

  counter = counter + 1
dig_T1 = calibration_data[0] + (calibration_data[1] << 8)
dig_T2 = self.to_signed(calibration_data[2] + (calibration_data[3] 
<< 8))
dig_T3 = self.to_signed(calibration_data[4] + (calibration_data[5] 
<< 8))
dig_P1 = calibration_data[6] + (calibration_data[7] << 8)
dig_P2 = self.to_signed(calibration_data[8] + (calibration_data[9] 
<< 8))
dig_P3 = self.to_signed(calibration_data[10] + (calibration_data[11] 
<< 8))
dig_P4 = self.to_signed(calibration_data[12] + (calibration_data[13] 
<< 8))
dig_P5 = self.to_signed(calibration_data[14] + (calibration_data[15] 
<< 8))
dig_P6 = self.to_signed(calibration_data[16] + (calibration_data[17] 
<< 8))
dig_P7 = self.to_signed(calibration_data[18] + (calibration_data[19] 
<< 8))
dig_P8 = self.to_signed(calibration_data[20] + (calibration_data[21] 
<< 8))
dig_P9 = self.to_signed(calibration_data[22] + (calibration_data[23] 
<< 8))



# calibration formulae from data sheet


var1 = (raw_temperature/16384.0 - dig_T1/1024.0) * dig_T2
var2 = ((raw_temperature/131072.0 - dig_T1/8192.0) *
(raw_temperature/131072.0 - dig_T1/8192.0)) * dig_T3
t_fine = var1 + var2
T = (var1 + var2)/5120.0


var1 = t_fine/2.0 - 64000.0
var2 = var1 * var1 * dig_P6 / 32768.0
var2 = var2 + (var1 * dig_P5 * 2.0)
var2 = (var2/4.0)+(dig_P4 * 65536.0)
var1 = ((dig_P3 * var1 * var1 / 524288.0) + (dig_P2 * var1))/ 
524288.0
var1 = (1.0 + var1/32768.0) * dig_P1
p = 1048576.0 - raw_pressure
p = (p - (var2/4096.0)) * 6250.0 / var1
var1 = dig_P9 * p * p / 2147483648.0
var2 = p * dig_P8 / 32768.0
p = p + (var1 + var2 + dig_P7) /16.0


return p, T


 
This goes in weewx.conf

[BMP280]
col_temp = extraTemp1
col_pres = barometer
pressure_oversampling = 4
temperature_oversampling = 2
filter = 2
sample_delay = 1
i2c_channel = 1
i2c_device = 119
mode = 3




On Friday, April 7, 2017 at 10:19:14 PM UTC-4, Craig Thom wrote:
>
> The data is sitting in six registers and I'm just reading it out, so there 
> won't be a delay.  
>
> The longest it should take to get a sample, with maximum resolution and 
> filtering, according to the data sheet, is under 50ms.  The delay (in 
> normal mode) between samples is configurable, but only up to 4 seconds, and 
> it won't delay the function; I'll just be reading old data.  I will be 
> running at 62.5 ms between samples (kicking the power consumption up to 
> almost a tenth of a milliamp).
>
> On Friday, April 7, 2017 at 9:56:59 PM UTC-4, Tom Keffer wrote:
>>
>> That looks right. At least in theory. :-)
>>
>> One thing I should note, and maybe you have already done this, but the 
>> main weewx loop will block when it hits read_raw_data(). You need to make 
>> sure it doesn't delay things too long. A second or two is fine, but you 
>> don't want to be waiting half a minute for new data. If there's any chance 
>> of this, you'll need to either figure out how to include a timeout inside 
>> read_raw_data(), or do the data acquisition in a separate thread.
>>
>> -tk
>>
>>
>>
>> On Fri, Apr 7, 2017 at 6:37 PM, Craig Thom  wrote:
>>
>>> OK, just so I'm understanding this.  This starts at the bottom of the 
>>> __init__.  col_press and col_temp are strings read from my [BMP280] section 
>>> of weewx.conf that contain where the data should go, like "barometer" and 
>>> "extraTemp1".  And I divide the corrected pressure by 100 because it's in 
>>> Pascals, which are 100 mbar/hPa.
>>>
>>> self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)
>>>
>>>
>>> def new_loop_packet(self, event)
>>>
>>>
>>> sensor_init()
>>> raw_pres, raw_temp = read_raw_data()
>>> pres_Pa, temp_C = calibrate_raw_data(raw_pres, raw_temp)
>>> 
>>> pres_tuple = weewx.units.convertStd((pres_Pa/100, "mbar", 
>>> "group_pressure"), packet['usUnits'])
>>> temp_tuple = weewx.units.convertStd((temp_C, "degree_C", 
>>> "group_temperature"), packet['usUnits'])
>>> 
>>> event.record[col_pres] = pres_tuple.value
>>> event.record[col_temp] = temp_tuple.value
>>>
>>>
>>>
>>>
>>> On Friday, April 7, 2017 at 9:11:02 AM UTC-4, Tom Keffer wrote:
>>>>
>&g

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

OK, take two.  It works after some tweaking.  This is my first program in 
twenty-five years and first in Python ever, so I'm sure it's ugly.  But it 
works.

This goes into weewx.conf


[BMP280]
col_temp = extraTemp1
col_pres = barometer
pressure_oversampling = 4
temperature_oversampling = 2
filter = 2
sample_delay = 1
i2c_channel = 1
i2c_device = 119
mode = 3




On Friday, April 7, 2017 at 9:56:59 PM UTC-4, Tom Keffer wrote:
>
> That looks right. At least in theory. :-)
>
> One thing I should note, and maybe you have already done this, but the 
> main weewx loop will block when it hits read_raw_data(). You need to make 
> sure it doesn't delay things too long. A second or two is fine, but you 
> don't want to be waiting half a minute for new data. If there's any chance 
> of this, you'll need to either figure out how to include a timeout inside 
> read_raw_data(), or do the data acquisition in a separate thread.
>
> -tk
>
>
>
> On Fri, Apr 7, 2017 at 6:37 PM, Craig Thom  > wrote:
>
>> OK, just so I'm understanding this.  This starts at the bottom of the 
>> __init__.  col_press and col_temp are strings read from my [BMP280] section 
>> of weewx.conf that contain where the data should go, like "barometer" and 
>> "extraTemp1".  And I divide the corrected pressure by 100 because it's in 
>> Pascals, which are 100 mbar/hPa.
>>
>> self.bind(weewx.NEW_LOOP_PACKET, self.new_loop_packet)
>>
>>
>> def new_loop_packet(self, event)
>>
>>
>> sensor_init()
>> raw_pres, raw_temp = read_raw_data()
>> pres_Pa, temp_C = calibrate_raw_data(raw_pres, raw_temp)
>> 
>> pres_tuple = weewx.units.convertStd((pres_Pa/100, "mbar", 
>> "group_pressure"), packet['usUnits'])
>> temp_tuple = weewx.units.convertStd((temp_C, "degree_C", 
>> "group_temperature"), packet['usUnits'])
>> 
>> event.record[col_pres] = pres_tuple.value
>> event.record[col_temp] = temp_tuple.value
>>
>>
>>
>>
>> On Friday, April 7, 2017 at 9:11:02 AM UTC-4, Tom Keffer wrote:
>>>
>>> I am new to Python and objects, really, since it's been over twenty 
>>>> years since I wrote anything.  What it looks like to me, for the service, 
>>>> is that weewx is going to create an instance of the class I define in the 
>>>> service file and call the function that's bound to my chosen event, right?
>>>>
>>>>
>>> ​That's correct.​
>>>
>>>  
>>>
>>>> And if I go with NEW_LOOP_PACKET rather than NEW_ARCHIVE_RECORD, do I 
>>>> still need to make sure it gets included in the archive record, or will 
>>>> that happen automatically?  Or do I bind to both?
>>>>
>>>
>>> Just add your new observations to the LOOP packet. 
>>>
>>> LOOP packets are compiled by the "accumulators". They keep track of 
>>> mins, maxes, sums, and counts. These are then used to turn the stream of 
>>> LOOP packets into archive records.
>>>
>>> What actually happens depends on whether the user is using software or 
>>> hardware record generation. If software, at the end of an archive interval, 
>>> all the observation types are extracted out of the accumulators and turned 
>>> into an archive record. If hardware, the actual archive record comes from 
>>> the console, however, starting with v3.7.0, this record gets augmented by 
>>> any additional types that can be extracted out of the accumulators. So, 
>>> your new types will get included that way.
>>>
>>> Either way, if it's in the LOOP packet, you're good.
>>>
>>> -tk
>>>
>>>
>import time
import smbus
import syslog
import weewx
from weewx.engine import StdService

# Inherit from the base class StdService:
class bmp(StdService):

   
def __init__(self, engine, config_dict):
# Pass the initialization information on to my superclass:
super(bmp, self).__init__(engine, config_dict)

self.col_temp= config_dict['BMP280']['col_temp']
self.col_pres   = config_dict['BMP280']['col_pres']
self.osrs_p   = int(config_dict['BMP280']['pressure_oversampling'])
self.osrs_t   = int(config_dict['BMP280']['temperature_oversampling'])
self.filter  = int(config_dict[

Re: [weewx-development] Pressure resolution and BMP280

[Craig Thom]

col_pres should be "pressure. I read that part of the weewx documentation, but 
I didn't remember it right.

The pressure from the BMP280 does not take elevation into account.

Re: [weewx-development] Update problems

[Craig Thom]

I think Weather Underground is having problems right now.

I am not missing an upload, seeing

 weewx[4581]: restx: Wunderground-PWS: Published record 2017-04-09 14:00:00 
EDT (1491760800)



every five minutes, as I should, but Weather Underground is going sometimes 
10-15 minutes between updates.

The only change I've made to weewx today is tweaking my elevation in 
weewx.conf.  Compared to the last few days, that's nothing.

On Sunday, April 9, 2017 at 12:56:20 PM UTC-4, shane turner wrote:
>
> Lil more data now... 
>
> On Apr 9, 2017 12:54 PM, "shane turner" > 
> wrote:
>
>> Getting a lot of nones... 
>>
>> On Apr 9, 2017 12:51 PM, "Thomas Keffer" > 
>> wrote:
>>
>>> try
>>>
>>> sudo weewxd /etc/weewx/weewx.conf
>>>
>>>
>>> -tk
>>>
>>> On Sun, Apr 9, 2017 at 9:32 AM, shane turner >> > wrote:
>>>

 Tried real-time.. Getting weird stuff...? 

 On Apr 9, 2017 12:06 PM, "Thomas Keffer" >>> > wrote:

> If you run weewx directly 
>  from the 
> command line it will print out exactly what data it is receiving from 
> your 
> console. It should match what you're seeing in the display.
>
> -tk
>
> On Sun, Apr 9, 2017 at 8:54 AM, shane turner  > wrote:
>
>> Thanks for looking at log.  My data on acurite display says 79 
>> degrees and it's reporting 75 to the 2 sites... Timing issue? Is it 
>> posting 
>> delayed data?
>
>
>
>>>

Re: [weewx-development] Update problems

[Craig Thom]

In addition, Weather Underground is also showing my temperature 3 degrees 
warmer on its map that it shows on my station display.

I think we should wait a day or two to see if they straighten it out.

On Sunday, April 9, 2017 at 2:08:41 PM UTC-4, Craig Thom wrote:
>
> I think Weather Underground is having problems right now.
>
> I am not missing an upload, seeing
>
>  weewx[4581]: restx: Wunderground-PWS: Published record 2017-04-09 14:00:
> 00 EDT (1491760800)
>
>
>
> every five minutes, as I should, but Weather Underground is going 
> sometimes 10-15 minutes between updates.
>
> The only change I've made to weewx today is tweaking my elevation in 
> weewx.conf.  Compared to the last few days, that's nothing.
>
> On Sunday, April 9, 2017 at 12:56:20 PM UTC-4, shane turner wrote:
>>
>> Lil more data now... 
>>
>> On Apr 9, 2017 12:54 PM, "shane turner"  wrote:
>>
>>> Getting a lot of nones... 
>>>
>>> On Apr 9, 2017 12:51 PM, "Thomas Keffer"  wrote:
>>>
>>>> try
>>>>
>>>> sudo weewxd /etc/weewx/weewx.conf
>>>>
>>>>
>>>> -tk
>>>>
>>>> On Sun, Apr 9, 2017 at 9:32 AM, shane turner  wrote:
>>>>
>>>>>
>>>>> Tried real-time.. Getting weird stuff...? 
>>>>>
>>>>> On Apr 9, 2017 12:06 PM, "Thomas Keffer"  wrote:
>>>>>
>>>>>> If you run weewx directly 
>>>>>> <http://weewx.com/docs/usersguide.htm#Running_directly> from the 
>>>>>> command line it will print out exactly what data it is receiving from 
>>>>>> your 
>>>>>> console. It should match what you're seeing in the display.
>>>>>>
>>>>>> -tk
>>>>>>
>>>>>> On Sun, Apr 9, 2017 at 8:54 AM, shane turner  
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for looking at log.  My data on acurite display says 79 
>>>>>>> degrees and it's reporting 75 to the 2 sites... Timing issue? Is it 
>>>>>>> posting 
>>>>>>> delayed data?
>>>>>>
>>>>>>
>>>>>>
>>>>