Date   

Re: APCC move axis question

Ray Gralak
 

So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where
"supposed to" is apparently clouded in lack of a clear standard, but in this case if it did, it would work?) How
does it know the proper slew rate?
The ASCOM MoveAxis method takes two parameters: an axis number and a rate in degrees/second. When initially defined (years ago) the rates were intended to be independent of sidereal rate, for anything from custom telescope control systems to tracking artificial satellites.

Since then, some drivers have interpreted the Right Ascension MoveAxis rate to be relative to the sidereal rate. However, the AP V2 ASCOM driver has always interpreted the axis rate to be relative to zero for both the RA and Dec axes.

I think the ASCOM driver is compliant with ASCOM documentation, but I am open to adding a configuration option to allow the MoveAxis RA rate to be relative to sidereal.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, August 29, 2021 2:23 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray said:

I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding
the rate supplied to it whether or not pointing and/or tracking rate correction is enabled.

However, the ASCOM driver is sending an RA movement relative to zero, which is maybe the problem. The
ASCOM definition for this method is unclear if the rate should be relative to sidereal or not. It only states that
the previous tracking rate should be restored when the move axis rate is set back to zero.

So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where
"supposed to" is apparently clouded in lack of a clear standard, but in this case if it did, it would work?) How
does it know the proper slew rate?

Maybe I should just vanish from this discussion and let Dale or one of the NINA folks decide if there's
anything to do. I'll just make a mental note not to use the arrows in NINA.

Thank you for taking a look and the explanation.

Linwood






Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray said:

I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding the rate supplied to it whether or not pointing and/or tracking rate correction is enabled.
However, the ASCOM driver is sending an RA movement relative to zero, which is maybe the problem. The ASCOM definition for this method is unclear if the rate should be relative to sidereal or not. It only states that the previous tracking rate should be restored when the move axis rate is set back to zero.
So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where "supposed to" is apparently clouded in lack of a clear standard, but in this case if it did, it would work?) How does it know the proper slew rate?

Maybe I should just vanish from this discussion and let Dale or one of the NINA folks decide if there's anything to do. I'll just make a mental note not to use the arrows in NINA.

Thank you for taking a look and the explanation.

Linwood


Re: APCC move axis question

Ray Gralak
 

Hi Linwood and Andy,

I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding the rate supplied to it whether or not pointing and/or tracking rate correction is enabled.

However, the ASCOM driver is sending an RA movement relative to zero, which is maybe the problem. The ASCOM definition for this method is unclear if the rate should be relative to sidereal or not. It only states that the previous tracking rate should be restored when the move axis rate is set back to zero.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, August 29, 2021 8:59 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray said:

You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polar
alignment result.

That's a fair point, but really steps around the core issue.

As a simple example, the NINA control panel has simple N/S/E/W controls. These stop working when pointing
corrections are active. I have no idea if there are other places in other programs that also use move-axis.

Should these in fact be failing when pointing corrections are active?

I just tried a trivial example:

- Opened APCC, initialized (tracking = 0), pointing corrections disabled
- Opened NINA, connected
- Using NINA control slewed N, then S - worked fine, fast (APCC showed it slewing)
- Checked pointing corrections
- Slewed N, S - no motion. Only thing I saw on APCC (or maybe ASCOM V2) was flickering from custom to
sidereal rates as I pushed the button

This itself is hardly an earthshaking issue since I can just use the APCC controls to slew (if my sleep deprived
brain can remember in the wee house), but it does bring with it a concern that other features of NINA or other
software connecting via ASCOM my not work.

Or is everyone pretty sure this is a very isolated case and nothing else uses move axis?

Or are you saying that Move Axis itself, if allowed, would break the pointing model?

Linwood

PS. Logs available if desired from that brief test.





Re: APCC move axis question

ap@CaptivePhotons.com
 

Andrea wrote:

 

  • Linwood,
  • Can you remind me your mount type?
  • About one year ago I saw something similar in Skyx but I thought was because the mount was new ( Mach 2). After that I learned to use the move commands in appc and I don’t know if it has been fixed. In my case the move click in Skyx caused a perpetual slewing that I needed to stop in appc. I didn’t use any model at that time.

 

It's an AP1100AE.

 

I had a MyT with TSX before, and used NINA, and did not have this issue (no APCC involved in that case of course).

 

Linwood

 


Re: APCC move axis question

Andrea Lucchetti
 

Linwood,
Can you remind me your mount type?
About one year ago I saw something similar in Skyx but I thought was because the mount was new ( Mach 2). After that I learned to use the move commands in appc and I don’t know if it has been fixed. In my case the move click in Skyx caused a perpetual slewing that I needed to stop in appc. I didn’t use any model at that time.
Andrea 

On Sun, 29 Aug 2021 at 17:59, ap@... <ap@...> wrote:
Ray said:

> You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polar alignment result.

That's a fair point, but really steps around the core issue.

As a simple example, the NINA control panel has simple N/S/E/W controls.  These stop working when pointing corrections are active.  I have no idea if there are other places in other programs that also use move-axis.

Should these in fact be failing when pointing corrections are active?

I just tried a trivial example:

- Opened APCC, initialized (tracking = 0), pointing corrections disabled
- Opened NINA, connected
- Using NINA control slewed N, then S - worked fine, fast (APCC showed it slewing)
- Checked pointing corrections
- Slewed N, S - no motion.  Only thing I saw on APCC (or maybe ASCOM V2) was flickering from custom to sidereal rates as I pushed the button

This itself is hardly an earthshaking issue since I can just use the APCC controls to slew (if my sleep deprived brain can remember in the wee house), but it does bring with it a concern that other features of NINA or other software connecting via ASCOM my not work.

Or is everyone pretty sure this is a very isolated case and nothing else uses move axis?

Or are you saying that Move Axis itself, if allowed, would break the pointing model?

Linwood

PS. Logs available if desired from that brief test.







Re: #APCC Pro 1.9 w/ASTAP platesolve test always fails #APCC

Sébastien Doré
 

Ray wrote:
I am not sure if this is a bug in APPM or simply incorrect keyword values in the FITS but this is the problem:

OBJCTRA = ' 6 30 38.84' / Object J2000 RA in Hours
OBJCTDEC= ' 4 56 54.41' / Object J2000 DEC in Degrees
Ray wrote:
According to the NASA FITS standard at the link below, leading spaces in a character string ARE significant. So, the OBJCTRA and OBJCTDEC keywords in the FITS file you supplied should not have the leading space before the RA and Dec values. So, you might want to try notifying the authors of the application (INDI?) that created that image.

Just to circle back around this one, I contacted the INDI developper and that specific issue (leading space character int the FITS header RA/DEC coordinates) has been fixed in the latest INDI version (1.9.1). The version I used to create the "faulty image" was about 6 months old (1.8.9), for reference.

Clear skies,
Sébastien


Re: #APCC - V1.9 Tracking Error #APCC

Rouz
 

About 3 hours of integration of Ha.


Re: #APCC - V1.9 Tracking Error #APCC

Rouz
 
Edited

Hi Ray,

Last session was the first night of actual data capture.

Bin1 scale  is 0.47 arcsec/pixel

PEM, Dec arc tracking, refraction all ON
Model spacing was very small (attached).

Tacking was good though over about 3 hours.

https://youtu.be/qK1BpF-LgI4


Re: #APCC - V1.9 Tracking Error #APCC

Rouz
 

Andrea,

Did something similar didnt see much in 5 minutes or so.

I can refine things more now.

Thank,
-Rouz


Re: Backlash issue or something else?

Tom Carrico
 

Testing last night and I got the same results...I am not sure where to go next. The plot is nearly identical to the one the night before. This is after I backed off the dec motor to allow the gear in the motor box to turn more freely.

To be clear, I never adjusted anything inside the gear box, all I did was remove the outer most gear to look at the spur gear. I then replaced it. Verified that it spins freely. Wiggling the telescope in dec, it feels like there is a bit of backlash.

I decided to change scopes and go back to one that I have used for years with no problems. Figured the C8 with the off axis guider and camera hanging sort of far of the back might be presenting too many variables. So, I put on my FSQ 106, re-balanced the mount and started everything up. In the past, this system has worked wonderfully. It also has a OSC camera and I guide with a 120 mm guide scope. The resolution with the FSQ is 1.4"/pixel

I slewed to a couple of different objects and took some guided exposures up to 7 minutes in length. I did not see anything like the graph above, the rms errors were typically 0.3". There were some dec corrections, but they were nothing like the above graph. In other words, it looked like things were back to normal. I chalked this up to too many variables with the C8 and would check on that at some future time. At this point I decided to do a new Pempro run, get a model with APCC and get to some serious imaging. This is when I learned that if I did not have bad luck, I would have no luck at all.

Did all the wizards in Pempro and got started. The graph below is what I got. I moved the scope around a few degrees in either direction to see if that would help and I always got this graph. Watching the star in SGP it would jump back and forth. These are 20" jumps, they would completely mess up an image, but my images looked great. I got out of Pempro and fired up PhD to see if guiding had also gone to pot. As mentioned, I use a guide scope so I am not looking at exactly the same thing, but that should not matter with excursions like this. The guiding was fine, no jumps like this. I made sure corrections were off, but I don't thing that mattered. By now, it was early in the morning and I was no longer trusting my decisions so called it a night.

Here is what I know...

- Dec still seems to be a problem using the C8, they might still be there with the FSQbut not visible with the FSQ. In fact, I would say the FSQ is completely usable with the current configuration

- I have never touched the RA motor, and have used Pempro many times on this mount with this scope, this is definitely new behavior. I checked the play in the RA axis and there is a little bit, but I decided not adjust it until I heard back. 

Would appreciate any help, I would totally believe I messed up somewhere, just need more places to look and things to try.


On 8/28/21 10:59 AM, Tom Carrico wrote:

Just got back from working on the scope. The large spur gear was too tight (thought I had checked it before finishing up yesterday...), took some force to turn.

Loosened the bolts on the motor and re-adjusted the position of the motor to minimize movement on the dec axis and make sure the spur gear turned freely. Took a couple iterations of loosen/tighten to achieve this, but I think I did a reasonable job. There might be some play in dec, but backlash seems to be preferred to anything else.

I will know more tonight, we are having a run of clear weather.

Thanks for the suggestions!

- Tom


On 8/28/21 9:59 AM, Roland Christen via groups.io wrote:

Have you enabled auto backlash compensation in PHD?
Unfortunately that will make things worse and result in heavy oscillation.
No software can counter a mechanical static friction, and will be really challenged by retrograde motion. There is no control algorithm that has ever been invented that can counteract retrograde. The opposite of retrograde is backlash delay, and of the two it is far more desirable to have a bit of backlash in the system. Backlash can be addressed in software and does not affect the stability of a control loop the way retrograde does.

Backlash will always be present in any non-encoder mount, whether it has a gearbox or is belt driven. Belt flex has a similar effect but can be lower than a spur gearbox, but there will also be some backlash in the worm to worm wheel connection. Adding precision encoders to the mount axes eliminates backlash entirely.

Roland


-----Original Message-----
From: Brian Valente <bvalente@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 11:39 am
Subject: Re: [ap-gto] Backlash issue or something else?

Hi Tom

can you upload the guidelog that you took these screen caps from?

It sounds/looks like stiction to me

Have you enabled auto backlash compensation in PHD?

On Sat, Aug 28, 2021 at 12:29 AM Tom Carrico <tom@...> wrote:
Hi,
I have an AP900 that I have had for 15 years. It has worked flawlessly. A couple weeks ago I noticed what I thought was a minor DEC backlash issue, so printed out the instructions and went to work. I could barely detect any movement in DEC with the mount in Park Position 3, but figured I would go through the process.  I verified that the set screw was properly tightened and followed the instructions to 'rock' the dec motor into place. I could not feel any backlash and figured things were going to be back to normal. I apparently made it worse...
This image shows what I now see in PhD 2. At some point it starts making a dec correction and things keep getting worse, almost like the corrections were moving in the wrong direction. I re-did calibration in PhD multiple times to make sure I had not messed anything up. In the PhD graph, each large vertical division is 25 points at 6 seconds per point, or about 150 seconds. The telescope is a Celestron Edge HD 8". The guide camera is off axis and is a ZWO ASI 290.


I changed the min move in dec to 5 to effectively disable dec corrections right after this happened. You can see that the polar alignment is fine, as there were no longer dec corrections. Up until I tried to make the mount better, I was getting rms guide errors consistently < 0.5", typically around 0.4". I have never seen anything like this.

I ran the PhD guiding assistant and it verified that my polar alignment was not too bad, but that there was some serious backlash

This is verified by the backlash graph


I ran this test a year ago, and the backlash graph was a perfect triangle. Clearly I am not doing the adjustment optimally. Do I just need to fiddle with it to get it right? When I try to move the dec axis I can barely feel any movement, am I going for no movement at all?
When I 'rock' the motor into place, I place firm pressure on it while I adjust the bolts per the instructions. I could certainly use more force (or a rubber mallet), but not really sure if that is the way to go.
Any advice would be greatly appreciated.
Thanks
- Tom C




--
Brian 



Brian Valente

--
Roland Christen
Astro-Physics


Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray:

Yes, this seems like a bug and is already on my list to investigate. I have just barely caught up with answering online and private offline questions, looking at logs, etc. This hasn't left me much free time to focus on fixing the issues reported.
Yeah, I understand the feeling, I find it hard to believe you can get any actual development done with the volume of email.

The mixed blessing of having people actually use the software you write! 😊

Linwood


Re: APCC move axis question

Ray Gralak
 

Linwood,

Yes, this seems like a bug and is already on my list to investigate. I have just barely caught up with answering online and private offline questions, looking at logs, etc. This hasn't left me much free time to focus on fixing the issues reported.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, August 29, 2021 8:59 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray said:

You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polar
alignment result.

That's a fair point, but really steps around the core issue.

As a simple example, the NINA control panel has simple N/S/E/W controls. These stop working when pointing
corrections are active. I have no idea if there are other places in other programs that also use move-axis.

Should these in fact be failing when pointing corrections are active?

I just tried a trivial example:

- Opened APCC, initialized (tracking = 0), pointing corrections disabled
- Opened NINA, connected
- Using NINA control slewed N, then S - worked fine, fast (APCC showed it slewing)
- Checked pointing corrections
- Slewed N, S - no motion. Only thing I saw on APCC (or maybe ASCOM V2) was flickering from custom to
sidereal rates as I pushed the button

This itself is hardly an earthshaking issue since I can just use the APCC controls to slew (if my sleep deprived
brain can remember in the wee house), but it does bring with it a concern that other features of NINA or other
software connecting via ASCOM my not work.

Or is everyone pretty sure this is a very isolated case and nothing else uses move axis?

Or are you saying that Move Axis itself, if allowed, would break the pointing model?

Linwood

PS. Logs available if desired from that brief test.





#ASCOM_V2_Driver #ASCOM_V2_Driver

 


-- I run robotic projects on a 900 mount.  Higher slew speed would increase system efficiency.  Any thoughts on what the downsides might be to selecting the maximum slew speed, or contrarywise, what the advantages are to a lower one?
James (Bruce) McMath


Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray said:

You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polar alignment result.
That's a fair point, but really steps around the core issue.

As a simple example, the NINA control panel has simple N/S/E/W controls. These stop working when pointing corrections are active. I have no idea if there are other places in other programs that also use move-axis.

Should these in fact be failing when pointing corrections are active?

I just tried a trivial example:

- Opened APCC, initialized (tracking = 0), pointing corrections disabled
- Opened NINA, connected
- Using NINA control slewed N, then S - worked fine, fast (APCC showed it slewing)
- Checked pointing corrections
- Slewed N, S - no motion. Only thing I saw on APCC (or maybe ASCOM V2) was flickering from custom to sidereal rates as I pushed the button

This itself is hardly an earthshaking issue since I can just use the APCC controls to slew (if my sleep deprived brain can remember in the wee house), but it does bring with it a concern that other features of NINA or other software connecting via ASCOM my not work.

Or is everyone pretty sure this is a very isolated case and nothing else uses move axis?

Or are you saying that Move Axis itself, if allowed, would break the pointing model?

Linwood

PS. Logs available if desired from that brief test.


Re: GTO vs AE/AEL data #Absolute_Encoders

J. Belden
 

While I do not have an data that would prove the AE/AEL encoders helped my imaging out, I can say that I have lived in Midland,TX for 3 years and prior to owning my AP1600 AE mount. I wouldn’t try imaging when the winds were over 15 mph/hr. Though, I did upgrade from an AP1100 non AE, so was my improvement based on the load capacity? I think maybe some but I have had many episodes where a sudden gust of wind would normally cause me to dump those frames but with the AP1600 AE, I have lost more frames due to ie satellites or planes. I believe without personally needing to conduct a bunch of tests to prove or disprove, that the AE option was well spent money. However, ever since I bought my first AP mount (Mach1) that my constant fiddle with mounts went away and I could use my time just imaging. Keep in mind that I use astronomy as a pure escape from work so the less I need to engineer something the better otherwise it will become work to me. Oh, I typically had an AGO 12.5/TOA130 with an STXL6303/FW/AOX as my imaging load.
Finally, in the beginning I didn’t believe I would benefit much from the AE option. I really don’t care if I need to autoguide some verses the cost difference but hindsight being able to image when the winds blow moderately has allowed me to setup more nights instead of watching grit tv.

Joe Belden


Re: APCC move axis question

Ray Gralak
 

Andy,

You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polar alignment result.

BTW, changing polar alignment invalidates the model anyway.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Saturday, August 28, 2021 4:27 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

I think I figured out what was causing my issues with move axis. I had tracking correction turned on in APCC,
that seemed to conflict with the direction arrows in NINA.
Once I turned it off the direction arrows worked consistently as expected. The easy fix is to turn off tracking
correction during the automated 3 point polar align with NINA and then turn it back on after it's done!


Re: #APCC - V1.9 Tracking Error #APCC

Ray Gralak
 

Hi Rouz,

Assuming accurate source plate solves, I think that you have some randomness in your setup. I can tell there is randomness because in each of your pointing models, some of your East/West pointing terms are very different. If your setup does not act precisely the same every time, then as you found out, more data points will be required to average out the randomness.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Rouz
Sent: Sunday, August 29, 2021 1:05 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] #APCC - V1.9 Tracking Error

Here is the Model.



Re: #APCC - V1.9 Tracking Error #APCC

Andrea Lucchetti
 

0ne thing I can suggest if you didn’t check already:

- take a series of short frames, with some delay in between, to cover 30 min or more
- do the Sum or create an animation of the series’ and check if the stars move. If yes, this is a flex in the system. This helped me to fix my focuser in the past.
Andrea 


Re: #APCC - V1.9 Tracking Error #APCC

Rouz
 

Here is the Model.


Re: #APCC - V1.9 Tracking Error #APCC

Rouz
 
Edited

Ok some more tests and positive results.

I tried the same model above with PEM OFF with the same results (just to eliminate things one by one).

I made another model with PEM OFF but very dense points (attached).

So far results are good, with PEM off or on and all other corrections on. Drift is very minor, stars are mostly round.
Perhaps a model with PEM on would be better still.

So it seems the points need to be very close together. Its not at 2 degrees in Dec and 4 Degrees in Ra.

Capturing data now.

5921 - 5940 of 86399