Well tried it out between Up Core Windows 10 and a desktop.

I have to say the terminology doesn't make a lot of sense - remote client , server is fine nothing knew but IMHO the set up is confusing and of course still depends on the user knowing IP addresses etc - plus good old Win10 Firewall sticking its nose in.

Anyhow I got it working but of course Ascom doesn't have a DSLR driver but running APT on the UP Core which was on the mount (my good old SWAZ GoTo) together with Synscan App Pro (no handset) and CDC on a desktop it ran for 2hrs no problem. Slewing here and there no problem. Plus APT PlateSolving worked too.

CDC did initially moan something about "Object Instance error" and loops horribly if the mount get disconnected (does that anyway) - but it worked too.

Response time were fine but I wasn't downloading CCD images between the UP Core and the desktop.

So initial impressions - Impressed it worked so well - wish it had a Ascom DSLR driver - set up not for end users. So just need an Indi interface (especially for DSLR) Ekos and your cooking. Obviously its early days and it was a quick test

As the old Canned Heat record said " Come Come lets work together" LOL

Peter, is there any specific reason you're so sarcastic recently? or is it just bad weather?

Stash,

There is a Ascom dslr driver but I don't know the status: github.com/vtorkalo/ASCOM.DSLR

The error "Object Instance error" is a Ascom exception reported by CdC, no idea why.

I forget to protect CdC again remote disconnection (this is done in CCDciel), I fix it now.
This is something new for the Ascom client because this never arise with the COM driver. You have a checkbox in the server configuration to disable the connect/disconnect capability to prevent to break existing application.

Hi Patrick,

I had tried that DSLR Ascom a while back - didn't work for me with APT

The Disconnection error also occurs when using the Synscan App (windows) with Remote Ascom. Its onl a problem in that it nearly does a deadly embrace and you cannot do anything else.

Love CDC and have been using it for years

Hello Radek,
reading your comment on MQTT driver for INDI, I had to register for this Forum!
I am looking for exactly such a driver!
In times of IoT and home automation, it would totally make sense to have some kind of gateway between INDI and MQTT.
My use case would be (for a starter):
A weather station sends its data via MQTT -> (configurable) INDI Driver makes necessary data available to observatory.

This way, no need to write a specific driver for each and every weather station, just have it send its data via MQTT and the observatory could subscribe to the relevant topics.

Unfortunately, I don't have enough coding experience to write something like this - but definitely willing to test such a driver.

Greetings,
Herwig
astrohd.de

Hi stash,

do you have by chance any more info on this ascom wrapper for MQTT, perhaps even a link?

Thank you,

Herwig
astrohd.de

Hi Herwig, welcome to INDI forum!
There are various use cases for INDI-MQTT. What I assumed in my project so far is that INDI publishes status of devices over MQTT. What you're describing is INDI subscribes to MQTT messages from other devices.
As the matter of fact both are feasible but making it work both ways requires lots of work. If community thinks it is worthwhile, a major project should be defined with several contributors. As for now we can make a small step for INDI but giant leap for mankind. Some day we can get there. In the meantime you can use existing weather drivers, including wunderground - just publish your weather data to wunderground and pull them back with the driver.

All the best!

Hi ,

This is not the orig paper which i cant find. I never found the wrapper just references to it

link is here www.google.co.uk/url?sa=t&rct=j&q=&esrc=...Ap_BkIHh-O3IEgw9Ortk

Google IBM cognative telescope network and ibm telescope commander might throw some info

The origins of remote ASCOM are some years ago when we had an ill fated project - ASCOM-X. This was trying to do the same thing - provide a framework for allowing ASCOM style operation remotely and over multiple operating systems.
At its core an ASCOM driver is very simple. Some code withat implements a defined set of properties and methods. This maps well into a text based protocol:
> get RightAscension
< get RightAscension 12.345
> slew 5.432, 15.678
< OK
Other protocols could be defined
So, being someone who tends to move into coding too soon, I implemented something like this - and it worked.
But I made one fatal error. I used UDP as the transport method.
It could have been anything - TCP/IP, files, RS232, fax, messengers with cleft sticks, pigeons, the telegraph - anything that can transport text messages.
Unfortunately everyone who commented focussed on the folly of using UDP, with vast explanations of how it couldn't possible work, especially in Windows. This in spite of this all being developed on Windows.

I gave up, and the whole thing went into limbo until a couple of years ago when some people developed what you now see. What I think they learnt was that public development of this sort of thing doesn't work.
It could hook into all sorts of other systems, the idea of hooking into INDI looks good. Users with Windows PCs running one of the mainstream astronomy applications could have a RasbPi on their scope that handled all the scope managment, guiding, image acquisition and so on. Another pi to handle the dome and weather.

Then, when they see how easy INDI and the linux system is, they will become converts.

Mr Ascom - honoured we are

Its funny you saying about UDP as Sky Watcher uses UDP for their connections to the mount from Synscan App and it works.

The UDP problem is lakin to the RS232 hand shaking options DTR/DTS,xon/xoff etc - they were there when hardware was slow and unreliable now things have changed we nearly all just use tx,rx and Gnd. Personally I think "they" were wrong are you were right , UDP would have worked well - but thats "water under bridge".

I guess people get to emotionally tied to their "baby".

IMHO Ascom Alpaca could be a way forward in joining the best from each world as it seems easier to interact with and all we need ,LOL, is a simple translation bridge,
I say this as neither Indi or Ascom will ,in my view, adopt each others protocol's.

I went through the published Alpaca spec and without trying to be catty it still follows the ASCOM protocol restrictions, which I'm having a hard time buying into in this day and age. Other than that, if the instrument manufacturers buy into Alpaca (I see no reason they would not, I would in a heart beat) when we finely have OS independent instruments.

I haven't used it, but I understand there is a windows sever that uses ASCOM drivers and talks to INDI? If so, that should be a good start on an Alpaca interface for INDI(?).

Back in about 2011 I floated (on this forum I think) an idea for embedded INDI, which is the same basic concept. I'll show my lack of INDI depth, but I thought INDI servers needed to be daisy chained. If that isn't true or there could be a "combiner," that is a way to talk to multiple servers from a single point, the INDI server could move into the instrument now... hint, hint.

Anyway, I've been on board with the web based instrument concept for a very long time... glad to see it finally happening.

2 cents from the cheap seats...

"I went through the published Alpaca spec and without trying to be catty it still follows the ASCOM protocol restrictions" - are you talking Ascom std message protocol or something else - Indi has its own "message protocol std" all client servers have too in my experience?

Having done some testing and even attempted Linux to Windows Ascom Alpaca connection ( it connected no problem) the biggest problem is I hate the Web interface its all over the place and too complicated ,IMHO, for "average Joe". You are expected to know/remember too much IP info and REST is far to talkative IMO (e.g. must I keep getting the temperature - Look at Wireshark output ). Why not use the MQTT model where the user only has to know the Broker IP name or address everything else is Topic and levels - e.g. Main Topic Camera - SiteA/Camera/DSLR/Canon/100d , SiteA/guidingCamera/CCD/ZWO/120mc and we are at least going to be talking - even if the nitty gritty has still to be set up - e.g. Gain,Exposure etc. Maybe RK's MQTT admin program will do all this automatically

Surely its not too much today to expect software to "poll" for servers/clients to find out Camera1, Telescope2 ,ServerHub1 etc on SITEA at the press of a single button ( I am not talking DNS here) - at least on a home network (how many will use it across the Internet) and NOT expect a user to set up lots of connection variables (I am not even talking about device variables here just Alpaca) e.g. Device numbers,driver numbers. And those little POP UPS,e.g. chooser and Remote Client windows - you dont see because they are hidden and you didn't notice your task bar just added another widget icon - appalling IMO - Most user unfriendly. OK its early days for Ascom Alpaca and Indi have Serial Assistant etc so maybe there is hope.

Having said that the Ascom Remote Client works very well for existing software without changes(just confusing set up's) - so PHD,APT,EQMOD,CDC (in real full blown Alpaca mode) etc all work (up to now in my testing at least ) and I was able to run software across 3 Windows PC's - 2 Mini's and a desktop. - same as Indi. Peter Wilson Well done

So the jury is still out but IMO both Indi and Ascom still need to make their software more user friendly so that set up is semi automatic and less complicated (hidden) without IP knowledge IMHO. I.E remove the initial steep learning curve so I don't hear "that's doing my head in" or "mind blowing" etc from users

Its not knocking all the hard work developers do (thank you) but maybe the direction/priorities and remembering most users are not (and should not need to be) IT savvy developers

Of course if all the manufactures got together and had a OS Independent standard message protocol that would be a hallelujah moment (wont happen) .

I will now get back under my stone and wait for the flack - LOL