Alpaca camera and mount client

[mikefsq]

Add Alpaca camera and mount client.

[agalasso]

Thanks for the PR!

A couple high-level comments before we review in more detail.

1. copyrights: for all new code going forward we assigning the copyright to "PHD2 Developers". Could you please update the notices like this:

 *  Created by mikefsq
 *  Copyright (c) 2026 PHD2 Developers
 *  All rights reserved.

We're happy to keep your name there as the creator and we will add you the the contributors list (Help > About) as well.

2. throwing exceptions. The code base currently avoids throwing exceptions other than strictly within a function or method -- an exception thrown in a function is caught in that function; this convention has served us well over the yeas as there is simply no possibility of an unhandled exception. This code appears to lean on raising and catching exceptions, which goes against the existing convention in the code base. Could you please look into eliminating throw/catch as much as possible and instead use function return values to propagate errors.

[mikefsq]

I updated this following cam_ascom.cpp, so now it has pure return values with a Debug.Write at each failure.

[bwdev01]

Thanks for the contribution. Can you give us some more background on this? Is it the product of agentic development with something like Claude? To what extent has it been tested?

[agalasso]

very nice PR!
great work on the error handling and bounds checking
I think we should merge this once Bruce's questions are resolved.

[mikefsq]

Sure, I've switched to using only alpaca drivers for my imaging running on a raspberry pi, or on a Mac mini, and it is working nicely. Adding this alpaca interface lets phd2 connect the same way the imaging client does.

I have tested it to some extent, and do use it for imaging -- and it works well for me. But since this will interface with third party drivers there will be bugs (and I'll help fix).

The interface itself is a very simple http protocol mapping to pretty much the same interface the older Ascom drivers use (which is defined in phd2). So this was a perfect bounded task for Claude, plus some manual cleanup.

Using libcurl accomplishes the mapping with minimal dependencies and is cross platform. The official library is C#/.NET and that is going to be a larger change for a cross platform build process.

For anyone else testing this I will write some new alpaca drivers if they send me the device name (and help with some debugging since I don't have the device).

[bwdev01]

I think the PR makes a reasonable start but I don't think it's ready to be merged, at least not for the Windows platform. I suspect the definition of work used with Claude is not quite what we want. The Alpaca API isn't just "pretty much the same as ASCOM", it is identical. That's the most important part of the Alpaca design. That means that a Windows user should see no differences at all between using an ASCOM mount driver and an Alpaca-compliant driver for the same type of mount. Remember, Windows is the reference platform for all of this. In order to achieve that, every single behavior in scope_ascom needs to be mirrored in scope_alpaca - which isn't the case yet with this PR. Based on maybe a 20-minute inspection of the code, here are some of the missing pieces:

1. There are no alerts of any kind to notify users of problems
2. Most of the diagnostic debug log entries we rely on for support are missing
3. Many commonly encountered error conditions - e.g. "not connected" errors - are not reported clearly
4. The check for unexpected mount slewing is done unconditionally rather than being controlled by the UI property
5. There is an incorrect function return when the reported guide rates are invalid
6. A 'connect' operation isn't handled on a background thread. I don't know how this behaves because I'm only doing a source inspection - but if the connect operation over the network is synchronous, is the UI blocked?
7. The 'connect' functionality doesn't take advantage of most of the 'Can_XXX' properties that are part of the interface. Instead, it simply bangs away with an operation that may not be supported, meaning that log files on both ends of the interaction get filled with error messages that could have been avoided in the first place.

I think a review of the PR is going to require a line-by-line comparison between both the Alpaca/ASCOM mount and camera implementations to insure parity. I would also like to get a better understanding of the limited testing that has been done. What was the network topology being used and what cameras and mounts were involved? What is the timing behavior seen when an Alpaca-compliant camera is being used in single-exposure mode over a network? Even when implementation parity is achieved between the two device types, I think there needs to be more field-testing before the Alpaca capability shows up in a mainstream release. Of course, this could be mitigated to some extent if the capability is initially confined to Linux and Mac platforms.

[mikefsq]

The Alpaca files compile on MSVC with no warnings from /W4 and /analyze, and these builds guide and calibrate against a sim. So both x86 and x64 builds are working.

I did a lot of testing using a proxy to manipulate requests in order to trigger all of these warnings, and also to introduced various kinds of network instability.