Chris, I think that all barometric sensors reporting on Wunderground.com are supposed to be calibrated to sea level equivalent so the process of converting them to local pressure has been standardized. However, there is a request to add “Station pressure” to the wunderground API. Station pressure is the actual pressure at the site, not adjusted to sea level.
BTW, I think that Airport barometric pressure values are probably the most reliable because barometric pressure sensors usually have to be recalibrated every 6 months and the ones at airports are almost certainly recalibrated that often.
In fact, to maintain accuracy over more than a few months any personal weather device measuring pressure should be recalibrated against a standard at least that often, since calibration probably drifts faster than a professional device. For that purpose, a local airport pressure reading should be accurate enough if the site elevation difference is accounted for.
Actually, calibration of a sensing device like this is quite a valid point…
I used to be a Microlight pilot (Ultralight in USA) some years ago and my Altimeter was calibrated
every 12 months along with the Air Speed Indicator, in the UK this was an advisory rather than
mandatory for Microlights but for £50 you couldn’t go wrong. For a full blown PPL with a Cessna
152 I’m sure that things are a little more serious when it comes to calibration though along with
sensors used in control towers etc.
Using my Blue Astro Stickstation as an example for Astro imaging:
If the stick showed 15c but the actual temp was 12c it wouldn’t really be that catastrophic when it
comes to focusing, so long as when the outside temp dropped 1c, the Stickstation also drops 1c
SGP’s auto focus system would still run as expected.
On the other hand, if my Stickstation was actually ‘out’ by +6c above what the actual air temp was
at my location and SGP registers that temp has hit +3c and sends the notification the temp would
actually be +9c which would be a bogus call from SGP but obviously not SGP’s fault.
Calibration is obviously a good idea if you seek accuracy !
So with the Stickstation giving us Pressure, Temp and Humidity (dew point is obviously derived from
a formula), where could you send such a device which will have an environmental chamber of some
kind which could identify the required offsets for all three pieces of data to bring it into calibration
should someone decide to have this done ???
Calibration is tricky business. The sensor in the stick is a Bosch BME280, which has excellent relative accuracy and slightly worse absolute accuracy. The linearity is good, which what is needed for it to be able to perform with calibration. The BME280 has 16 calibration constants burned in from the factory, mostly dealing with linearity. Those are read from the sensor upon boot and used in the rather complicated code that produces the values.
I have a Vaisala PA-21 § that was calibrated two years ago, a Vaisala PA-11 § that was calibrated five years ago, a brand new Vaisala HMP-155 (T/H), a few Rotronic (T/H) devices and bunch of new calibrated PT-100 (T) sensors. I could theoretically calibrate the sticks at room temperature, but I do not. What I do is ensure that all readings are within +/- 1.5 hPa and +/- 1.5°C. If they are, then the sensor is OK (I haven’t found one that isn’t yet).
Then there is the thing about what to trust in terms of calibration. In my line of work (Arctic stuff) I am often asked why we do not use more than one weather service for weather data. The answer is simple: which one is correct? Do they want us to use the one that tells of the best conditions for the operation? How about three suppliers… Average? Best? The two that agree the most? The same is true for sensors: you need a truly qualified calibration authority with top notch references.
For Astro use, the most important thing is to get the changes. If you want to be more accurate it is either going to cost you a bunch of cash (the HMP-155 is over $1000). What can be said of most devices is that they are generally linear enough. If you have the difference between the temperature and the dew-point, that is what matters for dew formation. If it is one or two degrees off makes no difference. The same goes for focus changes.
Then there is the fun part about pressure. One meter of altitude difference comes out at 0.1 hPa Hence, a sensor in your ceiling will not agree with one on your desk.
Calibrate with sense, and do be careful with the readings from weather services or airports - they are not raw sensor data. Calibrate against something you trust so that your readings agree.
I’ve made a vario for my glider using a MS5611 pressure sensor, Arduino and LCD display. A metre change in height is easily enough to notice.
The display also gives altitude information - QFE, QNH and flight level. Also temperature.
Pressure is within a millibar or two but I’m more interested in rate of change. For official altitude I have a real clockwork altimeter but for anything important, such as planning the circuit, I look over the side to see how far away the ground is.
Yep, looking out the window is a good way. I have, on a few occasions, resorted to trusting a radio altimeter when forced to land in small clearings in sudden blizzards. Oh, the perils of Swedish weather and helicopter operations.
Now with the Observing Conditions interface we have all possibilities of using home-brewed Arduino projects in astro! I like that!
I have been out of the loop with regards to the ASCOM group. Did the decimal character thing with the OC interface get fixed?
I have had the pleasure of testing the 2.5 beta and can report that the OC interface works according to what it says on the tin. I have run it with a Stickstation only and also with the hub interface connected to the Stickstation and two other sources of information. Everything appears to work perfectly well.
For fun, and for testing my own ASCOM (local server) driver for the Stick, I also ran two instances of AGP 2.5, both connected to the same Stick. That too worked flawlessly.
As my driver uses passive queries for the data (the Stick delivers data every four seconds), there is a brief time (between 0 and 8 seconds) from connect to when it actually delivers data. This, of course, triggers SGP to issue warning of dew-point approaching temperature. Maybe SGP should hold on a bit before issuing trend warnings like that… I don’t want to throw exception until the data starts flowing.
Can you have the device return a ridiculous value? These can be filtered out and not trigger warnings. I might just take dialog warnings out all together and make this a notification system only feature. For some reason people hate being warned about stuff.
Thinking about this for a minute… I think I’ll try these changes:
Warnings will only be issued during the execution of a sequence.
Warnings will only be delivered through the notification system add-on (filtering is already built in here… no more settings to add)
Warning will never be delivered through pop-up dialogs (except during early betas so we we can more aggressively validate warning assumptions)
Warnings will only be issued if enough data has been collected to establish a trend (10-20 minutes maybe?).
The freeze warning will be with 5 degrees of 0 with a downward trend or if temperature is already below 0
The dew point warning will only be issued if temp is within 6 degrees of the dew point and has a downward trend or temp is already within 2 degrees of the dew point)
All pressure based warnings will be removed. They are too complex.
I am currently evaluating setting up a complete weather forecast operation for the high Arctic, so I have had some time to look through the options. The OWM service is based on the same principles as openstreetmap. In essence, this means that there is absolutely no guarantee as to what kind of sensors are used or how they are located. A test that we performed was to use the exact same type (and newly calibrated) sensors for temperature and humidity, placing one 3m from a wall and one 25m away from the wall. The difference was over one degree celsius. The same goes for wind and the rest of the values.
Between “stations”, a standard open source gridded model is used. For my location, the values for current data are off by 3-4°C, and the area map shows no local variation for several hundred km2 - all are stuck at -11°C for temperature, for instance. I know the local variations quite well and they should be at least 3°C for my general vicinity.
That said, I like the service. The forecasts are as good as anyone’s, except for the European Center which is much more accurate. It can definitely be used as a source for non-critical data, but things like temperature, absolute pressure and precipitation it cannot be used for - at least not here.
The unattended observatory requires two important sensors: cloud cover and precipitation. For that we are stock with Boltwoods, AAG Cloudwatchers and the likes.
I did the OWM driver really as a more interesting simulator than as a source of reliable data.
As Per says you need local rain and cloud detection at least, for safety reasons. Relying on a remote source is asking for trouble. It could be fine and clear there and pouring on your scope.
One thing, will the warning thresholds be adjustable by the user?
Per, I think that EVERY professional pressure sensor used for weather conditions is supposed to be calibrated to sea level. And you absolutely want that because it makes for an easy calculation of pressure just using the observers local elevation. The weather service or airport can be many miles away yet pressure will change very little except for the well known elevation adjustment. Since airports and weather stations are calibrated often they can be a great source for pressure (and temperature) values if they are not too far away.
Chris, I think you could use a local weather service for temperature/pressure values for refraction calculations, if the station is not too far away. However, as Per and Chris said, if you are relying on closing an observatory if it rains or becomes cloudy then local equipment would likely be needed.
If you are using temperature for focus adjustments, I think it is best to attach the temperature probe to the focuser or OTA to get an actual reading of the metal’s temperature, which usually lags local air temperature.
I guess what I’m saying is if I have a good weather station, how do I get my data to this driver and why can’t I use it as a safety device? I would put any of the prosumer weather stations up against astro specific devices. They just always lack a driver. If I could use a driver like that to pull a weather underground feed, problem solved.
What we need then is an ASCOM safety hub that can take non-safety data (in an ASCOM sense) as well as other safety data as input and where you can set conditions for safe/unsafe. That can definitely be done, and the only issue is defining a language or some principles for definition of unsafe.
Great discussion - one of the things I have noticed is that there is no one device that serves all the data - I have Per’s stick but it does not have wind or rain etc.
I’m linking several devices together to form a consensus on safety and imaging viability. Along the way I discovered that OPTEC have a beta ASCOM hub server that allows for multiple devices too. It’s a time-limited beta at the moment but seems to be effective and, unlike POTH / Generic Hubs, it is transparent to CommandString calls.
regards
Chris
ASCOM 6.2 has an Observing Conditions Hub that handles this. You select the hub in SGP and then in the hub setup select the device that provides that particular function.
So you could get the pressure, wind speed and direction from OpenWeatherMap and the temperature, humidity, cloud cover and rainfall from a Boltwood driver.
The application sees everything as if it came from one device.
Hence, a sensor in your ceiling will not agree with one on your desk.