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
52 replies to this topic

#26 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 07 March 2019 - 06:06 PM

Yes, an Alpaca driver can be anywhere, even on Windows! And today’s Windows astronomy applications like SGP and TheSky will be able to use it via ASCOM Remote. They would connect to “remote” Alpaca driver at IP 127.0.0.1. Of course apps on other platforms can also talk to it.

Note that existing COM type Windows drivers are made available to Alpaca clients (future) by the ASCOM Remote gateway server.
  • psandelle likes this

#27 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 662
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 07 March 2019 - 07:33 PM

Once you have developed software for an Alpaca device or client running in Linux or MacOs, it will be easier to compile the same code to a Windows target rather then develop a COM version of the code. Like your Alpaca focuser simulator in Python, you likely could use in a Windows environment. There are compilers capable of compiling the same code (with a few or no changes) to an executable target for the different operating systems.


Edited by han59, 08 March 2019 - 05:07 AM.


#28 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 08 March 2019 - 03:52 PM

Read the Alpaca doc on the plane yesterday and got most of my questions answered.

 

I won't say much about ASCOM remote, as my current focus is to get Windows out of the automated portion of the observatory. I will say it looks like a positive addition  to ASCOM and may get rid of the remote desktop connection currently in play ++++!  Those using remote desktops should take a look at ASCOM Remote now IMHO.

 

I’ll use INDI for analogies, not to sell INDI but because it's the only net enable interface we have in use.  My assumption is that INDI will take advantage of Alpaca if it catches on.

 

From the spec, you can run Alpaca on a device (think filter wheel, no current analogy), a server (close analogy to an INDI server for those familiar.  Multiple devices at one address) and via a “combiner” where some number of devices and servers can be combined into a single stream (may be the wrong term but close enough).  Chaining INDI servers is the closest we have for an analogy at the moment and isn’t far off in the functionality.

 

As far as I know, there are no Alpaca devices at the moment and the only client interface may be in ASCOM remote… so this is early.

 

Alpaca uses the ASCOM data and device type declarations and is network enabled (only).  This means the device is not tied to a platform or OS.  Using the ASCOM definition should also speed porting as that parameter set is well established, validated and working on both sides of the interface.  This should be a major advantage to developers and companies providing devices.  As stated, current ASCOM applications get Alpaca for free via ASCOM remote. 

 

Alpaca does not allow self-declaration.  IMHO this is a major negative and will make my pitch.  The example given is motor current on the drive motors and not wanting to have to deal with that in a program.  I’m writing an Observatory Control program and I can’t see how you could have such a system and not want motor currents if available!  Understand my controller is for the Physical facility, not operation (like APC).  APC on the other hand may not care at all about motor currents.  Two applications with different needs, how common is that ;-) ?

 

If you spend any time looking at ASCOM or INDI you will find both need the same specific parameters and commands to get a device to work.  Both allow optional parameters and commands.  INDI also allows the creation of device specific parameters and commands, this being optional on both sides of the interface.  The fact that there is an INDI server app that can use ASOM drivers is pretty close to proof .  That same server is also a pretty good start on an Alpaca interface.

 

Since Alpaca does not forbid adding these extras, developers that need to add configuration, set-up and/or calibration will likely use the same interface to do so.  That means that these extras will be there!  What’s missing is to tell the interface they are there.

 

Two simple parameter calls that return tables are all that is needed.  One call would return a table of parameters the other a table of Commands.  These could be compressed to 1call, but I wouldn’t since the table parameters are different and overloading is IMO error prone.  The parameters are pretty easy, and the more important.  The developer of the device could choose not to include sensitive parameters/commands and an application programmer could choose to pull the tables or not.  Many devices will not have these so would return “not implemented”.  Along with the name you might wand a priority, public/private, read/write, min/max range, min/max warning and a few others, it's a table. 

 

I see no down side, no free for all, no can of worms in this option.  It might be nice to allow some parameter names to be reserved, RA_motor and DEC_motor might be 2 with temp and current having implied meaning, but even that isn’t required.  If an app saw RA_motor with units mA, range from -800 to 800 and min/max warnings at -700 and +700—with this information an application can create an appropriate widget on the fly and warn a user if the limits are exceeded… Easy these days.. no biggie.

 

Last and probably as significant, Alpaca moves us away from USB and RS-232 to Ethernet, BT and WiFi for today anyway!!!   Oh, need some more !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

So I am very hopeful Alpaca will take off.  OS and platform independence would save us a lot of headaches.  And per above, I would talk Alpac and not tie it to ASCOM other than by heritage.  Sorry I couldn’t get traction for the concept in 2011… J

 

As always, please add corrections and additions, trying to get good information, no ego involved.


  • psandelle, R Botero, Bob Denny and 1 other like this

#29 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 175
  • Joined: 04 Jul 2017

Posted 08 March 2019 - 04:43 PM

Greg,

 

To implement that in a Alpaca (or Ascom) driver is not the Action method just what you want to define how to set and get the motor current?

In this case the SupportedActions method allow the client to know about this actions.


  • Bob Denny likes this

#30 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 08 March 2019 - 05:06 PM

I have a few comments. Mainly we're not going to re-engineer Alpaca to change its design philosophy. It is currently (and will remain) an implementation of a mature and strictly defined set of Application Programming Interfaces (APIs), the ASCOM abstract interfaces, and in Alpaca implemented as a set of  REST endpoints which exactly implement the corresponding ASCOM API. 

 

I think our main communication difficulty is in the concept of an API, and secondarily the fact that ASCOM's design is in support of routine use of instruments, leaving the innards and adjustments specific to each device to the device makers and their driver/control software.

 


Alpaca uses the ASCOM data and device type declarations and is network enabled (only).

The key is that Alpaca is an implementation of the ASCOM Application Programming Interfaces. This is not just "data types" and "device types". At an abstract level, an API is a set of properties and methods with support use of some type/family of device. In the case of ASCOM, "family" is the key. Specifics of individual variations of a certain type of device are excluded from the interface (with the exception of an open-ended Action method but this is little used). "Routine Only" is the key to ASCOM's design and to its success. 

 

Your motor control example is illustrative of the philosophy difference. In ASCOM (and by derivation Alpaca) the motor currents are part of the "innards" of a mount and specifically excluded from the interfaces, by design. An ASCOM client is using the mount to position its optics, period. This means (1) slew to __ coordinates, (2) track the apparent motion of the sky, or not, or maybe a solar system object or even a satellite. And do it as close to perfectly as you can, period. There are a few other routine things like parking. In order to accomplish these things each mount has to do [I don't care what]. This forces each mount maker to take responsibility for the installation and adjustment of all of the doodads their mount needs to work "even closer to perfectly" than their competition. In the ASCOM ecosystem, motor currents would never ever be exposed to end users or applications. The devices must accomplish their tasks without users having to reach under the hood and adjust the spark timing or fuel mixture as they drive. For a system design in which those sorts of low level elements would be pushed all the way out to the astronomers trying to get images, I would say INDI is the interface technology of choice. Keep in mind that there are literally dozens of different types of mounts, with wildly differing electromechanical characteristics inside, and different geometries (German, AltAz, Chronos, Fork). ASCOM's Telescope/Mount API makes them all usable without differences to end users (for the most part the geometry can become evident with flipping and derotation). Putting it another way, a motor current would never be part of an observing request from an astronomer.

 


As far as I know, there are no Alpaca devices at the moment and the only client interface may be in ASCOM remote…

Actually, thanks to ASCOM Remote, there are tons of Alpaca devices available now. With a small amount of one-time setup, every device with an ASCOM driver on a given Windows system can be an Alpaca device with no changes to the device or its driver. Expect some self-contained ones to appear in the coming months.

 

Again thanks for helping me get clarity on the philosophies and technology landscape into which ASCOM Alpaca is being launched. I really do appreciate it. If you want to discuss distributed systems design philosophies, interface design, etc. let's start a new thread. I love this stuff and it would be fun.


Edited by Bob Denny, 08 March 2019 - 05:09 PM.

  • psandelle likes this

#31 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 08 March 2019 - 05:23 PM

Greg,

 

To implement that in a Alpaca (or Ascom) driver is not the Action method just what you want to define how to set and get the motor current?

In this case the SupportedActions method allow the client to know about this actions.

Thanks Patrick. As far as I know Action is rarely used, and even then temporarily as a bridge, and as a "test stage", for something that may end up being added to the interface (sCMOS cameras are driving some of this now). What I was trying to say is that the landscape is different in that ASCOM, and by derivation Alpaca, operate at a higher level in the system block/layer diagram then (apparently) does INDI. I see INDI as a meta-interface (a standard interface for publishing each device's own specific interface for clients/consumers to discover).

 

Thank you so much for implementing Alpaca in CdC so quickly!!



#32 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 08 March 2019 - 06:18 PM

 

 I have a few comments. Mainly we're not going to re-engineer Alpaca to change its design philosophy. It is currently (and will remain) an implementation of a mature and strictly defined set of Application Programming Interfaces (APIs), the ASCOM abstract interfaces, and in Alpaca implemented as a set of  REST endpoints which exactly implement the corresponding ASCOM API.

My CS degree is stale and I consider this trivial.  No engineering change, no change in philosophy?????

 

 

 The key is that Alpaca is an implementation of the ASCOM Application Programming Interfaces. This is not just "data types" and "device types". At an abstract level, an API is a set of properties and methods with support use of some type/family of device. In the case of ASCOM, "family" is the key. Specifics of individual variations of a certain type of device are excluded from the interface (with the exception of an open-ended Action method but this is little used). "Routine Only" is the key to ASCOM's design and to its success.

So it's windows only?  I understand that you are firmly advocating for ASCOM, Alpaca has it roots there but will, if successful, go much further.  

 

 

  Putting it another way, a motor current would never be part of an observing request from an astronomer.

I would monitor if available on my personal observatory...  why wouldn't I?  You have chosen not to allow it to be part of the request. I agree that has been an attitude in the design of ASCOM, just not one I nor a lot of others agree with.   Ant to think INDI users want to reach under the hood any more than ASCOM users want to is at best, IMO, naive

 

 Actually, thanks to ASCOM Remote, there are tons of Alpaca devices available now. With a small amount of one-time setup, every device with an ASCOM driver on a given Windows system can be an Alpaca device with no changes to the device or its driver. Expect some self-contained ones to appear in the coming months.

Sorry, that's marketing BS.  Please post links to the currently available instruments/devise with embedded Alpaca compliant interfaces.  I hope I am wrong, but doubt it.  By that same logic, all have been INDI compliant for some time, why switch? 


  • rkinnett likes this

#33 han.k

han.k

    ASTAP Software

  • *****
  • Vendors
  • Posts: 662
  • Joined: 09 Mar 2015
  • Loc: the Netherlands

Posted 08 March 2019 - 06:34 PM

Bob,

 

Some positive feedback, After installing  "ASCOMremote", within one hour I could operate my telescope from an other Window PC using ASCOM, so it works out of the box.

 

As a programmer, I started to adapt my simple client application for Alpaca and that took a lot more effort and study, but the first commands are executed. So I can say it is relative easy to implement. Having the pretty strict and structured ASCOM commands has its charm.

 

Peter Simpson and you have done a great job. Thanks!

 

Han


  • gregj888, psandelle and Bob Denny like this

#34 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 08 March 2019 - 06:46 PM

Excellent Han, thanks! I really appreciate your feedback, and I will definitely pass your compliments along to Peter, though I am fairly sure he is monitoring this discussion. 



#35 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 08 March 2019 - 06:47 PM

 

By that same logic, all have been INDI compliant for some time, why switch?

I agree, why switch? You have it all, and for your application INDI appears to have it all. Go with it.


  • psandelle likes this

#36 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 08 March 2019 - 08:35 PM

I agree, why switch? You have it all, and for your application INDI appears to have it all. Go with it.

 

 Ignoratio Elenchi if I am not mistaken.

 

These are good positive changes to ASCOM.  I could not reference analogies to ASCOM as ASCOM did not have net support until ASCOM remote.   Your last statement above needed to be called out.   You know what was being said... and replied this way. " Actually, thanks to ASCOM Remote, there are tons of Alpaca devices available now."  You  were asked did not post a link to a commercial with native Alpaca interface...  My comment wasn't meant as a negative, simply the reality of something new.

 

As Han stated above, ASCOM remote is a real positive solving a long time short coming of ASCOM.  Alpaca solves another big weakness of both ASCOM (even with remote) and INDI, don't sell it short, but don't cripple it on ego ether, my words.

 

Please discuss with your equipment vendors the response might surprise you.  



#37 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 08 March 2019 - 09:01 PM

I've done my best, and my last post was borne of frustration. The community will speak.

 

 

Please discuss with your equipment vendors the response might surprise you.

I really feel bad that it has come to this. 

 

 

Ignoratio Elenchi if I am not mistaken.

All I wanted to explain is that your wants and INDI's design aren't the same as the design of the constrained/defined API of ASCOM. So I suggested you just go with INDI. So go with it. I really meant it.

 

In any case I still appreciate your time and thoughts.



#38 555aaa

555aaa

    Vendor (Xerxes Scientific)

  • *****
  • Vendors
  • Posts: 2,210
  • Joined: 09 Aug 2016
  • Loc: Ellensburg, WA, USA

Posted 08 March 2019 - 09:31 PM

I'm kind of with Greg on this. My mount currently monitors current and I use it all the time, it's important to keep track of what the mount is doing. In a DDR mount, current is part of balance monitoring and for safety it should be available, and so that means that you end up with a non-ASCOM private interface with ASCOM stuck on top. Some other problems I am struggling with have to do with modeling and tracking - there's no way that I can see by which the mount can use an external modeling program and then have the model parameters sent to it via ASCOM, which it needs to do to perform accurate unguided tracking. There is no trajectory based interface or time-precise methods. A trajectory method pre-loads the mount with a sequence of coordinates and precise times and the mount moves through those coordinates; for example for satellite tracking. ASCOM only has a means to adjust tracking rate but it is indeterminate in time - you can't say go to such and such a speed at such and such a time. You can ask for something, and see if it happened, but you can't tell the mount to do something at a specific time. That is the sort of thing that's important in satellite tracking. There is a simple flag for needs refraction or not but the modeling thing is way more complex and it isn't very clear whether the mount has modeling authority or the application. A mount can't do modeling by itself; it needs a camera and other stuff to build its model. I think you have the same problem on the imaging side with precise shutter time which is important in astrometry. If there are solutions for these, I'm all ears, so to speak.

 

-Bruce


  • gregj888, Chris Ryan and rkinnett like this

#39 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 08 March 2019 - 09:52 PM

Bob,  for my remote observatory since I am ruling out windows, INDI is my only real choice at the moment.  Unobtanium isn't functionally effective no matter how pretty the spec.

 

The things I am most interested in on the remote system are:

   mount current - what Bruce said and a good way to track mount performance if you think it is acting up and can't get there for a week.

   battery pack voltage-- if I need to go to solar power, even if the controller monitors an protects the pack.

   motor currents on the dome/ror --  indicates the need for a maintenance visit BEFORE A FAILURE

 

A pretty  minimal and application specific list.  If part of the nominal connection they are less apt to be missed.  And yes, I can do these with INDI.  

 

BTW, I'll still use Firecapture/CdC with ASCOM on my portable capture rig and for public viewing sessions.  Win-10 surface for these applications.


Edited by gregj888, 08 March 2019 - 11:58 PM.


#40 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 175
  • Joined: 04 Jul 2017

Posted 09 March 2019 - 04:35 AM

I think all of this is not really related to Alpaca itself.

 

If I can risk an analogy with computer hard drive , this is the same difference between the SCSI protocol to access the data on the drive and the SMART protocol to monitor the drive status.

 

Alpaca is like SCSI, it allow to use the device as Bob clearly explain above.

What you are missing is SMART and maybe this is something you must ask the mount manufacturer for a standard way to report this values. Or why not discuss the way to produce this standard report using the available mount command.

 

Then if all the mount report there status in a standard format it is maybe possible to update the Alpaca telescope specification to add a property to retrieve this status.

This will enable the final application to use this status for anything they think is good.

 

The way this is done for now with INDI is too anarchic, this may work for you if you write your specific scripts but this cannot be generalized. So my remark to produce a standard report apply also to INDI.

 

When one write an application using INDI devices (I do that for 15 years now)  the only way is to use the standard properties set. This is about the same operational properties that are defined in Alpaca: https://www.indilib....properties.html

 

Anything not described in this page is too specific to every driver and may change at any time, so this cannot be used by the application, this can just be reported in the dynamic user interface, or use by installation specific scripts.

 

About camera shutter time,which are operational properties, there is already in Alpaca the properties LastExposureStartTime and LastExposureDuration to cover this case. It is up to the driver to implement them.

 

Patrick


Edited by Patrick Chevalley, 09 March 2019 - 05:39 AM.

  • gregj888 and R Botero like this

#41 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 09 March 2019 - 09:54 AM

Patrick,

 

Thank you and I agree in general.  If I look at INDI and ASCOM (I too use both) there are more or less required aspects (SCSI) that have to be there to operate.  These are required.  There are others that are common and included, camera cooling is probably a good example.  I had looked at the ASCOM properties while reviewing the Alpaca spec.  I believe I called that out in my description.

 

For an arbetrary command, self declaration of the parameters to pass and return becomes an elegant solution.  A simple list of commands would also require a way to get this information, which is a little more work.  I agree too you would not create general scripts that include a command like this.  I also don't see a lot of reasons to add commands, but I am not smart enough to think of all possibilities now and in the future.  How long has ASCOM been in use and how long did it take to get network enabled...  these things once adopted have a long life. 

 

The opposite is true for extra data (motor currents above).  These are easy to implement and manage at the installation level.  Don't use them if you want generic.  Again using the motor current example.  How hard is it to read a table and allow the user to select entries and actions?  IMHO its trivial to add a widget and add actions and some could be important.  As a user I could pull up a list of available data, select motor current, select warn on failure.  The Application could then add a widget to the interface and flash red if the current is out of bounds.  

 

Another example might be the battery pack in a solar powered system, if not in the interface already.  Same scenario  but now I want to shut down on low warning...  so I can close the roof while there is power and not hurt the batteries.  

 

In these cases the application can use the information appropriately without actually knowing what it is.  Sorry, I don't see the issue or the anarchy. 

 

Many of us write site specific scripts and like that flexibility.  

 

One thing maybe you could clear up for me.  Is the link between the ASCOM main and ASCOM remote Alpaca?  If so, can ASCOM remote servers be daisy chained?

 

If you go back on the ASCOM and INDI forums to about 2011, you'll find I called out for an Alpaca like interface then (I called it embedded INDI), so I think I am onboard and understand Alpaca.  I'm pushing back on the totally closed aspect, a longtime complaint against ASCOM.  I'm also very disappointed that an accurate status can't be put forward.  

 

Thank you.



#42 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 175
  • Joined: 04 Jul 2017

Posted 10 March 2019 - 05:46 AM

No, Ascom remote server cannot be chained the same way as the Indi server.

But there is no need for chaining because Alpaca do not use "snoop device" and this is the main reason for this feature in Indi to snoop a device connected to another server.

 

If the Alpaca device are connected with different IP address you can just specify the right address for each device. You can also do the same with multiple Indi server that are not chained.

 

Patrick


  • gregj888 and psandelle like this

#43 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 10 March 2019 - 09:47 AM

Patrick, thank you.  More than chaining, I was wondering if the client side) remote server (going to say SGP) is Alpaca compliant.  If so it could be used as a test vehicle or as a Windows to ?? bridge.  Sounds like the answer there is no, correct?

 

Not trying to be dense, just to understand.  



#44 Patrick Chevalley

Patrick Chevalley

    Vostok 1

  • -----
  • Vendors
  • Posts: 175
  • Joined: 04 Jul 2017

Posted 10 March 2019 - 11:53 AM

Do you meant defining in a first "ASCOM remote server" a device driver using the "ASCOM remote client" to a second  "ASCOM remote server" running on another computer that handle the real driver?

 

Why not? But what is the interest again configuring the "ASCOM remote client" in SGP directly to the second server.

On the inconvenience this double the network traffic and latency.

 

If this is because of network zoning, remember the network transport for Alpaca is HTTP. This make very easy to route the traffic anywhere, including through Apache proxy.



#45 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 10 March 2019 - 07:49 PM

 

Patrick, thank you.  More than chaining, I was wondering if the client side) remote server (going to say SGP) is Alpaca compliant.  If so it could be used as a test vehicle or as a Windows to ?? bridge.

I'm unsure if I understand this. Are you asking if SGP can talk to an Alpaca device on another system? If that's the question then yes. In SGP instead of choosing an ASCOM COM driver, you choose an ASCOM Alpaca driver ("ASCOM Remote 1"). On Windows this is separate driver that takes the ASCOM function calls from SGP and instead of calling into Windows/COM to reach a local driver, the exact same calls are instead routed via Alpaca/REST out over the internet direct to the remote Alpaca driver. The shim runs right inside SGP. No external server needed. All calls are exactly the same regardless of Windows/COM or Alpaca. 

 

I think you're hung up on servers somehow. As Patrick points out this is all HTTP/REST.

 

If I misunderstood you, then clarify and I'll do my best to answer. 


Edited by Bob Denny, 10 March 2019 - 07:50 PM.


#46 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 10 March 2019 - 08:11 PM

Patrick,  Don

 

SGP<>ASCOM.main  <====  this network link ====>>  ASCOM.remote <> ASCOM.com_driver

    ^^^^^^^^^^^^                          ^^^^                           ^^^^^^^^^^^^^^^^^^^

      computer-1                             is this Alpaca?                                computer-2 

 

 

So I think this is an easy question.  I have an Device (or two) on a remote computer using com drivers and want to tie in with the local computer.  I assume this is what 555aaa did and what I would do to try ASCOM remote...    Is the network link between the two computers Alpaca or is something else specific to ASCOM remote?  No Alpaca devices in this scenario.  No wrong answer here either, just trying to understand the pieces.

 

I'm calling ASCOM.main the portion of ASCOM running on the computer with SGP, CdC or other like application.  I'm calling to portion of ASCOM running on the remote computer (mount) talking to the  COM divers ASCOM.remote and that may not be how you have named them.   If you decipher to the ASCOM names I will try to use them in  the future.

 

Thanks.


Edited by gregj888, 10 March 2019 - 08:12 PM.


#47 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 10 March 2019 - 09:00 PM

 

 

SGP<>ASCOM.main  <====  this network link ====>>  ASCOM.remote <> ASCOM.com_driver

    ^^^^^^^^^^^^                          ^^^^                           ^^^^^^^^^^^^^^^^^^^

      computer-1                             is this Alpaca?                                computer-2

Yes. "ASCOM Main" is the ASCOM Alpaca driver (as opposed to the ASCOM COM driver) that SGP uses to get into the Alpaca world (so yes 'this is Alpaca"). Here's what it looks like to SGP (which uses ASCOM to interface to its devices).

 

Snap1.png

 

Snap2.png

 

At this point, SGP is connected to the Rotator on Computer 2 via the ASCOM Remote "inbound" Alpaca server which relays to the COM driver for the rotator.

 

All of the above exists now.


  • mclewis1, psandelle and arspi like this

#48 gregj888

gregj888

    Mercury-Atlas

  • -----
  • Posts: 2,702
  • Joined: 26 Mar 2006
  • Loc: Oregon

Posted 10 March 2019 - 09:11 PM

Don,

 

Excellent, Thank you. 



#49 555aaa

555aaa

    Vendor (Xerxes Scientific)

  • *****
  • Vendors
  • Posts: 2,210
  • Joined: 09 Aug 2016
  • Loc: Ellensburg, WA, USA

Posted 14 March 2019 - 01:02 PM

OK so since we're writing our mount ASCOM interface now, which will be native Ethernet (no serial port), you're suggesting Bob that we can write this as a native Alpaca interface? I take it that for users who are not using Aplaca, they will still need a conventional ASCOM driver which uses http to communicate to the mount. 

 

Is there an intent to use the JSON transaction ID to ensure that requests are properly ordered? That is something I'm concerned with. I'm concerned that there is possibly an issue with synchronization between the mount and camera(s) because there is no means to indicate when a command is to be executed and no signaling back of when a command is completed, and no distributed precise time.

 

-Bruce


  • Bob Denny likes this

#50 Bob Denny

Bob Denny

    Vendor (DC-3 Dreams)

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

Posted 14 March 2019 - 02:12 PM

 

OK so since we're writing our mount ASCOM interface now, which will be native Ethernet (no serial port), you're suggesting Bob that we can write this as a native Alpaca interface? 

Yes. I'm not sure what you mean 'native' Ethernet. you're not talking about the low level Ethernet frames, right? This is TCP/IP and for Alpaca it means HTTP on top of TCP/IP so your mount will need an embedded HTTP (web) server. It will also need to serve some sort of (HTML/Javascript/???) based user interface for setting things up, or maybe a plug-in "service box" of some sort. 

 

I take it that for users who are not using Alpaca, they will still need a conventional ASCOM driver which uses http to communicate to the mount.

No. Users of today's ASCOM-enabled observing software (planetaria, etc.) on Windows will be able to use your mount with no changes to their software (see the FAQ). An ASCOM/COM driver is not needed. The new ASCOM Remote layer will give them access to your ASCOM/Alpaca enabled mount.

 

Is there an intent to use the JSON transaction ID to ensure that requests are properly ordered? That is something I'm concerned with. I'm concerned that there is possibly an issue with synchronization between the mount and camera(s) because there is no means to indicate when a command is to be executed and no signaling back of when a command is completed, and no distributed precise time.

There is a facility for transaction ordering at both the client and the server end. But the scenario you are describing relates to the layer above the data transactions. From the ASCOM Alpaca Reference, section 3.1.3:

 

Timing Independence: To the extent possible with the device, modules must not place
timing constraints on properties and methods. Implement asynchronous calls wherever
possible in order not to lock up clients unnecessarily.

 

As an example, Telescope.SlewToCoordinatesAsync() must start the slew (or raise an error if it cannot for some reason), it should (must) complete "immediately". Then the client software would be responsible for checking Telescope.Slewing, and wait until it becomes False, or go do some other stuff, check again, etc. until the client can't do anything else until the slew has completed. This synchronization would not be the responsibility of Alpaca.

 

Note: at present, the synchronous Telescope.SlewToCoordinates() is also mandated in the ASCOM API (interface) spec. This method is not supposed to return until the operation is completed. Clients will depend on the return from this method call to be a valid indication that the slew has completed. This will result in a REST transaction that could last minutes. I expect the synchronous methods to become deprecated in the future, possibly allowing Alpaca drivers to return "method not implemented". This would be a breaking change for some of today's astronomy applications so for the time being we'll just try to live with it while helping to discourage the use of synchronous methods by application developers.

 

I would encourage you to look closely at the Developer documentation in general but specifically at the Alpaca Information on the ASCOM web site




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