Date   

Re: Adjusting cone error with camera and no view of pole?

Christopher Erickson
 

First, if you are using APCC-Pro, modelling compensates for cone error so you don't have to shim or adjust anything. It's all taken care of via APCC software in the model.

Second, I prefer adjusting cone error during the day. Too hard for me to go from a dim eyepiece to a flashlight and tools and bolts and shims and back to the dim eyepiece. I pick a distant terrestrial object near straight East or West on the horizon, turn off tracking and flip back and forth over the meridian on that object, taking into consideration the parallax distance as I flip back and forth. And I use the sides of pop cans cut with scissors and a paper punch for shims. I shim between the dovetail bar and the OTA rings or radius blocks.

And make sure your OTA is very carefully collimated before evaluating or adjusting the cone error. No big deal on refractors but a big deal on reflectors.

Cone error, a.k.a. orthogonality a.k.a. perpendicularity, is the relationship between the DEC axis and the optical axis, not the OTA axis.

"My advice is always free and worth every penny!"

-Christopher Erickson
Observatory Engineer
Summit Kinetics
Waikoloa, Hawaii


On Sat, Aug 28, 2021 at 8:11 AM Tom Blahovici <tom.va2fsq@...> wrote:
Hi
How does one adjust cone error if you have no view of the pole and use a camera?
Thanks


Re: ISS Tracked using APCC Pro v1.9

Robert Berta
 

Brent...nice job. Is that a video in a format like AVI that can be entered into Autostakkert? If so Autostakkert would pick best shots, perfectly align, and stack into a higher resolution single image. That is what I use for Ha solar astronomy. It is amazing how what seems to be a so-so not sharp image in a video becomes amazingly detailed and sharp.


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

Rouz
 

A general question:

This mount has no encoders and a good PEC will reduce the PE to say 1 arcsecond.

My typical OAG guiding error was a very consistent 0.4 arcseconds.

Would be correct to say that even with a good PE curve and modeling, the OAG would still yield better guiding?


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

Rouz
 

Roland,

Thank you for clarifying that.

Yes, I understood that PE correction applies to the few arcseconds of sinusoidal like wiggle in the Ra. Dec drift, should be corrected by the model.


I didn't see how a few arcseconds of wiggle would drift the image continuously, but given the drift disappeared after I made a new model with PEM off, I assumed that corrupt curve was messing up the model numbers as it was an accumulation of miscalculations with each slew perhaps.


So next,
I will reload that previous PE curve you said was good and will turn PEM on and make another model.



-Rouz


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

Roland Christen
 

Periodic error can be describes as speed bumps at regular intervals on the road. The PE curve measures those and applies the opposite movement so that the ride is smooth (and your head doesn't hit the roof at every bump). PE doesn't compensate for the curve in the road.

Drift is the slow curve in the road which has to be compensated by steering the car (autoguiding) or by putting software into the steering mechanism which measures the curve and then applies the appropriate amount of steering to keep the car on the road. Periodic error has no effect on how the model steers the vehicle (in this case the mount) to eliminate drift.

Rolando

-----Original Message-----
From: Rouz <rbidshahri@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 1:51 pm
Subject: Re: [ap-gto] #APCC - V1.9 Tracking Error

Hi Roland,

Having had some sleep now (severely deprived) I see what you mean about the previous curve being better. A flatter curve to work with and then I use the model to correct for PA and other factors not worm gear related.

I'll reload the previous curve and re-test with PEM and make a new new model.


Also Ray:
My previous assumption was that the PEC file was corrupt and was throwing off the model numbers leading to the incorrect model and therefore causing drift.



 


--
Roland Christen
Astro-Physics


Re: Adjusting cone error with camera and no view of pole?

Roland Christen
 

I pick a star near the zenith, slew and center it and hit recal. Then I press "flip scope" on the keypad and the star will be acquired on the opposite side. Any difference in RA direction will be 2 times the Ortho error. Ignore the N-S error since that is a function of the polar misalignment.

Roland



-----Original Message-----
From: Tom Blahovici <tom.va2fsq@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 1:11 pm
Subject: [ap-gto] Adjusting cone error with camera and no view of pole?

Hi
How does one adjust cone error if you have no view of the pole and use a camera?
Thanks

--
Roland Christen
Astro-Physics


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

Rouz
 

Hi Roland,

Having had some sleep now (severely deprived) I see what you mean about the previous curve being better. A flatter curve to work with and then I use the model to correct for PA and other factors not worm gear related.

I'll reload the previous curve and re-test with PEM and make a new new model.


Also Ray:
My previous assumption was that the PEC file was corrupt and was throwing off the model numbers leading to the incorrect model and therefore causing drift.



 


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

Rouz
 

Hi Ray,

I believe I had it downloaded, will take a look at it. Thank you for the link (I was aware you have created quite a few software and contributed much to the community).


-Rouz


Re: Adjusting cone error with camera and no view of pole?

Steven Panish
 

Tom - Look up the ConeSharp program, from the SharpCap folks.  Very easy to use, no need to use a specific star.  Adjusters make life easier than shimming.

Steve

On Sat, Aug 28, 2021 at 2:11 PM Tom Blahovici <tom.va2fsq@...> wrote:
Hi
How does one adjust cone error if you have no view of the pole and use a camera?
Thanks


Adjusting cone error with camera and no view of pole?

Tom Blahovici
 

Hi
How does one adjust cone error if you have no view of the pole and use a camera?
Thanks


Re: Backlash issue or something else?

Tom Carrico
 

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: Mach2 Problem with RS232 Connections.

Ray Gralak
 

Stacey,

That's great news! I am glad it was something you can correct without having to send in your CP5!

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Stacey Mills
Sent: Saturday, August 28, 2021 9:46 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Mach2 Problem with RS232 Connections.

Hi Ray, I've got the problem solved. I went back out into the HOT observatory and the USB->serial connection to
the CP5 worked! I'm not sure what the issue was earlier. I again tested my RocketPort card with a null modem
between two card ports and a couple of terminal programs (TeraTerm) and it seemed to work fine. However, I
figured I'd pull out a separate USB->4 serial port adapter that I had and see if that would work, AND IT DID, on both
CP5 RS232 ports. So the problem lies with my RocketPort card and not the CP5. I'm not sure why the terminal
programs worked and the CP5 didn't but I won't pursue that at the moment. Since the serial ports are backups to
the ethernet anyway, I'm happy using that setup and I'll yank the RocketPort card for now. So sorry to have caused
an issue that was really on my end. Thanks!

-Stacey


APCC Modeling with SCT

 

I use ACP Scheduler to run a robotic variable star program with a 900 mount unguided.  Tracking in particular with the longer exposures sometimes required is problematic and substantially impacts signal to noise levels I can achieve.  At least some of this I related to mirror flop on my c11.  I modified the instrument in an effort to mitigate this, but was never satisfied that I had eliminated it.  I have now replaced the scope with a Meade 12" ACF, which allegedly eliminates or reduces mirror flop.  In theory, APCC could greatly enhance my tracking and hence data quality.  I am wondering if anyone here has had success in using APCC's modeling ability with an SCT and especially a Meade ACF without using mirror locking. 
--
James (Bruce) McMath


Re: GTO vs AE/AEL data #Absolute_Encoders

Roland Christen
 

On Aug 19 Mr. Linwood posted some results comparing his new 1100AE mount to previous mounts that he owned. Below is his post, which might be informative to you:


" I’ve only had 3 nights I could image, but have been doing objects I did with other mounts to compare (I saved the old subs).  Wanted to share a typical result.
 
This is Sii for the bubble nebula at 2800mm, 300s images, at 0.277”/pix, FWHM is in arcseconds.  The left 3/4 or so were from a CEM70G, the right is from the AP1100.  The left were heavily culled to get more consistency, the right is EVERY SINGLE SUB from last night.  Same camera, OTA, imaging train… just different mounts.
 
I also have similar for the MyT, the main difference is on the MyT I didn’t have to cull so much.
 
It’s easy to think it may be night to night variation (and some may be) but every target is like this.  The jagged left side is three separate nights.  What impresses me is not just that the stars are smaller points, but the consistency – that flat line on the right is about 5 hours, over maybe 20 degrees altitude (at a guess), and did I mention every single sub included, no culling.
 
THAT’s why waiting is worthwhile!
 
Linwood
 
 

--
Roland Christen
Astro-Physics


Re: Backlash issue or something else?

Roland Christen
 


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


APPM and ASCOM camera: Fail to Star Exposure

Ken Sablinsky
 
Edited

Hit sent too early!

I did a dec tracking arc run last night via APPM and ASTAP, and it worked flawlessly except for in one camera configuration.  I have an ASCOM camera, Orion 26mp Mono, and if I set the binning to 2x2, and full frame, it fails the exposure with this error: ASCOM CCD Expose Failed(1): StartExposure.
1 2021-08-28 09:34:23.830:       Info,  StartTakeImage, ASCOM Camera: Binning=2, Subframe Type: 0, Duration=3, IsDarkFrame=False
2 2021-08-28 09:34:23.845:       Info,          MsgBox, Message: ASCOM CCD Expose Failed(1): StartExposure
3 2021-08-28 09:34:26.027:       Info,   State Machine, Entering State=WaitPlateSolveNow

If I set the sub frame to 1/2 by 1/2 or 1/4 by 1/4, it works fine.  And if I set the binning to 1x1, it works in all subframe modes as well.  I can use SGP with ASTAP as the solver, and it works fine via 2x2 full frame, just not when doing stand alone APPM and ASTAP.  This is a minor issue as there is an easy workaround to run it as a sub frame, but any idea if the problem is in the ASCOM driver or in my APPM settings?  
Here is a successful exposure wit hthe subframe turned on:
0 2021-08-28 09:34:34.852:       Info,  StartTakeImage, ASCOM Camera: Binning=2, Subframe Type: 1, Duration=3, IsDarkFrame=False
0000021 2021-08-28 09:34:35.798:       Info,   State Machine, Entering State=WaitPlateSolveNow
0000022 2021-08-28 09:34:38.971:       Info,   State Machine, WaitPlateSolveNow: Exposure Done. Saving to: C:\Users\kensa\Documents\Astro-Physics\APPM\SolveNow-2021-08-28-093438.fit
0000023 2021-08-28 09:34:42.470:       Info,   State Machine, Entering State=PlateSolveOnlyNow

Thanks
-Ken


Re: Mach2 Problem with RS232 Connections.

Stacey Mills
 

Hi Ray,  I've got the problem solved.  I went back out into the HOT observatory and the USB->serial connection to the CP5 worked!  I'm not sure what the issue was earlier.  I again tested my RocketPort card with a null modem between two card ports and a couple of terminal programs (TeraTerm) and it seemed to work fine.  However, I figured I'd pull out a separate USB->4 serial port adapter that I had and see if that would work, AND IT DID, on both CP5 RS232 ports.  So the problem lies with my RocketPort card and not the CP5.  I'm not sure why the terminal programs worked and the CP5 didn't but I won't pursue that at the moment.  Since the serial ports are backups to the ethernet anyway, I'm happy using that setup and I'll yank the RocketPort card for now.  So sorry to have caused an issue that was really on my end.  Thanks!

-Stacey


Re: 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


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

Roland Christen
 


I suppose I should run PEMPRO again and try for a better PEC curve.
Your PE curve is PERFECT! DON'T change it.

Rolando


-----Original Message-----
From: Rouz <rbidshahri@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 2:24 am
Subject: Re: [ap-gto] #APCC - V1.9 Tracking Error

[Edited Message Follows]
Now with the previous PEC curve and PEM ON.


Ra error improved slightly to 3.56 arc-sec peak to peak.

I suppose I should run PEMPRO again and try for a better PEC curve.

-Rouz

--
Roland Christen
Astro-Physics


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

Roland Christen
 

You should have left the old curve in there. This new PE correction is NOT correcting for periodic error like the last one. It may have made it worse.

Please think about what the PE correction does and does not do:
1) PE correction eliminates the slow periodic wiggles in the RA tracking
2) PE correction does NOT remove the drift, nor does it produce drift.
3) PE correction does absolutely nothing to the Dec tracking or Dec drift. Dec is stationary and does not move.

The only reason drift is there or not is due to polar alignment, atmospheric refraction and other effects.
I'm afraid you are chasing red herrings down a blind alley because of fundamental misunderstanding of what PE correction does (and perhaps what modeling is supposed to do?) It is a complex subject and I cannot really cover everything in a few sentences. All I can do is to try leading you slowly down the proper path, but if you go off on a side adventure then it becomes difficult to get back to the right path. Unfortunately your side adventure was to make a new PE curve without waiting for my input of the tests that I suggested.

Roland



-----Original Message-----
From: Rouz <rbidshahri@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 4:39 am
Subject: Re: [ap-gto] #APCC - V1.9 Tracking Error

Then re-ran PHD with the new curve.

The RA doesn't drift now like it did previously. I see a couple of arc-seconds of plus/minus movement but still better than before.

--
Roland Christen
Astro-Physics

5961 - 5980 of 86399