Moving to a Remote Hosting Site - Part 4: Installation

After six years of imaging from my backyard, the decision was made to move one of the rigs to a remote hosting site. At the moment that is still a bit of a journey into the unknown. In a number of blog-posts you can follow along on this journey. Part 1 described the goals, site selection and general considerations around software and hardware. Part 2 focused on the design and tools used to control the rig and how to do that remotely. Part 3 was all about putting the rig together and testing it. In this Part 4 you will read about moving to and installation at the remote site, calibration and first light.

Shipping

Finally, the moment was there, bringing the whole rig to Spain. One of the selection criteria for the site was within drivability by car from my home town. Now was the moment this aspect was put to the test. The car was a regular sedan, so the whole rig needed to be taken apart, including the cabinet. It was obvious that the original shipping boxes/crates would not work for most of the equipment. The telescope for example comes in a massive crate, that requires a van to transport. So the telescope was going on the backseat, covered in a blanket, carefully strapped so that it would stay in its place. The mount could be taken apart in two pieces, making it fit in relatively small-sized plastic storage boxes. The cabinet was dismantled. All components were taken out, but the DIN-rail with components and wiring remained intact as much as possible. Then every single component was wrapped in many layers of bubble-wrap for optimal protection. Packing it all in the car was still a bit stressful. Would it all fit? And if not, then what to do? Luckily everything (just) fitted, so on Sunday, 10 March 2024, I started a 2400 km drive to the remote site in Spain.

Installation

It is the morning of March 12, 2024, when I drive up the rocky driveway to the observatory. Just a few days ago this area was covered in snow and cloudy skies. But today was a beautiful sunny day. Colin Cooper, one of the owners of IC astronomy, welcomed me on-site. Colin and his partner Sam live at the site and were so kind to have me stay over at their place, because the regular accommodation nearby had been booked before me. What a service!

We started with a tour through the observatory. There are a total of five observatories on the premises. Three for remote hosting with 8-10 scopes in each. One was just behind the workshop and for personal use. The last one houses a telescope from Telescope Live, an impressive 70cm Officina Stellare RC telescope. An office with lots of backup/repair/support parts and a fully equipped workshop complete the infrastructure. Colin has a strong background in engineering and has designed and built the observatories himself. He also builds the piers to specific height for each telescope. My telescope was planned in Obs2 and the pier was made, perfectly level and pointing north, ready for installation.

*The three main observatories that house the rented piers. My telescope is planned for Observatory 2, the middle of the three.*

Before installing the telescope we had a closer look at visibility of the horizon around the planned location of the telescope. For a quantitative assessment, the method using Theodolite was used as described in an earlier blog. This information was used to create horizon files for the various pieces of software, such as Astroplanner, MountWizzard4 and Voyager. Besides this, Colin had a 360 camera and made a photograph of the horizon profile. At this point in time, the roofs of both neighbouring observatories were still closed, so compared to what you see in the image below, the green structures in the North and South would roll away at night. In most directions, the horizon limit was lower than 10°. Only in western direction there was a small area where this increased to around 20°.

A 360° image of the horizon. Roofs of the other observatories were closed. When they open, there is an almost unobstructed view to the North and South.
(Click the “<“ and “>” arrows to look around in the image)

We quickly emptied the car and started the installation. Holes for the GM2000 pier adapter were drilled in the pier and the mount was put in place. The telescope was brought in from the car. No rattling sounds after 2400km of driving on the back-seats… At home I had marked the approximate balance position, so we could slide it in the saddle directly in the right place. Then focuser, camera, Powerbox, Delta-T and focuser-controller could be installed and wired up. It was time to do the balancing. But before running the automatic balancing routine in the mount, first a quick manual check on free movement in all directions. This is where the first problem showed up. There was not enough clearance with one side of the walls. A matter of a few centimeters, but still… We decided that the best solution was to move the mount a bit backwards on the pier top-plate. This top-plate was rectangular and originally we put the mount on the front side to have enough space for the counterweights to pass by. But apparently that was a bit too much. So we moved the whole setup back a few centimeters. Unfortunately this meant that the whole rig had to come down again. But with the two of us, all was done in 15-20 min. Now it was time to balance the scope, and of course the goal was to have 0% in both directions. The SmallRig 200g weights such as used for the camera came in very handy in there as well. Their 1/4” threads fit almost everywhere on the CDK14. When putting them at the end of the truss-tube, one was not enough, and two were too much. So eventually two were screwed onto the mounting plate, for an exact balance.

Command and Control

A consequence of going by car, was that the cabinet with all the control equipment had to be taken apart and be re-assembled on-site. It turned out the workshop was a perfect place to re-assemble the cabinet. Knowing where each component has to go, in combination with proper labeling of the cables helps a lot with this task and the whole assembly was ready again relatively quickly. Once ready, Colin and I carried it into the observatory. There it could be connected to mains power, a wired internet connection, and of course the telescope. In the observatory there is no WiFi connection by design, so until the appropriate software was installed, we ran the rig with a long cable from the observatory to the office. All components seemed to be working fine, and outside access for the Shelly Pro 4PM controller and the Ubiquiti CloudKey for the camera’s was working without any further installation.

The ‘computer-guy’ is Steve, who is mostly working remotely. Steve installed some software on the control computer. This included software that always shows roof status on the desktop and a google drive to pick up boltwood files for weather information. For remote access to the system, IC Astronomy provides a Splashtop Business subscription. As with all these remote computing products, a server needs to be installed on the computer to be controlled. Controlling works via dedicated apps that are available for most platforms, including iOS and MacOS. Over the years, I have used different software systems like this, but this one certainly ranks at the top when it comes to speed, ease of use and functionality (e.g. very good file transfer function).

For direct IP-access to the system, such as required for the Voyager Dashboard software, a Zerotier network had been established. Upon installation on-site, most components seemed to be connecting directly, but for some reason the laptop couldn’t. After some trial and error without any success, a restart of the laptop solved the issue. One of these examples where you just give up understanding the problem, and accept an on/off cycle is just the ‘magic’ solution.

Polar Alignment and First Light

The clear weather extended into the night, and the conditions were perfect to polar align the rig and see if some first light images could be collected. The GM2000 mount can support a wide range of latitudes, but it may require a change in the positioning of the altitude-adjustment knob. The manual describes the latitude ranges for each possible position. And in my case, moving from 53º to 37º did require such an adjustment.

The Polar Alignment was conducted using MountWizzard4 and is a pretty straightforward procedure. You run a three-point mount-model and the software shows the amount of turns the altitude and azimuth knobs need to be turned. After the first run, azimuth required about 4 turns and altitude about 2 turns. That is quite a bit of adjustment, so it required a few iterations to make the full adjustment. As a final step, there is the possibility to point to an alignment star and fine-adjust with ‘live’ images to get the star in the center of the image. When completed, an 18 point model was run. The resulting PA error was 122 arcsec and the RMS value was 9.5. For a setup like this, these values are well within the acceptance criteria.

So far no focusing had been done yet. Stars were good enough in focus to run the PA routines, and the autofocus routine in Voyager uses ‘focus-stars’, so the system needs to know where it is pointing first. The first autofocus run was a disaster. Nothing happened to the V-curve, just a flat wobbly line. It took a bit of time before I understood what was happening. The cause of the problem was a stupid mistake from myself. The wires of the focuser and rotator were switched. So when the autofocus routine was running, the rotator was happily turning around…. That problem was quickly fixed. But Voyager works with a ‘memory’ of historic focus runs to make future ones more accurate and faster. Obviously that system was now fed with rubbish V-curves. Again, it took a bit of time to find the way to reset all that and to run a proper focus-run. Luckily much better data came through now. But still the focus was not great. The point of the V-curve was not a real point, but pretty flat, resulting in a pretty large critical focus zone. The impression is that there is some sort of in-scope seeing issue that blurs the finest details. It looked like turning the fans off had a positive effect, so hopefully this can be improved by finding proper settings for mirror heaters and fans. This will require some further fine-tuning. At the first evening I could not get to FWHM’s smaller than about 2.8 arcsec. In subsequent days that was improved to about 2.4 arcsec, but for this site, the ambition would be to get this down to under 2 arcsec.

By this time, it was time to go to bed, so the system was pointed to the M95 galaxy. A quick test-shot showed that the pointing had been successful. The system was then left with an RGB sequence to run over the remaining part of the night.

***Left:*** The altitude adjustment mechanism of the GM2000 mount can be placed in many different orientations. It required a careful check of the manual to fix it in the right position to accommodate the 37° location altitude. ***Middle:*** After polar alignment, the residual PA error was 122 arcsec, which is well within the acceptable range. The current model was made with only 16 points. A much larger model will be built once everything is installed. Right: Voyager stores information about how the V-Curve should look like. After the mix-up of focuser and rotator connections, it took a while before proper V-Curve parameters were restored again.

Collimation

The second night was also clear, so we could work on the collimation of the scope. After all, at no point since delivery of the scope in the Netherlands, had the scope been collimated at all. Collimation was done with the help of Skywave (SKW) software from the company Innovations Foresight. This utilises AI based wavefront sensing technology to perform a quantitative optical analysis. The AI model used is telescope specific and is custom-provided by the manufacturer. The first step is to define the telescope optical details in SKW. Then you need to create a ‘Request file’ in SKW, which combines the telescope details with the computer you’re running the software on. Remember, your license is linked to a physical computer, so think upfront which computer you will use to do the analysis. The request file can be sent to Innovations Foresight by email and a few days later you receive a WeTransfer link to your AI model. In my case this ordering did not run super smoothly, but that may well have been an error on my side. In any way, Gaston Gaudet from Innovations Foresight is very helpful to get you on your way.

Once you load the AI model in SKW, you have a number of ‘credits’ available. One credit is one analysed image. How many analysed images you need for one collimation is difficult to say. Typical it may just be a handful, so 63 may be sufficient for 10 collimations or so. But it could be more or less. You can always purchase more credits, and you can also purchase a version of SKW with unlimited number of credits. I chose the ‘default’ of 63 credits.

What the software needs is one out-of-focus image of a bright star. And while the documentation helps a lot in a practical way, just exactly how much to-of-focus and how bright of a star was something I had not found. So this part was a bit trial and error, and the first images loaded into the system did not result in a viable analysis. You don’t have to worry about your credits in this phase, because the software will check if your image can be analysed at all, without costing any credits. In the process however, some quantitative requirements became clear. They are:

Star magnitude between -1 and 4
No star saturation, signal somewhere between 20-40k ADU
Out of focus by 5510 microns (not sure if this is telescope specific)
Star somewhat in middel, diameter at least 202 px, no binning

Turned out that the star I had selected was way too faint. It gave visually a nice out of focus image, but not bright enough for the software. Finally settled on the star Bellatrix (gamma Orionis). A 10s exposure looked extremely bright, but it gave the required brightness for the software. Once it had determined that the image could be analysed, the ‘Analyse RAW frame’ button started to flash green, indicating the actual analysis could be started. Pressing the button and after a few seconds it had analysed the image. And the result was… 8.8 good score, all in the green. It was hard to understand that a telescope that had been transported from the company and spent 2400km on the back-seat of a car had correct collimation! But a welcome bonus of course. As can be seen in the left image, the focus position was 932 micron too far out of focus. So the focus was pulled in by the required amount and did a second image. This time, collimation came even in at a 9. So very happy with the result.

In case there is a miscollimation, the telrad-like dot would be off-center, in the direction of where the secondary mirror is leaning towards the primary too much. So the respective collimation screws should be carefully pulled to move the mirror a bit backward. Obviously this would have to be an iterative process.

Having mainly worked with refractors, the concept of collimation is pretty new to me. And I know there are many methods out there. The CDK is considered easy to collimate, as there is only the secondary to worry about. So probably any method would have worked well with some practice. But the quantitative result and simply feeding the system with one out-of-focus frame, makes SKW for me a very comfortable tool to have.

Finishing the installation

Most of the installation work was done on the first day. The only thing that still needed doing was installation of the cameras and the flat panel. For the cameras, one position was chosen on the cabinet, looking at the back of the telescope. The second camera was placed on the wall in front of the telescope. This way the telescope can be observed from quite a few angles to get a good impression of the situation. The camera’s are Ubiquiti G5 bullet cameras and are controlled via the Cloud Key Gen2 in the cabinet. This is a local system, with local recording capabilities if needed. So the camera’s don’t have any burden on the bandwidth of the cloud-connectivity, only when you actually check the cameras, which is at most a few minutes from time to time. This in contrast to some other IP-cameras that have a continuous cloud-upload of videostreams. The camera’s have IR illumination to image in the dark. This is turned off, to not interfere with anyone’s observations. However, that risk may be very low anyway, as the IR LED’s emit at a wavelength of 850 nm, which is a bandwidth most people would block anyway with their luminance or other filters.

The Flat panel appeared to require a bracket to hold it away from the wall under an angle, perpendicular to the telescope. Such a bracket was still to be ordered, so this was left as a job to be done by Colin after I had left. All the cabling had been put in place already. A few days later the Flat panel was placed, but it turned out that the bracket was not even needed. Putting it at the other side allowed for a perfect positioning of the scope in front of it, so also this last piece of the installation had been completed.

First image

In the morning of day three, it was time to say goodbye to Sam and Colin. What a wonderful hosts they have been, looking after me for those days. Thank you! It was time to drive the full 2400 km back home to complete the mission. During the half-way stopover in France, there was the first joy of being able to image remotely. From the hotelroom I was able to connect to the system, turn it all on and run a sequence on a target that I had chosen two nights before: M95. And like the first night, it happily ran the sequence, did the meridian flip with no problems and the following morning the first ‘remote’ data had come in. Given the focus/seeing issue mentioned above, not fully satisfied with the results yet, and further experimentation with heating/fans/shroud would need to be done. In subsequent nights the decision was made to go for 300s exposures instead of 180s, which gave better results. The Voyager software was still used in a semi-manual mode, trying to get more experience with the various elements of it, so a lot more automation is still to come. But already, it felt like the system was easy to handle and generally worked as expected. After a couple of nights, there was 9h worth of data (36 * 300s for R, G and B). Below the resulting image. Further details and processing information is available on this website and on Astrobin.

Conclusion

From the beginning of this adventure, the installation at the remote site, and remotely operating was always reason for a healthy dose of nervousness. What if it’s not working, what if something breaks in transport, what if there’s been an oversight and something is missing, etc, etc. But the installation could not have gone smoother. For a large part thanks to Colin who clearly knows his things and had everything perfectly organised. The many months of preparation, planning and testing also paid out. And while there are still things to work out, so far this adventure has been successful. And the ability to image from the laptop from anywhere in the world has already given me great satisfaction. And the knowledge that there is good support on-site looking after it, gives a great sense of comfort.

There are still a ton of functions in the software that have been barely touched and in subsequent weeks/months, work will be done to further automate the imaging process, with the goal of full ‘robotic’ imaging. When that is all in place, the plan is to write a fifth and final blog describing the experiences, lessons learned, etc. and hopefully some nice images.