Date   

Re: [ap-ug] End of an era?

Pete Lardizabal
 

WOW! Simply beautiful!

More rare than hens teeth...

😎

Pete

On Jul 31, 2020, at 6:17 PM, Roland Christen via groups.io <chris1011@...> wrote:


Hi Astronuts,

Today I finished the last of the 10" F14.5 Maks, which will go to whoever is on our list. This is the last of my hand figured Maks that I plan to make of this size and focal length in production. It used to be that there was much more visual astronomy than there is today, probably because imaging was hard in the film days and for the first couple of years when we had small chips to do electronic imaging. Nowadays it is impossible to get visual views that remotely resemble what you can do with a few thousand bucks worth of electronic equipment.

That said, here is my last production Mak, aimed at a far distant telephone pole insulator which has a glint of sunshine that shows up as an artificial star. With a 5mm SPL ocular (737x) I see a tight high contrast Airy disc at focus. For those who don't know what that is - an Airy disc is the smallest resolvable spot from a distant point source that can be seen in any telescope. For a 10" it's approximately 4.5 arc seconds, and is surrounded by a few faint diffraction rings. With a scope like this I once saw the Sirius Pup in the Florida Keys when the separation was a mere 4 arc seconds.

<dummyfile.0.part>
Business end of the mighty Mak


<dummyfile.1.part>
Let there be light and minimal obstruction


<dummyfile.2.part>
The little Stowaway couldn't help hitching a ride on it's big sister


Re: APPC refraction correction question

Dean Jacobsen
 

Craig,

I have been setting up APPM to take measurements on three declination lines that more or less bracket my intended target [I say "more or less" because the middle line is close to but not always exactly on the target's declination] from 40 degrees altitude east to west and set the RA spacing at about 10 or 11 degrees.

APPM will map the eastern and western sky and will also double map the counterweight up positions on the west side that fall within my west side meridian limits.

When I activate the model I always have had "Correct for Refraction" checked and I monitor and enter in current values for temperature and barometric pressure in the screen for the pointing model tab.

Actually, sitting here with APCC open I see that unchecking the "Correct for Refraction" does change the values, but not by very much.

I have had excellent results so far.  Nice round stars on the east side up to my meridian limits [1 - 3 hours past the meridian] and then when I flip the mount I get nice round stars going down the west side of the mount.

I have taken several hundred subexposures from 2 to 4 minutes at the short focal lengths that I use so far using this abbreviated all sky model and I haven't had to drop a single subexposure due to star shapes.  I can't really say how this method would work for focal lengths over 530mm.
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin - https://www.astrobin.com/users/deanjacobsen/ 


Re: End of an era?

Elenillor
 

Thank you for making these superb instruments. 

I am very please you made another group as I got one earlier this year. Seeing the one your brought to Astrofest many years ago prompted me to put my name on the list. At the time I had hoped you would make a more portable 8" version and still think that would sell well.  I am a portable visual observer and the 10" perfectly fits my needs for a high magnification scope. 

John


End of an era?

Roland Christen
 

Hi Astronuts,

Today I finished the last of the 10" F14.5 Maks, which will go to whoever is on our list. This is the last of my hand figured Maks that I plan to make of this size and focal length in production. It used to be that there was much more visual astronomy than there is today, probably because imaging was hard in the film days and for the first couple of years when we had small chips to do electronic imaging. Nowadays it is impossible to get visual views that remotely resemble what you can do with a few thousand bucks worth of electronic equipment.

That said, here is my last production Mak, aimed at a far distant telephone pole insulator which has a glint of sunshine that shows up as an artificial star. With a 5mm SPL ocular (737x) I see a tight high contrast Airy disc at focus. For those who don't know what that is - an Airy disc is the smallest resolvable spot from a distant point source that can be seen in any telescope. For a 10" it's approximately 4.5 arc seconds, and is surrounded by a few faint diffraction rings. With a scope like this I once saw the Sirius Pup in the Florida Keys when the separation was a mere 4 arc seconds.

Business end of the mighty Mak


Let there be light and minimal obstruction


The little Stowaway couldn't help hitching a ride on it's big sister


CP3 and CCD AutoPilot v.5

CurtisC
 
Edited

Mach1GTO, CP3 controller, Starlight Xpress Superstar guider, Baader Vario-Finder guide scope, MaxIm DL 6.21.  The computer is connected to the mount's serial port with a Keyspan adapter. 

Has anybody successfully used CCD AutoPilot v.5 with this hardware?  I can't get it to guide.  MaxIm keeps reporting that it "can't connect to guider relays."  Why?  MaxIm is set-up as "Telescope," not "Guider relays."  Something is telling MaxIm to look for guider relays. 

Also, MaxIm can't find guide stars.  I'm using the Baader guide scope.  There are always lots of guide stars.  The developer of CCD AutoPilot seemed to draw a blank when I presented him with this problem.  Something which may be related to the problem of finding guide stars (but Mr. Smith didn't think so) is that CCDAP lists the guider dimensions as "32x32."  I have no idea how these numbers are derived, or even if they are supposed to be pixels or millimetres.  They would be incorrect in either case.  The dimensions of the guider, as defined in MaxIm, is 1392 x 1040 pixels, and the physical dimensions of the chip is 6.47 x 4.84 mm.

CCD Commander has worked with this equipment for many years.  Someone may suggest that I'm wasting my time with CCD AutoPilot.  They may be right.  But I have a full license now, so I'd like to get it to work.


Re: APPC refraction correction question

Craig Young
 

I will give that a try on my next clear night.  First, I will create a new model with two DEC arcs, with the target DEC arc sitting between the two sample arcs.  That way the model straddles equally either side of the target arc.  Next, I will compare the tracking results: a) a single DEC arc model with refraction off, b) a single DEC arc model with refraction on and Offset error terms disabled, c) two DEC arc model with refraction enabled.  I'll come back here with the results after the test, hopefully soon.  If others are already doing this it would be good to add in their results to see which of these methods works best.  What we are looking for is the method providing the most accurate unguided imaging run, say a 1 hour run and looking at the quality of the stars (roundness) over that period (or tracking errors if using more analytic software like ATrack).

We can also use these test results as a benchmark for when Ray brings out the DEC arc feature in APPM.  So the more experience we can get from actual user experiences will help to evaluate the new feature and maybe provide some good feedback to Ray as he is designing the new feature.  The AP mounts are more than capable of reaching high performance unguided imaging over long periods of time with small plate scales.  What we need now is to perfect the methodology/software to match the hardware.

Craig


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Roland Christen
 

Ok.

Rolando



-----Original Message-----
From: Christopher Erickson <christopher.k.erickson@...>
To: main@ap-gto.groups.io
Sent: Fri, Jul 31, 2020 12:31 pm
Subject: Re: [ap-gto] Testing homing limits resulted in motor stall errors with Mach1 #APCC

Having a low voltage halt result in a solid yellow light and a limits halt result in a blinking yellow light and a hardware stall resulting in a S.O.S. blinking light (for examples) would be a nice feature to eventually add to the CP4 firmware.

On Fri, Jul 31, 2020 at 5:01 AM uncarollo2 <chris1011@...> via groups.io <chris1011=aol.com@groups.io> wrote:

'm afraid to repeat these tests as there could be potential problems with the hardware,
The "Motor Stall" warning will occur when unsafe limits are exceeded. This is not a warning that something is wrong with the motor or electronics, it is simply telling you that the software has turned off the power to the motors to prevent your scope from being damaged. At this time we use the same error code for all situations where the motor power has been turned off. It probably could be changed to indicate not "motor stall" but "motor power deactivated".  However, we have many other software challenges right now and this one will have to wait a bit. Be assured that nothing bad has happened to your electronics or the motors.

Rolando


-----Original Message-----
From: Leo Shatz <leonid.shatz@...>
To: main@ap-gto.groups.io
Sent: Fri, Jul 31, 2020 6:22 am
Subject: [ap-gto] Testing homing limits resulted in motor stall errors with Mach1 #APCC

Hello,

Recently I had a very good remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:
 
- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.
 
- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).
 
I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz
 


Re: Pier flip before meridian crossing is not possible with SGP and Mach1

Ray Gralak
 

Hi Leo,

APCC already integrates with SGPro to set meridian limits and flip points.

You can set this up on the Meridian Limits tab. Take a look at the Meridian Limits section of the help file if needed.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
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 Leo Shatz
Sent: Friday, July 31, 2020 8:46 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Pier flip before meridian crossing is not possible with SGP and Mach1

[Edited Message Follows]

I recently contacted SGP forum after dealing with aftermath of pier collision after failure to perform auto flip. I think
I've sorted out most of the things and I have now solution in hand, but I thought that it's still worth while to raise the
following issue with you, too.

If I understand correctly, Mach1 can perform pier flip safely when it stays withing meridian limits as defined in
APCC, which include both sides of meridian. However SGP does NOT support flips (either manual or auto) when
mount hasn't yet crossed meridian. When I raised a question about supporting pier flips before crossing meridian
on SGP forum, there was one answer so far I got from the SGP forum thread
<https://forum.sequencegeneratorpro.com/t/meridian-flip-failed-and-sequence-aborted-on-mach1-followed-by-
mount-pier-collision/12912> on this issue:


"AIUI SGP will flip before the meridian by using the ASCOM set pier side command. The ASCOM driver must
report CanSetPierSide as true and implement the PierSide set method. If set PierSide command is sent when the
mount can’t do it then the mount should throw an exception. I guess that the AP driver doesn’t do this but can be
set so that the hour angle after which a slew will change the pier side is before the meridian. One thing to
remember is that SGP is written to work for a multitude of people using a wide variety of mounts."


I'd be glad to know if there is a way to support pier flips before meridian crossing - maybe I'm missing something,
or it depends on additional integration between APCC and SGP.

Thanks,

Leo


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Christopher Erickson
 

Having a low voltage halt result in a solid yellow light and a limits halt result in a blinking yellow light and a hardware stall resulting in a S.O.S. blinking light (for examples) would be a nice feature to eventually add to the CP4 firmware.


On Fri, Jul 31, 2020 at 5:01 AM uncarollo2 <chris1011@...> via groups.io <chris1011=aol.com@groups.io> wrote:

'm afraid to repeat these tests as there could be potential problems with the hardware,
The "Motor Stall" warning will occur when unsafe limits are exceeded. This is not a warning that something is wrong with the motor or electronics, it is simply telling you that the software has turned off the power to the motors to prevent your scope from being damaged. At this time we use the same error code for all situations where the motor power has been turned off. It probably could be changed to indicate not "motor stall" but "motor power deactivated".  However, we have many other software challenges right now and this one will have to wait a bit. Be assured that nothing bad has happened to your electronics or the motors.

Rolando


-----Original Message-----
From: Leo Shatz <leonid.shatz@...>
To: main@ap-gto.groups.io
Sent: Fri, Jul 31, 2020 6:22 am
Subject: [ap-gto] Testing homing limits resulted in motor stall errors with Mach1 #APCC

Hello,

Recently I had a very good remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:
 
- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.
 
- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).
 
I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz
 


Re: APPC refraction correction question

Dean Jacobsen
 

On Fri, Jul 31, 2020 at 10:17 AM, Ray Gralak wrote:
The solution is simply to use at least two rows of declination data points. Having at least two declination rows would allow APCC to calculate pointing terms that vary directly or indirectly by declination more accurately.
Excellent!  Good to know this.
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin - https://www.astrobin.com/users/deanjacobsen/ 


Re: APPC refraction correction question

Ray Gralak
 

Am anxious to see what happened.
The problem is with which data points are in a model. Some of the terms have factors that vary directly or indirectly by declination. After subtracting refraction, some values used to calculate pointing terms became non-deterministic, much like right ascension becomes at a celestial pole.

With all the data points being at one declination, the amount of pointing error introduced by not including refraction kept the multi-term best fit "singular" (i.e., one solution) with the pointing terms modeling refraction+other errors.

The solution is simply to use at least two rows of declination data points. Having at least two declination rows would allow APCC to calculate pointing terms that vary directly or indirectly by declination more accurately.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
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 Young
Sent: Friday, July 31, 2020 2:11 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPC refraction correction question

Thanks Ray. Here is the pnt file. It consists of 22 samples along a DEC arc of -15 degrees from HA -3 to the
meridian. With refraction correction turned off the Offset error in HA is -170.12. With refraction correction disabled
the model terms are reasonable numbers. With refraction correction enabled you will see the model terms go
really bad. So the model seems good without refraction and samples along a DEC arc, but when refraction is
turned on the model is off the scale. Something dramatic happened. But, if you remove the offset terms then the
model is back to being realistic. Am anxious to see what happened.

Craig


Pier flip before meridian crossing is not possible with SGP and Mach1

Leo Shatz
 
Edited

I recently contacted SGP forum after dealing with aftermath of pier collision after failure to perform auto flip. I think I've sorted out most of the things and I have now solution in hand, but I thought that it's still worth while to raise the following issue with you, too.

If I understand correctly, Mach1 can perform pier flip safely when it stays withing meridian limits as defined in APCC, which include both sides of meridian. However SGP does NOT support flips (either manual or auto) when mount hasn't yet crossed meridian. When I raised a question about supporting pier flips before crossing meridian on SGP forum, there was one answer so far I got from the SGP forum thread on this issue:

"AIUI SGP will flip before the meridian by using the ASCOM set pier side command. The ASCOM driver must report CanSetPierSide as true and implement the PierSide set method. If set PierSide command is sent when the mount can’t do it then the mount should throw an exception. I guess that the AP driver doesn’t do this but can be set so that the hour angle after which a slew will change the pier side is before the meridian. One thing to remember is that SGP is written to work for a multitude of people using a wide variety of mounts."

I'd be glad to know if there is a way to support pier flips before meridian crossing - maybe I'm missing something, or it depends on additional integration between APCC and SGP.

Thanks,

Leo


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Leo Shatz
 

Rolando,

Thank you for answering my concerns. Your explanation makes sense to me now.

Leo


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Roland Christen
 


I still wonder why motor stall events were triggered at a moment
I explained that in a previous e-mail. Did it not come thru?

Rolando


-----Original Message-----
From: Leo Shatz <leonid.shatz@...>
To: main@ap-gto.groups.io
Sent: Fri, Jul 31, 2020 10:02 am
Subject: Re: [ap-gto] Testing homing limits resulted in motor stall errors with Mach1 #APCC

Dale,

I've mentioned it in description of the problem that there was no external mechanical force on the mount - it stopped at homing limit as was set in APCC.
The mount was well balanced in both Ra and Dec.
There was no payload, no telescope mounted on top, just scope rings with losmandy plate and a smallest CW just to balance everything (when freeing the Ra/Dec locks each axis was almost perfectly balanced).
This was done for testing purposes alone.

I still wonder why motor stall events were triggered at a moment when mount was parked in place when hitting homing limit (and I repeat - it didn't hit anything physically at that moment).

Thanks,

Leo


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Leo Shatz
 

Dale,

I've mentioned it in description of the problem that there was no external mechanical force on the mount - it stopped at homing limit as was set in APCC.
The mount was well balanced in both Ra and Dec.
There was no payload, no telescope mounted on top, just scope rings with losmandy plate and a smallest CW just to balance everything (when freeing the Ra/Dec locks each axis was almost perfectly balanced).
This was done for testing purposes alone.

I still wonder why motor stall events were triggered at a moment when mount was parked in place when hitting homing limit (and I repeat - it didn't hit anything physically at that moment).

Thanks,

Leo


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Roland Christen
 


'm afraid to repeat these tests as there could be potential problems with the hardware,
The "Motor Stall" warning will occur when unsafe limits are exceeded. This is not a warning that something is wrong with the motor or electronics, it is simply telling you that the software has turned off the power to the motors to prevent your scope from being damaged. At this time we use the same error code for all situations where the motor power has been turned off. It probably could be changed to indicate not "motor stall" but "motor power deactivated".  However, we have many other software challenges right now and this one will have to wait a bit. Be assured that nothing bad has happened to your electronics or the motors.

Rolando


-----Original Message-----
From: Leo Shatz <leonid.shatz@...>
To: main@ap-gto.groups.io
Sent: Fri, Jul 31, 2020 6:22 am
Subject: [ap-gto] Testing homing limits resulted in motor stall errors with Mach1 #APCC

Hello,

Recently I had a very good remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:
 
- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.
 
- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).
 
I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz
 


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Dale Ghent
 

So, the primary cause of a motor stall is an external mechanical force that is countering the direction that the motors are driving the axes in question. Sometimes it's electrical, such as your power source (such as a battery) furnishing too little voltage to the mount.

Since you didn't mention verifying the physical condition of the mount and the stuff you have hanging off of it, have you checked balance of both RA and dec and looked for any cable wrapping or snags that could be catching and preventing one of the axes from turning past a certain point?

You assertion that the issue might be software-based is misinformed - APCC and the ASCOM driver sends commands to the mount controller to slew and move to the requested point; so the software on your computer is not responsible for actually driving the motors themselves every micrometer of the way. It's impossible for APCC to be directly responsible or the cause of a motor stall.

Describe your mount's load in more details and the work you have done to verify balance, as well as any other mechanical configuration issues that would be the most likely causes of a stall event.

/dale

On Jul 31, 2020, at 7:22 AM, Leo Shatz <leonid.shatz@gmail.com> wrote:

Hello,

Recently I had a very good remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:

- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.

- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).

I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Leo Shatz
 
Edited

I'm using APCC Pro version 1.8.3.1 and VCP4-P01-13 firmware.


Testing homing limits resulted in motor stall errors with Mach1 #APCC

Leo Shatz
 
Edited

Hello,

Recently I had a very productive remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:
 
- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.
 
- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).
 
I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz
 


Re: APPC refraction correction question

Craig Young
 

Thanks Ray.  Here is the pnt file.  It consists of 22 samples along a DEC arc of -15 degrees from HA -3 to the meridian.  With refraction correction turned off the Offset error in HA is -170.12.  With refraction correction disabled the model terms are reasonable numbers.  With refraction correction enabled you will see the model terms go really bad.  So the model seems good without refraction and samples along a DEC arc, but when refraction is turned on the model is off the scale.  Something dramatic happened.  But, if you remove the offset terms then the model is back to being realistic.  Am anxious to see what happened.

Craig

10301 - 10320 of 82372