Per, I hate to be a stickler for details but are you sure it isn’t a copyright violation to put that paper on your personal server? I would prefer a direct link to the paper on an official server. Or, better yet, a specific quote from that paper that supports what I think you said about the localized temperature around a telescope setup being the major factor in the refraction calculations (and hopefully the reasoning why).
Again I ask because my analysis of refraction data over several years of clear nights doesn’t seem to support that notion. The important temperature seems to be the ambient temperature about 10 meters above ground level and away from any structures emitting heat.
I think the end user usually doesn’t have to deal directly with pressure. That’s a problem for us software guys to solve given that we know the source of the pressure measurement (and I think in most cases we do).
Provided site elevation does not change significantly atmospheric pressure usually does not change very rapidly as you move away from a location, so getting the pressure from a site miles away at a similar elevation is usually well within the error tolerance of the refraction equations. Plus it’s cheaper for the user as they don’t have to necessarily buy an expensive weather station.
So, where I think refraction calculations usually go wrong is by using the wrong temperature. From my tests I was getting better fits to refraction by using temperature from a calibrated thermometer far away from my setup. If I attached the thermometer anywhere near the telescope it would sometimes show warmer than ambient by up 5 or more degrees Fahrenheit. As expected the delta temperature would usually minimize as the evening went on.
The other thing I noticed is that temperature values would vary between devices, so unless the device has been calibrated the temperature could be wrong by a few degrees. IMO localized (i.e., around a telescope setup) temperature devices do not provide the most accurate temperature for refraction calculations. Those type of sensor devices are best utilized for differential temperature measurements for focus adjustments.
For refraction calcs I think data from a calibrated weather station away is best. But there is not always a need to buy one because luckily there are usually many nearby in urban locations (where many amateurs image). For instance, check out:
So, all one needs is an ObservingConditions driver to access that weather site.
Let’s just drop this discussion. We have different opinions, simple as that, and we have not been able to agree on anything yet. Let’s spare the good folks around SGP this.
Thanks. The first pass will come out with a warning to users with the notification module that temperature have come within 5 degrees of the dew point. This doesn’t need to be super scientific, just early enough for you to do something.
Per, OK, no problem. But, my opinion is based on several years of analysis of environmental and refraction data. I haven’t seen any papers contrary to my findings yet, but if you find some I would absolutely be willing to read them.
And I’m sure we agree on many things. There’s just usually no point in discussing those things.
This is pretty much ready for beta (coming shortly)…
Changes you can expect:
A new “Environment Device” drop down menu on the sequencer window (with all the other hardware)
Removal of the TEMPerHUM specific graphs (to be replaced by a better dashboard later)
Removal of the “Look for TEMPerHUM devices” in the options dialog
Addition of TEMPerHUM to the Environment Device list (temporary entry until a better, more stable ASCOM driver is produced for TEMPer devices)
Addition of a new floating dock window that displays all of the data your environment device is capable of collecting. In addition to this… after about a minute or so, these items will start to display trend arrows (up, down, stable) based on a simple moving average methods.
Warning when your device reports you are within 3 degrees of freezing (not super useful unless you have the notification system, but a pop-up dialog will display)
Warning when your device reports you are within 5 degrees of the dew point (not super useful unless you have the notification system, but a pop-up dialog will display)
Warning when your device reports a rise in pressure of 2 hPa in 1 hr (strong wind predictor) (not super useful unless you have the notification system, but a pop-up dialog will display)
Warning when your device reports a drop in pressure of 1.2 hPa in 1 hour and the pressure is less than 1009 hPa (rain predictor) (not super useful unless you have the notification system, but a pop-up dialog will display)
The ability to use your environment device’s temperature input for auto focus triggers. There is some debate over this (see above), but this is not a new feature in SGPro… it’s been there for a while, it was just specific to TEMPerHUM before now.
The ability to dump your device’s readings to a CSV file for analysis later. Note that your device’s reading history will be deleted, if the device is disconnected or SGPro is shut down.
Static warning are pretty easy to code in… if you have any other warnings you think might be useful, let me know (by useful, I mean a reading that provides information that can influence a user’s actions (like turning on a dew heater, etc… general info is OK too, just won’t be classified as a warning)
More to come in later builds… this is just the initial implementation.
I wonder if the air pressure tests (i.e. strong wind and rain predictor) need to take into account the site altitude to establish expected nominal pressure and pressure gradient. You seem to have static values that might only be applicable at sea level.
Me too. I am no meteorologist… I made sure to throw my assumptions out in my post so they can be challenged by people who might know better. I “think” my assumptions for wind and rain prediction are valid only at sea level (and I am unsure of how to alter them by altitude).
The ASCOM OpenWeatherMap driver has a Site Elevation setup property. This is used, with the pressure data from a local weather station (which is assumed to be sea level pressure), to get the pressure at the observer’s altitude using an algorithm provided by Per.
You are at the mercy of the local weather station - as reported by OWM - and I’ve no idea if this reports current sea level pressure or not. Aviation sites may tend to report the pressure lower than it actually is because they are more interested in people having adequate separation from the ground. The Regional QNH will be reported as the lowest forecast pressure in the altimeter setting region.
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.
Hence, a sensor in your ceiling will not agree with one on your desk.