×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

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

  • 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: Radek Kaczorek
Last edit: 5 years 1 month ago by Clive Stachon.
5 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: Eric
5 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 ?????
5 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...
5 years 1 week ago #36618

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

  • Posts: 407
  • Thank you received: 74
"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
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 ?????
5 years 1 week ago #36622

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

  • Posts: 33
  • Thank you received: 5
Stash, No flack from me, I agree.

Thx,
5 years 1 week ago #36632

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

  • Posts: 4
  • Thank you received: 1
Hi all,

Some of you may be interested in this :

Pylpaca (ASCOM Alpaca API micro-framework for Python)
github.com/T0T4R4/pylpaca

I'm smiling a bit when I see people questioning of the performances of a REST API versus an XML based one...

I would also argue that questioning the "network load" becomes obsolete these days.

ASCOM is indeed very easy to use, and even to create drivers on. I've gone through both ASCOM and INDI, and the only thing I can say is that Alpaca brings ASCOM to the linux world, which was the major drawback in the past.

As far as I read some people here are still playing in the Linux-vs-Windows primary school courtyard thing. So retrograd way of thinking...

If indeed some could build a layer on INDI to follow the Alpaca API definitions, then it would make the life easy for everyone, if not it'll be uip to the software makers like Patrick to talk both layers, which is sad...

Cheers

T0t4r4.
The following user(s) said Thank You: Chris Rowland
5 years 3 days ago #36962

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

  • Posts: 4
  • Thank you received: 1
[Attention Flak]

Hi @Stash,

The ASCOM REST Server and the Alpaca API are two completely different thing.

The Alpaca API are specifications only, and purely written with openess in mind in order to allow the spread of the ASCOM protocol cross-platform.
In that mindset, the API has been VERY well defined , although *you* may think it's a bit verbose, REST is the most spread approach used in the IT industry these days when building web APIs.
It's simple, easy to build and to query.
Literally NO-ONE gives a damn about network traffic these days (as in... people open wireshark maybe what... once a year?) whether it's at home (2000mbps) , or the web (100+mpbs home connection, 500mbps work connection).

The ASCOM Rest server, on the other hand, was just released in January (so alpha alpha stage), but is not something that *users* will see. This has to be configured once and only, and after that, we forget about it.
Users talk to the devices via the API, that's it. Compared to setting up Indi servers / drivers, it's damned easy.

You mightalso have forgotten the Alpaca Management API, which I think makes the use of the rest server interface obsolete.
That said, the ASCOM rest server UI is minimalist and perfect for what it needs to be doing.

The only missing bit is that it should be running as a windows service, if possible, and i've got to check with Peter if that's in the pipeline as it's not rocket science to make it so. There is one nuget package which does it all.

T0t4r4
Last edit: 5 years 3 days ago by Mathieu Clerte.
5 years 3 days ago #36965

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

  • Posts: 407
  • Thank you received: 74
Hi ,
You are entitled to your opinion but I still stand by what I said.

You ,IMO, have an odd but not uncommon manner among modern developers - "its so easy for users you just do this" - well just look at the other forums you will see one hell of a lot of problems "user" have with Ascom even in its "old" form and that excludes Microsoft induced problems such as updating/device drivers being invalidated etc etc .

"REST is the most spread approach used in the IT industry these days when building web APIs" - that says it all really - i have lost count over the years hearing that statement. I could say the same of MQTT for IOT. In the end I dont give a dam ( just most normal users) I just want it to work and be easy to set up OR change and be across any OS I choose - neither Indi and definitely not Ascom/Alpaca can , at this moment in time, can claim to be that - even if Indi is far closes and more mature the Ascom/Alpaca.

Please dont take me for an Linux/Indi fanatic - I am not and if you care to read some of my posts here and on SGL I criticise Indi/Linux just as much as I do any Ascom product LOL

You cannot talk ,with any certainty, about what Alpaca might do,across O/S, in the future as they may never happen. At present as far as I am aware ,besides CDC, there are no day to day Astro programs that use or give an option to use native Alpaca across multiple O/S.

Lastly I don't have a problem with Alpaca idea ,but Ascom should /could have done this years ago, as Chris Rowland hinted on this forum, he proposed such a system based on UDP , many years ago.
Ascom/Alpaca are way behind the curve and Indi,IMO, is far out in front - not to say there are parts I hate (others probably love), plus Indi ,IMHO, is far more than just a "message standard". Hopefully it will evolve even better with input from "end Users" not just developers who ,like it or not ,get tied up in the code and perhaps loose sight of what average Joe can do easily.

Both Ascom and Indi developers do a enormous amount of work - as far as I know for free - so I can do nothing but applaud them - doesn't mean I have to agree nor "belong" to one camp or another. I just want to do my Astro stuff with tools that are as flexible,easy and change with the times.

As I said ,and still stand by, the latter part of the Title of my initial thread - "if it works" only time will tell.
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 ?????
5 years 3 days ago #36966

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

  • Posts: 4
  • Thank you received: 1
I do agree with most of what you said. Same as you I am not aligning to a particular school.

Thanks for the "modern" attribute, and pardon me if my statements can be biased because indeed I am a developer, since 30 years. No particular attachment to any OS but I like KISS. Same, I don't like to lose my time. So I'm all for standards , reusability, don't repeat yourself and simplicity. I've also learned to listen to my gut feeling.

I am not advocating for ASCOM. It's here, widely used, so here we are. It has evolved from what was great at the time (COM ActiveX) to .NET, to REST API. A great evolution that follows what is done in the industry of the WWW. That's it.

Saying that INDI is more mature than Alpaca is not only stating the obvious considering that the first has now years of existence and refinery, but it's also (un-)voluntarely shooting an arrow at the embryo (Alpaca). Apart from the age difference, it's as good as comparing potatoes and carrots.

I don't know how savvy you are, but the first time I ran the ASCOM REST Server, I could reach my 'scope within minutes in postman, and drive it with node-red. If that is not simplicity than we don't speak the same language ??

And the reason why ASCOM didn't go the REST route earlier is mostly because it's only recently that wiring up a REST API with VS and the plethora of Nuget packages is as easy as pie, or can it be that Peter was on other projects, who knows. I still don't know how I can guide my INDI-driven 'scope via a simple restful request, but I didn't check the latest changelogs...

"If It works" depends on your expectations, which are variable for everyone.

At the moment, either my expectations are lower than yours or I am luckier because it "just" works, and beautifully.

Cheers
5 years 3 days ago #36968

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

  • Posts: 554
  • Thank you received: 138

I think you will find that in most cases problems that the user describes as ASCOM are nothing to do with ASCOM. Cable failures, USB failures, application failures are all nothing to do with ASCOM. There are some issues where the application or driver author has failed to follow the specfication, or interpreted it differently but there's a limit to what can be done by the ASCOM core people to rectify that. There is already a lot of documentation and test harnesses. If the specification is unclear then they can ask.


Your attitude is exactly the sort of thing I had when I tried to do this before. People who, like you, had no intention of taking part in the development process concocting irrelevant objections to it. It is why it did not happen then.

A typical way that people undermine something they dissaprove of is to come up with some specification item that it is not intended to do, nor does it need, and then whine that it doesn't fulfil it. This is what I'm seeing there.

The performance of ASCOM or Alpaca will have no effect at all on how well INDI works. It will be just as good - or bad - regardless of this.
This seems a bit like lip service and, delivered at the end of multiple posts where you try to undermine the work of those who work on a system that you dissaprove of is a bit meaningless.
The following user(s) said Thank You: Mathieu Clerte
5 years 3 days ago #36970

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

  • Posts: 4
  • Thank you received: 1
To put it in other words, ASCOM is only a set of interfaces.

github.com/ASCOMInitiative/ASCOMPlatform...ter/ASCOM.Interfaces

and Alpaca, an API framework specification that maps that allows the publication of these interfaces.

Easy stuff, 101 programming.

When something, like an "ascom" driver fucks up, it's only because of the driver implementation of the ASCOM interface, or the lower level (arduino sketch for example), but certainly NOT due to ASCOM itself.
Same for INDI.
5 years 3 days ago #36976

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

Time to create page: 4.330 seconds