×

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
: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.

  • Posts: 33
  • Thank you received: 5
Can I take exception to a few of the statements made?

I care about bandwidth... If I'm at the observatory or it's in the back yard, maybe not so much and remote desktop may work. If I am running to a remote observatory serviced by a microwave link at $30/month vs a broadband link at $150/month, I care. I do mostly speckle so each data cube is about 1 GB. I can do one every 6-10 minutes... I almost have to use a NAS to store raw data at the observatory and reduce the data there (1000:1 reduction in size or more, already programmed into the GPU on a Jetson TK1). To arbitrarily say bandwidth/date usage doesn't matter is simply wrong. It even matters for places like Kit Peak and have the data on a jump drive to prove it.

ASCOM- Let's face it, it's legacy from the RS232 world. The world has changed, plug and play, configuration apps, posted "Open" interfaces and so on. I can plug in my GigE Flea3 camera anyplace on my network, run a config app and it finds it. One click and the software is set up... Auto config and/or configuration help would be to my mind the minimum needed for a new system. Yes, this can be left to the instrument makers, but shouldn't it be called out as an expectation?

From what I can tell, adding a data field to ASCOM will cause the known universe to implode (just making a point). The word "anarchy" was applied when I asked about self-declaration. I don't think any developer or user can predict what will be of interest or needed in 5 years, apparently others do. So there is, IMHO, a need within the interface to add instrument types, data types and commands. I wanted to add an instrument selector, which I did by calling it a filter wheel, though I see there is one in INDI. This worked but is confusing to those looking on. Now I want an automated ADC (Atmospheric Dispersion Correction)... how do I do that: via scripting with Poth, easy in INDI (via snoop)?

The added data field was for my observatory controller and you have no idea what I want to report from my observatory or when... by adding the data type, units, name limits and actions, the field could be added on the fly to any application with minimal effort, the application not even knowing the relevance: real, Dec current, ma, -300 , 300, warn. This doesn't feel like anarchy :-).

There's one other minor fly in the ointment. Yes it's minor. To reuse the ASCOM driver on an ALPACA device means running windows on the device... anyone see a problem with that? It just means the interface will need to be rewritten for the embedded web sever and the ASCOM example code will be helpful. Just not the slam dunk initially thought.

So I like the fact ALPACA will give the instruments a network based interface that is OS agnostic, huge plus. It's a bit too archaic and closed for my tastes but a major step forward for ASCOM. It will be interesting to see how the instrument makers respond.

Anyone see IBM's "Cognative Telescope Network" information? I'm probably not a fan, but there are some interesting points.
The following user(s) said Thank You: Clive Stachon
5 years 3 days ago #36978

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

  • Posts: 407
  • Thank you received: 74
"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."

Very disappointing as you are going on to personal attacks - you dont know me ( and I you) but I have made no personal attacks against anyone - if fact on this site and others I have defended developers of all types. I would love Indi and Ascom to be able to interconnect - hence this thread.

I have no problem with any new development or idea and I am willing , indeed have , done testing as that's the point of "True Open Source".

Where is the "whining " you suggest am I doing - other than perhaps I said that Ascom should have made the changes a lot earlier. I. thought I had made it plain I was excited about Alpaca as an idea.

Sorry Chris Rowland I most have misread your earlier reply to this thread which implied , to me at least , that your idea of changing Ascom years earlier was rejected by "developers" for the reasons you stated - as ordinary users would not even know (or care) what UDP was.

I wont even respond to the crass statement about leaving my support for developers until last etc .
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 #36981

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

Time to create page: 1.475 seconds