Moving to a Remote Hosting Site - Part 3: Ready to Ship
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. In Part 3 you will read how things have been built together and tested. The system is now ready to be shipped.
Building up the Cabinet
The cabinet arrived as a flat-box with all separate panels. Putting it together was easy. The rack did not come with wheels, but for ease of use a set of heavy duty ball bearing swivel wheels were added. The cabinet had threaded M8 holes available for that. The one thing that was a bit trial and error was the exact placement of the vertical mounting bars for the cage nuts. They can be positioned anywhere you like within the cabinet. For correct positioning at the front, the depth of the UPS was most critical. Positioning at the back was determined by the thickness of the cable management panels.
Once the right positioning was determined, the various components could be mounted according to the planned layout as described in Part 2, using the supplied cage nuts. Two changes had to be made. First, the mount control box needed to be much closer to the mount. Even the longest proprietary 10Micron cable is only 1m long and was not long enough to reach the control box somewhere down in the cabinet. So one of the shelves was mounted in the highest position and the control box together with two power supply units went on to that shelve. Second, one DIN rail was not wide enough to hold all the components as well as the various terminal blocks. One standard DIN rail was mounted 20cm deep into the cabinet holding all smaller components. A second DIN rail with variable depth was mounted more forward into the cabinet, holding the Dragonfly nice and flush against the front.
The Shelly Pro 4PM switches four power circuits remotely via a cloud-service. The circuit breaker on the left doubles as a manual on/off switch for the Shelly. The relay on the right monitors the mains power and will trigger Voyager to a controlled system shutdown if power is lost.
DIN-rail mounted terminal blocks proved to be a very practical and space-efficient way to connect the various power circuits and components. The blocks used here were from the WAGO 2002-13xx series, with three connectors per block.
The Dragonfly supplies all the switching needs in the cabinet. Control of the Dragonfly is managed through the Viking add-on of Voyager. The Ubiquity Cloud-Key (top-left) allows cloud-based access to the ethernet-switch and cameras.
Cable Management
With so many components in a small space, cable management can quickly become a nightmare. And unfortunately this cabinet is probably not the best example of cable management. But a couple of measure were taken to improve the cable management. First of all, extensive labeling was applied. All ethernet, and power cables were labeled on both ends, so that it was clear what went in where. Secondly some variety in colours was used. For example all mains power cables running through the cabinet have a different colour. Obviously the live, neutral and ground cables had their brown, blue and yellow/green colour. The Ethernet cables are blue and most USB cables are black. Finally, two dedicated cable management panels were installed in the back of the cabinet. They serve two purposes. First of all they help to stow away excess lengths of cable. Secondly cables can be entering and exiting the panel at exactly the right place in front of their intended device, keeping much more oversight over what goes where.
In the back of the cabinet, two cable management panels were mounted, which were a very practical and efficient way to keep things reasonably organised.
The cable management panels allow for having cables coming in and out right where they are needed, and offer space to stow away excess cable lengths.
Terminal blocks are a great way to minimise cabling in a cabinet like this. Connecting cables into the push-in clamps is easy but requires a dedicated operating tool.
The final result
After putting it all together, controlling of all components via the various remote controls was tested. Everything worked as expected. Via manual cloud-based operation, the four main power circuits can be turned on/off. The individual components can be switched on/off via Dragonfly and Powerbox using the Voyager software or the manufacturers dedicated software. The cameras and switch can be monitored via a cloud connection, and the UPS can monitored via the could, and controlled via the local PC. During a test-run ‘under the stars’ everything worked immediately and without any troubleshooting (see below).
When selecting this particular cabinet it was assumed that the 12U height and 450mm depth would be a bit big, based on the theoretical sizes of the components. A lower and/or less deep version was considered. But after installing it all and cabling it up, it was a perfect fit. Cables and their cable management always take up more space than you think, and having a bit of space available goes a long way when you’re working in it as well as for heat dissipation.
The cabinet fully rigged up during the test run. Everything worked as planned.
Space in the cabinet was well used, allowing decent cable management.
Turning 10Micron Mount on/off
The 10Micron mounts work with a mount control box separate from the mount. This is a standalone Linux-based computer that handles the mount modelling, processing weather information, etc. But turning it on or off remotely is a bit more complicated than with some other mounts. First, to turn it on, there is a rocker-button that needs to be held for a second or so. For remote operation, there is a 3.5mm connection. Wires from the 3.5mm plug need to have a shortcut for about 1s to initiate the startup procedure. This is achieved by connecting a loop to one of the relay inputs on the Dragonfly. The output then connects to the 3.5mm connector on the mount control box. In Voyager a command is given through Viking to close the relay for the required 1s.
To turn off the mount, a command should be sent to the mount software. The way this was implemented is described on the Voyager forum. The :shutdown# command can be sent to the IP-address of the mount via the free software Packetsender. In Voyager, Packetsender can be initiated using the external script option as part of the close-down procedures. Both drag scripts are saved under a quick select Dragscript button, making it very easy to turn on or off the mount.
A simple Dragscript turns on the relay of the Dragonfly, which short-circuits both poles via the hard-wired connection of the relay entry (see image left) for a period of 1s. This is enough to turn on the 10Micron mount.
The software Packetsender allows sending a simple ASCII command to an IP-address. The :shutdown# command will initiate the shutdown procedure on the mount. Packetsender is triggered as an external script event in Voyager.
Camera
Matching a camera to a long focal-length scope like the CDK14 is not so easy these days. The ideal pixel-size would be in the 8-9 micron range. But the old 16803 CCD sensors are not manufactured anymore, and new similarly dimensioned GSENSE4040 sensors are not without their shortcomings. Most modern CMOS cameras have a relatively small pixel-size of 3.76 micron. But the sensor technology of these new sensors is very advanced and able to deliver low-noise images with an impressive dynamic range. Either a full-frame variant, such as the IMX455 (61MP), or the even bigger medium format sensors IMX461 (100MP) and IMX411 (150MP) therefore make generally a good match for a telescope of these dimensions. The ASI6200MM Pro, as described in an earlier blog, would be a great fit. However, in a backyard scenario, cameras can just be switched between telescopes as needed. But once shipped off to Spain, the only monochrome camera left would be the ASI533MM Pro. And while this is a lovely camera, for a telescope like the FSQ106 its format is quite small.
Another issue with the ASI6200MM camera is that it does not have a mechanical shutter. Taking Dark frames requires closing up the telescope to prevent light coming in. While this can be organised with the staff on-site at IC Astronomy, having a camera with mechanical shutter would be the better option.
So the decision was made to add another camera to the system, in which both of these problems were solved. This camera is the Moravian C3-61000 Pro. A full-frame camera, built around the same 61 Megapixel IMX455 sensor that is found in the ZWO ASI6200 or the QHY600. The monochrome sensor comes in two variants, the consumer grade version and the industrial grade version, indicated by ‘Pro’ in Moravian nomenclature. It is hard to find information on the differences. Even Sony gives no more information than that the industrial grade version is designed for more intensive use. Whether this means that the sensors have narrower tolerances or are the better performers of a batch will remain a question mark. The Pro is advertised for use of more than 300h per year. And since it is certainly the expectation that use will be higher than that, the Pro version was selected.
The Moravian C3-61000 Pro is an impressive instrument that has quality written all over it. The full-frame IMX-455 sensor is a proven chip with good results in astrophotography.
The big square body with the two fans ensure sufficient heat dissipation. The option to get a custom colour center plate in blue or red is a nice touch when compared to the more common black.
All filterwheels from Moravian come with a built-in tilting adapter. Overall thickness increases, so make sure there is enough backfocus. The integrated M68 adapter fits well with the rest of the imaging train.
Moravian Instruments is a technology company from the Czech Republic and has built up a reputation of building high-end astronomical cameras. I ordered the camera directly from the manufacturer. The experience throughout the process with both Pavel and Eva was outstanding, with quick and thorough responses to my questions. I ordered a version with a custom-colour center plate. This is supposed to have a longer production time. The original estimate was 6 weeks, but after I placed my order, the camera was ready for shipment in just over 2 weeks.
It arrived in a custom-made aluminum case. The camera and filter wheel were fully assembled and power supply and cables were part of the package. When taking out the camera, one thing was imminently clear. The build quality of this instrument was well above anything seen from the usual manufacturers like ZWO or QHY. Both camera and filterwheel are milled from hefty aluminum. The two fans keep the inner works cooler than my ZWO is able to do. Connectors are solid, and the cabling of the filterwheel is nicely tucked away and barely noticeable. I ordered the camera with an M-sized filterwheel with 7 positions for 50mm round filters and an embedded M68 connection. The adapters that Moravian delivers have standard a built-in 3-point tilting adapter. Not sure if that will need any use, as during the first light testing session, the tilt as measured by ASTAP was labeled as ‘none’.
The filterwheel connecter is nicely tucked away behind the wheel itself. There is no USB-hub present with a spare connection.
The top of the camera has two 1/4” and four M4 holes. This gives a bit more flexibility in connecting accessories to the camera.
Four 200g Smallrig counterweights are screwed into the 1/4” holes directly, bringing more balance in the camera assembly as it rotates.
All this quality has a flip-side and that is weight. The combination of camera + filterwheel is a chunky beast and weighs around 2.5 kg. In comparison, the ASI6200 + filterwheel is less than 1.5kg. When adding a camera tilting unit to the ASI6200 the difference will be much smaller, but still. The focuser used in the setup is the Optec Gemini Rotator/focuser. This device is rated to handle cameras up to 10kg, so no problems there. But the ability to rotate introduces another variable and that is Z-axis balancing. The asymmetric nature of a heavy camera with filterwheel means that the weight distribution around the RA-axis will change when the camera rotates. On my FSQ106 with manual rotation, this effect is huge. Whether this is a problem for this rig is questionable. Still, the goal is to go unguided, so anything to optimize balance, alignment, etc is worth doing. To bring the camera more in balance, I added 4 x 200g Smallrig counterweights. These have a 1/4"/20 thread and can mount directly into the top-end of the camera, which has 2 x 1/4” and 4 x M4 holes. By the way, these Smallrig weights turned out to be also great balancing weights for the whole rig, at a fraction of the price of the Planewave alternative.
It is too early for a full review of the camera, but the first impressions are exceedingly positive. With the sensor being the same as in the ASI6200MM, I would not expect very different imaging results. But this certainly looks like a camera that will reliably function under intense use.
Uninterrupted Power Supply setup
The power supply at IC Astronomy appears to be generally reliable. But a good Uninterrupted Power Supply (UPS) unit is often advised. Not only is it there in case the unexpected happens, but it also helps to protect the sensitive equipment by filtering out any power surges. For my setup, I have chosen for the SMTL750RMI2UC from APC. This is a 750VA unit, that should keep the rig running for about 20-25 minutes. What needs to be setup carefully is what happens in case of a power outage.
That setup starts with the question which components will be running on battery power and which not, as they will be connected to different outlet groups on the UPS. The UPS here has two such outlet groups and only the small sensor to monitor for a power loss will stay outside of the backup power. All other components, such as rig, computer, switch, cameras, etc will all be run from battery. All these devices connect to outlet group “Outlet Group 1”. The small sensor connects to a separate outlet group labeled “Mains”. Via an internet connection cloud-based access can be obtained to monitor the status of the UPS and can power-cycle each of the two outlet groups individually.
For fine control over what should happen to the local computer in case of a power outage, the APC software ‘Powerchute Serial Shutdown’ should be installed on the local PC and the local PC needs to be connected through USB. In PowerChute an important page of settings is ‘Shutdown Settings’. Here you specify what happens in case the power drops out. An interesting option is the one that is based on how much time the UPS can still provide power for, based on current load. The settings are now that when the UPS still has 300s (5 min) of power left, the shutdown procedure starts. The main part of the shutdown procedure is a controlled operating system shutdown. PowerChute assumes 180s for that to take place, so well within the 5 mins time available. There would also be time to run a command file script. This is not setup yet, but the plan is to have such command file script generate a safety monitoring file that Voyager can use to initiate an emergency exit. For now Voyager monitors the input from the relay not coupled to the backup power and shuts down from there.
So far the focus has been on a controlled shutdown of equipment and computer. No options have been implemented to restart automatically again after a power failure. In fact, someone would probably have to go physically into the observatory to switch the UPS back on. But if power has really been shut for any extended period of time, this UPS would probably not be the only piece of equipment in the observatory that could do with a button press…
The shutdown settings in PowerChute allow for a controlled shutdown of the Windows operating system of the local PC. Parameters can be reasonably fine-tuned to make optimum use of available battery time.
The equipment is connected to the UPS via ‘outlet groups’. This UPS has two such outlet groups of three plug-points each. The top one is labelled ‘Mains’ and does not switch to battery power. The bottom group is labelled ‘Outlet Group 1’ and switches to battery power in case of an outage.
Test under the skies
The one advice many people share when putting their rig at a remote site, is to test the whole setup before it’s shipped. In my case that was largely dependent on the availability of some clear skies. Luckily last week the clouds cleared away for a while. Humidity was high, and it was not super clear, but enough to do some testing under the skies. The whole rig was wheeled outside, installed, levelled and balanced. After this was done, the intent was not to be outside with the scope anymore, but to manage everything from inside the house.
While the rig was connected via the home network, all interactions worked through the Zerotier network. The Shelly Pro 4PM could be reached and the four main switches were manually turned on. The local PC could be operated via the Zerotier connection, using NoMachine screen sharing software. This will probably be replaced by Splashtop which is used at IC Astronomy. Voyager and Viking were started and all the components of the rig turned on and could be connected to without any hiccup. The backfocus distances were carefully calculated with the new camera, but a first time out it is always a question if you’re anywhere near focus. Because if you’re not, no single star will be visible and it becomes a full hit and run search. Luckily it turned up quite close, and by manually changing the focus position I could achieve reasonable focus. Enough to start building my mount model. MountWizzard4 (MW4) was started, but could not connect to the camera. This turned out to be an ASCOM limitation. An ASCOM driver does not allow multiple software systems to connect to the same device. This is not the case with INDI, where many clients can all work through the same INDI server/driver. In Alpaca this appears to be addressed. It was not a big deal. Disconnecting Voyager allowed me to connect MW4 and I ran a 3-point model. Pointing, loading images, plate solving, etc. all worked flawless, and my polar alignment was not too far off, so I left it with that.
Autofocus
Next was to initiate the focus procedure in Voyager, referred to as RoboFire. RoboFire has two autofocus methods. The first method points the telescope to a nearby ‘focus star’ and runs a V-curve on that single star. The other method is local field and takes into account all stars across the frame. For the first method to work, pointing the mount needs to be somewhat accurate, hence first building the mount model. Both autofocus methods need to be ‘trained’ on a specific set of equipment (the profile). Behind a RoboFire configuration button you can set a decent amount of parameters, but since I was not too experienced with them, I left most of them untouched. So next I pressed the “VCurve First Light Wizard” button and watched what happened. At first I thought it would all go horribly wrong. It used step-sizes of 3, while the focuser has a maximum of 115,000 steps to cover 12.7mm. But the routine kept going and I noticed how it adjusted itself to step-sizes, V-curve, etc. After about 2 minutes or so the routine was ready and I was in focus! After that also tried the local field method and also that worked itself out quite nicely. Overall the local field is a bit slower, because it needs to download and process the whole full-frame image each time. But both methods work extremely fast and give some visual clues as to how well the focus is. The focus routine worked so well that every now and then I just tried it just for fun to experience the super fast way of working. This was a big difference with KStars/Ekos, where focusing, even though hugely improved due to recent work on it, still is a process that requires careful setup and not 100% reliable. We will have to see how reliable RoboFire is in the long run, but so far the results are encouraging.
Imaging
Next was to point the scope to a target. I chose M36, for no particular reason. Selecting the target went quick using the Sesame database. The scope slewed to the target and solved the coordinates, which were very close to target. Voyager can do a precise pointing, but that gave an error that the mount did not allow syncing. At the time I contributed that to the mount modelling aspect of the 10Micron mounts. But the following day I found in the mount driver a selection option to allow syncing without altering the mount model. So turned that on and will have to wait for a next session to see if that solved the issue of precise pointing. Now it was time to run a sequence. Setting up a sequence is very simple. There are just many parameters that can be set. For now left most of them default, and will hopefully gather experience over time on how they can be used to improve the system. One of the things I worked on a bit more was file naming. In KStars/Ekos there is only limited control over file naming, and I always end up renaming all my files based on a certain syntax. In Voyager however, I was able to define my naming syntax fairly close. In fact close enough to just use it and skip renaming files altogether. This is an important improvement step for the new situation where a lot more data will be collected. The sequence was run without any issues, and I captured about 2h worth of data on M36.
Two more essential parts of a successful imaging session needed to be tested: dithering and meridian flip. The 10Micron mount will be used unguided. And because dithering is usually connected to the guide-system, unguided dithering is not always that easy to do in software. In KStars/Ekos, you just define a random guide-pulse of a set length, but have to define a guide-profile for it to work successfully. In Voyager, unguided dithering doesn’t even have to be selected. You just define how often you want to dither and the system does the rest. Perfect! The other testing involved the meridian flip. This was done the following day during day-time. Under the Mount setup you have to indicate that ASCOM needs to be used for it and you can set the time past the meridian when a flip needs to be initiated. In the sequence file you then define whether Voyager manages the meridian flip, or not. Best is to say 'yes’ here. Originally my settings in the mount did not really match the settings in Voyager, but once they were aligned, the meridian flip was conducted without any problem.
A 2h recording of M36 under sub-optimal conditions. So far the first test under the skies was successful.
Image Inspection in ASTAP reveals an almost absence of sensor tilt. Top right might be the tiniest bit of, but questionable if it is worth start changing anything.
Flats and Darks
Also the following morning Flats were shot with the DeepSkyDad 60cm flat panel. In Voyager there is an AutoFlat routine that takes care of this. In this routine you define a target exposure in ADU (e.g. 30,000), a minimum and maximum exposure time, and an initial panel brightness. During the AutoFlat procedure Voyager will then vary panel brightness and exposure times to reach the target exposure level. I would like to keep the exposure times as similar as possible between filters, so I set the margins very small there. Only for the red filter this did not suffice so there I had to increase the margins a bit. So far I have only tested broadband, so we will see how this works with narrowband. Overall the AutoFlat procedure went very well and very fast.
Darks was a bit more difficult to take. It is easy to make a sequence with only darks, but a sequence assumes a target. And the system really wants to point to that target before the sequence starts, even in manual override mode. And the mount keeps tracking, so when you take darks for the rest of the night, at some point the mount will stop. An alternative method is to use Dragscript (see below), so over time I will find an optimal solution for sure. But an AutoDark function, just like AutoFlat would have been a nice addition.
Conclusion
The first night of testing went much better than I had expected. Typically when putting a new rig outside my experience is that you run into several issues that take a while to solve, and you’ll be happy to just solve the issues. In this case I have not yet experienced any issues and I was off running a sequence pretty quickly. I would love to have another night under the skies. Specific areas of testing would be: collimation of the scope, precise pointing of the mount, rotating and synchronising the rotator with the plate solve, and some automation using RoboScript. So far all my work was done within the menu ‘On the Fly’, but the automation comes in through the embedded tool RoboScript. So the plan is to grow over time a fully automatic RoboScript for fully automatic/robotic imaging. And now that everything seems to be working, adding such automation seems to make sense.
So overall the test was successful and the rig is ready to be commissioned. In a few days I will drive to Spain to start the installation there. So next step is dismantling the rig and the cabinet, carefully pack everything, load up the car, drive to Spain and unpack and install everything. So far it has been an exciting journey, and can’t wait to actually see this scope ‘live’ under the Spanish clear skies.
Part 4 of this blog series will cover the installation on-site.