I’m guessing with observatory control there will be weather station support too in V2.4. I currently own a Davis weather station and I’m wondering if that is on your todo list and if so, would V2.4 support serial communications or USB? At the same time - is there an intention of supporting one of the rain/cloud detectors, such as the AAG unit?
kind regards
Chris
Yes, it’ll work. Chris wrote a ‘wrapper’ for the boltwood 2 format so it basically works with just about anything. The only issue I’ve really run into with is that they worked out a new ASCOM standard for ‘safety devices’. Unfortunately, the manufacturer of mine doesn’t want to support it and I have to rely on the ASCOM ‘wrapper’.
They’re still working out some of the bugs and it is last on the support list because it doesn’t seem to be important to many people. If people are really wanting weather station support, I’d keep posting about it :).
Obviously the weather is of interest- for some, the pressure and temperature are used in telescope pointing and tracking models - but these mounts tend to take care of themselves and do not need SGP. My particular thoughts were more to do with enhancing the operation of SGP sequence control, along the lines of:
- temperature - for focus setting purposes (since TemperHum devices are so contrary)
- relative humidity - quitting a sequence when its over 95% or similar
- cloudy - pausing a sequence, resuming when it is not (in the UK you often get 30 mins of cloud that blows over)
- overcast or raining - abort the sequence park the mount and shut the dome (or wake me up to put a cover over the scope) - the fact that SGP is so good at reliable automation, the least reliable aspect is the weather!
The AAG cloud watcher (about Euro 250) and I guess the Boltwood (just seen they do a cheaper portable one, Doh! ) can provide the cloud information.
AIUI the plan is to implement the ASCOM safety interface. This has one property - IsSafe - and SGP monitors this. If IsSafe returns false the sequence is stopped and the scope/dome shutdown process done.
It’s up to the safety monitor what counts as safe, this will be set in its setup dialog along with any settings needed by the hardware.
The Boltwood Safety Monitor is now on the ASCOM site, in the downloads section, so you can have a look. It includes a help file and simulator and test programs so you can try it without a Boltwood.
Chris
PS why safety? We had a huge amount of discussion and found that all we could see that was sufficiently universal was to answer the question “Is it safe to continue?”
I think Stan (Foster Systems) issue with it was more that it would fail like the other attempts and he’d reprogram his driver just to find out people weren’t supporting it. ASFAIK, SGP is (when it’s released) the only company that currently supports it which doesn’t help the cause for it.
thanks Chris - I have asked the guys at AAG if they are compatible with the ASCOM safety interface. I’ll drop a line back here if I get a response.
Apart from the safety aspect, it would be very useful to have pause and resume linked to cloud detection. One could set a sequence going and it would start up once the cumulus had dispersed in the evening for example.
I keep having to tell people, there’s no demand for it 
It’s a chicken and egg situation, no point in developing drivers because no application supports it and no point in developing applications because there’s no drivers.
All we can do is make a start. The interface definition won’t go away.
As for the pause when it’s cloudy issue I’ve provided two drivers and it is possible for an application to monitor both and use one to decide if it’s OK to image and the other to decide if it’s OK to have the observatory open. It’s all described in the help file!
Chris
1 Like
Sorry Chris, I did not mean to offend - I’m not as familiar with the issues as you are and I’m not quite following you.
The two drivers that might be applied to cloudy conditions - in which help file are you referring to? I did a search in the SGP help file and did not find anything in the obsy. tab.
The help file I am referring to is the driver help file. You have the option to see this when you install the driver. If you download the driver - the safety monitor driver - from the ASCOM downloads site - and look at the driver help file you will get a lot of information about how the driver works, how to use it and so on. I’m sure it will give you more information than a series of emails asking for information.
1 Like
Yea, I think it’s genius. I guess you just gotta look at the history to understand where the old guys come from with it.
I discussed the general topic with AAG - they have some software called GNS (Good night system) that they claim works with SGP. It behaves much the same as a watchdog on a micro and TCP/IP’s messages to an iPhone. The program gets progress updates from the acquisition software / AAG cloud watcher and the user sets time limits for each activity…so if there is a crash, rain, failure to plate solve, focus etc, it can time out and send a warning. There is a free trial version and I’ll give it a go and report back.
2.4 will support the ASCOM Safety Device interface initially for the weather station. Unfortunately there isn’t a lot of support out there for it at the moment. But with Chris’ ASCOM driver it should support anything that outputs the Boltwood OneLine format, which should actually support the majority astronomy related weather stations.
We may add wider support in the future but we have to start somewhere. Unfortunately there is no ASCOM weather class so it makes weather stations somewhat of a mine field, each requiring a native implementation, which takes a fair amount of time. We prefer to spend our time implementing features for our software rather than hardware support.
Thanks,
Jared
GNS as well as the framework for additional monitoring systems will also see light in 2.4.
Thanks,
Jared
The problem with an ASCOM weather interface is that every weather device has it’s own set of properties. If we had one you would need to discover what properties were available, have set up for each one as required, then monitor them all. This looks like a lot of work for the application developer.
The safety interface is designed to answer the question “is it OK to do some operation?” The detail of what counts as safe is delegated to the safety driver. This should be better for the application developer.
If you can come up with a ASCOM Weather interface proposal that meets what you want and has a good prospect of working with more than one device then please propose it. Thought through requests from application developers carry a lot of weight.
There is another possibility - the new Switch interface. This provides an interface to a list of devices, The Switch has a broad definition, it can be read only and it can have multiple states. It’s not just for controlling power. A weather device could implement a Switch interface, for example temperature could be implemented as: name “AmbientTemperature”, minimum -40.0, maximum 50.0, step size 0.1, CanWrite - false.
Maybe I should do a Switch driver for the Boltwood.
BTW I’m not that happy with Switch as a name but it was difficult enough to get people to consider this at all. I had a lot of you ain’t gonna need it, something that’s relevant to to implementing functionality but for an interface becomes you can’t have it.
Chris
Thanks Jared. My original post merely asked what was planned in the release - I was going to tailor my accessory purchases to suit. It obviously is a difficult subject judging from the comments it has drawn, probably much in the same way as cameras were in the beginning, before useful standards became prevalent.
It is a useful discussion however since, as SGP is stable enough to work flawlessly for hours on end and for those of us who need to go to work the following day, the prospect of all-thru-the-night imaging with an alarm call is very appealing. The least reliable part of my imaging setup is the weather and that is something I could not say before I used SGP.
All. Please take that into account. There is a bit of a defensive air to some of the responses. A feature inquiry or suggestion is potentially for the improvement of SGP, not an implicit criticism. That is a good thing, even if it is not taken up. One suggestion in a dozen may be useful. I did not waste my time with DL.