Way back in part 1 of this project I mentioned that I got into a little spat with a software developer about bringing up a linux version of his code <link>? Well, I prowled around (a lot) in his forum and discovered that he really likes to talk. That's a good thing, a very good thing, and I certainly can't say anything bad, I've got what? 200 or so posts on various technical items on this blog, and a trail a mile wide across the internet, so something about glass houses comes to mind.
At any rate, I ran across this post of his where he discusses the barometric pressure reading from the AcuRite console <link>. The sensor is inexpensive, but it's a high sensitivity device and capable of measuring altitude to within 20cm if it is properly used. What does altitude have to do with barometric pressure? Everything.
I'm not going to go into the ins and outs of altitude vs temperature vs air pressure because there's entire sites devoted to this that will do a much better job of explaining it, except where it involves getting a reading worth using from the Acurite sensor in the console of my weather station. It's the last piece of weather information I want to grab from the station; I want battery level from the weather head, but that's not weather info. The rest of the stuff like rainfall this week, highest recorded temperature, those things can all be derived from the other data, and is a big piece of why I broke into the unit.
But, the barometric pressure still eludes me. So, here's what I've learned so far and I'm quite open to suggestions. The barometric sensor is: Measurement Specialities MS5607-02BA03 and here's its spec sheet PDF file <link> and the manufacturer's web page <link>. It's a very nice device that uses a piezo crystal to sense pressure. Since it's subject to temperature variance, it's read in the factory and calibration parameters are stored inside the chip. The idea is that the developer resets the chip, reads the calibration parameters and then applies them to the reading from the chip and comes out with an extremely accurate measurement for altitude. For a device in a fixed location, the altitude reading can be directly translated to atmospheric pressure. That would give you an extremely accurate barometer.
Getting back to the forum post above, it's pretty clear that AcuRite doesn't do this. They have some secret algorithm that is supposed to take the need for reading the calibration out by sampling readings for about a month to derive a value that will allow them to predict the weather more accurately for the console's location. Pardon me if I'm a bit skeptical about that. Weather forecasters have been trying to do that for centuries, and I hardly think AcuRite achieved the 'Holy Grail' of atmospheric science. I think they couldn't figure out how to work the chip and gave up and called marketing in for a story to cover up the problem.
Who wants to buy a barometer that you have to wait a month before the readings start making sense?
We don't need accuracy in the absolute reading, we need accuracy in the changing of the reading, and a linear response that we can calibrate and forget for a while. Remember the old physical barometers that our farmer grandparents had in the front room where you could check it on the way out the door to the barn? Those devices worked well. When you got them, you checked the local weather and set the reading to be the same by turning a screw on the back. Then you set a movable needle (ours was red) to point to the same reading. Then if the pressure went up (clear weather) you could tell because the needle moved up from the red one. Simple, and did the job nicely.
I logged the data from the R2 message (where the barometer is supposed to show up) for quite a while, but still haven't figured it out. In a fit of pique, I pulled the console apart to see if I could read the chip's markings:
In fact, the sensors used in these consoles aren't accurate; you can't expect to get an "accurate" barometric sensor for anything less than about $1,600. That's the reason your sensor is reporting over 40 inches of mercury; we adjust for the variations between sensors using the adjustment you were asked to do.But I don't buy that explanation. I've seen a bunch of gauges that cost far less than $1600, with specs that are pretty impressive, and this device claims accuracy to mere centimeters. Nope, it's simply that the data is not corrected using the burned in parameters that should be used.
So, given the various graphs provided by the manufacturer the device is relatively linear, just way off because the calibration hasn't been done, so how the heck do I find the pressure in the data? If I can get the pressure, then rely on the temperature inside a house to be relatively stable, we should be able to derive an offset that gives us a pretty reasonable value. Here's a small sample of the data sent in the R2 message.
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 07 47 E0
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 E0
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 DC
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 D9
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 03 47 D9
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 03 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 05 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 07 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 09 47 D6
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 09 47 D1
The reading on the console for the last line was 77 F and 30.09 in/Hg. Notice how only the last three bytes change? Actually though the last four bytes change. Heres the highest and lowest values sorted from the file I'm logging to:
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 8F DF 47 B0
02 00 00 80 00 00 00 00 00 04 00 10 00 00 00 09 60 01 01 01 01 90 3B 47 BB
Yes, the other values in the data do not change. It was reported on the forum that the calibration values were being sent, but this isn't the case I my examination. If these are calibration values, they don't resemble the items described by the manufacturer, nor do they make sense. So, we're left with the last four 8 bit values. The data supplied by the sensor is in 24 bit values, so these last bytes could not be all of the temperature and pressure. Since this is made in Europe, it's likely the data is in degrees C and mbar, and just looking at the four bytes as pressure, temperature, the last line of the first block could be, 0x9009 = 38873 which doesn't seem to be reasonable. It might be somewhat reasonable for in/Hg though as in 38.8 in/Hg; a bit high, but sort of there. I don't get much sense out of the other number 0x47d1 = 18385 either.
But notice that the second 16 bit number is roughly half the first number; it might be that the first number is a higher conversion from the A/D convertor than the second and both of them represent the same thing, just different settings on the A/D convertor. The chip supports this, so it's possible.
And remember, I can't compare the numbers to the reading on the front of the display since AcuRite is using some secret algorithm to compute that because their way is more accurate, meaningful, whatever...
The low pressure for the last 24 hours was 952 mbar (28.11 in/Hg) and the high was 956 (28.23) and from the graph I looked at the average was 954 (28.17), so suppose the first 16 bit number was the pressure reading (uncompensated) and I just took a 24 hour average to see what came up, a change of 23 in the number would be a 1 millibar change in pressure. If I just go with the average of 954 and consider the mean of my high and low reading 36877 and bump it up by one tenth for every 2.3 change in the number, to see what happens:
Hmm, I could hook a BMP180 up to an Arduino, get both the temperature and barometric pressure from it, send it through an XBee to my Pi controller and replace the configuration I have outside in the Stephenson screen. That would actually be a cool project.