21 replies to this topic

[artik]

My OpenLiveStacker can use Indi for mount and camera. Currently it runs on Linux and Android.

 

There is nothing significant that prevents it from building it on Windows (maybe minor patches), however there is big issue.

 

I can run indi client on Windows but not indi server.

 

Question is there ASCOM to Indi bridge so that I can use indi client with ascom driver so I will not need to use ASCOM API for camera and mount.

 

Is there anything like that?

[NearVision]

There was a program from cloudmakers.eu called windi. They don't have it on their website anymore but I did find the page on the internet wayback machine. https://web.archive....akers.eu/windi/

 

Maybe contacting them for the old source code? I've also seen a few references to running indi in cygwin. I haven't kept up on windows development so I'm not sure if cygwin is still the best option for running linux software in windows. I know that running in a virtual environment isn't the best option...

[artik]

There was a program from cloudmakers.eu called windi. They don't have it on their website anymore but I did find the page on the internet wayback machine. https://web.archive....akers.eu/windi/

 

Maybe contacting them for the old source code? I've also seen a few references to running indi in cygwin. I haven't kept up on windows development so I'm not sure if cygwin is still the best option for running linux software in windows. I know that running in a virtual environment isn't the best option...

Yeah I followed it and it seems to be unmaintained.

 

Easiest way to run indi on Windows in WSL - but the idea was build a native windows app. And have some bridge.

 

Anyway simplest stuff would be add Alpaca (not ASCOM) client and have ASCOM Alpaca bridge since from what they say at ASCOM web site using it from C++ is going to be a major headache.

Edited by artik, 03 May 2025 - 07:17 AM.

[Bob Denny]

Anyway simplest stuff would be add Alpaca (not ASCOM) client and have ASCOM Alpaca bridge since from what they say at ASCOM web site using it from C++ is going to be a major headache.

Yes. Alpaca is like ASCOM but built on TCP/HTTP/REST-API. Same universal interfaces but free of COM and Windows. See ASCOM Master Interfaces (Alpaca and COM). This document does not talk about COM or Alpaca but focuses on the universal interfaces for each device type. The specific REST API protocol for Alpaca is described in Alpaca API Reference V9 (May 2023) and demonstrated via a live OpenAPI Browser that describes all of the interfaces described in the Master doc. 

 

The ASCOM Alpaca bridges already exist in both directions. Any existing ASCOM-speaking Windows app can talk to an Alpaca device on any platform via the ASCOM Chooser which automatically discovers Alpaca devices and will build a bridge driver to a selected device. Going the other direction, any ASCOM (COM) speaking windows device can be given an Alpaca presence via the ASCOM Remote Server, making it reachable from any platform on the LAN.

 

I should note that one popular Windows app, NINA, speaks "native" Alpaca as well as ASCOM so no need for a bridge between NINA and an Alpaca device. Also note that there are already a number of self-contained Alpaca-speaking devices and some other apps that speak Alpaca. The cool thing about the self-contained devices is that they need no library, no driver, and no USB. To see what's out there, have a look at our Public Outreach website, specifically the Product Showcase. 

 

If you work in Python, see the Alpyca package for applications and the AlpycaDevice SDK for devices. C# driver templates are coming soon.

Edited by Bob Denny, 03 May 2025 - 04:01 PM.

[artik]

Basically I'll need to have at minimum an alpaca interface for OpenLiveStacker to use it on Windows.

 

Having RESTful API will for sure make it easier. OLS is mostly implemented in C++ so not having to deal with COM is kinda a good thing 

 

Question what is the software/services that provides ASCOM->ALPACA bridge? Does it support ImageBytes for camere?

(Never used Windows for astronomy - mostly Linux user myself)

[Bob Denny]

Question what is the software/services that provides ASCOM->ALPACA bridge?

Both direction "bridges" (dynamic drivers and ASCOM Remote Server) support ImageBytes image transfer. The Alpyca python app package supports ImageBytes. 

 

Basically I'll need to have at minimum an alpaca interface for OpenLiveStacker to use it on Windows.

You would need to implement the client (app) end of Alpaca then. While you develop, you may find the Omni Simulator useful. It will run on Linux as well as Windows, and it has a fully functional Alpaca camera simulator, along with a live/functional OpenAPI/Swagger browser you can use to exercise your app's camera interface. With Alpaca you could run OpenLiveStacker on Linux and use a camera that is hosted on a WIndows system, or vice versa.

 

PS Congratulations on your new release!

Edited by Bob Denny, 03 May 2025 - 07:03 PM.

[ButterFly]

For sanity's sake, it suggest adding alpaca support to your current linux/android implementation first.  Worry about porting over to windows later.  Your alpaca portions will be ready to go, with UI being your main concern for porting.  Let the dynamic chooser in windows take care of doing the actual alpaca to device conversions.

 

Your codebase is already c/c++, so take a look at the code in ESP32 ASCOM Alpaca Implementation.  That will jump start your understanding of the client/server base.  AscomRemote, is written in c#, so you will need to refactor, but the building blocks for handling camera specific things are there.

 

For the actual implementation, take a look at, and start from, ASCOM ALPACA bridge agent.  This is a bridge between alpaca and INDIGO, rather than INDI.

 

Bear in mind that there are no native alpaca telescopes yet, and only a handful of native alpaca cameras.  One still needs to use a computer to turn the hard wired serial connections into alpaca devices, in the vast majority of cases.  Nonetheless, that is still useful for OpenLiveStacker.  My phone and tablet have only one USB port, so it's either camera or telescope for me, from OpenLiveStacker.  The telescope goto portions I still handle with SkySafari on the device, so I haven't tried the telescope support in OpenLiveStacker yet.  If alpaca were baked into OpenLiveStacker, I could use both OpenLiveStacker and SkySafari at the same time to work with the scope.

[artik]

For sanity's sake, it suggest adding alpaca support to your current linux/android implementation first.  Worry about porting over to windows later.  Your alpaca portions will be ready to go, with UI being your main concern for porting.

 

Actually implementing Alpaca interface is the major part of Windows port. The rest is trivial for a simple reason OLS uses web interface. OLS C++ uses CppCMS for web/restful interface - and this what allows poring to both Linux and Android easily. The only "Linux Specific" part is indi/indigo since indi/indigo server does not run on Windows.

 

On Linux indi and indigo do great job and they are open-source making stuff easy (this allowed poring of indi/telescope parts to Android)
 

Your codebase is already c/c++, so take a look at the code in ESP32 ASCOM Alpaca Implementation.  That will jump start your understanding of the client/server base.  AscomRemote, is written in c#, so you will need to refactor, but the building blocks for handling camera specific things are there.

 

I would be easy to use REST API from C++. From what I understand AscomRemote is the middleware that allows access of ASCOM drivers via Alpaca REST protocol?

Or is there something else? Is it de-facto common Alpaca wrapper of ASCOM drivers?

 

 

Bear in mind that there are no native alpaca telescopes yet, and only a handful of native alpaca cameras. 

 

 

I don't look at Alpaca as "driver" level. I mean it is clearly does not provide same functionality same as indi does. I mostly look it as REST based interface for ASCOM. Allowing me not to tinker with COM and having cross platform access to devices connected to windows

 

I'm totally aware that Alpaca (unlike indi or indigo) is basically protocol and not much more.

 

 

One still needs to use a computer to turn the hard wired serial connections into alpaca devices, in the vast majority of cases.  Nonetheless, that is still useful for OpenLiveStacker.

 

I assume it is mostly useful as wireless ASCOM. And if needed remote access from OLS running on Android (similarly it can access indi server)

 

 

My phone and tablet have only one USB port, so it's either camera or telescope for me, from OpenLiveStacker.

 

Actually for camera only few vendors provide Android support for camera (ZWO, ToupTek and QHY) and mounts currently accessible only via wifi. Probably as some day it would be possible to use USB hub to connect mounts via serial port 

 

 

The telescope goto portions I still handle with SkySafari on the device, so I haven't tried the telescope support in OpenLiveStacker yet.

 

The problem is that you want connection between OLS and mount for stuff like plate solving and alignment. That is why I ported indi mount support to Android (i.e. indi telescoe server runs on Android). And actually OLS and SkySafary Plus with indi work very well.

 

If alpaca were baked into OpenLiveStacker, I could use both OpenLiveStacker and SkySafari at the same time to work with the scope.

 

They already do via indi, but if windows hosts the actual camera and mount it would be useful indeed.

 

 

So for me the major step using Windows with OLS is to implement Alpaca client in OLS :-) 

[ButterFly]

I would be easy to use REST API from C++. From what I understand AscomRemote is the middleware that allows access of ASCOM drivers via Alpaca REST protocol?

Or is there something else? Is it de-facto common Alpaca wrapper of ASCOM drivers?

 

 

 

I don't look at Alpaca as "driver" level. I mean it is clearly does not provide same functionality same as indi does. I mostly look it as REST based interface for ASCOM. Allowing me not to tinker with COM and having cross platform access to devices connected to windows.

 

Exactly, exactly.

 

With alpaca, you are talking to a server - not the device itself.  So, in windows, let's say you have a telescope directly connected to the mount.  There are no native alpaca speaking telescopes yet, so the user has to use AscomRemote to connect to that telescope through ascom, then ascom remote creates a server, which is an alpaca device containing that telescope.  Software talks to that server - not the telescope, or the ascom driver of that telescope.  That software that talks to the server can be running on windows, android, ... .  That's where the port to windows from linux will be easy.  You're still just talking to the same server, in the same language, just from somewhere else.

 

In linux, you need the bridge because there is no "AscomRemote for linux" yet.  The alpaca/indigo bridge above does exactly what AscomRemote does on windows - it translates between the server and the device.  Once your program talks to the server, it doesn't matter which operating system the server is actually running on.  It's only accepting http commands!

 

So, to port to windows, you would simply stop talking to alpaca/indigo bridge server.  The alpaca server commands are the same, right.  Instead of sending those commands to the alpaca/indigo bridge server, you send them to the AscomRemote alpaca/ascom bridge server.  The IPAddress changes, and that's it!  You don't need to worry about COM at all - AscomRemote is taking care of that for you.

 

So, for the specific case of syncing a mount to your solved coordinates:

In linux, you would send the synctocoordinates alpaca function to the IPAddress of the server running the alpaca/indigo bridge server.

In windows, you would send the synctocoordinates alpaca function to the IPAddress of the server running the alpaca/ascom bridge server.

[ButterFly]

So, let's say that next year, there is a telescope mount with native alpaca support.

 

The only difference is there the bridge is now internal to the device, and doesn't need an intermediary on any separate operating system:

In either linux or windows, you would send the synctocoordinates alpaca function to the IPAddress of the server running the mount's internal bridge server.

[artik]

In linux, you need the bridge because there is no "AscomRemote for linux" yet.  The alpaca/indigo bridge above does exactly what AscomRemote does on windows - it translates between the server and the device.  

 

I actually don't since indi on Linux is what ASCOM + Alpaca is on Windows and indi works quite well and open source - (unlike most ASCOM drviers)

 

But it is a different story it is a question of vision. I don't see Alpaca replacing indi or indigo in any nearby future.

 

BTW I originally wanted indigo due to its bus design allowing both local and remote access till I discovered there were no Alt-Az drivers for skywatcher and it was a major problem for me. Otherwise poring indigo would have been way easier to Android.

 

The fact that there are FOSS drivers for mounts thanks to indi/indigo - this what made the OpenLiveStacker mount control possible

[ButterFly]

I actually don't since indi on Linux is what ASCOM + Alpaca is on Windows and indi works quite well and open source - (unlike most ASCOM drviers)

 

But it is a different story it is a question of vision. I don't see Alpaca replacing indi or indigo in any nearby future.

 

BTW I originally wanted indigo due to its bus design allowing both local and remote access till I discovered there were no Alt-Az drivers for skywatcher and it was a major problem for me. Otherwise poring indigo would have been way easier to Android.

 

The fact that there are FOSS drivers for mounts thanks to indi/indigo - this what made the OpenLiveStacker mount control possible

Yes and No.  Same for windows.  In windows (linux), one doesn't need alpaca because there is ascom (indi).  Each of ascom and indi operate as translators to the native SDKs.  So it's the same issues as with: in windows (linux), one doesn't need ascom (indi) because there are SDKs.  That's from the user's perspective.  From the developer's perspective, the benefit of all of ascom, indi, and alpaca is their ability to function generically, without the particulars of SDKs.  You can, in that sense, view ascom and indi as "SDKs" for windows and linux, respectively, with alpaca being the more generic version.

 

This is all applies when the actual devices are all hard wired to the same machine.  You get additional benefits when the place where the hard wiring occurs is different from where the software is running.  I could, for example, hard wire my telescope to a computer, then pipe that raw serial data over tcp, then on a separate computer running my desired software, have a virtual serial port mapped to that piped serial over tcp from the other computer.  The computer running the software would think it's just directly hard wired to itself, rather than having gone through this bridging.  That's what telescope wifi does now, for example.  It just serial over tcp essentially.  I can use just that to have SkySafari on my tablet talk to any of my telescopes hard wired to my windows machine.  The windows machine simply reads in the raw serial data, pipes it over tcp, and SkySafari on my tablet on the same network reads that pipe, and sends it ordinary serial commands in the telescope's own native protocol.  Alpaca is doing more than in this case.  Alpaca doesn't need the telescope's native serial commands - it uses generic commands, which something else then translates into the telescope's native serial commands.  At present, because there are no native alpaca telescopes, that something else is somewhere other than the telescope itself.  When the telescope is hard wired to windows, it's AscomRemote.  When the telescope is hard wired to linux, it's the alpaca/indigo bridge, for example.  Later on, when there are native alpaca telescopes, it will just be internal (and probably linux).  So the bottom line benefit to developers right now is the generic capability.

 

But, the benefits can go even further.  As a particular problem I had to solve: I want a goto from planetarium software to move the mount, have a camera plate solve when it's done, then move it again if it's not within tolerance.  A local sync from the planetarium software is treated as a boresight alignment between the main scope and the guide scope doing the plate solving.

 

So, the software takes in a telescope (however it does so: either ascom, indi, or native SDK) and it takes in a camera (however it does so: either ascom, indi, or native SDK).  Only once I have those two things, and plate solving capability, I am ready to send out an alpaca device, called SolvingSlew, containing only one spoofed "telescope".  The planetarium software sends the goto command to this spoofed "telescope".  The software sends the goto to the mount async, and returns immediately.  Slewing stays "ON" while it does so.  Once the mount gets there, it plate solves, and moves again if it needs to.  I send out an audio cue to know to back off the eyepiece.

 

The planetarium software, running on any operating system, sees this spoofed telescope like any other telescope.  My software is handling the particulars of the actual telescope and the actual camera.  This is very hard to do as an ascom "telescope", or as an indi "telescope", or worse, a new SDK for a "telescope" that NO planetarium software speaks!  Regardless of which particular telescope mount I use (my servocat, my AVX, my AZEA6, ...) or which particular guide camera I use (my ASI 220, or my 120, on either of my 50mm guide scope or my arducam zoom lens), the planetarium software sees it as the same spoofed telescope.  So Skayafari on my tablet talks to this spoofed telescope at the same time that my planetarium software CodeTalker running on my windows machine is talking to it.  Both those planetarium software send a goto command like they always do, and this iterating stuff is handled in my controlling software.

 

The benefit, again, even though more complicated, is the generic nature of my control software.  I doesn't matter which telescope it is on which mount, or which camera it is on which guide scope, it's just a generic spoofed telescope to any planetarium software on any operating system (super emphasis added).

Edited by ButterFly, 04 May 2025 - 04:59 PM.

[artik]

TL;DR:

 

1st of all lets agree that having universal standard protocol across devices like Alpaca is good thing.

 

But to make it successful you need  something like indigo or indi like project for Alpaca - there is no work-around of having working driver hub and server with numerous drivers implemented for both Linux and Windows. And no - indigo bridge to alpaca isn't a solution.

 

Long:

 

 

Now the devil in the detail and it is the reason why it isn't nearly as successful as it could/should be.

 

Under Windows there are a standard APIs. Every vendor who wants its device to work implements it. For Astronomy it is ASCOM

Under Linux every vendor who wants its device to work submits his drivers to the relevant project, if it is Linux Kernel or for Astronomy there is Indi and Indigo that provide their API 

 

If I develop a camera or a mount I need to implement ASCOM API under Windows and publish the drivers for download and submit the driver to indi as open (preferably) or closed source - this is how these two worlds behave. (Also windows is getting little bit closer to Linux - now drivers are accessible from central Windows repo so user does not need to hunt them down.)

 

ALPACA is protocol based on ASCOM API. There is No ASCOM for Linux or there is no Alpaca server for Linux, if I want to support Linux-device-host via Alpaca as device vendor I need to implement the protocol myself: either in the device itself or as service that talks to the device via USB/TTY/wifi etc. or hope that a middle-ware like alpaca-indigo actually works well.

 

There is no Alpca hub with ascom like API to submit your drivers - that is why it is rarely relevant for Linux. 

 

So practically:

 

Linux connected devices:

   USB/serial <-> vendor-sdk/vendor code <-> indi API <->  indi protocol | <-> indi client <-> Actual software (Linux, Android, iOS or Windows)

   USB/serial <-> vendor-sdk/vendor code <-> indigo API <-> indigo protocol/bus <-> indigo client <-> Actual software (Linux, Android, iOS or Windows)

   USB/serial <-> vendor SDK <-> Actual software (Linux)

 

Windows connected devices:

   USB/Serial <-> ASCOM driver <-> ASCOM API <-> Actual software (Windows)

   USB/Serial <-> ASCOM driver <-> ASCOM API <-> Alpaca Server <-> Alpaca protocl <-> Alpacal client <-> Actual software (Linux, Android, iOS or Windows)

   USB/serial <-> vendor SDK <-> Actual software (Windows)

 

 

As hardware vendor there is no C++/C API I can implement to work with Alpaca - there is no central repository to submit your driver to, there is no standard API/ABI to implement to work with Alpaca that would allow users download shared object/dll

 

Implementation wise

 

Alpaca REST API mapping almost 1-to-1 ASCOM - for good and bad - simple request response

Indi and Indigo are virtually identical concepts that can even theoretically be interoperable (not always practically thou) based on properties - for good and bad.

So conceptually ASCOM and Indi/Indigo API are very-very different

 

 

Finally it would be fantastic if what I could do is just to use a simple REST client for Alpaca and forget anything else - and it should be like that.

 

But for this you need something like alpaca_server and alpaca_com_like_api for Linux that would allow vendors submit their drivers easily to a central hub writing identical (or virtually identical) code to work with ASCOM and with aplaca_server

 

And even if it is there it need to be "jump-started" with initial implementation of existing common drivers (that way indigo did when split from indi)

 

That is why vision no mater how great it is is far from reality

 

Small Edit:

 

Example while alpaca-indigo bridge isn't really relevant for me: ITelescopeV3 implemented with exception of MoveAxis method group (not compatible with INDIGO substantiall

 

Basically I can't do framing of the object or manually slew the scope - this is kind of a deal breaker

 

This is also very alarming: INDIGO RGB is mapped to Colour, other modes to Mono sensor type (no bayer offsets etc)

 

So basically I can't get raw bayer image if I understand correctly... 

Edited by artik, 05 May 2025 - 04:55 AM.

[han.k]

Linux connected devices:

   USB/serial <-> vendor-sdk/vendor code <-> indi API <->  indi protocol | <-> indi client <-> Actual software (Linux, Android, iOS or Windows)

   USB/serial <-> vendor-sdk/vendor code <-> indigo API <-> indigo protocol/bus <-> indigo client <-> Actual software (Linux, Android, iOS or Windows)

   USB/serial <-> vendor SDK <-> Actual software (Linux)

 

Windows connected devices:

   USB/Serial <-> ASCOM driver <-> ASCOM API <-> Actual software (Windows)

   USB/Serial <-> ASCOM driver <-> ASCOM API <-> Alpaca Server <-> Alpaca protocl <-> Alpacal client <-> Actual software (Linux, Android, iOS or Windows)

   USB/serial <-> vendor SDK <-> Actual software (Windows)

 

 I'm not fully up to date but with Alpaca you can communicate directly between the application and devices without a central server. As soon you skip COM and communicate in Alpaca only you do not need an installed ASCOM anymore. For INDI you will always need a central server which is missing in above lines.

 

For INDI the device driver defines the interface during communication while for ASCOM the communciation interface is fixed

. 

 

 

This is also very alarming: INDIGO RGB is mapped to Colour, other modes to Mono sensor type (no bayer offsets etc)

 

So basically I can't get raw bayer image if I understand correctly..

 

 A raw bayer image is a mono image with different label only.

 

 

Han

Edited by han.k, 07 May 2025 - 02:59 AM.

[artik]

 I'm not fully up to date but with Alpaca you can communicate directly between the application and devices without a central server

Yes but... it is true as long as you are talking about a low data stream device that is equipped with wifi or ethernet. But in reality most devices talk via USB or even serial port.

 

So you'll need a driver that would talk HTTP locally and each and every one of them implementing http REST server on their own...

 

Much logical way is to create a bus that bridges between drivers using common API and the client via wire protocol: exactly the stuff indi, indigo and AscomRemote do.

 

Also I don't think ether INDI, INDIGO or Alpaca are practical and efficient solution for high FPS planetary/lucky imaging - because streaming frames in high bandwidth is hard and requires very efficient approach.

[han.k]

To get an 2000x3000 pixels image from my simulated ALPACA camera to CCDCiel using Alpaca binary image communication & display & save it, takes about 0.3 seconds. So for deep sky imaging it is okay. For planetary imaging it is likely not. In my eyes one awkward design choice for Alpaca is the binary transmission of images in Y lines ( typical vertical lines) while images are normally stored in X lines so it could slow down the total transfer time. For planetary high FPS imaging a direct driver will do better then Alpaca.

 

But implementation of a basic control to an Alpaca mount and request and read out an image using the Alpaca protocol is not too difficult. You do not have to implement to full Alpaca API. Only a very restricted set and get commands will do for OpenLiveStacker. No worries about building an INDI or INDIGO interface based on what the devices tells you after sending a <getProperties> request. For an ASCOM/Alpaca the device properties are fixed and standardized. The properties do not have to be communicated and interpreted. If OpenLiveStacker can talk Alpaca with the ASCOM 7 installed software package then the Alpaca to COM bridge (called dynamic driver) will give access to all ACOM COM devices.

 

Han

Edited by han.k, 07 May 2025 - 04:30 AM.

[artik]

2000x3000 pixels image from my simulated ALPACA camera to CCDCiel using Alpaca binary image communication & display & save it, takes about 0.3 seconds. So for deep sky imaging it is okay.

 

 

Yes about same with indi and indigo (but I think even worse) the problem is that you don't always do long exposures I frequently use 5s and even 2s exposures under light polluted skies with mono sensors is fine especially when the mount isn't perfect. And this can go to wasting up to 10-30% of total imaging time.

 

So that is why for imaging Indi/indigo and for that matter Alpaca is only a last resort option instead of using direct SDK/API.

 

.

No worries about building an INDI or INDIGO interface based on what the devices tells you after sending a <getProperties> request For an ASCOM/Alpaca the device properties are fixed and standardized.

 

Sure, properties based API feels wired and hard to work with. And properties despite begin standardised can vary a lot from device to device. I assume I'll get some surprised from ASCOM/Alpaca as well.

 

One of my basic things I wanted is to get if I read 8 bits, 16 bits, get bayer, mono or rgb image - it was guess work with indi and indigo and looking at the Alpcaca is going to be the same.

 

If OpenLiveStacker can talk Alpaca with the ASCOM 7 installed software package then the Alpaca to COM bridge (called dynamic driver) will give access to all ACOM COM devices.

 

 

Sure - this would be essential part of porting OpenLiveStacker to windows - since having mount control and generic camera driver is kinda important.

Edited by artik, 07 May 2025 - 04:43 AM.

[ButterFly]

There are very few native alpaca devices right now, so a bridge is necessary at present. Nonetheless, the one higher lever of generic programming does still have benefit for developers. Going one level higher avoids the particulars of both ascom and indi. But, as artik mentioned, there are some deal breaking issues on the indigo end. This is a good time to fix those, should you be able to make the time.

Yes on the issues with image bit depth and color space, and retrieval speed. The price one pays for generic is definitely speed. I do wish the bit depth, at the least, were included in the standards. As is, rather than just a formatting issue, an ascom to alpaca bridge still has to deal with ascom using a fixed bit size, which then gets sent for alpaca formatting. It does waste some time, and makes ascom hard, and eventually impossible, to use with short exposures. Ascom's video class is rarely used by most open source software I have looked through. Pretty much anything that uses short exposures uses native SDKs. Alpaca has the potential to overcome some of that, but native alpaca cameras, that don't go through ascom first, are still very rare.

Even with telescopes, alpaca has been slow to adopt. Both the ZWO AMx's and SkyWatcher's Wave's have in built wifi. Alpaca seems natural there. The issue is with the alignments though. The alpaca device has to come from whatever does the alignment, and that's NOT the mount itself yet. ZWO does NO alignment at all. SkyWatcher relies on SynScan App to do the alignment. With ZWO, and no alignment, there really isn't an excuse, other than, I guess, them leaving open the possibility of having an on-board alignment in the future. With SkyWatcher, SynScan App already sends out two protocols over the network once there is an alignment, so there really is no good excuse at all. At best, I surmise their excuse is "we don't need that because we already broadcast protocols over the network".

There is potential to make developers' lives much easier, but there are some wrinkles to iron out. It will happen. Android simply didn't exist when ascom and indi first came around. Today, it's the most widely used operating system. Even if one would tolerate an actual cable going to those devices, there's still only one hole to put them in on most devices! Going fully wifi and fully generic is the most reasonable way forward.

[artik]

Alpaca has the potential to overcome some of that, but native alpaca cameras, that don't go through ascom first, are still very rare.

 

 

It is just impractical - most cameras use USB interface and DMI for efficient communication, http REST isn't the way to go. You may be able to have good streaming speed if you use something like HTTP streaming - or HTTP push. Something like `multipart/x-mixed-replace` - BTW this is what I use for pushing video to browser in OpenLiveStacker - I just use mjpeg - i.e. jpeg stream.

 

So it is highly unlikely to happen especially with current alpaca API definitions.

 

Even with telescopes, alpaca has been slow to adopt. Both the ZWO AMx's and SkyWatcher's Wave's have in built wifi. Alpaca seems natural there.

 

Not really, most scopes use very short messages over serial port and even work over wifi it is just wrapping around serial port message over UDP or TCP.

 

For example AM5 uses lx200 variant and virtually all new harmonic mounts based on OnStep that uses lx200 protocol. Many other use synscan protocol and its variants and there is celestron. Basically there are already several very established and lightweight protocols that do the job.

 

Also these devices rather aren't that smart, for example skywatcher driver in indi updates tracking rate all the time and if it does not the mount will not track properly. So the driver has quite a lot of jobs and typical implementation of the protocol is rather quite low level. So that is why most of logic of alignment and model goes to the driver.

 

Bottom line, implementing http server in a device requires way more effort than simple serial or UDP packets over wifi and moving all complex logic to the driver.

 

And today if I want to create a new mount I'd just take OnStep and have out of box drivers and hardware circuits - and it is all open-source.

 

Android simply didn't exist when ascom and indi first came around. Today, it's the most widely used operating system. Even if one would tolerate an actual cable going to those devices, there's still only one hole to put them in on most devices! Going fully wifi and fully generic is the most reasonable way forward.

 

 

First of all the problem with Android is while it is Linux - it is a wired form of Linux. It does not use glibc making it incompatible with all LSB and it has complex permission systems. So for me having OpenLiveStacker on Android is the way to build portable system - since you already have a powerful device. But it is horrible platform to work on.

 

Anyway I think Alpaca is good initiative but it requires hands on work in bringing drivers to both Linux and Windows in a practical way like indigo did instead of expecting the device vendors to implement restful http service on their tiny devices.

[ButterFly]

Also these devices rather aren't that smart, for example skywatcher driver in indi updates tracking rate all the time and if it does not the mount will not track properly. So the driver has quite a lot of jobs and typical implementation of the protocol is rather quite low level. So that is why most of logic of alignment and model goes to the driver.

 

Bottom line, implementing http server in a device requires way more effort than simple serial or UDP packets over wifi and moving all complex logic to the driver.

It's not as big a leap as you imagine it to be.  There are already servers broadcasting, just not in the desired language.  Take SynScan app, as an example.  That is the driver that is doing "the work" of controlling the mount.  It is also already broadcasting the SynScan™ Serial Communication Protocol, over TCP on port 11882, and it's also broadcasting the SynScan App Protocol, over TCP/UDP on port 11881.

 

SynScan App, although available on Android, is not yet available on linux.  The indi drivers speak directly over serial to the mount rather than speaking to SynScan App.

 

Take a look over the SynScan App Protocol (which isn't the ordinary SkyWatcher serial protocol).  Its commands are based entirely on ascom's ITelescopeV3.  That's probably not a coincidence!  I suspect they were simply waiting for codebase from the ascom initiative to create alpaca drivers, which is allegedly coming soon.

 

Again, the server is already there - that's the hard part.  UDP is just a stream of bits.  TCP is that stream with checking.  HTTP is TCP with formatting.  At the end of the day, the "leap" to alpaca is only a matter of parsing text.  Once the initiative provides the codebase, I suspect alpaca will follow soon thereafter.  My AZEQ6 has no onboard wifi, whereas my Wave does.  Whether the Wave itself, rather than relying on SynScan App, will broadcast alpaca remains to be seen.  The Wave itself can't do an alignment (it relies on SynScan App), so there really isn't much point.

 

Sure, ZWO doesn't also broadcast a protocol separate from the LX200, and its "driver" doesn't do any alignment at all, but the server on the mount is still there.  As is, it's just a matter of parsing text, but I do truly hope they add an alignment routine of some sort to their drivers.  ZWO really needs to work on that first.  Once the codebase is available from the initiative, they can make the switch to alpaca just as easily.

[artik]

SynScan App, although available on Android, is not yet available on linux.  The indi drivers speak directly over serial to the mount rather than speaking to SynScan App.

 

 

Actually there are two ways of indi speak with AZ GTi and both working

 

- indi driver talking directly to the mount via serial/udp protocol

- talking to the app via synscan protocol - I checked and it works quite well - I mostly tried it before I fixed skywatcherAltAz driver issues

 

 

The SynScan App Protocol is indeed looking like "Ascom" over wire - but I didn't bother with it since I needed generic solution

 

Sure, ZWO doesn't also broadcast a protocol separate from the LX200, and its "driver" doesn't do any alignment at all, but the server on the mount is still there.  As is, it's just a matter of parsing text, but I do truly hope they add an alignment routine of some sort to their drivers.  ZWO really needs to work on that first.  Once the codebase is available from the initiative, they can make the switch to alpaca just as easily.

 

It isn't only zwo it is also OnStep - try to see if it is possible to implement alpaca in OnStep? It is Open-Source and immediately all OnStep drivers will support it.

 

From my experience there is no way for something like azgti to support alpaca over wifi because lots of logic is in the driver.

 

Really check it. I'm all for alpaca being a standard.

 

I'd also suggest add something like lx200 bridge since huge amount of mounts work over lx200 protocol - so it would be simple if the situation is translating one protocol to another.

[ButterFly]

 

From my experience there is no way for something like azgti to support alpaca over wifi because lots of logic is in the driver.

 

Distinguish the mount's wifi server with SynScan App's wifi server.  Those are separate servers, and many SkyWatcher mounts don't have internal wifi.  When the mount has its own wifi server, there are indeed two servers.  SynScan App is already doing the alignment and control, and sending out a server, so that's where the alpaca support would be put in.  So, even though the azgti (itself) can't yet support alpaca over wifi, the azgti could indeed support alpaca, if SynScan App would support alpaca.  Then, every SkyWatcher mount controlled through SynScan App would support alpaca over wifi, so long as the device running SynScan App has wifi.

 

 

 

I'd also suggest add something like lx200 bridge since huge amount of mounts work over lx200 protocol - so it would be simple if the situation is translating one protocol to another.

 

In windows, to get an alpaca device out of an LX200 speaking mount, one simply uses AscomRemote.  LX200 itself is a translation layer to the particular mount's motor control command set.  A manufacturer could skip the LX200 layer, if they want, but as software developers, that's not our concern.  All we need as software developers is something that goes from alpaca to the mount's motor control command set, however that happens, and however many translators are in the way.  In windows, that AscomRemote bridge always works if the underlying ascom driver works.

 

The issue you pointed out with MoveAxis for the alpaca/indigo bridge is concerning.  If it works for the underlying linux "driver" it is bridging, that needs to be patched.  If MoveAxis works as expected without the bridge in linux, this really is nothing more than a "translation error".