Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

ASCOM - Not Just for Windows Any More

  • Please log in to reply
50 replies to this topic

#1 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 March 2019 - 02:40 PM

Posting not on behalf of my company, but as one of those who want to see the astronomy software community remain open and welcoming to new software developers and instrument makers. I have been given permission to post this info.

 

Some of you may have noticed the changes to the ASCOM Initiative Website that appeared a couple of weeks ago. The new content relates to ASCOM Alpaca, a cross-platform and internet extension to ASCOM. Quoting from the new Alpaca Developers page:

AlpacaLogo128.png

For over twenty years ASCOM has enabled astronomy programs to connect to ASCOM-compatible astronomical devices through standard APIs built on Microsoft COM technology. These APIs have been (and still are) very successful and support a wide variety of astronomy programs and devices that run together on a single Windows PC.

 

In today's heterogeneous network-connected world this is a significant limitation and so we have introduced ASCOM Alpaca, which provides the path for:

  • Astronomy programs and devices to be connected across Windows, Linux, and MacOS.
  • Observatory systems to include programs and devices on multiple platforms
  • Devices that can operate via WiFi or Ethernet and avoid the problems with USB
  • Interoperability between astronomy programs and devices running under different operating systems
  • Implementation of astronomy programs and device control logic written in different languages on different operating systems
  • Current unmodified Windows astronomy programs to use ASCOM compatible devices connected to any networked PC or other platform via Alpaca, or to a self-contained Alpaca device.
  • Current unmodified Windows-resident devices (mounts, focusers, etc.) to be used by astronomy programs running on networked PCs, Macs, and mobile devices that use Alpaca for device communications.

The introduction of ASCOM Remote in 2018 began the process of extending the ASCOM ecosystem to include the internet, Linux, and Mac OS, including small embedded controllers like the Arduino and Raspberry Pi as well as astronomy software on those platforms that wish to use instruments which are hosted on Windows systems.

 

As of early 2019, this effort has grown into a new wave of development, with several astronomy instrument vendors embracing the implementation of the ASCOM Alpaca API as ReST end-points, reachable over the internet. This effort is much farther along that you might imagine, and we can expect vendor announcements in the coming months. In addition we already have one cross-platform planetarium program, Cartes du Ciel, and a cross-platform capture program CCDCiel, both by Patrick Chevalley, that now support the Alpaca protocols, giving them access to today's unmodified Windows-resident ASCOM-compatible devices from Mac OS and Linux.

 

Obviously this announcement is for developers, as Alpaca is enabling technology. I'm posting this announcement here because there are a number of members who are developers, or who may want to develop new devices and apps outside Windows, not to mention the potential for the Raspberry Pi and Linux communities here. 

 

If you are a user, please see the ASCOM Frequently Asked Questions section where some common questions and possible concerns are addressed in a non-technical way.

 

Note that there are a couple of videos on the ASCOM Alpaca Developers page that you may find useful for discussions with fellow developers. One of them is a demo of an Alpaca-speaking Rasberry-Pi/Linux based rotator simulator written in Python being controlled by the Field of View Indicator in an unmodified Windows copy of Software Bisque TheSky X.

 

We all owe Peter Simpson a huge debt of gratitude for designing the protocols which implement the successful ASCOM interfaces, and which have become the basis of Alpaca, as well as for implementing the all-important middleware ASCOM Remote. Thank you Peter!!

 

  -- Bob


Edited by Bob Denny, 05 March 2019 - 02:40 PM.

  • mclewis1, NMCN, rgsalinger and 5 others like this

#2 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 05 March 2019 - 03:40 PM

Two quick questions-

 

1) ASCOM has historically had the devices physically connected to the host computer.  If I look at my intended use I would like a hub in the observatory for the scope and cameras, and an individual TCP/IP connection to the observatory controller where multiple clients could potentially connect (multiple scopes).  Will the new ASCOM support this?  In the case of the scope and camera(s) those may need to be hosted on separate computers to add an additional wrinkle.

 

2) Can you put the driver in the instrument so a camera or scope is ASCOM complaint an just needs to connect to ethernet, BT or wifi... more or less plug and play? 



#3 mclewis1

mclewis1

    Thread Killer

  • *****
  • Posts: 18316
  • Joined: 25 Feb 2006
  • Loc: New Brunswick, Canada

Posted 05 March 2019 - 07:14 PM

Greg,

 

Have a look at the doc for Alpaca and the enabling component called ASCOM Remote.


  • gregj888 likes this

#4 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 05 March 2019 - 08:10 PM

Bob,

 

Just watched the videos and looks promising.  Still not clear how many drivers can connect to a "client" (?) on the remote PC and how many of those clients can connect with the PC running the main application (Like SGP). 

 

As expected, the remote PC needs to run Windows if you intend to use the existing ASCOM drivers.

 

On the plus side, the rotator shows that the end device can have a built in interface so Plug and Play looks somewhat easy.  Embedding ASCOM (or INDI) into the device with a web interface for setup would do away with all drivers and be totally platform independent...  what a concept :-)



#5 rpineau

rpineau

    Open source X2 plugins for TheSkyX and RTI Zone

  • *****
  • Vendors
  • Posts: 284
  • Joined: 30 May 2012
  • Loc: CA, USA

Posted 05 March 2019 - 09:29 PM

In the end you still need a windows box where all the actual equipment is connected and supported by ASCOM .... So if I want ALL OS X and no Windows.. ASCOM still doesn't do it.

 

https://ascom-standa...acaOverview.png



#6 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 March 2019 - 09:48 PM

In the end you still need a windows box where all the actual equipment is connected and supported by ASCOM .... So if I want ALL OS X and no Windows.. ASCOM still doesn't do it.

 

https://ascom-standa...acaOverview.png

This is incorrect. The Alpaca protocols are totally independent of Windows. There is nothing stopping a program on (for example) MacOS from talking to (for example) a Linux mount via the Alpaca protocols. The image simply shows how today's Windows-based technology can already connect to future technology on other platforms. 

 

Snap1.png


  • psandelle likes this

#7 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 March 2019 - 10:00 PM

Bob,

 

Just watched the videos and looks promising.  Still not clear how many drivers can connect to a "client" (?) on the remote PC and how many of those clients can connect with the PC running the main application (Like SGP). 

 

As expected, the remote PC needs to run Windows if you intend to use the existing ASCOM drivers.

 

On the plus side, the rotator shows that the end device can have a built in interface so Plug and Play looks somewhat easy.  Embedding ASCOM (or INDI) into the device with a web interface for setup would do away with all drivers and be totally platform independent...  what a concept :-)

I'm unclear on your first question. To me the 'client" is the 'main application (like SGP). Are you asking how many remote Windows devices or non-windows devices can be made reachable from SGP? The answer is "more devices than SGP can use". Or I am confused.

 

Of course, you need Windows to host Windows ASCOM devices. The point here is that anyone on Linux or Mac who wants to implement the Alpaca protocols can immediately connect to any Windows-hosted device. No changes needed on the Windows end! That's the flip side of the Linux rotator demo, a Linux app can use a Windows device with no changes needed on the Windows side. Your Linux program can use the Astro-Physics mount complete with APCC. It has to implement the Alpaca protocol but that's all. 

 

On the third point, exactly, except INDI is not part of this... yet. I can see a Linux-resident middleware server analogous to ASCOM Remote, though. That one would allow Linux-hosted INDI devices to become part of the Alpaca ecosystem, just like the Windows-hosted ASCOM/COM drivers are already opened to the Alpaca world by the existing ASCOM Remote middleware

 

Any volunteers out there who would want to build a Linux-resident INDI-device hosting server that connects to the Alpaca environment? It would be a fun project. It probably could be hosted on a very low-end thang like a Pi.


Edited by Bob Denny, 05 March 2019 - 10:34 PM.

  • lambermo and psandelle like this

#8 rpineau

rpineau

    Open source X2 plugins for TheSkyX and RTI Zone

  • *****
  • Vendors
  • Posts: 284
  • Joined: 30 May 2012
  • Loc: CA, USA

Posted 05 March 2019 - 10:03 PM

Do you think vendors are going to write Plugin/Driver on other platform than Windows if all they know is ASCOM.. and ASCOM is not present on these platform.

So unless there is an underlying standard that is multi-platform to interface with the hardware, Alpaca is just an overlay/extension to allow non Windows machine to talk to hardware managed via ASCOM on Windows (similar to the INDI server/client architecture without the multi-plaform server).

 

Alpaca only define the top layer protocol and does nothing toward having mult-iplatform low level hardware support.

So unless there is a INDI bridge or a X2 bridge it's still mostly going to be used to connect  to windows across a network.

 

Show me an ALL OS X or ALL Linux implementation with direct support for .. Meade DSI IV camera as an example... you know .. the one where there is currently only ASCOM support on Windows... (just an example as I don't have this camera and know there is no support on other platform than Windows).

Alpaca is not a bad thing or a bad idea.. it's just not going to change a lot from a user standpoint if you're not already on windows.


Edited by rpineau, 05 March 2019 - 10:05 PM.


#9 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 March 2019 - 10:22 PM

 

Do you think vendors are going to write Plugin/Driver on other platform than Windows if all they know is ASCOM.. and ASCOM is not present on these platform.

Of course. The devices need native code on each OS, of course. The choice, then, is whether to (a) force developers on each platform to use their proprietary API (a total loser), or (b) to implement INDI and provide access only to Linux programs, or to © implement Alpaca and provide the possibility to access the device from anywhere. In a way INDI and Alpaca are competitive, but INDI has no life on the 800 lb gorilla of astronomy software/device platforms: Windows. 

 

I already know of two device companies who have lived on Windows and who died and went to heaven when they saw Alpaca. They are implementing self-contained devices which have Ethernet and WiFi, and which will only speak Alpaca. These devices will be immediately usable by all of their existing Windows clients. Anyone else on Linux or Mac will be able to use them via direct Alpaca (forget Windows) as soon as their software can speak Alpaca.

 

Don't sell the movers and shakers in astronomy hardware and software short. And yes this is a chicken and egg problem. We have the chickens, now we need some eggs.

 

PS: Cameras are the most difficult devices to interface. The ASCOM Camera standard has only been out there for 10 years, yet proprietary APIs are still common. Either the camera makers force app developers to use their API, or the imaging app developers force the camera makers to support their proprietary API. A many to many problem. This will not change soon, ("tradition", price competition, and life-science applications drive the camera makers) and the advent of CMOS is making it more uncertain. CMOS is at an inflection point, which means people are learning and adapting. No one knows how that will end up being architected for astronomy.


Edited by Bob Denny, 05 March 2019 - 10:33 PM.

  • mclewis1 and psandelle like this

#10 rpineau

rpineau

    Open source X2 plugins for TheSkyX and RTI Zone

  • *****
  • Vendors
  • Posts: 284
  • Joined: 30 May 2012
  • Loc: CA, USA

Posted 05 March 2019 - 10:31 PM

Let's agree to disagree for now and let's see how this evolves. for me "Of course. The devices need native code on each OS, of course" is the most important part and I don't see this happening.

So let's check back in 6 month or even a year and see how the landscape has evolved.



#11 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 March 2019 - 10:39 PM

The self-contained WiFi/Ethernet devices are already being built now. So you won't have to wait long. But you are right, it will take years before the mainstream catches up. This is exactly what happened during the early years of ASCOM... the people who were writing the proprietary control code fought it tooth and nail because their programs were serving as barriers to other software entering the market. This is what we want to prevent, and keep the ecosystem open. It will take a few years, but you have to start somewhere, and the leaders will get a nice leg up on the others who "resist".

 

 

for me "Of course. The devices need native code on each OS, of course" is the most important part and I don't see this happening.

I don't understand what you're saying. The devices must have control code on at least one OS. Or maybe you're saying that (for example) the existing Linux devices won't be interested in being useable from Mac or iOS or Windows? Existing Windows devices are already enabled for use by iOS, Android, MacOS, and Linux. Some REST code is all that's needed that that's supported universally on all platforms. These would be the eggs I am talking about. Anyway I probably don't understand what you're saying. 


Edited by Bob Denny, 05 March 2019 - 10:44 PM.

  • psandelle likes this

#12 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 05 March 2019 - 10:44 PM

Bob,

 

Need to clean up the diagrams.  "Client" came from your drawing, and I assumed that end should have been a server.  Very hard to ask questions using the diagrams as they are.  Remote client and remote server in the same box is also a little perplexing.  I would suggest a few example topographies.

 

Yes, that answers my first question.

 

I understand on the drivers, that's why I want the native web interface.   Alpaca seems to do that.  I floated an idea several years ago for embedded INDI...  very close to the same concept.  Ever yacked about it on the ASCOM forum.  I understand that this is not INDI, but will note that INDI is cross platform at this point (CdC on win talking to devices connected to Linux and/or Macs).  I am on board here, this is a winner in my book.  Linux can use the same interface for the same camera... Awesome.

 

So if I have 3  Alpaca devices connected to a Pi: scope, filter wheel and focuser.  These are all low overhead so enough computer to handle them.  At the SGP, how do I connect if on my observatory network?  Same question across the web?  Abstract answer is fine, what if anything is needed that isn't available?

 

Now, to the Pi above I have a small PC.  As and aside, I hate WIN10, so keep that in mind.  That PC is running Win10 with the remote ASCOM server(?, the remote end) and a camera connected.  How does that change things or does it?

 

Certainly a positive development.


  • psandelle likes this

#13 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 05 March 2019 - 10:54 PM

 

So if I have 3  Alpaca devices connected to a Pi: scope, filter wheel and focuser.  These are all low overhead so enough computer to handle them.  At the SGP, how do I connect if on my observatory network?  Same question across the web?  Abstract answer is fine, what if anything is needed that isn't available?

Install ASCOM Remote on the SGP machine. Fire up the middleware then point its ASCOM Standard (COM) devices to the IP/Port of the Pi that is controlling the scope, filter wheel, and focuser. Make each of those device son the PI talk Alpaca. Boom! SGP can use them without any modifications on Windows. This is what I show in the second video: A Pi-resident Linux/Python/Wifi rotator that can be controlled by an unmodified copy of TheSky X on WIndows. 

 

I hope I understood your question. 

 

 

Need to clean up the diagrams.  "Client" came from your drawing, and I assumed that end should have been a server.  Very hard to ask questions using the diagrams as they are.  Remote client and remote server in the same box is also a little perplexing.  I would suggest a few example topographies.

Without understanding how the ASCOM Remote middleware works, we will have a tough time communicating. It is clever, it is not what you might think on the surface. Here is a link to the documentation, but the best way to get familiar with this is to actually install it and use it!

 

The place to get started is here.


  • psandelle likes this

#14 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 05 March 2019 - 11:37 PM

Bob,

 

I may over time, but am pretty interested in the INDI solution at the moment.  INDI can already do all this, though without  Alpaca.  I can see an  Alpaca connection for INDI, that's pretty simple in the scheme of things.  I suspect Alpaca will be the winner out of all this. 

 

The INDI solution may change if I stub my toe on something.  The reasons are mostly related to Windows...  Updates that are hard or impossible to turn off, CPU hog (compared to Linux), a lot easier to do "strange stuff", multi platform support is better.   

 

One thing that INDI can so is to daisy-chain servers.  I would prefer to also have multiple server connections to the client SW (SGP) but being able to chain them makes it viable.  Chaining also makes a single connection which can have some advantages especially if going across the web .  That's the root of the PI/PC question above and the answer still isn't clear, will try it later.   

 

I do have ASCOM loaded and have used it some for simple stuff. 

 

I have Linux and INDI loaded on 3 PCs, a couple of Pis and a Jetson.  One PC is a mini (ATOM) that's slated for the mount.  The Pi3 is the Observatory controller (and weather station, cloud detect).  I'll have to figure out  Alpaca for the observatory controller, it will be able to handle INDI, and now  Alpaca at the same time... so good timing.

 

I'm quite serious about Windows-10  It's ok for GUI applications, not so much for automated operation IMHO.  


Edited by gregj888, 05 March 2019 - 11:37 PM.

  • Chris Ryan likes this

#15 rpineau

rpineau

    Open source X2 plugins for TheSkyX and RTI Zone

  • *****
  • Vendors
  • Posts: 284
  • Joined: 30 May 2012
  • Loc: CA, USA

Posted 06 March 2019 - 02:13 AM

The self-contained WiFi/Ethernet devices are already being built now. So you won't have to wait long. But you are right, it will take years before the mainstream catches up. This is exactly what happened during the early years of ASCOM... the people who were writing the proprietary control code fought it tooth and nail because their programs were serving as barriers to other software entering the market. This is what we want to prevent, and keep the ecosystem open. It will take a few years, but you have to start somewhere, and the leaders will get a nice leg up on the others who "resist".

 

I don't understand what you're saying. The devices must have control code on at least one OS. Or maybe you're saying that (for example) the existing Linux devices won't be interested in being useable from Mac or iOS or Windows? Existing Windows devices are already enabled for use by iOS, Android, MacOS, and Linux. Some REST code is all that's needed that that's supported universally on all platforms. These would be the eggs I am talking about. Anyway I probably don't understand what you're saying. 

What I'm saying is that I don't want ANY windows in my environment.. So all "control code" (aka drivers, OS level) need to exist on the non Windows platform for this to be of any interest and use to me (and a lot of other people that are running away from Windows and ASCOM).

Putting a REST API on top of a Windows only standard doesn't make the devices multi-platform over night. It only allows other platform to access Windows controlled devices .. which means having Windows and ASCOM somewhere.. which is exactly what I (we) don't want ... Windows.

I write (and wrote) drivers and plugins for app (not just astronomy app with TheSkyx Pro) and make them cross platform .. so I have a little bit of knowledge in this area and a lot of people are tired and sick of Windows.

So introducing Alpaca with "ASCOM - Not Just for Windows Any More" .. ASCOM on Windows is still is the main requirement for now. So this is not solving the multi-platform problem, just one side of it.


  • TelescopeGreg likes this

#16 rpineau

rpineau

    Open source X2 plugins for TheSkyX and RTI Zone

  • *****
  • Vendors
  • Posts: 284
  • Joined: 30 May 2012
  • Loc: CA, USA

Posted 06 March 2019 - 02:18 AM

And as a side note there is already a INDI wrapper for ASCOM allowing you to use all you applications supporting INDI with ASCOM devices on Windows : http://www.cloudmakers.eu/windi/

So .. Alpaca ... for INDI ..


  • psandelle likes this

#17 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 06 March 2019 - 10:01 AM

 

Putting a REST API on top of a Windows only standard doesn't make the devices multi-platform over night. It only allows other platform to access Windows controlled devices .. which means having Windows and ASCOM somewhere.. which is exactly what I (we) don't want ... Windows.

I still haven't explained myself well enough, I'm sorry. No Windows needed anywhere. And there is nothing about ASCOM Alpaca that is Windows centric or Windows dependent or Windows Oriented or Windows anything. Feel free to use Alpaca instead of INDI between an Arduino focuser and a Linux box. 

 

The CloudMakers wrapper is analogous to the ASCOM Remote "wrapper" middleware server. What Alpaca has is the translations both directions


Edited by Bob Denny, 06 March 2019 - 10:06 AM.

  • psandelle likes this

#18 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 06 March 2019 - 10:08 AM

 

One thing that INDI can so is to daisy-chain servers.  I would prefer to also have multiple server connections to the client SW (SGP) but being able to chain them makes it viable.  Chaining also makes a single connection which can have some advantages especially if going across the web .  That's the root of the PI/PC question above and the answer still isn't clear, will try it later.

May I have an offline conversation with you? I could use some basic INDI clarification that would probably bore people here, and would certainly obfuscate this discussion. If you wouldn't mind, please PM me. Thanks!!

 

And this is a very good conversation. Thanks.



#19 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 06 March 2019 - 10:45 AM

Bob, PM sent



#20 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 06 March 2019 - 11:10 AM

Got it and thank you.

#21 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 06 March 2019 - 03:24 PM

rpineau,

 

It looks like the instruments with the REST interface would be stand alone.  If so, the new devices are hardware and OS agnostic...  That's exactly what I was shooting for with embedded INDI and I think what you want.

 

Keep Alpaca, toss ASCOM so to speak (sorry Bob, trying to make a point). 

 

One advantage of INDI is that devices self declare.  I don't know yet if ALPACA supports this, if not it should.  By self declaring you can literally setup a generic interface in something like CdC that can link to an instrument and build a control panel on the fly.  With some classes and knowledge EKOS could do the same and sequence properly.  The real benefit is expansion going forward, new feature can just work, though perhaps in a somewhat manual mode.


  • Chris Ryan likes this

#22 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 06 March 2019 - 03:50 PM

 

One advantage of INDI is that devices self declare.  I don't know yet if ALPACA supports this, if not it should.

Let's start a new thread on this. It is an Alpaca vs INDI thing, and the two reflect a completely different philosophy. I don't want to obscure the message here about Alpaca with a design philosophy discussion on the relative merits of meta-interface (INDI) vs a strict/constrained interface (ASCOM). I'm thrilled to be able to dispel that perception that Alpaca is Windows-centric or even Windows-dependent. One thing I should mention is that Alpaca is serverless.  

 

 

Keep Alpaca, toss ASCOM so to speak (sorry Bob, trying to make a point).

Strongly related to the above, ASCOM is a set of abstract client-driver interface definitions which were initially implemented over COM on Windows, but which are now also implemented as REST end-points. The key is the ASCOM abstract interface specifications which have proven over 20 years to be just what is needed for routine use. See the video on the ASCOM Alpaca developer page; you have to wait for the Windows-centric initial intro of 01:35. Here's a link to the "meat" of the video which talks about the Windows-independence starting 01:35 into it

 

 

It looks like the instruments with the REST interface would be stand alone.  If so, the new devices are hardware and OS agnostic...

Exactly. Alpaca is serverless.

 

Thanks so much for hashing this out with me Greg. When something new comes along, we all bring preconceptions to the table, me included.


Edited by Bob Denny, 06 March 2019 - 04:11 PM.

  • psandelle likes this

#23 gregj888

gregj888

    Vanguard

  • -----
  • Posts: 2113
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 07 March 2019 - 12:23 AM

Bob,  

 

I have a plane ride or two over the next week, will try to read the spec.

 

I sent you a copy of the WIP hack (I used INDI since it was already network enabled) of the same concept from 2011.  So this is good from my view.  

 

Instead is INDI vs Alpaca, I would propose a tread on use models and system topographies.  If you think of Alpaca as the lowest level "interconnect", what else might be needed to make a useful installation.



#24 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

  • -----
  • Vendors
  • topic starter
  • Posts: 83
  • Joined: 17 Mar 2009
  • Loc: Mesa AZ USA

Posted 07 March 2019 - 01:05 PM

Hey Greg -- Thank you so very much for taking the time to have a civil, respectful, and enlightening conversation on all of this. [Note much of this has been via PM as off-topic from this thread]. I learned a lot from you and by updating myself on INDI. It's going to help me immensely with the talks I have scheduled this year, and with my briefings for the instrument manufacturers. 

 

One important thing: This isn't about ASCOM / Alpaca versus INDI. Computing mirrors life, where we have belief systems and values on which we base our engineering choices. Like religions, it's easy to fall into the trap where "my decisions are  right and others are fools for their decisions". There is no "right" in art or engineering, only in science. I understand where you're coming from.

 

Thanks again, really.


  • gregj888 likes this

#25 han59

han59

    Vostok 1

  • *****
  • Posts: 187
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 07 March 2019 - 05:56 PM

Bob,

 

I'm reading the documentation. Do I understand correctly that you could avoid COM interfacing? You could develop an Alpaca driver for Windows. See my extension of figure 6 from "ASCOM Distributed Architecture.pdf" below:

 

Han

 

canvas1.png

 




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics