It is INDIGO, not INDI, framework inside APT. INDI support is only a side effect of a partial INDIGO backward compatibility and only to a limited extent, e. g. fall-down to legacy INDI protocol including INDI BLOB support and formally documented INDI property/item names mapping. INDIGO doesn't and probably never will support legacy INDI streaming and snooping because a different approach was taken already.

As far as INDI has no documented DSLR properties in addition to the common CCD property set, gphoto2 INDI driver is not fully compatible with INDIGO client on properties/items level, because no name mapping does exist. Nevertheless, it may work on some very basic level (trigger the capture in M mode and download image).

Peter

Well that is disappointing. Clearly standard Indi is a much more mature implementation. The Dev for APT claims to be close to the Indigo dev let's hope Indi is not forgotten going forward.
My main interest in this development is I prefer the proper Indi client server scheme over the crude remote desktop required for Windows and Ascom. Unfortunately my Celestron CGX requires an alignment before it becomes operable either via the hand control or from the Windows only CPWI planetarium. Plus Windows only or not, APT is a very nice piece of software with many features.

I do not know how mature INDI is. But it is definitly older. By the way what do you think anout the news that pixinsight is migrating from INDI to INDIGO. i think that tells a lot about the maturity...

Well that is disappointing. Clearly standard Indi is a much more mature implementation. The Dev for APT claims to be close to the Indigo dev let's hope Indi is not forgotten going forward.
My main interest in this development is I prefer the proper Indi client server scheme over the crude remote desktop required for Windows and Ascom. Unfortunately my Celestron CGX requires an alignment before it becomes operable either via the hand control or from the Windows only CPWI planetarium. Plus Windows only or not, APT is a very nice piece of software with many features.

If you are interested, you can contact the author and ask for proper INDI support. Now there are StellarMate/AstroBerry/QHY StarMaster/AtikBase plus there are a couple more commercial devices under development based on INDI technology to be released soon, so it makes sense to support them.

Why the contest/friction between Indigo/Indi or so it seems to me IMO - most Astro users couldn't care a fig what software they use as long as it works in the way they want to work.

IMHO and simple experience :-

for DSLR

1. Indi works well and is fairly mature ,as it uses Gphoto2 (as I guess Indigo does for Linux) ,but it cannot be used by any Windows Client (unless you know different).

2. Indigo has a RPI based Web image (Indigosky) that will connect a DSLR but does not have the functionality/robustness of Indi Ekos- Plus Indigo ,IMO, seems to be more concentrated on Apple kit. APT was released when I last tried Indigosky - Stage0 ?

3. APT,in Windows only, has the big advantage as it uses Canon's own SDK (Canon are a pain IMO) which is not available on Linux/Unix as far as I am aware and does not allow DSLR or native ZWO access on Indi or Indigo at this stage. Although this was released in Jan2019 which suggests Linux support www.canon-europe.com/press-centre/press-...sdk-and-api-package/


IMHO (which doesn't count for much) APT have made a mistake in not including DSLR users in the initial release - but its their software and therefore their decision - good luck APT it is good software(I have used it for 4yrs) . Guess I am too focused on DSLR use but then there are many such users and they are not Apple based.

If I am wrong about what does work or doesn't etc - please correct me.

Well, technically it works with KStars/SkyCharts/PixInsight/etc on Windows, but I take it you already know that

Yes I did - I wrote that badly. What I was trying to point out was that there is no Windows Application (Astro) that can call Gphoto2 directly unless it was Indi/Indigo aware - i.e. no Indi or Indigo server involved in the chain.

Nearest was Virtualhere (RPI Virtualhere server and Windows Virtualhere client - no Gphoto2 involved) but that was too slow but it did work!

Hope that makes more sense know

Stash, indigo is not concentrated to Mac. Indigo is native to linux and Mac. And the client library is also windows native. It just happend that the there is more client software on mac. But with Pixinsight and APT, windows it will be also well supported. And yes you are correct indigo does not have native linux clients but this is changing. However all indi clients work against indigo server but in legacy mode. By the way have you tried ekos against indigo? It works

I wonder what the oldest standard is that's in current use on the internet. TCP/IP must be pretty old, so are the email protocols. Then there's ASCII... As for the QUERTY keyboard...

rumen wrote: Stash, indigo is not concentrated to Mac. Indigo is native to linux and Mac. And the client library is also windows native. It just happend that the there is more client software on mac. But with Pixinsight and APT, windows it will be also well supported. And yes you are correct indigo does not have native linux clients but this is changing. However all indi clients work against indigo server but in legacy mode. By the way have you tried ekos against indigo? It works

I have tried indigo with Ekos, and it does work, but poorly, you even have to start the indigo server manually, which is a pain...

Not strictly "on the internet" but the Internet wouldn't work without it - the "Half Adder"

Yes tried all variations and as someone else has already said its too slow (slower than Virtualhere) But I did like he Web control Interface in Indigosky , as I reported to you before(email), which was clean ,simple to use and uncluttered .

"It just happend that the there is more client software on mac" - hence my use of the word concentrated

Plus still does helps with DSLR via APT. Yes I do like my APT software

As I stated its not Indi/Indigo/Linux fault - I lay the problem squarely on Canon(and other DSLR makers) - for not releasing the SDK for Linux.

Thats not a criticism of Gphoto dev team who deserve massive praise for the massive project of reverse engineering the protocols used.

Hopefully later releases of APT (3.90) will provide me with what I want.