We had previously committed to implementing support for weather type devices like BlueAstro Stick Station in 2.5. We were going to start with this one, but alas, have decided not to spend our time here on implementation of specific devices.
With the official release of ASCOM 6.2, we will instead spend that time implementing the new “ObservingConditions” interface. This is tech speak for saying that we will be supporting ASCOM devices that report on environmental conditions. This means that someone (hopefully its manufacturer) will write an ASCOM driver that conforms their device to this interface (talk to your device manufacturer about writing an ASCOM driver for their stuff). So… this means that folks can write an ASCOM driver for TEMPer devices, TEMPerHUM devices, BlueStick AstroStation, etc… SGPro will support them all if they conform.
What does this mean in SGPro? That’s a good question. Initial implementation will:
Allow you to use the device’s temperature reading to trigger focus (and allow you to use this device instead of the focus controller’s thermistor)
Allow for graphing and logging of temperature (and other conditions) over the sequence… for instance, image history will tell you the time, HFR, focus pos and temperature from this device.
SGPro 2.5 will probably also see the official removal of TEMPerHUM devices from the code base (we will likely wait until the appropriate TEMPerHUM ASCOM driver is written before we do so…).
There are tons of other uses for this info… please feel free to request them if you see a use for them.
I was in the “committee” designing the observing conditions interface for ASCOM 6.2 and will crank out a driver for the Stickstation real soon, hopefully within 10 days from now.
There is a simulator in the 6.2 release, so Ken and his team can dive right into implementing this in SGP at once.
Per - I have one of your sticks and it is great - do the new ASCOM definitions allow for something like SGP to connect to your device, for temp, humidity and pressure and at the same time, something like the AAG cloudwatcher, for rain, clouds etc… or is there a distinction in that one is environment and the other is ‘safe to operate’?
There’s an ObservatoryConditions hub that can merge data from multiple ObservatoryConditions devices.
I’m not sure if there is an ObservingConditions to Safety interface but there’s nothing to stop one being written.
The way I see this happening is that ASCOM provides an interface, then driver and application developers have something they can use to create all sorts of good things.
What’s needed is more people who are prepared to put write things that can fit into ASCOM. The ASCOM inner core can’t do everything.
Anyone interested in testing the ASCOM 6.2 Observing Conditions interface can now download an initial test driver from the Blue Astro web site (http://blueastro.se). Currently, it requires exclusive access to the Stickstation device, but as soon as I have confirmed it works OK I will implement a local server version and add ASCOM support to the Windows Application. At that time, the Windows Application will connect to the Stick via ASCOM, and the ASCOM driver will allow multiple clients to connect.
As for the principles of observing conditions devices, I can confirm that there is support directly in the ASCOM 6.2 platform for merging serveral devices’ data into one client connection (observing conditions hub). That way you can add wind and what not to the data stream from the Stickstation.
The support for feeding 10Micron mounts with refraction data will be back in the final release of the Stickstation ASCOM driver. The test version does not have this feature yet.
As Chris pointed out, there is nothing that stops us from creating a safety driver that just connects to a conditions device and generates the safe/nosafe flag from limits set on the data from the condition readings. In fact, I will do just that, I think. A good feature would be that it could connect to another safety device and then combine the safety flag of that device with the one generated from the condition readings.
I’ve updated the Boltwood safetymonitor driver I did last year to include an ObservingConditions driver. It’s currently in the files area of the ASCOM-Tak forum:
An ObservingConditions to SafetyMonitor device looks like a good idea.
I wonder how complex this is going to get, with multiple ObservingConditions, Switch and SafetyMonitor devices all being combined in different ways to provide different interfaces.
We probably need to try things and see what works.
You remember when we swapped from Yahoo Groups to here and it was the only place that had your file?
Anyways, it was difficult to find until it was placed on there. Perhaps Andy would host it on his website? It’s nice to have a common place to get all the files for SGP. Part of ‘new guy’ angst is digging around trying to find all the pieces to make SGP work.
Hi Per, I have your ASCOM driver installed. SGP has connected to the driver (I think). Where do I see the graph of your sensors’ readings in SGP? Does it just automatically autofocus based on the SGP autofocus settings, such as when temp changes x mount, trigger the autofocus? Thanks! Rick
@perfrej has nothing to do with this. His driver just provides data. SGPro does not graph anything from the stick station. You can see current data and rends in the docking module dedicated to environment conditions (cloud icon).
No, you have to ask SGPro to use this temperature instead of your FC temperature. CP->Focus tab->Other:
