Saturday, February 14, 2015

Acurite Console Barometer: OK, This is it.

Back in a previous post I tried to decode the barometer reading from the AcuRite console.  I just couldn't get it, but one of the readers, Play Kube, stepped up and nailed it for us. The post is here <link> and his findings are down in the comments.  He emailed them to me and I posted them for him. Then I added code to my stuff and recorded the readings for a few days and this is the correlation to my (very accurate) fence post barometer. I spent quite a bit of time making sure my barometer compared to the weather stations around me and it was dead on.  The decoded AcuRite readings follow mine really, really well.  Take a look:

Isn't that great?  There's a couple of caveats though: The console barometer is NOT temperature or altitude corrected.  That's because we don't have access to the temperature or altitude corrections that the chip manufacturer supplies inside the chip. These values can be read and the math applied to get the reading dead on, but we don't have them to work with.

The way I corrected the readings was to simply adjust the algorithm to compensate.  This means that if I move the console up or down by a significant amount (I move to sea level) or the temperature changes (put it in the sun) the readings will change.  However, in most of our houses the temperature stays pretty stable and it's unlikely we'll be moving soon.  If one of these does happen, just readjust the algorithm and you'll be all set for the next time.

Looking at the chart, the difference in the readings is less than a mbar and tracks exactly.  Here's the code I used to decode the reading:

                    float bar = 6.23 * (R2[23] << 8 | R2[24]) - 20402;
                    weatherData.barometer = bar / 100; // convert to mbar from pascals
                    weatherData.barometer += 81.1; //adjust for altitude

It's a simple linear equation like a line graph from high school algebra.  Take the last two bytes and form a single number from them, then use a slope of 6.23 and an offset of -20402.  This will get you the barometric pressure reading if you were at the same altitude and temperature as the person that figured it out. So, to adjust it to your location, just go look up the barometric pressure reading for your location at the same time and add the difference in.  That's what the 81.1 number above means, I just added it in as the last step. The changes will be in GitHub soon.

Don't think this is too simple a solution.  The manufacturer of the chip put a lot of work into getting the sensor to follow pressure changes, then they put the adjustments for temperature and fixed altitude in the chip so they can be read and applied.  There was a lot of work done to get it to work. The trick was to get the slope correct, then the offset was just the method of getting it to line up vertically.  The altitude offset is simply necessary to adjust for the specific location.

Slick, but remember, change altitude or temperature and you may have to revisit the algorithm and change the values. We owe this discovery to Play Kube for sending me the mail a few days ago.

I still haven't found the battery level from the weather head though.


  1. This is pretty close to what I figured out for weewx (scaling for mbar included in the slope):

    p = 0.062424282478109 * d1 - 206.48350164881

    where d1 = ( R2[23] << 8 | R2[24] )

    I had a correlation factor of > 0.99 with a handful of manual readings from a calibrated pressure gauge (absolute pressure, not barometric).

    I calculated something similar for inside temperature:

    t = 0.049538214503151 * d2 - 1801.189704931

    where d2 = ( R2[21] << 8 | R2[22] )

    I might borrow your constants and see how close it looks.

    1. And you didn't tell me ???

      The level of precision you're using is way too much, there's a lot more error in there than the number of digits to the right of the decimal you're using. And, I could get the correlation even closer by using a successive approximation to get the best offset and slope, but it isn't necessary.

      What's needed is a good reading so that the up or down trend can be established for a reliable weather change indicator.

      Remember to keep the console at a relatively stable temperature.

      Now, when I have the time I may try out the temperature formula you gave me. Once again, it's an academic exercise for me since I have temperature sensors in place already and am building more.

      Thanks for the update, We still need the battery level of the weather head though.

    2. I tried to reply to the earlier post a couple of times, but nothing happened, so I moved on :)

      The precision is from a linear best fit based on 24 sampling points. It has a very high correlation factor, so I don't want to arbitrarily remove precision. However, with your much larger dataset, maybe we could come up with a better fit and more confidence in the significant digits.

    3. I used this calculator to find the best fit after using a spreadsheet to determine that it was indeed linear:

    4. That is an absolutely awesome calculator, it could have saved me a ton of time on various projects over the years.

      I pretty much just dumped the console barometer data I collected. Once I saw it was within a fraction a a mbar, I called it good and moved on to something else. If I'm within a fraction and all I'm really interested in is the trend over the last hours, that's good enough. Especially since I keep my doors open and a breeze through the house will change it more than that due to temperature,

      Although, it could be possible to decode the temperature, and factor it into the reading. But then we're trying to overcome the shortcomings of the console with an approximation.

      The data set for a couple of days is still up on Xively, but getting it back could be a pain. If you want it, I will give it a try and pass it on. The data comes back to me as a JSON string in multiple parts that have to be taken apart and combined.

    5. Pressure remained linear across significantly different indoor and outdoor temperatures, leading me to believe that the values reported should be interpreted as absolute pressure. I let weewx take care of calculating the barometric pressure from that and my altitude, although I had to add a fixed fudge factor to that value to align with NWS.

    6. Did you take the console outside? I didn't try that, since it was plugged into the raspberry pi and I would have had to cart it and an extension cord.

    7. No, it was inside at all times. I meant to imply that a) the outside temperature has no effect, so the reading is not already compensated for air density, b) the inside temperature has no effect, so the reading is already compensated for the sensor's intrinsic temperature sensitivity, therefor the reading can be relied upon as an absolute pressure, and software should apply altitude and barometric calculations.

  2. Hi,
    I have an acurite wx station here in Brazil and I have been trying to figure out how the forecast algorithm works.
    Since I don't understand anything about hardware/software like you guys I have been trying a "rudimentary" approach which is to make time lapses movies of the display and then try to figure how the icons respond to the various changes in the parameter readings.
    I was wondering if you think it is possible and if you tried to analise directly the code which rules the forecasting algorithm.

    1. I haven't looked at the forecast algorithm, but for me, it's always wrong. That's a substantial thing here in Arizona where it's sunny 340 days a year.

    2. Dave,
      I live in a transition zone between subtropical and temperate climate.
      I found the algorithm performance to be satisfactory, except in summer, when it constantly predicts rain in the middle of sunny dry spells.
      I understand this is because a simple glitch in the rule, which makes it too sensitive for small pressure changes. I imagine this must ruin the whole forecast in a location where dry spells are the rule.

  3. Great work Dave! Been playing and tweaking with your stuff for a few weeks now.

    The libusb kicked my tail. For my Pi, I did need to:
    - Add a file to "/etc/" called it, stupidLibusb.conf
    - Added a line "/usr/local/lib" to it (only line)
    - Ran ldconfig to grab the new conf file and it worked.

    Also, looking at your getweather.c program, it looks like it's missing a "#include " so it can take advantage of the memcpy.

    1. I used the -I and -L parameters to the compiler to do the same thing. Also, it depends on the compiler version what includes are needed, I just happened not not need one for memcpy. Otherwise, it wouldn't have compiled and I would have had to add it.