"its trying to get the average barometer reading over a period of weeks
to then work out the altitude…
that will work if over those weeks a series of highs and lows pass through but overall the barometer reading is near average (1013 for sea level)
but if you are stuck under a high…"
That is the exact point I made on their forums. Their answer was that they had tested it in their atmospheric test chamber and that they were confident it would work under most conditions. They did admit that resetting the console when the pressure was near 1013 mb would likely result in the most accurate calibration.
Fortunately I saw in another thread over there that the unit sends out the baro reading over the usb connection in raw format and doesn’t attempt to provide any altitude compensation so once they send you the SDK and you get support up and running in WD it won’t be too much of an issue any longer. Curiously, their MBW server which receives the uncompensated for baro reading from the device runs its own altitude compensation averaging and comes up with different values from the software running inside of the console. For example I reset the console 2 days ago when the barometric pressure was at 1013 and after only 2 days the console is reading 1.3 millibars lower than the value displayed on the MBW server.
Maybe the problem is that the pressure sensor component they are using is inaccurate, so they are forced to travel this long and winding road to get it calibrated/compensated?
Maybe the problem is that the pressure sensor component they are using is inaccurate, so they are forced to travel this long and winding road to get it calibrated/compensated?
Actually aside from the calibration issues, I have found the pressure sensor to be very accurate as compared to the data on WU from a Davis vantage view located about 2 miles away and to the data from my Oregon Scientific station. For example once it had miscalibrated itself to being 6 mb too low it tracked pressure changes from the other stations very closely pretty much always being 6 mb too low. In fact all the sensors seem to give pretty accurate readings when compared in this way.
I reset my console yesterday, and today it is running about 0.15 inches/mercury higher than my Oregon Scientific unit and about 0.20 inches/mercury higher than the local ASOS about 5 miles away. Other than the pressure, I have been fairly happy with the other readings coming out of the unit. They are all within tolerance of other stations in the area.
I agree that the MBW software is very very limited and not user-friendly, and I’m glad that Brian will be providing support through Weather Display. I think the low-cost and seemingly good quality will make these stations popular. By the way, I have received emails indicating that neither Cumulus nor VWS will be supporting these stations.
Well the latest from them is that they have still not finished writing the documentation for the SDK and hope to finish it next week. So another week goes by.
Hey Brian, Jeff at acurite says you have everything you need now to begin work on adding support for the acurite 5 in 1 sensor based models. Is that true? Let me know if you want someone to test a new build with support for those stations.
Hi
I do have the data protocol info now, yes
and I am expecting a sample station to turn up in the post any day now
so that I can then work on adding support
I downloaded and installed the beta version linked to above but ran into an issue.
Once WD initialized it starts generating exception errors. The errors continue until I used task manager to shut down the acurite.exe program contained in the beta package. The text in the exception alert box is:
Exception: Unable to find an entry point named HidD_GetInputReport in Dll hid.dll
Module: Hid
Method: HidD_GetInputReport
I was using a beta version of acurite’s PC Connect I am testing for them so I uninstalled it and re-installed the old version which is still posted on their website however I didn’t see any difference in the exception errors. The PC Connect program is successfully relaying data to their My Backyard Weather website. Interestingly the data quality and data received boxes are lit green in WD and the temperature data appears to be the correct value. The humidity data is displayed but it is 20% lower than the value displayed on the station console. I am running in USB mode 4. The system I am running on is an old dell dimension with a 2.2 Ghz celeron and 2 gigs of memory running XP. It was just a cheap box I bought specifically to host WD and my station. All service packs and updates installed.
After I closed the acurite.exe program in order to stop the flood of exception alerts WD called reboot.exe after about 10 minutes. The WD program error log contains these lines which seem pertinent. (note the one about TED access error is repeated several times more than shown here)
TED access error 10060: [10060] Connection timed out
Above error or program log occured at :5:56 pm 01/10/12
ERROR: Access violation at address 01875071 in module ‘WeatherD.exe’. Read of address 00000000 at time/date 6:06 pm 01/10/12
Above error or program log occured at :6:06 pm 01/10/12
ERROR: Access violation at address 01875071 in module ‘WeatherD.exe’. Read of address 00000000 at time/date 6:06 pm 01/10/12
Above error or program log occured at :6:06 pm 01/10/12
ERROR: Access violation at address 01875071 in module ‘WeatherD.exe’. Read of address 00000000 at time/date 6:06 pm 01/10/12
Above error or program log occured at :6:06 pm 01/10/12
There was nothing of interest in the windows event log
Let me know if I can gather any more data for you.
I would suggest that you do not have the needed version of .NET installed
make sure you have .NET 4.0 or later
as for the TED errors in WD, that will be due to the setup you have done for the energy detective, in the misc setup, and WD could not get an internet connection
I believe I did have the 4.0 version of the .Net framework installed but when I checked the windows update optional installs there was an update for 4.0. However as I was installing the update I noted that the installation stalled until I stopped the acurite weather service. After the installation finished, I rebooted and now the acurite service won’t run.
I fiddled around a bit tonight with no luck getting it running so I switched the station usb back to its temporary host computer (a high end win 7 machine with a big hungry power supply) which still had the acurite software installed on it. It is getting late here so I am going to leave any more investigation and mitigation until tomorrow. Will let you know if installing that optional update did the trick once I get that acurite service running again. Probably will need to uninstall, clean out the registry and anything else left behind and then do a clean install of their software.
OK, sorted
the hid.dll included with the WD install is too old
so, exit WD, then delete that file
(so that the newer version in the windows system folder is used instead)
you will not need the service running for WD to work
there is lots of reports of people having trouble with the service stopping and not being able to be restarted on the acurite support site
Too bad I didn’t come back and check sooner - after an epic struggle I got the service running again, but the best news of all is that after deleting that HID.dll file WD is working with the Acurite station — WooooooooHoooooooooooooooo!!!
let me know how WD goes
I have one report that the separate acurite reader is loosing the USB device after a short period of time
I have not found that problem here
I did get one erroraneous rain reading here in testing ,so I will have to add some checks to make sure the data is as expected
I am losing the connection to the console as well. I have WD set to reboot the machine if it lose connection but it seems to only re-acquire the device if it is unplugged from the USB port before WD is started. The acurite data reader does show the correct state of the connection with no device detected displayed when it does lose the connection.
One other thing I’ve noted is that it seems like the barometric reading does not seem to use the QFE barometer even if the box for it is checked.
We are having snow today, however the forecast calls for warming temps today and an eventual change over to rain so I should be able to get some rainfall data once that happens.
Also someone has posted a solution that seems to be working for everyone for the service stopping issue. Turns out that it is caused (at least on XP machines) because the service spews a lot of text into the windows application event view log. The services stops once the log is full and it can’t spew more text into it. You can adjust the maximum allowed log file size by opening the windows event viewer, right click on the application log, then select properties - 8 megs is the recommended log file size and you can also select the checkbox for overwriting the oldest entries when the file gets full. That seems to solve the issue for everyone.
