1. main@ap-gto.groups.io
  2. Messages
   Date   
Re: Parking Issue

Ray Gralak
 

The likely case is one of those ASCOM applications is sending something to cause the mount to not complete the park operation while parking.

Are you both using Asynchronous parks in the AP V2 driver? (you should be).

If the Park operation does not complete within a set amount of time (or check for tracking stopped), you could issue commands to unpark/start tracking/park the mount again.

This should handle the case when some application sends something to the mount.

Craig, are you also using the network to connect to your mount?

-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 Craig Anderson
Sent: Sunday, January 10, 2021 10:17 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

I’ve had this problem from time to time at my observatory. When it happens for me, the scope is left not tracking,
pointing up, and ACP Expert reports waiting for the mount to park. If I send the mount to Park manually in that
situation, the error clears and the roof closes. I have not noticed the “Park” button in APCC greyed out in my
scenario, and APCC is where I click to park the mount. It seems to be a problem for me more frequently when
the CloseSpecialRoof script executes, so I make sure to avoid opening or imaging when there’s any chance of
rain at all. My configuration includes AP1600, APCC Pro, AP V2, ACP Expert, MaxIm DL, SkyRoof, AAG Cloud
Sensor, and an optical @Park monitor.

-Craig



On Jan 10, 2021, at 11:42 AM, Steve Reilly <sreilly24590@centurylink.net> wrote:

Ray,

Have another look at the screen shot and APCC. Does APCC not have Unpark as
being Active choice and Park greyed out (inactive)?

Mike I purposely left it as is for now in case there was a need for remote
login to investigate. In previous occurrences I could indeed park the mount
via the ASCOM Park command but that doesn't help understand the cause of
this situation and offer any solutions so I left it as is after closing the
roof for safety reasons. I had hoped there might be some procedure to try
before resetting things.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,



This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the ASCOM


driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it happens,
once long enough to have let rain fall on the equipment, it causes
real problems. The mount must be parked before my roof can close so
using a direct close on moisture reading can't work. I had hoped to
find a solution but I don't see this now. The screen capture shows the


roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.


ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to backup
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to


show the mount parked?





Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in AstroMC
which it did successfully, and yet ACP still shows the mount as "Parking"


as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.


So the question is, where is the log jam and who is responsible for the


stall? How can I prevent this?





I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it up


correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"


phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and power
everything off and start from scratch with a startup script run but
that only puts me back at square 1 and doesn't identify the problem. Is it


a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?





Wide open to ideas/suggestions.



-Steve
Re: Parking Issue

Ray Gralak
 

Steve,

I do indeed stand corrected. But then why is the option to unpark active? That's confusing.
It could be that what I mentioned in my previous post: one of the ASCOM applications might have sent a command around the time the
park operation was about to complete, putting APCC in an inconsistent state.

Which version of APCC are you using?

-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 Steve Reilly
Sent: Sunday, January 10, 2021 9:39 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Thanks Ray,



I do indeed stand corrected. But then why is the option to unpark active? That's confusing.



-Steve







From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 12:15 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue



Steve,



Have another look at the screen shot and APCC. Does APCC not have Unpark as
being Active choice and Park greyed out (inactive)?


That's not the park status. See this portion of your screenshot:







-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 Steve Reilly
Sent: Sunday, January 10, 2021 8:43 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
Ray,
Have another look at the screen shot and APCC. Does APCC not have Unpark as
being Active choice and Park greyed out (inactive)?
Mike I purposely left it as is for now in case there was a need for remote
login to investigate. In previous occurrences I could indeed park the mount
via the ASCOM Park command but that doesn't help understand the cause of
this situation and offer any solutions so I left it as is after closing the
roof for safety reasons. I had hoped there might be some procedure to try
before resetting things.
-Steve
-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue
Hi Steve,
This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the ASCOM
driver says it's parking, and APCC says it is parked.
Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.
There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.
-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue
This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it happens,
once long enough to have let rain fall on the equipment, it causes
real problems. The mount must be parked before my roof can close so
using a direct close on moisture reading can't work. I had hoped to
find a solution but I don't see this now. The screen capture shows the
roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.
ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to backup
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to
show the mount parked?
Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in AstroMC
which it did successfully, and yet ACP still shows the mount as "Parking"
as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for the
stall? How can I prevent this?
I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it up
correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and power
everything off and start from scratch with a startup script run but
that only puts me back at square 1 and doesn't identify the problem. Is it
a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?
Wide open to ideas/suggestions.
-Steve
Re: APCC Pro version update

Dominique
 

Hi Ray,
I am for this session with version 1.8.8.13 of APCC and I see the follow-up fixes are not displayed? Does this correct for the same?
Re: Parking Issue

Steve Reilly
 

This should do it
https://www.dropbox.com/s/v8y72py2yi58xoz/ApccZip-Steven_Reilly-2021-01-10-1
20444.zip?dl=0

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 12:37 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

I do have the zipped log file if that is of any help. It's the usual
files and just the log file for that period and 12.4MBs. I can upload
to Dropbox if you want it.
Go ahead and post the link, but I may not get time to review it until later
today.

For APCC to get into this state, something (an ASCOM client application?)
might have stopped mount tracking in the middle or near the end of the park
operation.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 9:07 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Ray,

I do have the zipped log file if that is of any help. It's the usual
files and just the log file for that period and 12.4MBs. I can upload
to Dropbox if you want it.

-Steve


-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray
Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM
driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but
because the mount is not parked, the driver cannot indicate that the
mount has completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it
happens, once long enough to have let rain fall on the equipment, it
causes real problems. The mount must be parked before my roof can
close so using a direct close on moisture reading can't work. I had
hoped to find a solution but I don't see this now. The screen
capture shows the
roof closed only because I closed it using the close command in
AstroMC and the mount was already in the Park 4 position and had been
since 0623. The last image had downloaded at 0531 and the shutdown
script was executed at
0623 if I remember correctly. It was a brief notification from Windows
10 but those were cleared after reading. Not sure if any record is
made of those.
ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to
backup this event I'm unaware. Maybe APCC can pinpoint the time as
it seems to
show the mount parked?



Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in
AstroMC which it did successfully, and yet ACP still shows the mount as
"Parking"
as does the ASCOM driver but not APCC. The difference is that ASCOM
and APCC show the mount at the parked position whereas ACP shows what
I assume is the position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for
the
stall? How can I prevent this?



I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it
up
correctly and I have cell signal. It doesn't correct anything. The
system is still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and
power everything off and start from scratch with a startup script
run but that only puts me back at square 1 and doesn't identify the
problem. Is it
a communication issue where a request is sent and waits forever and if
so why can't there be a reasonable time restriction before another
request is sent or other action is taken?



Wide open to ideas/suggestions.



-Steve
Re: Parking Issue

Craig Anderson
 

I’ve had this problem from time to time at my observatory. When it happens for me, the scope is left not tracking, pointing up, and ACP Expert reports waiting for the mount to park. If I send  the mount to Park manually in that situation, the error clears and the roof closes. I have not noticed the “Park” button in APCC greyed out in my scenario, and APCC is  where I click to park the mount. It seems to be a problem for me more frequently when the CloseSpecialRoof script executes, so I make sure to avoid opening or imaging when there’s any chance of rain at all. My configuration includes AP1600, APCC Pro, AP V2, ACP Expert, MaxIm DL, SkyRoof, AAG Cloud Sensor, and an optical @Park monitor.

-Craig

On Jan 10, 2021, at 11:42 AM, Steve Reilly <sreilly24590@...> wrote:

Ray,

Have another look at the screen shot and APCC. Does APCC not have Unpark as
being Active choice and Park greyed out (inactive)?

Mike I purposely left it as is for now in case there was a need for remote
login to investigate. In previous occurrences I could indeed park the mount
via the ASCOM Park command but that doesn't help understand the cause of
this situation and offer any solutions so I left it as is after closing the
roof for safety reasons. I had hoped there might be some procedure to try
before resetting things.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,

This is a recurring problem that I've often blamed on ACP but am 
rethinking this as the screen shot shows ACP attempting to park, the ASCOM
driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am 
rethinking this as the screen shot shows ACP attempting to park, the 
ASCOM driver says it's parking, and APCC says it is parked. I'm 
guessing that ACP gets the information from the ASCOM driver so yes, 
it actually isn't parked. This is a rare problem but when it happens, 
once long enough to have let rain fall on the equipment, it causes 
real problems. The mount must be parked before my roof can close so 
using a direct close on moisture reading can't work. I had hoped to 
find a solution but I don't see this now. The screen capture shows the
roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.
ACP doesn't have a shutdown record as it seems that is made after it 
completes which it didn't. If there is a log somewhere else to backup 
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to
show the mount parked?



Anyway the issue remains, the roof was wide opened, scope was in the 
Park 4 position, my inline Microswitches wired in series were both 
closed (continuity signal to the relay) proving a safe position for 
the roof to close, the roof was manually directed to close in AstroMC 
which it did successfully, and yet ACP still shows the mount as "Parking"
as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for the
stall? How can I prevent this?



I hopefully will have Good Night System fully configured today but 
that only notifies me via smart phone of these failures if  I set it up
correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other 
person has some idea to tracing the problem. I can stop this and power 
everything off and start from scratch with a startup script run but 
that only puts me back at square 1 and doesn't identify the problem. Is it
a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?



Wide open to ideas/suggestions.



-Steve
Re: Parking Issue

Steve Reilly
 

Thanks Ray,

 

I do indeed stand corrected. But then why is the option to unpark active? That’s confusing.

 

-Steve

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 12:15 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

 

Steve,

 

> Have another look at the screen shot and APCC. Does APCC not have Unpark as

> being Active choice and Park greyed out (inactive)?

 

That's not the park status. See this portion of your screenshot:

 

 

-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 Steve Reilly

> Sent: Sunday, January 10, 2021 8:43 AM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] Parking Issue

>

> Ray,

>

> Have another look at the screen shot and APCC. Does APCC not have Unpark as

> being Active choice and Park greyed out (inactive)?

>

> Mike I purposely left it as is for now in case there was a need for remote

> login to investigate. In previous occurrences I could indeed park the mount

> via the ASCOM Park command but that doesn't help understand the cause of

> this situation and offer any solutions so I left it as is after closing the

> roof for safety reasons. I had hoped there might be some procedure to try

> before resetting things.

>

> -Steve

>

> -----Original Message-----

> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak

> Sent: Sunday, January 10, 2021 10:51 AM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] Parking Issue

>

> Hi Steve,

>

> > This is a recurring problem that I've often blamed on ACP but am

> > rethinking this as the screen shot shows ACP attempting to park, the ASCOM

> driver says it's parking, and APCC says it is parked.

>

> Your screenshot shows the mount is unparked, with tracking stopped,

> according to APCC.

>

> There's no way to know for sure what happened from a screenshot, but because

> the mount is not parked, the driver cannot indicate that the mount has

> completed parking.

>

> -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 Steve Reilly

> > Sent: Sunday, January 10, 2021 6:28 AM

> > To: main@ap-gto.groups.io

> > Subject: [ap-gto] Parking Issue

> >

> > This is a recurring problem that I've often blamed on ACP but am

> > rethinking this as the screen shot shows ACP attempting to park, the

> > ASCOM driver says it's parking, and APCC says it is parked. I'm

> > guessing that ACP gets the information from the ASCOM driver so yes,

> > it actually isn't parked. This is a rare problem but when it happens,

> > once long enough to have let rain fall on the equipment, it causes

> > real problems. The mount must be parked before my roof can close so

> > using a direct close on moisture reading can't work. I had hoped to

> > find a solution but I don't see this now. The screen capture shows the

> roof closed only because I closed it using the close command in AstroMC and

> the mount was already in the Park 4 position and had been since 0623. The

> last image had downloaded at 0531 and the shutdown script was executed at

> 0623 if I remember correctly. It was a brief notification from Windows 10

> but those were cleared after reading. Not sure if any record is made of

> those.

> > ACP doesn't have a shutdown record as it seems that is made after it

> > completes which it didn't. If there is a log somewhere else to backup

> > this event I'm unaware. Maybe APCC can pinpoint the time as it seems to

> show the mount parked?

> >

> >

> >

> > Anyway the issue remains, the roof was wide opened, scope was in the

> > Park 4 position, my inline Microswitches wired in series were both

> > closed (continuity signal to the relay) proving a safe position for

> > the roof to close, the roof was manually directed to close in AstroMC

> > which it did successfully, and yet ACP still shows the mount as "Parking"

> as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC

> show the mount at the parked position whereas ACP shows what I assume is the

> position it was prior to being commanded to park.

> > So the question is, where is the log jam and who is responsible for the

> stall? How can I prevent this?

> >

> >

> >

> > I hopefully will have Good Night System fully configured today but

> > that only notifies me via smart phone of these failures if  I set it up

> correctly and I have cell signal. It doesn't correct anything. The system is

> still in this "Parking"

> > phase and I'll leave it like that hoping that Bob Denny or other

> > person has some idea to tracing the problem. I can stop this and power

> > everything off and start from scratch with a startup script run but

> > that only puts me back at square 1 and doesn't identify the problem. Is it

> a communication issue where a request is sent and waits forever and if so

> why can't there be a reasonable time restriction before another request is

> sent or other action is taken?

> >

> >

> >

> > Wide open to ideas/suggestions.

> >

> >

> >

> > -Steve

> >

> >

>

>

>

>

>

>

>

>

>

 
Re: Parking Issue

Ray Gralak
 

I do have the zipped log file if that is of any help. It's the usual files
and just the log file for that period and 12.4MBs. I can upload to Dropbox
if you want it.
Go ahead and post the link, but I may not get time to review it until later today.

For APCC to get into this state, something (an ASCOM client application?) might have stopped mount tracking in the middle or near
the end of the park operation.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 9:07 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Ray,

I do have the zipped log file if that is of any help. It's the usual files
and just the log file for that period and 12.4MBs. I can upload to Dropbox
if you want it.

-Steve


-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the ASCOM
driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it happens,
once long enough to have let rain fall on the equipment, it causes
real problems. The mount must be parked before my roof can close so
using a direct close on moisture reading can't work. I had hoped to
find a solution but I don't see this now. The screen capture shows the
roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.
ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to backup
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to
show the mount parked?



Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in AstroMC
which it did successfully, and yet ACP still shows the mount as "Parking"
as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for the
stall? How can I prevent this?



I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it up
correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and power
everything off and start from scratch with a startup script run but
that only puts me back at square 1 and doesn't identify the problem. Is it
a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?



Wide open to ideas/suggestions.



-Steve
Re: Parking Issue

Ray Gralak
 

Steve,

 

> Have another look at the screen shot and APCC. Does APCC not have Unpark as

> being Active choice and Park greyed out (inactive)?

 

That's not the park status. See this portion of your screenshot:

 

 

-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 Steve Reilly

> Sent: Sunday, January 10, 2021 8:43 AM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] Parking Issue

>

> Ray,

>

> Have another look at the screen shot and APCC. Does APCC not have Unpark as

> being Active choice and Park greyed out (inactive)?

>

> Mike I purposely left it as is for now in case there was a need for remote

> login to investigate. In previous occurrences I could indeed park the mount

> via the ASCOM Park command but that doesn't help understand the cause of

> this situation and offer any solutions so I left it as is after closing the

> roof for safety reasons. I had hoped there might be some procedure to try

> before resetting things.

>

> -Steve

>

> -----Original Message-----

> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak

> Sent: Sunday, January 10, 2021 10:51 AM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] Parking Issue

>

> Hi Steve,

>

> > This is a recurring problem that I've often blamed on ACP but am

> > rethinking this as the screen shot shows ACP attempting to park, the ASCOM

> driver says it's parking, and APCC says it is parked.

>

> Your screenshot shows the mount is unparked, with tracking stopped,

> according to APCC.

>

> There's no way to know for sure what happened from a screenshot, but because

> the mount is not parked, the driver cannot indicate that the mount has

> completed parking.

>

> -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 Steve Reilly

> > Sent: Sunday, January 10, 2021 6:28 AM

> > To: main@ap-gto.groups.io

> > Subject: [ap-gto] Parking Issue

> >

> > This is a recurring problem that I've often blamed on ACP but am

> > rethinking this as the screen shot shows ACP attempting to park, the

> > ASCOM driver says it's parking, and APCC says it is parked. I'm

> > guessing that ACP gets the information from the ASCOM driver so yes,

> > it actually isn't parked. This is a rare problem but when it happens,

> > once long enough to have let rain fall on the equipment, it causes

> > real problems. The mount must be parked before my roof can close so

> > using a direct close on moisture reading can't work. I had hoped to

> > find a solution but I don't see this now. The screen capture shows the

> roof closed only because I closed it using the close command in AstroMC and

> the mount was already in the Park 4 position and had been since 0623. The

> last image had downloaded at 0531 and the shutdown script was executed at

> 0623 if I remember correctly. It was a brief notification from Windows 10

> but those were cleared after reading. Not sure if any record is made of

> those.

> > ACP doesn't have a shutdown record as it seems that is made after it

> > completes which it didn't. If there is a log somewhere else to backup

> > this event I'm unaware. Maybe APCC can pinpoint the time as it seems to

> show the mount parked?

> >

> >

> >

> > Anyway the issue remains, the roof was wide opened, scope was in the

> > Park 4 position, my inline Microswitches wired in series were both

> > closed (continuity signal to the relay) proving a safe position for

> > the roof to close, the roof was manually directed to close in AstroMC

> > which it did successfully, and yet ACP still shows the mount as "Parking"

> as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC

> show the mount at the parked position whereas ACP shows what I assume is the

> position it was prior to being commanded to park.

> > So the question is, where is the log jam and who is responsible for the

> stall? How can I prevent this?

> >

> >

> >

> > I hopefully will have Good Night System fully configured today but

> > that only notifies me via smart phone of these failures if  I set it up

> correctly and I have cell signal. It doesn't correct anything. The system is

> still in this "Parking"

> > phase and I'll leave it like that hoping that Bob Denny or other

> > person has some idea to tracing the problem. I can stop this and power

> > everything off and start from scratch with a startup script run but

> > that only puts me back at square 1 and doesn't identify the problem. Is it

> a communication issue where a request is sent and waits forever and if so

> why can't there be a reasonable time restriction before another request is

> sent or other action is taken?

> >

> >

> >

> > Wide open to ideas/suggestions.

> >

> >

> >

> > -Steve

> >

> >

>

>

>

>

>

>

>

>

>

 
Re: USB and cold weather

Don Anderson
 

Dominique
I suspect that unpowered usb3 hub at the computer is your problem. All hubs in the chain need to be powered.

Don Anderson


On Saturday, January 9, 2021, 05:18:42 p.m. MST, Dominique <d.h.durand@...> wrote:


I saw a problem like this 2 days ago in 28 ° F. My installation is complex with the Pegasus powerbox V2 installed in front of the plate, 1 USB3 Hub at the output of the mount wiring, 1 active 5m extension cable and 1 other USB3 Hub (not powered) connected to the laptop (see the attached diagram). As it generally works well and ceal makes my life easier, I have no reason to change.
Can the di-electric silicone grease for the connections make things better? In the meantime I have covered all the USB3 connections and I will see tonight (it will still be cold) if it gets better. It would be a shame to do without USB3 especially when you have to do the flats with the QHY294M-pro used in 47M.

Dominique

Re: Parking Issue

Steve Reilly
 

Ray,

I do have the zipped log file if that is of any help. It's the usual files
and just the log file for that period and 12.4MBs. I can upload to Dropbox
if you want it.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the ASCOM
driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it happens,
once long enough to have let rain fall on the equipment, it causes
real problems. The mount must be parked before my roof can close so
using a direct close on moisture reading can't work. I had hoped to
find a solution but I don't see this now. The screen capture shows the
roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.
ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to backup
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to
show the mount parked?



Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in AstroMC
which it did successfully, and yet ACP still shows the mount as "Parking"
as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for the
stall? How can I prevent this?



I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it up
correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and power
everything off and start from scratch with a startup script run but
that only puts me back at square 1 and doesn't identify the problem. Is it
a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?



Wide open to ideas/suggestions.



-Steve
Re: USB and cold weather

Don Anderson
 

Michael
Try running your set up with an external USB cable using your existing Startech hub. If your rig runs reliably at the low temperatures, you can pretty much zero in on cabling within the mount being the problem. If that is the case, then you can look into installing better shielded USB cables to see if that works.

Don Anderson


On Saturday, January 9, 2021, 12:55:40 p.m. MST, Micheal Fields Jr via groups.io <mpfjr@...> wrote:


My camera unfortunately doesn't have a built in usb hub so I can't go from camera to hub.  I am going to further experiment with this later today but at this point the only solution seems to be to not have through the mount cabling which was one of the factors that steered me towards this mount over its competitors.  

I hope I can get this working reliably.   

Re: USB and cold weather

Don Anderson
 

That hub should work fine at 47F but those specs are just a general average. Your particular hub may not work reliably at those temps. The problem could also be running power cables along side data cables within the mount. Most USB cables are not well shielded. That could explain why you are getting better results with an external USB cable. 

Don Anderson


On Saturday, January 9, 2021, 12:51:21 p.m. MST, Micheal Fields Jr via groups.io <mpfjr@...> wrote:


This is the hub I am using. https://www.startech.com/en-us/cards-adapters/st4300usbm   It claims it can go down to 32F as well.  I'll check out the pegasus astro product.  I still find it weird though that if I bypass the mount pass through it works fine.

On Sat, Jan 9, 2021 at 09:55 AM, Don Anderson wrote:
Micheal
Problem could be related to the cables or the hub. Most consumer/commercial electronics is rated to around 32F(0Celcius). That is not to say that the device will work reliably down to that temp. Failure at 47F is a bit unusual though and suggests something is defective. USB3 is a lot more touchy than USB2. You could have a bad USB3 cable in the mount as well as a failing USB hub. If you are looking for a new robust hub that is good for low (-40F) temp, I would look at the products from Pegasus Astro. I bought one of their USB control hubs to replace my consumer hub that quit working at about 35F. Works great.
Hope this helps
 
Don Anderson
 
 
On Saturday, January 9, 2021, 03:22:22 a.m. MST, Micheal Fields Jr via groups.io <mpfjr@...> wrote:
 
 
I seem to have some errors when I have my stuff out in the cold.  This is california cold at 47F.  Every frame I downloaded had this weird mosaic tile puzzle look to it. Qhy says it is USB CrC errors.

Swapped cables and didn't have luck until I ran a 6 foot cable from my PC to the hub directly bypassing the Mach2 through the mount usb 3 cable.  But it wasn't 100% fixed.  Just a lot better.  Then I brought the whole thing in the house to set up and experiment and shoot video and it all started working again.  The only difference is that inside it is 70F.  I've heard of USB hubs and other electronics get angry when it is cold so I figure that must be it.  

I use the StarTech Industrial metal 12v powered 4 port hub.  I've used this hub for years without issue.  

If I bypass the mount and go direct, I don't have problems  But once I brought all this inside where it is warm, I can go through the mount with very little problems.  Maybe 2 bad frames out of 200.  This hub I have was over 100$ when I originally bought it.  Now it can be had for a steal at $80 on Amazon.  The cables were just whatever Amazon had that had good reviews.

All my cables are minimal length.    Please tell me what cables  you like and what hubs you like?

People from AP, any way for the end user to run my own cable through just in case it turns out to be a finicky cable?  I'd go ahead and upgrade to 3.1 or 3.2 Gen2 most likely.

See attached jpg showing what it looks like.   
Re: Parking Issue

Steve Reilly
 

Ray,

Have another look at the screen shot and APCC. Does APCC not have Unpark as
being Active choice and Park greyed out (inactive)?

Mike I purposely left it as is for now in case there was a need for remote
login to investigate. In previous occurrences I could indeed park the mount
via the ASCOM Park command but that doesn't help understand the cause of
this situation and offer any solutions so I left it as is after closing the
roof for safety reasons. I had hoped there might be some procedure to try
before resetting things.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, January 10, 2021 10:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Parking Issue

Hi Steve,

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the ASCOM
driver says it's parking, and APCC says it is parked.

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but because
the mount is not parked, the driver cannot indicate that the mount has
completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am
rethinking this as the screen shot shows ACP attempting to park, the
ASCOM driver says it's parking, and APCC says it is parked. I'm
guessing that ACP gets the information from the ASCOM driver so yes,
it actually isn't parked. This is a rare problem but when it happens,
once long enough to have let rain fall on the equipment, it causes
real problems. The mount must be parked before my roof can close so
using a direct close on moisture reading can't work. I had hoped to
find a solution but I don't see this now. The screen capture shows the
roof closed only because I closed it using the close command in AstroMC and
the mount was already in the Park 4 position and had been since 0623. The
last image had downloaded at 0531 and the shutdown script was executed at
0623 if I remember correctly. It was a brief notification from Windows 10
but those were cleared after reading. Not sure if any record is made of
those.
ACP doesn't have a shutdown record as it seems that is made after it
completes which it didn't. If there is a log somewhere else to backup
this event I'm unaware. Maybe APCC can pinpoint the time as it seems to
show the mount parked?



Anyway the issue remains, the roof was wide opened, scope was in the
Park 4 position, my inline Microswitches wired in series were both
closed (continuity signal to the relay) proving a safe position for
the roof to close, the roof was manually directed to close in AstroMC
which it did successfully, and yet ACP still shows the mount as "Parking"
as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC
show the mount at the parked position whereas ACP shows what I assume is the
position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for the
stall? How can I prevent this?



I hopefully will have Good Night System fully configured today but
that only notifies me via smart phone of these failures if I set it up
correctly and I have cell signal. It doesn't correct anything. The system is
still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other
person has some idea to tracing the problem. I can stop this and power
everything off and start from scratch with a startup script run but
that only puts me back at square 1 and doesn't identify the problem. Is it
a communication issue where a request is sent and waits forever and if so
why can't there be a reasonable time restriction before another request is
sent or other action is taken?



Wide open to ideas/suggestions.



-Steve
Re: Parking Issue

Mike Dodd
 

On 1/10/2021 10:51 AM, Ray Gralak wrote:
Hi Steve,

Your screenshot shows the mount is unparked, with tracking stopped,
according to APCC.

There's no way to know for sure what happened from a screenshot, but
because the mount is not parked, the driver cannot indicate that the
mount has completed parking.
Steve.... What happens if you click the Park button in the ASCOM driver when the mount is in that situation? Does the driver flash "PARKING" and does the mount move to the specified park position?

Just a thought....

--- Mike
Re: Parking Issue

Ray Gralak
 

Hi Steve,

This is a recurring problem that I've often blamed on ACP but am rethinking this as the screen shot shows ACP
attempting to park, the ASCOM driver says it's parking, and APCC says it is parked.
Your screenshot shows the mount is unparked, with tracking stopped, according to APCC.

There's no way to know for sure what happened from a screenshot, but because the mount is not parked, the driver cannot indicate
that the mount has completed parking.

-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 Steve Reilly
Sent: Sunday, January 10, 2021 6:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Parking Issue

This is a recurring problem that I've often blamed on ACP but am rethinking this as the screen shot shows ACP
attempting to park, the ASCOM driver says it's parking, and APCC says it is parked. I'm guessing that ACP gets
the information from the ASCOM driver so yes, it actually isn't parked. This is a rare problem but when it
happens, once long enough to have let rain fall on the equipment, it causes real problems. The mount must be
parked before my roof can close so using a direct close on moisture reading can't work. I had hoped to find a
solution but I don't see this now. The screen capture shows the roof closed only because I closed it using the
close command in AstroMC and the mount was already in the Park 4 position and had been since 0623. The last
image had downloaded at 0531 and the shutdown script was executed at 0623 if I remember correctly. It was a
brief notification from Windows 10 but those were cleared after reading. Not sure if any record is made of those.
ACP doesn't have a shutdown record as it seems that is made after it completes which it didn't. If there is a log
somewhere else to backup this event I'm unaware. Maybe APCC can pinpoint the time as it seems to show the
mount parked?



Anyway the issue remains, the roof was wide opened, scope was in the Park 4 position, my inline Microswitches
wired in series were both closed (continuity signal to the relay) proving a safe position for the roof to close, the
roof was manually directed to close in AstroMC which it did successfully, and yet ACP still shows the mount as
"Parking" as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC show the mount at
the parked position whereas ACP shows what I assume is the position it was prior to being commanded to park.
So the question is, where is the log jam and who is responsible for the stall? How can I prevent this?



I hopefully will have Good Night System fully configured today but that only notifies me via smart phone of these
failures if I set it up correctly and I have cell signal. It doesn't correct anything. The system is still in this "Parking"
phase and I'll leave it like that hoping that Bob Denny or other person has some idea to tracing the problem. I can
stop this and power everything off and start from scratch with a startup script run but that only puts me back at
square 1 and doesn't identify the problem. Is it a communication issue where a request is sent and waits forever
and if so why can't there be a reasonable time restriction before another request is sent or other action is taken?



Wide open to ideas/suggestions.



-Steve
Parking Issue

Steve Reilly
 

This is a recurring problem that I’ve often blamed on ACP but am rethinking this as the screen shot shows ACP attempting to park, the ASCOM driver says it’s parking, and APCC says it is parked. I’m guessing that ACP gets the information from the ASCOM driver so yes, it actually isn’t parked. This is a rare problem but when it happens, once long enough to have let rain fall on the equipment, it causes real problems. The mount must be parked before my roof can close so using a direct close on moisture reading can’t work. I had hoped to find a solution but I don’t see this now. The screen capture shows the roof closed only because I closed it using the close command in AstroMC and the mount was already in the Park 4 position and had been since 0623. The last image had downloaded at 0531 and the shutdown script was executed at 0623 if I remember correctly. It was a brief notification from Windows 10 but those were cleared after reading. Not sure if any record is made of those. ACP doesn’t have a shutdown record as it seems that is made after it completes which it didn’t. If there is a log somewhere else to backup this event I’m unaware. Maybe APCC can pinpoint the time as it seems to show the mount parked?

 

Anyway the issue remains, the roof was wide opened, scope was in the Park 4 position, my inline Microswitches wired in series were both closed (continuity signal to the relay) proving a safe position for the roof to close, the roof was manually directed to close in AstroMC which it did successfully, and yet ACP still shows the mount as “Parking” as does the ASCOM driver but not APCC. The difference is that ASCOM and APCC show the mount at the parked position whereas ACP shows what I assume is the position it was prior to being commanded to park. So the question is, where is the log jam and who is responsible for the stall? How can I prevent this?

 

I hopefully will have Good Night System fully configured today but that only notifies me via smart phone of these failures if  I set it up correctly and I have cell signal. It doesn’t correct anything. The system is still in this “Parking” phase and I’ll leave it like that hoping that Bob Denny or other person has some idea to tracing the problem. I can stop this and power everything off and start from scratch with a startup script run but that only puts me back at square 1 and doesn’t identify the problem. Is it a communication issue where a request is sent and waits forever and if so why can’t there be a reasonable time restriction before another request is sent or other action is taken?

 

Wide open to ideas/suggestions.

 

-Steve
Re: USB and cold weather

Joseph Beyer
 

Not sure this idea will help but my Nikon D800 uses a USB3 cable and I commonly had problems with connectivity, especially in the cold.  Now I use the following: from the camera I use an 18 inch USB3 cable plugged into a powered Startech USB2 hub on the OTA, then down through my Mach1 using a 6 foot USB2 cable plugged into 16 foot active USB2 cable (Tethertools).  I use either a USB2 or 3 plug on the computer.  The raw images are roughly 50 Mb and download in about 1-2 seconds.  I’ve not had a problem since adding the active cable into the line. 
Re: USB and cold weather

Joe Zeglinski
 

A bonus for using USB-2, besides 3x the distance,  is that those cables are “thinner”, by two extra wires in the sheath, than USB-3. So, the cable bundle  inside the mount is just a bit looser, especially twisting when its cold.
 
Joe
 
 

From: Micheal Fields Jr via groups.io
Sent: Saturday, January 9, 2021 6:09 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] USB and cold weather
 
I do not use video for sure.  Not with this camera.  3 seconds on USB2? 

Interestingly I have an Icron Ranger 2304 which is a USB 2.0 over Cat5e which was allowing me to run long ethernet cable out to my mount in the back yard but use my in home computer to control everything.

I would take about 30 seconds per download.    You are right, I don't love your solution but it is either that or not use the through the mount cabling.  Such a shame.

I just did some experiments.  Bottom line is if I bypass the mounts internal cable, I have zero issues at USB 3 speeds.    You are right though.  USB 2 port doing the same cables resulted in perfect no error images.

Damnit.

Re: USB and cold weather

Xentex
 

In automotive applications I've seen people slop silicone grease all over a multi-prong connector and not have any issues.  I do it myself for outside connectors, but for the most part those are only speaker terminals and low speed or low voltage power terminals (pool applications).

Thinking more about USB connectors, I'm not so sure.

The way the USB connectors work you have relatively small surfaces making contact with each other with pretty low pressure spring force.  The silicone greases are pretty viscous and very good insulators.  So my concern is they might actually weaken the signal transmission a bit because when you slide the connectors together the pins might not have enough surface pressure to completely push the grease out of the way.  I'm sure they'll still make contact, but it could be a little less contact area, which could slightly degrade a signal that's already nearing its limit.  As it the temp gets colder the silicone grease gets thicker (harder to displace) and the spring force on the connectors likely goes down.  So a silicone grease could make the situation worse, not better.
Re: USB and cold weather

Sébastien Doré
 

Hello Michael,

As Roland pointed out, it also seem to me to be a matter of signal integrity at high freq. From your video I counted 6 USB interfaces between your PC to your camera (1st hub input connector, 1st hub output, Mach2 TTM input, Mach2 TTM output, 2nd hub input, 2nd hub output), each of which are certainly affecting your USB3 signal waveform.

I would try removing one of the hubs from the signal path (hence removing 2 USB3 interfaces) and see if that helps. 

Having 2 hubs to amplify signal is probably of little help anyway in your case given the short cables used  between your PC and the camera. In fact, it probably does more harm than anything by causing multiple insertion loss, reflections, frequency multiplication (harmonics) adding noise and cross-talks which all gets worst the higher you go in frequencies (i.e. in speed). More amplication (gain) isn't better when applied to a noisy and heavily distorted (USB) signal unless the signal gets very efficiently conditionned (filtered) inside the hubs (which is unlikely).

Sébastien
_._,_._,_
10801 - 10820 of 86336