ASCOM Alpaca - ASCOM is not just for Windows any more

If you are new to ASCOM in general and plan to develop an Alpaca app or driver, is is strongly suggested that you first go through the About Alpaca and ASCOM section and then return here. Next, please understand the critical Alpaca Scope of Application below in order to prevent a naive disappointment. Then familiarize yourself with all three sections of the Design Principles in the orange menu on the left. Please invest some time to check it out before getting heavily into your development. Finally in the Resources section on the right, as well as in the orange menu on the left are libraries and templates that you can use for applications and devices using both C# and Python, both of which are cross-platform

Classes of Alpaca Hosts

Alpaca hosts can take several forms including both combined device/driver and the classic separate device and driver forms used with classic ASCOM/COM:

• Microcontrollers: e.g. Arduino / Pi Pico / ESP32. These are less expensive, lower capability devices that are challenging to code and where coding is done at the Posix / BSD socket level. Development is done on other devices and code downloaded to the devices. Dedicated libraries can help development on these systems e.g. the Dark Dragons Astro library for ESP32 devices.
• Single Board Computers: Raspberry Pi / RADXA – A range of devices with differing capabilities and price points e.g. Pi 0/4/5, RADXA X4. These most often run Linux and can host Python SDK devices or C# Alpaca Device Template devices.
• Separate Device and Driver: This reflects the traditional ASCOM/COM architecture where a device is separate from its Alpaca driver. Typical use cases would be existing devices where ASCOM capability is not yet avaailable. In this case the Alpaca driver is hosted on a PC, Mac, or Linux, typically with serial or USB connections, just like ASCOM/COM drivers of the past. In fact we recommend that newly developed separate drivers be Alpaca instead of COM. Drivers can be developed using the C# Alpaca Device Template or the Python SDK.

CRITICAL Alpaca Scope of Application CRITICAL

Alpaca is designed to provide simple point-to-point universal connectivity within an observatory between client applications and devices in the same way that COM does in classic ASCOM. While it is a network protocol, Alpaca's design purposely does not include device-level hardened security measures that would be needed on the open public or campus internet. Instead it is intended to be used within an isolated protected in-observatory local network. This keeps coding minimal, implementations lightweight, and management simple.

Simply stated, Alpaca and network security are separate things. Alpaca does the job of providing apps with device access. Since security is an open-ended topic, combining the two could easily cause a device's astronomy functions to be completely drowned out by its internal security provisions. Keeping them separate also eliminates the need to prove to security personnel the "safety" of the implementations within each device in the observatory, an impractical task for manufacturers of the devices and for observatory managers as well. Finally, device level security means that applications have to become more complex in order to manage every device security scenario, thus more complexity and safety testing/certification.

Placing control apps and devices within a secure envelope offloads the need for security to well known trusted network tools and topologies with the strengths needed by the user. A simple home or club observatory can operate behind a common NAT router with appropriate IP whitelisting and port mapping without practical risks of hacking the devices. A multi-tenant shared observatory might not be a hostile environment, but if a hostile or bumbling tenant were encountered, it could cause trouble for other tenants. Most remote shared facilities eventually find that they need to use use VLANs or tenant VPNs to provide isolation and protection.

Also, Alpaca is not designed to provide an entertainment system for providing read-only monitoring of devices. Such a facility would need to use a hub of some sort both to protect the devices from high-demand read accesses, as well as to provide the high-security required for public or campus network access. An example hub would be a multi-homed Apache web server with carefully controlled and cached back-end access to the observatory net's control system and devices, plus front end high-security access to the public / campus net.

Driver Design Principles

The interface specifications aren't the full story! There are some vital design principles that, if adhered-to, will maximize the chances that your driver will operate properly with a variety of client software. See the Design Principles topics in the orange menu at the top left and repearted here:

• The General Principles
• Asynchronous APIs
• Exceptions in ASCOM (applies to Alpaca!)

Alpaca Documentation

We have extensive developer level introductory and API reference documentation for Alpaca online here. See the links in the orange box menu at the upper left, as well as the Developer section of our Documentation Center.

Help - Use the Developer's Forum

As a developer, we ask that you seek help and information using the ASCOM Talk Developers Forum.

Visit the ASCOM-Talk Developers Forum

Common Traps and Mistakes (mostly for Alpaca driver developers)

It probably seems unprofessional to start this section with what not to do, but we're just trying to save you time and pain.

• Not understanding the driver-client architecture and that your driver will be used by many applications, some of which don't yet exist. See About Alpaca and ASCOM.
• Using sources for another driver (or worse, one of the simulators) as a starting point (you start with other peoples' mistakes and the wrong design)
• Exposing timing restrictions or other device quirks to driver clients (they don't want to do stuff just for your goofy device)
• Not following the capitalization of key words in Alpaca REST-Like/JSON messages as documented in the API Specification. JSON is case sensitive. JSON also always uses '.' for the numeric decimal point, not ','.