A couple of Elves erected a roll off roof observatory in my back yard this week. I have finished my Arduino/ASCOM/Observatory App and once the customary 3 weeks of cloud have passed (if only), I’m ready to rock’n’roll.
What I really really want for Xmas though is for SGP to monitor the ASCOM safe-for-imaging status and then open the roof, connect to the mount/camera etc and start a imaging sequence once the conditions are favorable (similar to what it does in reverse when the clouds roll in).
I hope this note reaches you at the North Pole. I know it is a busy time but I have been a good boy all year…
Gordon, I don’t think they’ll add that. I dunno how your weather is, but in my case it’s 99% if the weather is terrible, it’s terrible all night. You’re really just trying to guarantee after you go to bed and it clears up, it tries… if it goes crazy again, it’s probably not worth imaging that night.
Great news on your Observatory. No more setting up & tearing down at the whim of the weather.
I’d be very interested on your Arduino/ASCOM/Observatory App as I’m presently building my Observatory and remote control is high on the list.
Steve -here is a dropbox link to the draft version. This is my first programming after a 30 year hiatus, so I’m sure it is not the last word in elegance and it may change in the future as I learn more from practical application.
I’m using a FA Duino 12RA PLC version and I made a test jig that emulates the two motor controls, an open and close roof position sensor and a mount-parked sensor to test all I/O combinations. So far it is behaving itself and works on its own and with SGP/Maxim DL. My intent is to write up the project side of things, to help like-minded astronomers to give programming a go and put the code permanently on my website. It uses the ASCOM templates that load up into Visual Studio and it is all written in C++/ C#. (Per helped by suggesting to replace the ASCOM serial methods with a .Net serial communication event handler)
All comments welcome. I am trying to keep it simple yet robust, otherwise it becomes too difficult as a worked example to explain the principals involved.
I’ve always tried to implement driver protocols on the principle that the hardware only sends a message when it’s spoken to but when it is spoken to it always replies. I also ensure that the reply identifies the command that generated it. This allows a simple command - response style of communication with the encoding of the command and decoding of the reply handled separately to the message handling.
It’s just a different approach and from a quick look what you have looks pretty good.
This would be a great feature and one I would love to see, many nights here it does not clear till quite late, a fair few times woken up the morning an see it cleared a 1am and stayed that way till the morning.
Normally such situations are forecast so is something you would only setup if there was a good chance of clear late.
The pause on safety would also be a nice feature, I have also started a session only to be stopped for a hr or so of cloud, if watching it I will manually dismiss the end of seq options and either close the roof manually and leave everything running or shutdown for a couple of hrs and restart - recently this has been my imaging life as the UK has been ‘blessed’ with the jetstream for the past 3mths so have been reduced to grabbing subs when we can.
There is a lot to consider with the pause approach, is it just a roof close (can it close without parking the scope), do you stop the mount tracking, cool the camera etc
Also in this situation that is a lot of human decision making going on, checking my allsky, running around outside do a visual check, looking at weather sites and Sat24 etc working out if it worth hanging about for a possible clear patch - automation of that will be a challenge.
For pause on safety, try using the recovery wizard and setting it for 1.5-2 hours. I usually find if the clouds are just passing, 2 hours is about the max time it lets them get by. But, you can figure that out on your own too.
Ultimately we want:
Weather is bad… SGP waits until it’s clear for x minutes and gives it a shot. (new feature)
Weather is cloudy but not wet, SGP tries to save the sequence for a set amount of time. (current feature, recovery mode)
Weather is bad and SGP has already started. (current feature)
Do you guys agree? Changed the name too.
Gordon, no worries. I come off as harsh when I don’t mean to sometimes.
I used to run with recovery, worked fine for PHD star lost - must admit since I have had the AAG working seem to have disabled it, does recovery kick in if safety is the reason for a sequence end ?
Thanks for all the info Chris,
I’m a beginner in programming terms. Give me machine code anytime
I’ve designed my RoR Obsy, made my pier and weather permitting clearing the area and prepping ready for the build. Hoping to have everything fully automated by August next year.
Steve
No problem Steve, I am the same - I programmed extensively in assembler to design these in the 90’s. This is the first time I have been anywhere near a modern operating system (or object orientated for that matter). It was always fun returning to 10-year old software to make some improvement or other and trying to figure out what it did!