MCinAZ

Another alternative to ASCOM in the Linux world which may be worth considering is INDIGO (https://indigo-astronomy.org). There is a SynScan driver available which may work with your mount. The drivers we've tried work well, and the software components appear to be stable and well designed.

This doesn't address the original question (I think there's a desktop setting for that, perhaps described in the link above), but what I do may be useful to others. On my desktop, I have a number of launchers for different terminal window configurations, highlighted in green in the first image below. Clicking one of those will open one or more xterms on a desktop, arranged to my preference. Typically, I will use a particular set of xterms depending upon available screen area, e.g., laptop screen vs. desk monitor. It takes a bit of fiddling sometimes to get the window coordinates just so in the scripts, but once done I can get to the same starting point quite easily. My usual four-xterm desktop that I use on my laptop screen is shown in the second image. I'd be happy to provide a tar file with my scripts upon request. I'm still using Mint 18 Cinnamon, but the strategy works with about any desktop. There's nothing particularly clever about it, but I'm lazy and it makes life easier.

I also use SharpCap Pro as a polar alignment tool, and have been quite pleased with the results. For my mounts, I fabricated adapters which thread into the opening for the polar alignment telescope cap. The adapters provide a standard 1/4-20 screw which is used to mount a ZWO ASI120 camera. Since I have a small collection of Canon lenses, I use the ZWO Canon EF adapter and a 100 mm lens, as pictured below. I've found that this to be a good compromise between field of view and on-sky resolution, and can generally align to within a few arcmin of the pole (as reported by the software) in a matter of a few minutes. Because SharpCap reports polar alignment values to the arc-second, it's easy to chase perfection that will likely never be achieved. There are a number of error terms which are often of no real consequence but will affect the numbers displayed. Seeing, image resolution, accuracy of the algorithm used to extract centroids, flexure, etc., can all contribute discrepancies which are apparent at the arcsec level. In most cases, however, polar alignment to with one or two arc-minutes is more than good enough. What I've found works as well as I ever need is to perform the initial alignment per the image/rotate/image procedure, then rotate back through 90 degress, then an additional 90 degrees, noting the errors at the three points. If they look bad -- say, three arcmin or worse -- I'll touch things up if I need high accuracy. I sometimes image with a camera that provides a 12 x 9 arcmin field of view, so in order to ensure that my targets will fall on the sensor following a slew, I like to be polar aligned to with a couple of arc-minutes. If I'll only be viewing with an eyepiece, alignment within 10 arc-minutes is all that's needed. Given the focal lengths you describe, I would think that coarse alignment near enough to the pole to allow successful plate solutions and unintended movement in declination during the 90 degree rotations could be challenging. Even at 270 mm, I can't imagine that image scale is your limiting factor. The QHY Polemaster uses only a 30 mm f.l. lens, and lots of people are very happy with them.

Does the low refresh rate seen in your RDP/VNC window affect the speed at which frames are captured? I've recorded a number of occultations using oaCapture at the far end of a VNC connection several times over the past year, and while the update rate for the video image is sometimes quite low, the number of images written to disk each second is unaffected. I'm running conventional Core i5 or better machines at both ends, though. It may be the case that the RPi runs out of CPU or I/O bandwidth trying to keep up with both the camera and network simultaneously.

If your dome is very heavy, the pipe will probably deform with time, and could take a set when the dome is parked for an extended period. That might make rotation and loading somewhat uneven. PVC pipe gets brittle over time as well, more quickly at elevated temperatures. I don't know how MDPE would behave, but also probably something to investigate before committing to a structure.

As a general rule, electronic components on a circuit board such as pictured above are tolerant of brief immersion. Major exceptions are electromechanical devices such as switches, interconnects between circuit boards or board-to-display, and circuits powered by a high capacity battery. The latter two are the typical killers of mobile phones. When one of those goes under, the first thing you want to do is remove the battery since there's no telling how many unintended circuit paths have been formed. If you have a source of compressed air, it may be worth brushing some isopropyl alcohol on the switches, then hitting them with a good burst from various directions. The alcohol will mix readily with any water which may be trapped in the switch, so a few cycles will help remove it from the internal mechanism. If water is left in the switch, it can lead to corrosion which will reduce reliability and perhaps lead to switch failure. The alcohol will not damage the board or components (it's commonly used to clean flux from circuit boards following assembly or rework) and will not promote corrosion. Finding a replacement fob is advised, since there is risk of early failure from slow corrosion. That path may be complicated if the fob employs a rolling code algorithm for security purposes. (There are some circuit boards with carbon-coated contacts which are commonly used in conjunction with a flexible conductive strip to interface to an LCD or keypad. Such contacts should never be cleaned with alcohol. In this case, there is no reason for concern.)

To me, the questions are, "Do Alpaca drivers work with ASCOM on Windows machines, and are vendors going to provide universal Alpaca drivers rather than ASCOM-specific drivers going forward?" If separate ASCOM and Alpaca drivers are required for Windows vs. non-Windows platforms, I don't foresee many manufacturers putting money into development of the latter. I watched a YouTube presentation about Alpaca given by Bob Denny a few months ago. It looks interesting, but it wasn't clear to me if Alpaca drivers work in the Windows environment. If not, I doubt that there's much future for it -- hardware suppliers will continue to cater to the ASCOM market and for those of us who don't live in Windows land, there's no obvious benefit over INDI.

What may be happening is that oaCapture is confusing the USB device for an external timing module (the Timer device shown in the list of dropdowns at the top of the screen), then waiting for a response it never receives. I'm certain that this can happen if a USB device which uses a Cypress USB/serial transceiver is connected when oaCapture launches. I don't know of a way to convince oaCapture to ignore the USB device, though perhaps James can suggest a workaround. There is a way to distinguish between a timer and other modules which may use the same USB/serial transceiver, but that remedy is not incorporated into 1.7.0. You might try connecting the USB cable for your mount after oaCapture is up and running. I know the program looks for a timer if connected when it launches, but I think it's necessary to rescan if the timer is connected after oaCapture is started. If the hang you describe is related to the situation I described above, starting oaCapture first may get you going.

It appears that you can do what you'd like if you have installed ASCOM. https://docs.sharpcap.co.uk/3.2/#Filter Wheel Control

Unless there's something in Mint 20 that's not in Mint 19, perhaps things would go more smoothly with the earlier release. Mint 19, like Ubuntu 18.04, will be fully supported for a while yet, which will allow time for the developers and package maintainers to catch up with all the new libraries. I've reinstalled since, but I'm pretty sure I had oacapture-1.7.0 and INDI/Ekos/KStars installed on this machine previously when I was considering a move from Mint to Ubuntu. That was an 18.04 installation. I didn't see any issues with library conflicts (though I have to say, I found KStars to be quite disappointing. But that's a rant for a different day.)

So as not to hijack Dr_Ju_Ju's ASCOM-6.5 release thread, I'll start a new one. As stash_old noted, alpaca allows for operation across different machines and architectures. Beside CCDCEIL, Bob Denny reported in a recent YouTube video that OPTEC has networked focusers which are supported by alpaca. What's not clear to me is whether an alpaca driver works on a Windows PC under ASCOM. If not, i.e., a device running in a Windows environment would need an ASCOM driver, but in order for the same device to work in a Linux or MACos environment it would require a separate alpaca driver, then I don't see much future for alpaca. It's basically just doing what INDI set out to do 15 years ago. After all that time, I don't know of a single device which has a factory-supported INDI driver. While there are certainly INDI drivers for some hardware devices, virtually all were written by (usually unpaid) third parties. Few manufacturers will be willing to develop and support separate ASCOM and alpaca drivers so long as Windows/ASCOM dominate the amateur market. One of the other near-requirements for alpaca is that devices be interconnected through Ethernet rather than across USB. While this has many merits, the vast majority of existing hardware devices utilize USB, and I don't see that changing too quickly.

An important question, alluded to by others, concerns your intended use of the telescope. If you will primarily be imaging, you will likely have enough room. For visual observing, it may be tight. Some scale drawings ought to help you see how things might fit. If things are a bit close up top, it may be advisable to lower the mount a bit. At worst this might cost you access to the horizon, though that's generally a simpler trade-off than going into a larger dome.

Thanks to James for his ongoing efforts to support this very useful package. Entirely as a result of the discussion about the recently released 8 GB Raspberry Pi Model 4 started by stash_old on 05-26, I just happened to take delivery of one of those units last Friday. I've completed installation of oaCapture-1.7.0 under the official Raspberry Pi OS (formerly Raspbian) released 2020-05-27 from the packages on the Open Astro Project downloads page. A few notes which may be of use to anyone else installing in an environment where oaCapture has not been installed previously. First, there are some dependencies upon packages not included in the default Raspberry Pi OS distribution. These are listed below. Install in the order shown (there may be dependencies upon libqtcore4 for the other Qt packages). libcfitsio7 libhidapi-libusb0 libqtcore4 libqt4-network libqtgui4 Among the packages on James's download page, libqhyccd depends upon the QHY firmware, so you should install qhy-firmware_20.5.24-1_all ahead of libqhyccd_20.5.24-1_armhf. I installed libefwfilter_0.4.1022-1_armhf and libuvc_0.0.6-2openastro4_armhf, though I don't know if that's significant. Since I was missing a few packages on the first attempt, I had some broken packages but running the following command made everything happy: sudo apt --fix-broken install So far, I've only launched the program as a remote X application, but it came up quickly and looks to be functional. More testing with the cameras I have available to me (along with the mysterious Timer device) to follow. I'm particularly interested in seeing how things go with oalive and our collection of Canon DSLRs.

I'll second the suggestion for stainless hardware, but be sure to apply anti-sieve to the threads before assembly or you'll likely be back in the same boat the next time you need to remove the fasteners. If it were me, I would go with button head socket cap screws.

I've put piers into three different observatories, and none was more than about half a meter in diameter and perhaps 800 mm deep. These were isolated from the surrounding floor, but if you already have a concrete floor in place, I'd give that a go and worry about an isolated pier only if it proves necessary. For short focal length work where you can limit vibrations from people walking around during critical times, you'll almost certainly be fine. I've seen plenty of home observatories with a cubic yard of concrete underground. In almost all cases, the only benefits are to the concrete supplier and the owner's ego. What I find most amusing are the installations with literally tons of concrete supporting a mount on three 150 mm long pieces of 12 mm diameter threaded rod. Nothing says stability like putting a large, moving mass on a tuned structure.

Do you have any way to see traffic between Ekos and the mount driver or between the driver and the mount?

I note some mild correlation between darker green squares and my email exchanges with James. Not that I in any way make it a point to be a troublemaker, mind... :-)

I've used FTOOLS (https://heasarc.gsfc.nasa.gov/ftools/) for this sort of thing in the past, though in a native Linux environment. Installation documentation mentions that you can run on Windows using Cygwin, or of course in a VM running Linux. There's also the CFITSIO library, which is very useful if you want to write your own code.

At Lowell Observatory in northern Arizona, we have a number of Anker USB 3.0 hubs which have performed reliably in sub-zero C conditions. They look to be reasonably priced through our president's favorite mail order retailer.

At Lowell's half-meter telescope, we've got a pair of 5 m USB 3.0 extenders which just barely reach from our computer shelf to the mount. One is dedicated to the mount itself, while the other is connected to a 12-port hub up by the telescopes. This works quite well, though we've seen issues with some devices if the extender is connected to a hub closer to the computer -- daisy-chaining USB hubs is generally not a good idea, so don't do that. The reason for so many ports is that we have two telescopes on the mount with several cameras along with focusers and other instruments. Not all will ever be operated simultaneously, however, so bandwidth isn't an issue. I had no previous experience with USB extenders, but so far I haven't seen any down side to using them.

A variation of this has the motor and drive pinion on a pivoting plate attached to a fixed wall, with weights and/or springs used to provide engagement force. That makes for fixed wiring but still accommodates inconsistencies in the rack. There are generally three challenges associated with these types of drives. The first is start-up torque. If the motor spins up very quickly, the system can experience very large forces as the inertia of the roof is overcome. A high gear ratio which results in slower opening speed is probably the simplest solution, though in some cases DC motors are used and ramped-up to speed. If the gear drive doesn't allow for back drive (e.g., a typical worm drive), you also have to pay a bit of heed to ramp-down at the other end of travel. With a belt or spur gear reducer, you can probably get away with setting the limit switches such that the roof coasts closed approximately where you want it. A second concern is stalling during movement. If something jams, you want to be sure that some mechanism stops the motor before anything is damaged. As Stub noted, a fuse may be sufficient protection. This is always more of a concern with unattended operation since there probably won't be anyone around to hit the stop button if things start going wrong. Finally, loss of power or a drive failure needs to be considered. The last thing you want is the roof stuck open as weather is moving in. If there's a mechanism which allows override using a separate motor such as a surplus drill, that's a good start. But again, if there's a worm drive which may jam, you should probably consider options to disengage it entirely. This usually isn't too difficult with a pivoted mount if the contingency is considered during the design phase.

Those latches look a lot like what I had in mind for my last build. I never found any at the time, but a pair of 6" C-clamps did the job. Not elegantly, but effectively, anyway.

I saw the thermometer in my observatory in the Sonoran Desert wrapped past its 120 F/50 C limit on more than one occasion, with no detrimental effects on the equipment within. While I carried the Dell laptop computer into the house between sessions and never stored eyepieces in the observatory, telescopes and mounts stayed in the building year round. I would be concerned at those temperatures about cemented or oil-spaced optics but I doubt things will get nearly that warm in a temperate climate so far north.

I've found that completing the design to the last imaginable detail in advance, along with giving consideration to the process required to complete construction, helps immensely. Of course, the second part of that is largely experienced-based -- you don't really think too much about how you're going to swing a hammer in some confined space unless you've previously created the need to do so. Perhaps the biggest error I've made (and consistently see others making) when it comes to a building with a movable roof is failure to fully consider the logistics associated with achieving adequate weatherproofing while still allowing for movement. It's not a trivial problem, but getting to the 90% completion point during construction then trying to find a solution is asking for trouble. The second and third roll-off builds I managed were much more successful only because, unlike the first build, I used a CAD program to determine where every piece of lumber and trim would go before the first shovel full of dirt was moved. It's so much easier to move a 2x4 or add 1/2" to the width of the roof trusses on a computer screen than at a building site.

Do you see much thunderstorm activity in Somerset? If so, you may want to consider running optical fiber from the house to the observatory for your network connection. We lost a PC at Lowell a couple of years ago due to a nearby ground strike. I was told that there was literally a hole in the circuit board in the area where previously there had been a serial connector. At that particular facility, the control room is perhaps 15 m from the dome. We still have one RS-232 run between the two buildings, but both ends have to be left disconnected through our summer storm season. (One of my upcoming projects: replace that copper run.) I hadn't read the particular article that you referenced, but I'm generally aware of activities to determine sizes and profiles of outer solar system objects using lots of amateur class telescopes. Some of the folks involved in observing occultations of 2014 MU69 in preparation for the recent New Horizons flyby were amateurs, one of whom I know from my own occultation work here in Arizona. Larry Wasserman published an interesting article about this work on Lowell's site last week. https://lowell.edu/chasing-shadows-to-measure-the-size-of-ultima-thule/