This work is essentially done… SGPro calls these things “Environment Devices”, but six of one…
The question now really stems from what to do with it (meaning for the first release… not that I have no ideas as to what we can / will use some of this data for in the future). This is what I am thinking right now:
Allow the Environment device to provide (override) temperature measurement for auto focus triggers. When overriding, any temperature coming from the focus controller would be ignored in favor of your Environment Device’s temperature.
Create a new “docking module” that displays all the information your device provides (think of the Image Statistics module). The information here would be “Now” type data, where “Now” means that it will comply with the defined “averaging period”, or if there is none, just the reading straight off the device (this is really handles by the device itself, just writing it for clarity).
Allow for collection of data while it is connected (in or out of a sequence) and provide a means to dump it to a CSV file for analysis. Disconnecting the device will wipe out the data history.
Write available data to the image’s FITS headers
We will likely rip out the graphs that were part of the TEMPerHUM release (I never liked them anyhow and they are, honestly, not of much use…). Then after the initial release (as defined above) start considering what a real environment dashboard might look like… graphs, trends, real-time analysis and input into a running sequence, etc. I think the first step is just to get it into SGPro and the equipment profiles even if the functionality is somewhat limited.
Hi Ken,
I have one of those BlueAstro Stickstation’s which gives only Temp, Dew point and pressure.
Now I’m no meteorologist but…
If the data coming in appears to ‘Predict’ that dew formation is possible or getting more likely then
maybe a new alert option can be added to the notifications module options so it can send a message
to your phone informing that dew formation is likely, maybe a user could set a threshold S G Pro can
react to.
Also, constantly tumbling air pressure could indicate that the weather may be deteriorating which might
make cloud formation more likely, reason to get out there & take stock of the situation especially for user
who don’t have a permanent setup.
Also, if the Temp drops to the +3 degree’s threshold, this is when ice ‘Can’ begin to form, again this
could serve as a great opportunity to pop out & check things are still going ok.
Certainly helpful alerts for anyone who sets up & goes inside to get warm would be a major plus.
New docking module sounds great especially if you can bring up a ‘Details’ box which can show the
trend lines like the Stickstation’s software does. Maybe the docking module could show trend arrows
next to each data element with an UP, Down and right pointing arrow graphic which gives the user a
quick & dirty way of annualizing what each thing is doing, confirmed obviously by the detailed graph.
I also think an option to override my Moonlite focusers temp sensor and use the Stickstation’s temp
figure would be great idea too, the Moonlite temp sensor is not really that good to be honest.
That might not be such a good idea. For a focuser what is important is the temperature of the metal it’s made of, because that expands/contracts, causing the focus shifts. OTA/focuser temperature usually lags local air temperature, so you probably don’t want to use the external air temperature. If you were to attach a more accurate sensor directly to the focuser and also the OTA and somehow use both (or average them) then that might work better. The exact focus shift is probably a complex formula based on the materials changing dimensions, temperature differentials, and time.
However, for refraction calculations you do not necessarily want local temperature because the atmosphere changes a few tens of feet above the ground. I think a better source for refraction calculations might be a local airport or professional calibrated weather instrument not close to human bodies. computers, mounts/telescopes giving off heat. I think there is an ObservingConditions driver that can use data from nearby weather stations.
Local devices might be useful for detecting clouds, rain, etc. but if you are going that route I think you should consider a Boltwood cloud sensor or similar astronomy-specific device.
Well my Moonlites temp sensor is on the end of a wire which sits within a couple of inches of the
focuser body, short of some complicated electronics to do what your suggesting I think this is the
best im going to get. Anyway, the metalwork contraction does lag behind the actual temp around it,
all im trying to do is get a more responsive temp change which the Stickstation appears to give, the
moonlite one takes quite a while to respond. When I first connect to the controller (ambient temp is
at approx. 20c) the sensor registers around 11c in SGP slowly rising until about 5 mins later is will
settle around the 20’ish temp.
My Stick is mounted below any of the workings on the mount so as heat rises it wont be affecting the
stick. If a temp drop of 1 degree is detected by the sensor then SG will decide if a change in focuser
position is required by running the autofocus routine, this will take into consideration any shrinkage
in the imaging train (at least once SGP works better with a Newtonian’s central obstruction) and
SGP will respond accordingly IF it is required.
I cant see how using a station miles away will be of benefit in my back yard, the conditions there could
be vastly different from outside my home although I do see your point.
You might be surprised that often there are local users contributing calibrated sensor data in your area. Does your sensor come with a calibration report? It might not be critical for delta changes in temperature, but if you are using it for refraction calculations it might.
Second, the temperature near the ground is almost always a few degrees, sometimes up to 10 degrees warmer than the most influential part of the atmosphere (30-40 ft and up) when it comes to refraction calculations.It helps using a sensor collecting temperatures away from the ground and massive objects like telescopes and mounts cooling down (BTW, heat radiates downward too!).
BTW, I’m not “arm-chair guessing” the above statements. I’ve done many experiments over several years fitting atmospheric data to measured refraction results.And I’ve had a half dozen different sensors at the same time all reporting different temperatures.
I think this is a cool idea, but I am unsure how to quantify “dew is about to form”. Does that mean a notification sent when the temperature comes within 5 degrees, 3 degrees of dew point? Not sure here and I am not really looking to add a whole new slew of options (for instance, letting a user define this threshold… seems simple, but there are probably a dozen or more for which this one user definable parameter will define precedence). If we agree on a number, then we can do that.
This one is good and can be added.
Initially this will not be available. This is what I was referring to in the future as the environment dashboard. Initial capabilities will allow you to export history to CSV.
I think most of the scientific papers published around refraction in astronomy clearly stipulate that the very local temperature and pressure values in the scope vicinity are the ones to be used in the different formulas that the established mount modeling softwares use. Absolute values are most likely less important than relative ones, so most sensors that can display a relative accuracy are likely good enough.
Pressure values are difficult to simply absorb from different sources. Most sensors perform some kind of compensation (QFE, QFF, QNH etc) and do not report raw, for altitude uncompensated, values. The formulas for refraction expect 800 hPa in Santa Fe, New Mexico, not 1010, so using altitude compensated values from airports will just throw things off.
Focusers… Even if metal temperature lags ambient temperature, that lag is easily compensated for in software, so using an ambient sensor should be quite OK if a dampening factor is introduced.
In conclusion, I think the ASCOM Observing Conditions interface is a step in the right direction. The readings can be used for many purposes, like dew avoidance, focus compensation, atmospheric refraction and most likely more. Having SGP support for this is great!
My tests don’t seem to agree with that. If you have links to those studies I would be happy to read them to see what might be different from my analysis. From years of fitting data to me there seems to be only a fractional component from the local environment. If I had the time I probably could publish a paper myself on that topic.
Now I would agree that atmospheric SEEING quality is affected mostly in the local area, just not the refractive index of the miles of air through which a telescope is pointing.
As for the professional sensors in observatories and airports, they have to be calibrated (federal guidelines), at least here in the USA and are likely more accurate than any consumer device unless said device has been calibrated by a calibration center. At about 10 meters off the ground pressure and temperature do not usually change very rapidly.
About focusers, I think you way oversimplifying things with a “dampening factor”. I don’t want to get into a long explanation of all the potential variables, but the effects are measurable and not always simple to calculate and predict. Again, if I had time I could write a paper, but I would rather write software.
Yes, I too would like to write papers, but we all suffer from the constant lack of time, don’t we?
When it comes to refraction, I found a really good paper on this from Her Majesty’s Nautical Almanac Office in good old England. It is one of the best and most understandable ones I have seen and references a number of other works on the subject. A good read, and a piece that has relevance for us astro amateurs. For everyone’s pleasure I have a copy on my personal file server, available at http://filer.frejvall.se/Refraction.pdf. Any SGP user wondering why they have to plate solve at lower pointing elevations (high zenith angles) should print a copy to digest while sipping the Christmas toddy
Users who do use refraction compensation in some form should be advised that most of the stuff out there requires the ambient pressure data to be free of altitude compensation, or needs to know whether it should be de-compensated for altitude compensation. Let’s close this technical distraction by illustrating this:
Any aviation-oriented reading, like a TAF or METAR, uses QNH, which is what you set in your altimeter. QNH is compensated for the altitude of the reading and makes your aircraft altimeter read the real elevation of the airfield when you are at its geographic reference point. It is also truncated down to an integer so that you can safely assume that it doesn’t show the runway lower that it actually is, which could cause you to land to hard or fly into the terrain (CFITS - Controlled Flight Into Terrain - love that term!). QNH is difficult to use for astro refraction calculations.
Any “standard” weather station and all weather reports will usually show 1013.25 hPa (29.92 in/Hg) on a standard day. This is what it would be at sea level. If you’re at 1000’ altitude, the true pressure is only 977 hPa, which if not compensated for will throw off refraction by 4" at 30° elevation and over an arc-minute close to the horizon. An that is at only 300m elevation. At my remote observatory in southern France, the altitude is 930m (3050’), and the weather station still reports 1013.25 hPa - which should be 906 hPa. The displacements here would be 11" at 30° and 3.5 arc-minutes closer to the horizon. Using a standard weather station or weather report without compensating for your altitude is bad for astronomy.
I apologize for this excursion, but I do find this very interesting.
For the focuser temp compensation, it is merely a guess on my account, and not something I need to explore.
Ken, I associate with at least five sharp meteorologists regularly, and one or two on a daily basis. If you want to do some dew warning stuff I am all ears on finding out when it will form, both theoretically and practically. It would be a nice feature of SGP, I think.
I had some interesting stuff happen with my first scope, a black livery Skywatcher 250P, which dewed up pretty badly. One of my meteorologist friends asked me about the color and then suggested that I insulate the tube. I did, and that moved the dew formation point positively to a point where the dewpoint was almost touching the temperature. Black tube radiating its heat to the vast universe making the air inside much cooler and the hence closer to the dewpoint.
The more automated we get, the more we benefit from getting everything straight regarding the meteorological side of things!
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.
