Results 1 to 7 of 7

Hybrid View

  1. #1

    Default Weather Safety and Dome/Roof Control Experiences

    [This thread contains some really good info on dome/roof control for weather safety - copied from the Scheduler section]


    I hesitate to raise this issue, because I know it has already been extensively discussed, and there really isn't a problem. Nevertheless.....

    In the notes for the Scheduler, it is emphasised that the Scheduler should retain control of opening the dome, and that no opening command should be placed in the Startup script. This tends to imply that control of the dome should be left to the Scheduler. However, that is not correct.

    Closure of the dome is not managed by the Scheduler. If the weather becomes unsafe, the unsafe condition will trigger closure of the dome by ACP. No problem!

    However, if the observing session comes to an end, and no weather unsafe condition has arisen, the shutdown script will then run. If no dome closure command is placed in the shutdown script, and if the option "Close and park/home when scope is parked by script" is not selected in ACP, the dome will remain open. In other words, the Scheduler does NOT take responsibility for closing the dome, only opening it.

    This caught me out once or twice, when the weather turned wet after the session had ended, and the shutdown script had already finished, leaving the dome open.

    Ticking the "Close and park/home when scope is parked by script" seems to be the most straightforward way of dealing with this, but that means that the dome is closed each time the scope is parked, which may not be desirable.

    I think a better option might be to close the dome by means of a command in the shutdown script, but I don't know how to do that (having limited programming skills).

    Any comments?

    Last edited by Bob Denny; May 24, 2017 at 14:46. Reason: edit/copy note

  2. #2
    Join Date
    Nov 2015
    Christchurch, Dorset, United Kingdom


    Hi Stephen.

    Just picking up on one aspect of your post, I believe from one of your previous posts that you are using a Pulsar (UK) dome with the Rigel control system which I am also running. Like you, I had an early Rigel system with some deficiencies in the controller software which has recently been updated.

    My own experience has shown that relying purely on software to protect against weather events is not sufficiently robust.

    In my own Pulsar observatory a combination of early Rigel firmware without the shutter battery low-voltage monitoring, poor Bluetooth link stability, a faulty shutter-motor gearbox and a Windows failure left the shutter open for three days while I was out of the country and led to extensive mount, camera, focuser and telescope water damage. Although the shutter-motor gearbox problem could not be predicted and I was unaware the shutter battery was not being monitored I had experienced several Windows crashes and in retrospect it was foolish to have left the observatory unattended and operating autonomously while still at the setting up phase.

    I was on the verge of ditching the Pulsar-Rigel system and placing an order with Diffraction Ltd for the Maxdome system which includes an external trigger input for software independent shutter closure with a weather event when I discovered that Pulsar had incorporated the hardware and firmware changes for an external input to trigger immediate shutter closure to their latest system deliveries.

    As part of the Pulsar-Rigel firmware and hardware update an external trigger input socket has now been added to the rotation controller box which overides external software control and forces shutter closure immediately upon activation of an external switch.
    Mathew at Elecsoft, who designed the Rigel system for Pulsar, sent me upon request a small additional circuit board mounted on a BNC socket with just three wires to be soldered to the rotation controller circuit board, and a small hole drilled into the plastic case to mount the BNC socket.
    With my engineers hat on I would have preferred a remote trigger input to close the shutter on the shutter controller box, as is the case with the Maxdome controller, rather than the rotation control box as this still relies on the Bluetooth link being active between rotation controller and shutter controller, but in practice this involves additional power supply requirements for the rain sensor on the rotating dome that can be quite difficult to implement if heating of the sensor is required for anti-icing and now that the shutter firmware closes the shutter automatically if the Bluetooth link goes down then the need for a direct trigger input at the shutter controller box is no longer essential.

    As a retired engineer this was a simple task for me to fit the socket and connect the three wires, only an hours work, though I did already have the necessary tools and antistatic workstation. The option to return the rotation control box to Pulsar and have them install the modification was available. The turn around time quoted was just a few days and the charge for supplying the modification was very modest.
    (If you want to install the BNC socket yourself you would need a soldering iron, solder, drill, small cross-head screwdriver, small half-round file, small adjustable spanner, wire snips and an ESD antistatic mat and wrist strap)

    To this new external trigger input socket I have connected a Hydreon rain sensor (import from the USA via Amazon UK) which has a pair of free contacts that close on rain detection and force the shutter to close irrespective of what the observatory system software says. The Hydreon sensor uses a clear acrylic dome and infrared to detect rain in a way similar to that used by automatic windscreen wiper sensors work in cars. The Hydreon sensor includes a heater to clear the dome of ice and evaporate away rain droplets after the rain ceases.

    I already had an AAG Cloudwatcher that interfaces with ACP to close the dome via software in the event of poor weather as well as providing an independent rain sensor switch.
    Previously I was unable to implement the AAG Cloudwatcher independent rain sensor switch as the Rigel system had no input socket or firmware support.
    Now that the Rigel system has the remote trigger implemented both the AAG Cloudwatcher independent rain sensor switch (capacitive) and the Hydreon switch (Infrared) are connected in parallel to the Rigel trigger input socket and a rain event detected by either system will close the shutter independently of software or the state of the observatory computer.

    While the above does not answer your scripting question I hope that my experience of relying on software to handle failsafe dome closure with a weather event, and failing to do so, may encourage you to look at adding a hardware level protection against poor weather. This is fairly simple with a dome since in most cases it is not necessary to park the scope first so the shutter can be closed without risk of collision.
    If you do not have this remote trigger socket addition to the Rigel rotation control box then contact Mathew at Pulsar-Elecsoft for retrofit details and cost of either installing this yourself or returning the rotation control box to Pulsar for them to install it.

    I should add that the damage to my observatory was nothing at all to do with ACP.
    The Windows crashes were an OS memory leak problem that was ultimately resolved by reinstalling Windows 7 Pro after many fruitless weeks of trying to find the problem with MS remote support assistance (won't be doing that again after paying the premium rate support charges and never finding the cause!). The shutter-motor gearbox failure was just one of those random mechanical failures that could not be foreseen and now that the Pulsar-Rigel system has the latest firmware installed that monitors the shutter-battery voltage and auto closes if it fall too low, improved Bluetooth link stability, automatic shutter closure upon loss of contact with the observatory PC and the new independent external trigger input for the rain sensor that the system is about as robust as is reasonably possible with an amateur level observatory and that the support from Mathew at Pulsar- Elecsoft resolving these issues has been exemplary.


  3. #3
    Join Date
    Oct 2005
    Mesa, AZ


    William, thank you profusely for your post on using and upgrading the Pulsar system. It took a LONG time to write up and your efforts are most appreciated.

    Stephen, actually there are times when the Scheduler closes the dome/roof. However for an unsafe weather condition, ACP itself has the responsibility to kill any run in progress and then safe the observatory.

    As shipped, the ACP-Weather and Scheduler shutdown scripts depend on the park/close option being on (also the default setting). If you want to separate these functions by disabling this option, you will need to add code to both scripts to specifically close. The code for this is


    Note that this call will just START the closing process. It may take some time to complete (I just encountered a roof that takes six minutes!).
    -- Bob

  4. #4


    Thanks William for your comprehensive reply and thanks Bob for your clarification.

    William - Actually, I am already in the process of installing the modification to my Rigel controller that you mention to incorporate the independent rain sensor. I quite agree that we should not rely on the closure signals coming from the computer. Curious to know why you have installed yet another rain sensor (the Hydreon unit). Is that just for added security, or do you think that rain events may occur that would not be detected by the AAG sensor?

    I now intend to add the close shutter command to the Scheduler shut down script. I see no reason not to do this. The shutter closure command is already present in my ACP weather shutdown script, which is why I did not notice a problem when an unsafe weather event occurred.


  5. #5
    Join Date
    Nov 2015
    Christchurch, Dorset, United Kingdom



    The second, Hydreon, rain sensor was installed purely down to problems with bird-poo accumulating on the AAG Cloudwatcher sensor head I live close to the coast and next to a dairy farm so if the seagulls don't get you the crows do.

    My observatory is left unattended for several months each year and I had problems with bird droppings on the AAG sensor head. The capacitive rain sensor of the AAG was not sufficiently self-cleaning due to the shallow angle that the sensor head is installed and the rain sensor simply stopped responding to rain events while dirty. The Hydreon unit being covered by a small dome is self cleaning to a certain extent and it only responds to sudden changes of IR reflection within the acrylic dome so that even quite large spots of bird poo are ignored once they have been on the dome for a few hours.

    Since fitting the Hydreon sensor I then had problems with contamination of the AAG light sensor and the IR temperature sensor and in the end I extended the garden sprinkler system with a pair of spray nozzles fitted to the AAG mast, which is set fairly high up, and used an IP enabled water valve that I can operate remotely to spray clean the AAG sensor head.

    In operation, the two technologies used for rain sensing, capacitive sensor and IR sensor both detect rain reliably with no noticeable differences in sensitivity, the Hydreon IR unit just is able to ignore contamination of the sensor a little better.

    If I was able to monitor and service the observatory daily throughout the year then just the AAG would be sufficient but having the Hydreon as well gives me a little more security. The bill for the water damage to my observatory ran to four figures and I don't want to see that again...


  6. #6



    Sorry to hear about the bird poo problems! So far, I don't think I have experienced that particular problem, but I have many others!

    I see you are located in Christchurch. I'm in Sussex, north of Lewes. It's a reasonably dark site. No seagulls to speak of, just a few woodpeckers and kestrels.


  7. #7
    Join Date
    Dec 2015
    Southern Hemisphere


    That’s a fantastic write up. I am in a similar situation where the dome is located couple hundred km away. I wanted to implement as many redundancies into the system as possible to catch unforeseen events. Regarding rain, my primary sensor is the AAG, but that is tied to the PC. I have a Hydreon rain sensor as well, configured to be my last resort in closing the dome in a rain event. The AAG is the first line of defence, triggering the weather script. If the PC has become unresponsive for some unknown reason to the dome controller, the watchdog on the dome controller will detect lost comms between the dome and PC. This triggers a closure 25 seconds later. If the PC is alive and if for some reason the AAG’s relay faults, the Hydreon rain sensor will trigger a closure via the dome interconnects at a predefined level of precipitation. The thresholds on both devices are at different levels. With the AAG more sensitive than the Hydreon. Hopefully the Hydreon responds only as a last resort. The goal is to protect the equipment in a rain event. I must say, I really like the idea of the water jets on your AAG. Something that I will add to my system.


    A few astropics:

    RCOS 10” Military Ruggedized - fl 9.1
    Astro-Physics 900GTO
    SBIG STL-11000M / OA-L
    FLI Filterwheel
    ScopeDome 3 Meter
    AAG Cloudsensor



Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Dome/Roof Control Issue (was: Scheduler failure during dome open)
    By Todd Benko in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 18
    Last Post: Jun 5, 2016, 20:41
  2. Dome/Roof Control Issues (was: repeated operator intervention)
    By Bruce McMath in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 12
    Last Post: Apr 16, 2016, 19:53
  3. Lesve Dome Controller - programme mods for simple roof/rain control
    By Roger Banks in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 4
    Last Post: Mar 27, 2009, 16:09

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts