As for every serious technical specification, we took all the time it required. Youtube videos, websites, amateur and professional observatory visits, even scientific papers: all kind of sources was used to define what really counts and especially, what doesn't. 

Even if Peepoodo is a backyard observatory for the moment, we always kept in mind that it will be relocated in another location with a better sky. Therefore, we always considered a remote and fully automated setup. 

General requirements:

• Low budget 
• Small footprint
• Safe for children
• Remote interface
• Self protected
• Easy relocation
• Scalability

Budget: 

Originally we didn't want to exceed 5k€ for the observatory. It is difficult to estimate the final costs, but we are probably very close to it.

Footprint: 

Relatively soon, we understood that we need to find a compromise between maintenance friendliness, and WAF (Wife Acceptance Factor). It was jointly decided to go for 2m² footprint (1,4 x 1,4m). The trick was to have a slightly larger roof (1,6 x 1,6m) and let my wife decide for the colors :-) 

Safe for children:

You may wonder why this point isn't the first one and the reason is simple: we realized only during the construction how heavy the parts are, and how frequently we tested the observatory functions while the children are playing around. We quickly decided to install an emergency stop button. We also secured the heavy roof with springs, in the case an unwanted action would brutally open the roof. This situation happened to Franck who was, fortunately, not injured. Finally, we selected each electric actuators with exactly the right force, and no more. If an arm get stuck during roof closing, it won't hurt anyone.

Remote interface:

Not every observatory is a remote observatory. We decided to keep the remote interface between the warm room and the observatory as simple as possible, and decided to go for a powerline connection via one unique 220VAC electric line. Remote control is then done via VNC. For a remote control over the internet, we used Teamviewer, but after months of frustration due to the limitations of the free version, we decided to replace it with RustDesk.

Self protected

In case of inappropriate weather conditions, the roof must be able to close without any human intervention, and in any telescope position. For this reason, we designed the 2 half-roofs in a way the sphere in which the telescope fits will never collide with the roof. Before we installed the Hydreon, we used a simple capacitive rain sensor with switchable dew heater. This simple system reacted 2 times over a year.

Easy relocation

Being 2km away of the city center of Graz, and 1km away from the hospital, we suffer from a Bortle scale of 5 to 6. Very bad, but enough to do honorable narrow-band images. However, we wanted to test first from the backyard, and then relocate the equipment in a better location. For this reason, the observatory is mounted on 4 galvanized post spike supports, fairly easy to remove

Scalability

Our original idea was to rebuild an identical observatory in a larger scale. Meanwhile, it is no priority anymore. 

Additional requirements after 1 year of use

The other aspects we took into consideration after an intensive usage:

• Maintenance friendliness (Part exchange such as Arduinos, Raspi, controllers, etc)
• Reliability (replaced items such as guiding scope, removed the 12V relays)
• Scalability (I2C, IPX)
• Redundancies (Rain, dome control)
• Observatory monitoring (temperature, humidity, SQM, etc)
• Open source every time it's possible
• Less is more

Maintenance friendliness:

We are still not sure if it was the right decision, but we always favored standard electronic equipment, even if the temperature range was not always adequate. Typically electronic equipment is specified for 5..40°C, but the outside temperature during the Austrian winter can easily go down to -15°C. For the Arduino, we decided to go for the Uno and connect them with Dupont connectors. They are not easy to clamp, but in case of damage, the Arduino can easily be exchange, by removing 3 screws and 3 or 4 Dupont connectors. As for the Arduinos, most of the electronic boards (DC/DC, motor controllers, current measurement, etc) are standard parts connected either with screw connectors or Dupont. The Raspberry Pi 4 could also be exchanged with a mini PC with less than 1 day of effort. 

So far, none of the electronic board has been replaced and most of them already experienced 4 winters at subzero temperatures.

Reliability:

The ToupTek cam was mounted on the finder scope and used as a guider. The connection was regularly lost for no specific reason. After having modified the USB cable, changed the USB hub, changed the USB setup and performed a firmware upgrade, we finally decided to... change the camera to a ZWO ASI 120 mini. We faced few driver conflicts with our main camera (ZWO ASI1600) at the beginning, but the driver was modified and so far, we had no critical issue

Scalability:

For some reasons we will explain later, we abandoned the idea of building a scalable mechanics, but the control part is. For this reason, we decided to use I²C interfaces between the Raspberry Pi 4 and the Arduinos, and connect simple digital I/Os between the PLC and the controllers with good old wires. Even if the I²C interface is probably not the best choice for a future larger observatory, it would be easy to scale up our control architecture, since all function is related to a specific control box, specific actuators and specific sensors. 

Redundancies:

Believe me, you will never regret to have 2 different type of rain sensors. Never!

In our case, the roof controller is directly connected to a capacitive rain sensor and would react after approximately 2 minutes of a small rain (approximately 0,5mm of rain). For a faster reaction, the Hydreon RG15 will send a feedback to the PLC almost immediately at 0.02mm of rain, and the PLC will send a command to the roof controller to close. Even if the PLC doesn't react, the capacitive sensor would do it after a few minutes. It is still enough time for the equipment to be wet, but not enough to damage our equipment. 

Observatory monitoring:

Temperature is a must. We even recommend to have two temperature sensors: one inside the observatory, and one outside. The delta will give you an excellent indication on how long you should wait for your telescope to be at the right temperature after having opened the observatory.

Meanwhile, you can find numerous weather apps that tell you not only the temperature, but also the humidity and the dew point (Dew stays one of the toughest ennemy). We use Bergfex Pro and ClearOutside.

Additionally, it is always nice to monitor the cloud and rain conditions. We use the RegenRadar from wetteronline.at, where you can monitor the weather condition every 15mn 2h before and after the current time. We noticed that the weather conditions during the twilight usually preconditions what will happen during the night. After one or two years of accurate analysis, you'll be surprised how you can anticipate a clear or a cloudy night!

Ideally, all monitored data shall be available in your favorite automation software, as shown in the previous picture. Simply looking at the diagram, you will immediately know if the night was successful or not.

Open source:

This is almost a philosophical question! ASCOM will work most of the time. But in the cases it won't, you'll hardly understand why. The same applies for paid software, where it is not always easy to understand what happens and how it works. 

In our case, Franck has professional experience on programming interfaces, and it is easier for him to look inside the the source code and understand what's wrong. Without his skills, I would probably favor NINA and ASCOM drivers, but on the other hand, the open-source community is very active and represents a serious alternative to any paid service. 

We now use EKOS and KStars, INDI drivers, RustDesk, and many other software tools made by the open-source community.

Less is more:

We originally designed a relay box for all 12V supplies, remotely controlled by a Firmadata driver. Finally, we deactivated this feature since we rarely need to restart one unique 12V supply and even if we have to, we prefer to switch off the entire system and restart again, in order to avoid strange driver behaviors.  

We also purchased a traditional weather station we never installed. Who needs a rain gauge that tell you after 1h that it rained 5mm?!

Less equipment increases the reliability of your gear. If an equipment isn't necessary, simply remove it, even if it made fun to build it on your own :-) 

What would be different today?

1. We would investigate alternatives to a wooden structure, such as aluminium profiles and aluminium covers 

2. We would reconsider using an I2C interface due to the short distance

3. We would consider the USB interface with more care (cables, hubs)

4. More camera, and a microphone

5. We would ask for more advice! 

6. No scalability

Good surprises!

1. It is not critical to leave the electronic at ambient temperature as long as they electronic is properly enclosed. After 4 years, we didn't have to replace any electronic items. The key is to select components that are widely known and well documented. It is usually a way to ensure a certain reliability.

2. It is better not to keep the equipment inside an hermetic observatory. It avoids critical humidity issues which have far more negative consequences than leaving it open

3. A solid pier mounted on a concrete block is sufficient. No need for a huge concrete slab, unless absolutely mandatory: its costs money, stores thermal energy, and is very difficult to destroy if you decide to relocate your observatory