Wireless / Remote Operation
Moore’s law is alive and kicking.
Remote operation is an extremely convenient, if not mandatory, requirement for astrophotography. For the duration of time it takes to acquire images with depth, it makes no sense to sit out in the open, even in an enclosed observatory. There are different levels of “remote operation”, some of which may not occur in the same continent. In this study we are within a stone’s throw, where it is easy to reset power or USB connections in the case of a problem. I operate my system from indoors and initially used a USB extender over CAT5 cable with considerable success. Using this configuration I was able to prove the reliability of the entire system with the applications running on an indoor desktop PC. It did not, however, allow me to acquire video images, since the bandwidth of its USB 2.0 hub was insufficient to stream uncompressed video at 60 fps. This and the fact that in some instances it required three nested USB hubs, prompted an evaluation of other means of remote control. There was something else; at a recent outreach event at a local school it was apparent that I required a wireless system to remove trip-hazards between the computer and the telescope mount.
For some time a number of astrophotographers have searched for a reliable wireless system, concentrating their search on WiFi-based USB hubs. These have existed for some time but always with specific hardware in mind (typically printers and storage devices). At the time of writing, the conflicting protocols did not allow general USB connectivity over WiFi. With the advent of miniature PCs, however, commonly used in multimedia configurations, it has occurred to many that one of these devices may be a better option than leaving a laptop out in the dew. Located at the mount as a local computer running the application software it is remotely controlled through its network interface by a virtually any PC, iOS device or Mac in a less extreme environment.
Small Is Beautiful
This chapter looks at the implementation of such a control hub, using one of the recent Intel NUC (Next Unit of Computing) series of PCs (fig.1). These are fully functional computers that can operate Windows or Mac OS, are approximately 4-inches square and consume less than 10 watts at 12 volts. My particular unit has a Core-i5 processor, 4 USB-3.0 hubs, Ethernet, HDMI and DisplayPort connections. A small Qualcomm® card provides dual channel WiFi (802.11 a/b/g/n) and Bluetooth 4.0 capability and there is space inside for up to 16 GB RAM and a mSATA solid state drive. Using three batteries; “clean”, “dirty” and “PC”, the entire imaging system is self-contained under the mount. The WiFi network connects to a home broadband router and allows remote control from a range of devices, including a Mac, iPad, PC or any other device that will run remote desktop software. In operation, the NUC is not connected to a keyboard, mouse or display and hence it requires some specific setups that allow it to power up, log in, shut down and connect to the WiFi network automatically. Unlike Bluetooth, WiFi has a longer range and a higher bandwidth which allows for feasible remote control above 54 Mbps. In this particular case I’m using a home network but also it is possible to implement a direct computer to computer network too, either through WiFi, a direct Ethernet cable connection or via powerline adaptors in a wired observatory setting.
fig.1 An Intel Core i5 NUC®, sitting on top of my interface box and attached to an external USB 3.0 128 GB SSD. This system is self-contained and just needs a 12-volt power feed. It is controlled remotely through its WiFi interface. The interface box is made of steel and the top of the NUC’s aluminum enclosure is plastic to allow the BlueTooth and WiFi antenna to operate. With this size and power usage, it is safe to place the NUC and SSD drive into a small plastic box and permanently mount it inside an observatory
Of course, a remote PC in the observatory is nothing new. In this particular implementation the NUC is dedicated to the task and is not encumbered by power-hungry Windows themes, drive scanners or unnecessary software. For that reason one must take sensible precautions and use it exclusively with known websites and through secure, firewall-based connections. The reward is a computer that works extremely quickly, since it uses solid-state memory and reliably too, since the short USB connections to the equipment introduce negligible latency. In a permanent setup, it is entirely feasible to house it in a sealed plastic container, with a few small cutouts to facilitate the wired connections (as in the chapter on building an Arduino-based observatory controller).
Remote Control Software
There is a wide choice of remote control software, many of which are free. I use Microsoft Remote Desktop (MRD), which is available for PC, Mac and IOS and whose protocol (Windows Remote Protocol, or WRP) is built into the Windows operating system. Another popular choice is TeamViewer, which requires installation on the host computer and operates through the World Wide Web. This application is often the top choice when the observatory is truly remote, even in a different country. For my setup I use MRD as it is less intrusive and allows direct connections when I am away from home.
The objective here is to have the NUC connected to power and USB peripherals at the mount. It is powered up with its power button and then operated remotely, either via a home network, cable or a direct connection, using MRD. It should be able to be shutdown and restarted remotely and its connections to the network should be automated so that there is no need for a monitor, mouse or keyboard.
To do this requires a few prerequisites:
1It needs to be set up to accept remote access.
2The NUC has to power up without a logon screen.
3It has to automatically connect or generate the WiFi network.
4It also needs a method to be re-booted or shutdown remotely, since one can only log off in MRD.
5It needs a network setup and a consistent IP address for each of the access methods (WiFi router, direct WiFi, cable) so a remote connection is possible.
Setting Up the NUC for MRD (1)
Windows remote desktop compatibility is built into the Windows Pro operating systems and just needs to be enabled: In the NUC’s control panel dialog, select “System and Security” and click “Allow remote access” under the System heading. Now click “Allow a program through Windows Firewall” and scroll down to check that remote desktop is enabled for home and private networks through the firewall. This will allow remote access to the NUC, assuming you have the correct IP address, user name and password.
Automatic Login (2)
For the PC to fully boot, one needs to disable the logon password screen. In Windows, this is clearly a security bypass, so Microsoft do not make it obvious. In Windows 7, if you type “netplwiz” in the Start menu box, it brings up the User Accounts dialog. Deselect “Users must enter a user name and password to use this computer”. This may require an admin password to confirm the setting but once enabled the NUC powers-up and is ready to go within 10 seconds without any keyboard or mouse interaction. (A further setting in the PC’s BIOS setup enables automatic boot with the application of power.)
Shutdown and Restart (3,4)
A normal computer, set up with keyboard, screen and mouse allows you to restart and shut it down. Under remote control, this is not necessarily the case, since some OS versions only allow a remote user to log off. One way to overcome this is to create two small command files, with their shortcuts conveniently placed on the desktop that just require a double-click to execute. These point to one-line text files, named “shutdown.cmd” and “restart. cmd”. You can create these in moments using the Windows notepad application. In the following, note that Windows versions may use a slightly different syntax:
Windows 7 restart:
“psshutdown -r -f -t 5”
Windows 7 shutdown:
“ psshutdown -s -f -t 5”
Windows 8/10 restart:
“%win32%system32shutdown /r /f /t 5”
Windows 8/10 shutdown:
“%win32%system32shutdown /s /f /t 5”
For this to work, Windows 7 specifically requires the PSTOOLS archive in its system folder. In practice, the psshutdown.exe is extracted from the ZIP file and put in the windows/system32 folder. (This archive is available from technet.microsoft.com.) For convenience I placed these .cmd files in a folder with my astro utilities, created a shortcut for each and then dragged then to the desktop. Executing these suspends the MRD connection. (The “f” or “/f” syntax in the above commands is useful in a lock-up situation as it force-quits all applications. The number 5 refers to a delay in seconds. I find this is sufficient time to double-click the shortcut and then quit the remote control connection before the NUC loses communication (fig.2).
fig.2 This simple text file is executed as a command. In this case to shut down a Windows 7 computer, forcing applications to quit. Next to it on the desktop next is the shortcut to the text file, allowing remote control. Note the slightly different protocol for Windows 8 and 10 in the main text. When you execute this, you will lose remote control
fig.3 The startup folder includes two shortcut; the first is to a locally served Astrometry.net plate-solver and the second is to execute the network shell command-line routine in the Windows/System32 folder, with in-line instructions to connect to the home WiFi network. The command line includes the SSID. In practice, the text “SSID” here is replaced by your WiFi network name. This information is obtained by right-clicking the shortcut and clicking Properties > Shortcut. This may not always be necessary if you have instructed your PC to connect to your preferred network elsewhere in one of the numerous alternative network settings dialogs
fig.4 In the case of an automated connection to a WiFi router, check the wireless network connection TCP/IPV4 properties. If you have set up your router to give the NUC a static IP address, then you can leave the general settings to automatic, as shown opposite. This is my preferred approach for reliable and repeatable connections. To set up a consistent IP address for a wired connection requires a different approach, shown in fig.5
Network(s) Setup (5)
Home Network
At home, the most convenient way to connect to the NUC is via a wireless router. To do this, MRD requires the IP address of the NUC WiFi connection. Most routers dynamically assign IP addresses, depending on the order of connection. That poses a problem if the IP address changes every time it connects, since one cannot talk to the NUC “user” to find out what it is! The answer is to create a static IP address. Luckily a good router allows one to set a static IP address for a particular connection (fig.4). The instructions are similar but vary slightly between router models. It is very easy with my Airport Extreme; I type in the MAC address of the NUC computer connection (found in the wireless network connection status, often called the “physical address” and which comprises of six groups of two hexadecimal characters) and assign an IP address, something like 10.0.1.8. When connected to the router, this becomes the IPv4 address of the connection, found in the Network Connection Details screen on the NUC, or by typing “ipconfig” in a Windows command screen.
In the MRD profile settings on the remote PC or iPad, enter this same IP address as the “PC name” and your normal NUC user name and logon password into the fields of the same name. MRD allows for multiple profiles (or “Desktops”) and I typically have three; home router, direct WiFi and direct cable connection.
In practice, it is useful to check these system set-ups with the NUC hooked up to a display, mouse and keyboard. (If something goes wrong, you still have control over the NUC.) Next, try and connect to your home network with the applicable SSID security passwords to ensure it is set up for auto-connection. To do this, check the settings in “Network and Sharing Center”, on the “manage wireless networks” tab.
With these settings the NUC boots with power application and sets up the network connection. Next, head over to your remote PC/Mac/iOS device and connect. On the initial connection, there is often a dialog about accepting certificates and are you really, really sure? (These pesky reminders reoccur until one instructs MRD to permanently trust this address.)
Ad-Hoc Network
If you are away from home, there is no router to assign the IP address for the NUC. It is still possible to connect both computers with an ad-hoc network. This is a direct link between the NUC and your remote PC/Mac/iOS device. This requires a little ingenuity to set up, since a wireless service can only have one set of properties. In Windows 7:
1Click on the network icon in bottom right of the task-bar, and Click Open Network and Sharing Center or Control Panel>Network and Internet>Network and Sharing Center
2Click Manage Wireless Networks > Add
3Manually create a network profile
4Enter your preferred network name (SSID), and no authentication (open) or encryption
5Uncheck “Start connection automatically” and “Connect even if the network is not broadcasting”
6Click Close
7Click Start on the desktop and in the dialog box type “CMD”, then Enter
8At the command prompt type:
“netsh wlan set profileparameter name=SSID “ “connectionType=IBSS”
In the above, substitute “SSID” for the name of your ad-hoc network. This will change the connection type to ad-hoc and you will no longer have to type in the network key. As before, to get the ad-hoc network to setup automatically when the NUC powers up, we can add a command to the startup folder (fig.3) and removing or swapping over the one for the home router.
1Click Start > All Programs > right click Startup and click Open
2Right-click on empty space and click New > Shortcut
3Type in “netsh wlan connect SSID” (again, substitute “SSID” for the name of your ad-hoc network)
4Click next and enter a name for the command, something like “auto ad-hoc”
5Click Finish
You also need to set up a static IP address for the ad-hoc network: In the Network Connections window, right-click on the wireless network icon and select properties. Click on Internet Protocol Version 4 (TCP/IPv4) and Properties. The General tab is normally used for the router connection and is typically set to Obtain an IP address (and DNS server address) automatically. To set up a static ad-hoc address, click on the Alternative Configuration tab. Click User configured and type in an IP address. Pressing the tab button should automatically update the Subnet mask boxes (fig. 5). If the network cannot connect with the primary address within 2 minutes, it defaults to the alternative (static) address, allowing ad-hoc connection. The easiest way to do this is to look at the physical address of your client computer and copy its IP address over to the NUC, but change the fourth number. The subnet for both computers should be the same. With an ad-hoc network, you need to wait 2 minutes for the NUC to default to the alternative configuration and then search and join with the client computer.
fig.5 In the case of an ad-hoc connection to a remote computer, check the wireless network connection TCP/ IPV4 properties. In the alternative configuration, set the IP address of the client computer, but make the last set of digits unique
fig.6 In the case of a wired connection to a remote computer, check the Local Area Connection TCP/IPV4 properties. In the general tab, type in an IP address in the same range as the client computer, but change the last set of digits. Both client and remote computer should have the same subnet mask
Wired Network
WiFi connections are convenient but not always necessary. It is also possible to connect the NUC and the PC with an Ethernet cable. Normally one needs a crossover variety between PCs. The MacBook auto-detects the connections and can works with an ordinary patch cable. (It sometimes fails on the first connection attempt, but connects on the second.) The cable connection is faster, most notably during image updates on screen, and is less susceptible to interference from other users. To connect to the NUC one needs to set the IP address (fig.6). This is found in the LAN hardware IPv4 properties and this address is also entered as the PC name in a MRD profile, along with the customary NUC user name and password (fig.7).
fig.7 On the client computer, remote access requires three pieces of data: the IP address in the PC name box, your remote computer’s user name and its password
Ethernet Through Mains
If your NUC is in a protected environment and has a local mains supply, a third variation is to use a pair of powerline adaptors, which transmit a high frequency data carrier over the domestic mains circuit. With these, place one next to the NUC and the other close to either your broadband router or the host PC. Set the router to a static IP address for the NUC’s MAC address and use this in the MRD profile for both remote and Internet connection. Alternatively, add an alternative static IP address in the NUC’s Ethernet adaptor IPv4 properties, for direct cable connection to a host PC. These devices operate at a range of speeds, up to 1,200 Mbps and avoid the need to thread another cable from the observatory to Houston Control. There are a range of models, with the more advanced versions using the earth wire as well as live and neutral, to improve range and robustness. Some offer multiple ports too, for additional accessories. In practice, for these to configure themselves correctly, I found I needed to connect these up fully to both computer systems before switching the NUC on. In practice, my wired connection over 550 Mbps powerline adaptors is considerably more responsive than the WiFi. This is particularly useful if you wish to extend the remote desktop over two displays and became possible with the introduction of Windows 10. It is the principal reason I use Windows 10 over Windows 7 (fig.10).
fig.8 A typical Ethernet over mains (powerline) adaptor is an alternative to a hard-wired Ethernet connection, provided you have a safe mains installation at the observatory. Once paired, it allows direct access to a connected computer or if configured through a router, to any Windows, iOS, Android or Mac device on your home network. This one has a modest speed of 200 Mbps but others go up to 1,200 Mbps and use live, neutral and earth connections for more robust transmissions. I seal mine in an IP65 enclosure within the observatory, kept company by a small bag of desiccant. In practice, I connect the LAN system before powering-up the PC, to ensure it assumes the right LAN configuration
In Operation
Depending on whether I am at home or at a dark site, I have two startup shortcuts on the NUC, like the one described above, one for the home network and another for the ad-hoc. The home network automatically configures itself on power-up to the available WiFi or LAN network for wireless and cable operation. I keep one on my desktop and the other in the Startup folder; switching them over before a change of venue. With the alternative static address, I am able to connect to the NUC after a 2-minute wait. To connect, the IPv4 address is entered into a MRD profile as the PC Name along with the NUC’s Windows user name and password, as before.
On my iPad, MacBook or iMac, I have several MRD connection profiles, two for home and another for away. When I power the NUC down, or restart it, after hitting the command shortcut on the desktop, I close the MRD connection before the NUC powers down. That leaves things in a state that makes a subsequent re-connection more reliable. I have also noticed that MRD works more reliably, after making changes to the connection settings, if the application is closed down and opened again.
To ensure the NUC runs fast and lean I change the desktop theme to a classic one, without power hungry animations or background virus checking (though Windows Defender checks any installable files). Automatic updates are disabled and the computer is only connected to the World Wide Web through a hardware firewall. Browsing is restricted to safe websites for drivers or on secure forums. In the advanced power settings, to prevent Turbo Boost that doubles the processor clock speed and power consumption, I set the maximum processor power state to 80% and apply aggressive power savings throughout the advanced power settings (but disable shutdown / sleep / hibernate modes). The important exception to the rule is to maintain uninterrupted USB and network communications. To ensure this, disable the USB power saver options both in the advanced power settings and in the device driver properties accessed via the hardware manager. (These recommendations are not only applicable to remote operation but to any PC connected to astro-hardware.)
fig.9 During the setup phase (including the installation of the operating system, drivers and applications) it is useful to connect the NUC to a monitor, mouse and keyboard as a normal computer and check it runs the hardware correctly for a few weeks. In this case, it is communicating over a USB over CAT 5 interface system to the mount’s USB hub
Lastly, although this NUC has a 128-GB solid state drive (SSD), I store the exposures to an external drive for convenience. At first, since the NUC had four USB 3.0 ports, I used a high-speed USB 3.0 memory stick. Unfortunately this particular model would not permit the NUC to power down while it was inserted. There are some peculiarities around USB 3.0 operation and eventually, I installed a 128 SSD drive into a USB 3.0 caddy as an image repository. If you format the drive as FAT32 rather than NTFS it is readily accessed by any computer without the need of special utilities. (In the past I have tried NTFS to HFS+ file system-interchange utilities, but after several corrupted files and poor support from the supplier, I made the decision to avoid the reliability issues entirely, rather than take a chance with valuable data.)
Moore’s Law (After Gordon Moore)
The opening picture shows the initial deployment of the NUC in a portable setup, sitting on the tripod’s accessory tray under the mount. It is now sited within the observatory, nestling against the drive caddy and a bag of rice, to keep things arid. Observatories are great but it is a chore to dismount equipment off a pier and lose precious alignment and modelling data just for an occasional field visit. A second highly-portable imaging system is the logical solution (described in its own chapter). The NUC is ideal; its small footprint has 4 USB ports, a 12-volt DC power feed and additional connections. Ideal that is, until you see the next development: Stick computing. These PCs are just 38 x 12 x 120 mm and make the NUC look obese. As Will Smith declared in Independence Day, “I have got to get me one of these!” The Intel versions come in a few configurations: I use a Core M3 version, which has 64 GB SSD, 4 GB memory, USB 3.0, WiFi and Bluetooth built in (fig.11). It has a separate 5-volt, 3-amp DC power supply, fed via a USB-C cable. This is the same cable used by the latest Apple Macbooks. I do not use AC power in the open for safety reasons so I use a high quality 3-amp 12–5 volt DC–DC converter module via a power cable adaptor with a DC plug on one end and a USB-C adaptor on the other. The smaller form factor of the PC also means that it runs warmer than the NUC and this model has active cooling. A full installation of Windows 10 Pro, with all the image acquisition and control software occupies 20 GB. That assumes a compact planetarium such as C2A. (This figure increases rapidly if The Sky X is installed with its All-Sky catalog or large astrometric catalogs, such as USNO A-2 or the larger UCAC catalogs.) A micro-SD card slot boosts the storage potential by another 128 GB, ideal for storing images and documents. Moore’s law certainly seems to be alive and kicking.
The forums are a wonderful source of information and while discussing the feasibility of using a PC stick for astrophotography, I was made aware of an alternative to using an ad-hoc network for direct WiFi connection. This uses a wireless access point (AP), rather than an ad-hoc protocol. Access points, unlike ad-hoc networks operate at the full adaptor speed. There are ways of doing this manually but it is convenient to use a utility like Connectify. In a few mouse clicks, it modifies the existing WiFi connection into two, one for the Internet and the other for remote access, with or without Internet sharing. Either connection can be used for remote control; in both cases, one uses the IP address of the IPV4 connection for the PC Name in Remote Desktop (shown in the WiFi properties tab) and in the case of the access point (also known as a hot-spot when it allows Internet sharing), note the SSID name and security password. On the host computer connect its WiFi to this SSID and then in MRD, select the configuration for the access point IP address and connect with the remote computer’s login and password. It works, but the effective data rate is much slower than with other configurations.
fig.10 Just to give an idea of how useful a two-screen remote operation can be, this screen grab is of a Macbook pro connected to an external monitor (two-screen requires Windows 10). From the left is Sequence Generator Pro, my observatory app, AAG CloudWatcher and PHD2 on the 20-inch monitor and TheSkyX planetarium and telescope control occupies the laptop screen on the right. If you operate this over WiFi, the screen update may be too slow. A LAN solution, as described in the text, is quicker
fig.11 A Core M3 Intel computing stick. The HDMI connector on the end gives a sense of scale. It has one USB-3.0 connector, supplemented by another two on its power supply (connected via a USB-C cable)
In practice, via my router, very and with an un-powered 4-way USB hub, drove a USB to serial converter, Lodestar X2, focus module and QHY PoleMaster. In AP mode, however, the WiFi range of the stick is limited and a faster and more reliable alternative is to use a small USB-powered WiFi router. My one operates at 300Mbps and is just 2.5 inches square (fig.12). These can be set up to work as an access point, router or extender and in practice works reliably over 30 m (100 feet). I prefer to use it configured as an access point, connected via its Ethernet port using a USB to Ethernet adaptor. I use the stick’s own WiFi connection for Internet use and connect to the TP-Link with my computer or iPad, running MRD.
Really Remote Operation
Folks are increasingly setting up remote rural observatories and operating them over the Internet. The configuration here is also the basis for such a system. In practice it needs a few more settings to allow remote Internet access. There are two principal methods: to use a VPN (virtual private network) or allow direct communication through the router’s firewall. The VPN route is arguably more secure and in effect, both computers log into an Internet server and talk to one another. An Internet search identifies a range of paid and free VPN services. The other method configures your firewall to allow a direct connection. Using the setup utility for your Internet router, add the IPv4 address to Port 3389 in your router. At the same time make sure you are using a strong password for your astro PC with plenty of strange characters, capitals and alphanumerics. Remote access uses the IP of your broadband router. Since a default router configuration dynamically assigns an address upon each power-up, one either has to set up a static address, or leave the unit powered and check its address by typing in “whatismyip.com” in a browser window. If in doubt, the Internet is a wonderful resource for the latest detailed instructions on how to change network settings.
fig.12 The diminutive TP-Link TL-WR802N USB-powered WiFi AP/router/bridge/repeater can be either located at the mount or by the host computer. You can connect to the PC via a USB/Ethernet adaptor and use the PC WiFi to connect to the Internet. Windows will default to using Ethernet for Internet access unless you disable the Automatic metric for both adaptor’s advanced IPv4 properties and assign a lower number to the WiFi adaptor than to the Ethernet adaptor.
Other Remote Controls
In addition to remote computer operation, you may require further remote controls; for instance to provide facilities for resetting USB and power to individual devices. It is a fast moving area and Ethernet controlled power devices are starting to hit the market. There is an ASCOM switch device interface definition and a driver for power control using Digital Loggers Inc. Web Power Switch. These are currently designed with U.S. domestic power sockets but I am sure European versions will follow soon. (Simple relay board systems already exist but have exposed live terminals that require safe handling and housing.)
Switching USB connections will not be too far behind. A simple relay or switch may not suffice since, whilst it is okay for switching AC and DC power, USB 2.0 is a high-speed interface and all connections and circuits need to have the correct inductive and capacitive characteristics (impedance). If they do not, the signal is degraded and may become unreliable. For those with an electronics background another way is to configure a web-linked Arduino-based module to reset USB power and data signals. The alternative is to call an understanding neighbor or spouse! In the last year the first commercial Arduino-based observatory controllers have hit the market, dedicated to managing power, USB connections, focuser and dew heater control and are worth looking out for.