Date   

Re: Mach2 Unguided imaging results from last night

Konstantin von Poschinger
 

Hi Roland,

thats sound absolutely great. With guiding I also got such good results.
When we will be able to use the new Keypad software?
Is the instruction also ready, so we can read and find out how to build a Dec line model or a model that follows the object path?

Konstantin

 
Konstantin v. Poschinger

Hammerichstr. 5
22605 Hamburg
040/8805747
0171 1983476

Am 07.10.2020 um 00:03 schrieb uncarollo2 <chris1011@...> via groups.io <chris1011@...>:

Hi Astronuts,

I have been busy assembling and testing Mach2 mounts and software and getting a better feel for how well the mount tracks unguided. The scope is my 160 with Quad TCC running at 1.16 arc sec per pixel. Last night was 2/5 seeing, heavy smoke from the West coast fires, and with clouds constantly running in and out. Makings for very poor imaging but excellent for unguided imaging tests.

The target was the Bubble Nebula and M52. I took quick pointing data of 5 stars each on opposing Dec lines instead of taking data along the object's path. This way the modeling program could better calculate orthogonal errors, polar alignment error, scope flexure, as well as the drift error due to atmospheric refraction. The result was surprisingly good. I was able to take 1 hour exposures with the object 4 hours before the meridian, where the tracking rates were quite far from sidereal. The cropped image below shows the result of a single 1 hour exposure:

Rolando

<dummyfile.0.part>




Re: AP900 PEC Curve

Bill Long
 

I dont think AP900 mount were sold with CP4's so the previous owner would have upgraded the control box and recorded a fresh curve. At least that is what I would assume anyhow. I guess they could have saved the old one to file and uploaded the new one.

At any rate they are pretty easy to make with PEMPro. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Wes Atchison via groups.io <wa5tku@...>
Sent: Tuesday, October 6, 2020 3:04 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] AP900 PEC Curve
 
Is there a way to tell when the PEC curve that is stored in the mount was generated?  I have an AP900 with CP4 the I acquired in March.  I am wondering if the PEC curve stored is the original AP generated curve or one generated by the previous owner.

 Thanks for any help in advance,

Wes
WA5TKU


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Roland Christen
 

Hi Joel,

Ray Gralack looked at your ASCOM log and discovered that the mount was sent a sync to a negative Dec number (-55 Dec instead of +55). Doing so caused the scope to subsequently dive under the mount when the park command was sent.

If your command program had been connected to APCC instead of the mount directly thru the driver, then that errant sync would have been flagged and prevented from getting thru. It's one of many safety features of APCC. You would also be able to set limits easily, so that pier crashes would not occur. The basic APCC is all you need to protect those delicious scopes on that mount, Pro version is optional.

Rolando


-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:54 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Re: AP900 PEC Curve

Roland Christen
 

No way to tell.

Rolando



-----Original Message-----
From: Wes Atchison via groups.io <wa5tku@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 5:04 pm
Subject: [ap-gto] AP900 PEC Curve

Is there a way to tell when the PEC curve that is stored in the mount was generated?  I have an AP900 with CP4 the I acquired in March.  I am wondering if the PEC curve stored is the original AP generated curve or one generated by the previous owner.

 Thanks for any help in advance,

Wes
WA5TKU


AP900 PEC Curve

Wes Atchison
 

Is there a way to tell when the PEC curve that is stored in the mount was generated?  I have an AP900 with CP4 the I acquired in March.  I am wondering if the PEC curve stored is the original AP generated curve or one generated by the previous owner.

 Thanks for any help in advance,

Wes
WA5TKU


Mach2 Unguided imaging results from last night

Roland Christen
 

Hi Astronuts,

I have been busy assembling and testing Mach2 mounts and software and getting a better feel for how well the mount tracks unguided. The scope is my 160 with Quad TCC running at 1.16 arc sec per pixel. Last night was 2/5 seeing, heavy smoke from the West coast fires, and with clouds constantly running in and out. Makings for very poor imaging but excellent for unguided imaging tests.

The target was the Bubble Nebula and M52. I took quick pointing data of 5 stars each on opposing Dec lines instead of taking data along the object's path. This way the modeling program could better calculate orthogonal errors, polar alignment error, scope flexure, as well as the drift error due to atmospheric refraction. The result was surprisingly good. I was able to take 1 hour exposures with the object 4 hours before the meridian, where the tracking rates were quite far from sidereal. The cropped image below shows the result of a single 1 hour exposure:

Rolando




Re: APPM Questions

Shane Ramotowski
 

Thanks for the replay, Ray!

That's what I had expected.  I should have that covered since slaving with DeviceHub and SGP both seem to work and both use the same ASCOM methods.  Based on one of your previous ports, I did update my Slewing properly to handle the "stopped, but not quite done slewing" case.  I'm using an IMU that gets a little confused during movement and needs some settle (and thus, some additional motor movement) time.

Thanks again - Shane

On 10/6/2020 7:47 AM, Ray Gralak wrote:
Hi Shane,

How does APPM send the telescope's destination coordinates to the Dome
driver? Does it do that though ASCOM?
Yes, through ASCOM, but as I alluded to, the API is lacking. It does not provide the dome with enough information to calculate position.

In Active mode, APPM first checks if the driver can accept SendToAzimuth and/or SendToAltitude. Assuming it can APPM will convert the telescope's destination RA/Dec to Azimuth/Altitude and issue the dome driver's SlewToAzimuth() and SlewToAltitude() methods.

In Passive mode, APPM does not issue any moves directly to the dome driver. However, APPM monitors the "Slewing" property to determine when the dome has completed movement. APPM also does this in it's Active mode as well.

The problem with the ASCOM Dome interface is that it doesn't provide enough information to the dome driver. What the dome driver needs are:

1) The telescope's destination RA/Dec.
2) The mount's destination pier side.
3) In case of a multiple scope setup, which telescope (or telescopes) to center the dome opening.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Tuesday, October 6, 2020 5:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Hi Ray,

I'm currently working on motorizing my dome and am in the middle of
testing my newly written ASCOM driver and want to make sure that I can
support APPM.

How does APPM send the telescope's destination coordinates to the Dome
driver? Does it do that though ASCOM?

This is my first ASCOM driver, so I'm likely missing something or
misunderstanding something, but I don't see any ASCOM methods that would
work for sending telescope coordinates. Is it done though a custom
command in Action(), CommandBlind(), CommandBool(), or CommandString()?
I know about the CanSlave property, but as I understand it, that is for
a hardware (external to DOME driver) solution.

Thanks - Shane

On 10/5/2020 8:56 PM, Ray Gralak wrote:
Tony,

APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO
the Dome driver should be intelligent enough to figure out where the telescope is heading and move the dome
there. I would say it is up to the Dome driver developer to make this work. I would say you should talk to the
NexDome manufacturer to see what suggestions they have.
Also, I have been on and off working on a generic cross-platform dome driver. At the rate it's been going, it may
be months away from when I can complete it, but the intent is to fix some of the bad decisions (in hindsight) made
by ASCOM in the API design. (Then I would have to convince application developers to implement what is
essentially a superset of ASCOM.)
-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Tony Benjamin
Sent: Monday, October 5, 2020 7:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Ray,

Is my understanding on this whole process more or less correct?:



* as soon as I hit "Start" for the APPM run that first RA/Dec (Zenith) is sent to SGP (assuming I'm using SGP
for dome movement);
* SGP does the math required to figure out what Azimuth to send the dome to (should take like a Nano
second - it is a computer after all); and
* that Azimuth position is then sent to the Nexdome driver which then actually has the dome move?

Is that the way things should work? If so, then I would be guessing that the Nexdome driver may be the real
issue
in all this?




--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net








--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Roland Christen
 

If the second object was almost but not quite at the meridian, the mount would have acquired it with scope on the west side, then continued tracking until the scope was under the mount. That's assuming no further flip command was sent. It would explain the position of the scopes in the morning.

Rolando



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:54 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Roland Christen
 

Howard will check your log. It will show all the commands that were sent.

Rolando



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:54 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Joel Short
 

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?
The ASCOM log was linked to in the original post, but here it is again:  ASCOM LOG.  
Actually I use Park 5.

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.
Interesting.  I did have another target that was supposed to begin at 02:00, but I thought the imaging sequence ended around 00:35 with an abort.  Perhaps that flip tried to happen again at 02:00.
joel


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Roland Christen
 

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened.

Roland



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 3:21 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver, or the driver did not receive it. You should check the driver log at the time you think the flip command was sent and see if it was received.
The pier flip definitely happened.  Images before and after are flipped.  I suck at reading logs.  According to the SGP log the meridian flip was called for at 22:08:03  (about 1min after the target crossed).  I tried looking at the ASCOM  driver log at that time but I don't know what I'm looking for and didn't see anything obvious one way or the other.

The CP4 has the ability to have limits set without using APCC.
Good to know.  I'll have to figure out how to do that.  With the understand that I generally do not track past the meridian but do a flip within 30min past, do you have a recommendation for what values to set for limits?

Thanks again Roland, I always appreciate knowing that the owner is active on this forum and willing to share your wealth of knowledge.
joel


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Howard Hedlund
 

Hi Joel,

Please send me your ASCOM log file from last night.  I'm going to make an educated guess here:  Do you use Park 2 as your park position?


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Joel Short
 

It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver, or the driver did not receive it. You should check the driver log at the time you think the flip command was sent and see if it was received.
The pier flip definitely happened.  Images before and after are flipped.  I suck at reading logs.  According to the SGP log the meridian flip was called for at 22:08:03  (about 1min after the target crossed).  I tried looking at the ASCOM  driver log at that time but I don't know what I'm looking for and didn't see anything obvious one way or the other.

The CP4 has the ability to have limits set without using APCC.
Good to know.  I'll have to figure out how to do that.  With the understand that I generally do not track past the meridian but do a flip within 30min past, do you have a recommendation for what values to set for limits?

Thanks again Roland, I always appreciate knowing that the owner is active on this forum and willing to share your wealth of knowledge.
joel


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Roland Christen
 


But I'm having trouble conceptualizing how the mount and telescopes got into the position they did.  My target (Sh2-132) had crossed the meridian at 10:10pm and a pier flip occurred successfully. Everything was fine until 11:10pm when the guide star was lost. So if the mount had simply kept on tracking the pier crash would have occurred on the other side of the pier. 
It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver, or the driver did not receive it. You should check the driver log at the time you think the flip command was sent and see if it was received.

The CP4 has the ability to have limits set without using APCC.

Rolando

-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 2:21 pm
Subject: Re: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

Thanks Roland.  I have already brought the mount back with a CCW rotation, and restarted the mount just to make sure the motors and everything still worked properly (which it does).  But I'm having trouble conceptualizing how the mount and telescopes got into the position they did.  My target (Sh2-132) had crossed the meridian at 10:10pm and a pier flip occurred successfully. Everything was fine until 11:10pm when the guide star was lost. So if the mount had simply kept on tracking the pier crash would have occurred on the other side of the pier.  

I do not use APCC and it was my understanding that the ASCOM driver does not have limits available.  A year or two ago I had a pier crash and at that time I argued that limits are a basic necessity and should be included with the ASCOM driver itself.  At that time I started using Mount Watcher to prevent the mount from tracking too far past the meridian and I had tested it to make sure it worked, but for some reason it did not prevent this event.  

I don't believe that this would have happened if the guide star had not been lost, which started a cascade of events that led to this.  However I though I had protections in place to prevent it.  


Satellite Tracking

Dean Jacobsen
 

Is anyone using their mount for satellite tracking?  I am starting to go through the Horizons manual.  I am interested in amateur radio satellite tracking in particular.
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/ 
Amateur Radio Call Sign - W6DBJ


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Joel Short
 

Thanks Roland.  I have already brought the mount back with a CCW rotation, and restarted the mount just to make sure the motors and everything still worked properly (which it does).  But I'm having trouble conceptualizing how the mount and telescopes got into the position they did.  My target (Sh2-132) had crossed the meridian at 10:10pm and a pier flip occurred successfully. Everything was fine until 11:10pm when the guide star was lost. So if the mount had simply kept on tracking the pier crash would have occurred on the other side of the pier.  

I do not use APCC and it was my understanding that the ASCOM driver does not have limits available.  A year or two ago I had a pier crash and at that time I argued that limits are a basic necessity and should be included with the ASCOM driver itself.  At that time I started using Mount Watcher to prevent the mount from tracking too far past the meridian and I had tested it to make sure it worked, but for some reason it did not prevent this event.  

I don't believe that this would have happened if the guide star had not been lost, which started a cascade of events that led to this.  However I though I had protections in place to prevent it.  


Re: Pier Crash - need help diagnosing #ASCOM_V2_Driver

Roland Christen
 

It appears that the scope tracked past the meridian and continued until it was past the west side upside down. Apparently you do not have the limits turned on, so there is nothing that would stop the mount from continuing on its way.

Since the scope is now underneath the mount, I strongly suggest that you return the RA axis by either slewing or manually (clutches loose) bring the RA axis back, in counterclockwise rotation, to counterweight down position. Place the scope in Park3 and re-start the mount from Park3.

If you continue to rotate the RA axis clockwise, you will most likely twist the internal motor-encoder cables, which will eventually damage them if you allow the mount to rotate clockwise past the lowest point again and again.

I strongly urge you to NOT turn off the internal limits so that the mount cannot continue past the meridian indefinitely, especially if you are not there to catch the problem.

Roland Christen
Astro-Physics Inc.



-----Original Message-----
From: Joel Short <buckeyestargazer@...>
To: main@ap-gto.groups.io
Sent: Tue, Oct 6, 2020 1:11 pm
Subject: [ap-gto] Pier Crash - need help diagnosing #ASCOM_V2_Driver

I have an AP1100GTO CP4 and use the ASCOM driver for mount control, with SGP and PHD2.  Last night I had a pier crash and it is really puzzling as to what happened and I could use some help figuring it out.  The guide star was lost around 11:10pm and for some reason SGP recovery didn’t work properly. The really strange thing is that the scope was on the EAST side of the pier pointing down at the ground, but pointing on the west side of the pier. If the scope was tracking properly it would have just continued moving west, so something strange happened to to cause the scope to crash into the EAST side of the pier. Another strange thing is that the AP1100 ASCOM driver reported that the scope was parked this morning.
 
I also have Mount Watcher activated to shut down the mount if it gets too far past the meridian or too far CW up. That failed as well. I really have no clue what caused this.  Here is a link to the ASCOM_V2_Driver log.  Any ideas as to what happened would be appreciated.  
joel


Pier Crash - need help diagnosing #ASCOM_V2_Driver

Joel Short
 

I have an AP1100GTO CP4 and use the ASCOM driver for mount control, with SGP and PHD2.  Last night I had a pier crash and it is really puzzling as to what happened and I could use some help figuring it out.  The guide star was lost around 11:10pm and for some reason SGP recovery didn’t work properly. The really strange thing is that the scope was on the EAST side of the pier pointing down at the ground, but pointing on the west side of the pier. If the scope was tracking properly it would have just continued moving west, so something strange happened to to cause the scope to crash into the EAST side of the pier. Another strange thing is that the AP1100 ASCOM driver reported that the scope was parked this morning.
 
I also have Mount Watcher activated to shut down the mount if it gets too far past the meridian or too far CW up. That failed as well. I really have no clue what caused this.  Here is a link to the ASCOM_V2_Driver log.  Any ideas as to what happened would be appreciated.  
joel


Re: APPM Questions

Ray Gralak
 

Hi Shane,

How does APPM send the telescope's destination coordinates to the Dome
driver? Does it do that though ASCOM?
Yes, through ASCOM, but as I alluded to, the API is lacking. It does not provide the dome with enough information to calculate position.

In Active mode, APPM first checks if the driver can accept SendToAzimuth and/or SendToAltitude. Assuming it can APPM will convert the telescope's destination RA/Dec to Azimuth/Altitude and issue the dome driver's SlewToAzimuth() and SlewToAltitude() methods.

In Passive mode, APPM does not issue any moves directly to the dome driver. However, APPM monitors the "Slewing" property to determine when the dome has completed movement. APPM also does this in it's Active mode as well.

The problem with the ASCOM Dome interface is that it doesn't provide enough information to the dome driver. What the dome driver needs are:

1) The telescope's destination RA/Dec.
2) The mount's destination pier side.
3) In case of a multiple scope setup, which telescope (or telescopes) to center the dome opening.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Shane Ramotowski
Sent: Tuesday, October 6, 2020 5:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Hi Ray,

I'm currently working on motorizing my dome and am in the middle of
testing my newly written ASCOM driver and want to make sure that I can
support APPM.

How does APPM send the telescope's destination coordinates to the Dome
driver? Does it do that though ASCOM?

This is my first ASCOM driver, so I'm likely missing something or
misunderstanding something, but I don't see any ASCOM methods that would
work for sending telescope coordinates. Is it done though a custom
command in Action(), CommandBlind(), CommandBool(), or CommandString()?
I know about the CanSlave property, but as I understand it, that is for
a hardware (external to DOME driver) solution.

Thanks - Shane

On 10/5/2020 8:56 PM, Ray Gralak wrote:
Tony,

APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO
the Dome driver should be intelligent enough to figure out where the telescope is heading and move the dome
there. I would say it is up to the Dome driver developer to make this work. I would say you should talk to the
NexDome manufacturer to see what suggestions they have.

Also, I have been on and off working on a generic cross-platform dome driver. At the rate it's been going, it may
be months away from when I can complete it, but the intent is to fix some of the bad decisions (in hindsight) made
by ASCOM in the API design. (Then I would have to convince application developers to implement what is
essentially a superset of ASCOM.)

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Tony Benjamin
Sent: Monday, October 5, 2020 7:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Ray,

Is my understanding on this whole process more or less correct?:



* as soon as I hit "Start" for the APPM run that first RA/Dec (Zenith) is sent to SGP (assuming I'm using SGP
for dome movement);
* SGP does the math required to figure out what Azimuth to send the dome to (should take like a Nano
second - it is a computer after all); and
* that Azimuth position is then sent to the Nexdome driver which then actually has the dome move?

Is that the way things should work? If so, then I would be guessing that the Nexdome driver may be the real
issue
in all this?





--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net




Re: APPM Questions

Shane Ramotowski
 

Hi Ray,

I'm currently working on motorizing my dome and am in the middle of testing my newly written ASCOM driver and want to make sure that I can support APPM.

How does APPM send the telescope's destination coordinates to the Dome driver?  Does it do that though ASCOM?

This is my first ASCOM driver, so I'm likely missing something or misunderstanding something, but I don't see any ASCOM methods that would work for sending telescope coordinates.  Is it done though a custom command in Action(), CommandBlind(), CommandBool(), or CommandString()?  I know about the CanSlave property, but as I understand it, that is for a hardware (external to DOME driver) solution.

Thanks - Shane

On 10/5/2020 8:56 PM, Ray Gralak wrote:
Tony,

APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO the Dome driver should be intelligent enough to figure out where the telescope is heading and move the dome there. I would say it is up to the Dome driver developer to make this work. I would say you should talk to the NexDome manufacturer to see what suggestions they have.

Also, I have been on and off working on a generic cross-platform dome driver. At the rate it's been going, it may be months away from when I can complete it, but the intent is to fix some of the bad decisions (in hindsight) made by ASCOM in the API design. (Then I would have to convince application developers to implement what is essentially a superset of ASCOM.)

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Tony Benjamin
Sent: Monday, October 5, 2020 7:42 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Questions

Ray,

Is my understanding on this whole process more or less correct?:



* as soon as I hit "Start" for the APPM run that first RA/Dec (Zenith) is sent to SGP (assuming I'm using SGP
for dome movement);
* SGP does the math required to figure out what Azimuth to send the dome to (should take like a Nano
second - it is a computer after all); and
* that Azimuth position is then sent to the Nexdome driver which then actually has the dome move?

Is that the way things should work? If so, then I would be guessing that the Nexdome driver may be the real issue
in all this?




--
Shane Ramotowski
kor@cotse.net
https://www.kor-astro.net

8601 - 8620 of 82249