×

INDI Library v1.8.9 Released (01 Mar 2021)

INDI monthly update. In addition to driver improvements, major code refactoring is in progress by @pawel-soja to modernize and improve INDI aging code.

New forum users, please go here first: indilib.org/forum/new-forum-users.html

well this has put the cat amongst the pidgeons - if it works

  • Posts: 712
  • Thank you received: 174
Jasem, maybe you should look at INDIGO XML vs. JSON HTTP/WebSocket mapping before you will try to reinvent the wheel. Among INDIGO web applications it is used also by INDIGO ASCOM drivers for years. Peter

github.com/indigo-astronomy/indigo/blob/master/PROTOCOLS.md
2 years 1 month ago #35333

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
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
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
2 years 1 month ago #35334

Please Log in or Create an account to join the conversation.

  • Posts: 957
  • Thank you received: 360
Peter, is there any specific reason you're so sarcastic recently? or is it just bad weather? :D :D :D
--
Radek Kaczorek
Astroberry Server | NEQ6 | Atik 460EX | Atik EFW2 | ASI 120MM
2 years 1 month ago #35335

Please Log in or Create an account to join the conversation.

  • Posts: 196
  • Thank you received: 96
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.
2 years 1 month ago #35337

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
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 :-)
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
2 years 1 month ago #35348

Please Log in or Create an account to join the conversation.

  • Posts: 3
  • Thank you received: 0
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
clear skies,

Herwig
astrohd.de
2 years 1 month ago #35400

Please Log in or Create an account to join the conversation.

  • Posts: 3
  • Thank you received: 0
Hi stash,

stash wrote: IBM wrote a good paper on using MQTT for "serious" Astronomy to share/control data/devices over the world. Biggest plus as I see it is not having to know where the device are. IBM had developed an Ascom wrapper for MQTT but now with Alpaca/Indi maybe it will provide best of all flavours.


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

Thank you,

Herwig
astrohd.de
clear skies,

Herwig
astrohd.de
2 years 1 month ago #35401

Please Log in or Create an account to join the conversation.

  • Posts: 957
  • Thank you received: 360
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!
--
Radek Kaczorek
Astroberry Server | NEQ6 | Atik 460EX | Atik EFW2 | ASI 120MM
2 years 1 month ago #35419

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
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
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
The following user(s) said Thank You: Kaczorek
Last edit: 2 years 1 month ago by stash.
2 years 1 month ago #35457

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
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.
The following user(s) said Thank You: TallFurryMan
2 years 1 month ago #35487

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74
:ohmy: 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.
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
2 years 1 month ago #35506

Please Log in or Create an account to join the conversation.

  • Posts: 33
  • Thank you received: 5
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...
2 years 4 weeks ago #36618

Please Log in or Create an account to join the conversation.

Time to create page: 0.764 seconds