Date   

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


Re: Mach2 Problem with RS232 Connections.

Ray Gralak
 

Stacey,

The reason I am asking is to test APCC's configuration. It's possible that both:

1) USB-serial port driver has an issue.
2) APCC is set up incorrectly.

If could try this test:
1) Start the test from a powered OFF state.
2) Turn the mount on.
3) Start APCC manually, but do not configure it to connect to the ASCOM driver.
4) Connect to the mount and let it run for 5-10 seconds, even if you see errors.
5) Close APCC.

Find the latest APCC log file and post it here. You can find APCC logs here:

C:\ProgramData\Astro-Physics\APCC\Logs

-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 8:34 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Mach2 Problem with RS232 Connections.

No, CP4 is in another observatory. I would be a LITTLE easier to take the CP5 over to the other observatory and
try it there. I assume this won't change any settings on that system???? I'd rather not disturb a working system
and think this is a longshot, though since the USB driver port doesn't work either and that's an entirely different
setup. Would there be any reason to redo the firmware on the CP5???

-Stacey
.


Re: Backlash issue or something else?

Roland Christen
 


At some point it starts making a dec correction and things keep getting worse, almost like the corrections were moving in the wrong direction.
The wrong direction is caused by very high friction somewhere in the geartrain. It's called retrograde motion and is caused by static friction which builds up and finally breaks loose. I suspect that the center spur gear that you tightened is way too tight and you will need to back it off slightly. Spur gears must have a slight clearance between the teeth, otherwise they will cause this reverse motion.

Roland


-----Original Message-----
From: Tom Carrico <tom@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 2:28 am
Subject: [ap-gto] Backlash issue or something else?

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



--
Roland Christen
Astro-Physics


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

Roland Christen
 

That looks perfect. No need for a new PEM curve. The PEM compensation is doing exactly as it should, it is removing the slight 2 arc sec wiggle in the RA tracking rate.

Bottom line, the mount runs very accurately and the only reason for the remaining drift is due to slight polar misalignment, telescope flex, atmospheric refraction, etc. In order to remove this drift, you either use modeling with APCC or guiding. So the next thing is to make a new model and try this same test with PEM ON again. Theoretically the model will compensate for the drift in the two axes whether PEM is on or off, but it only eliminates the drift and not the 2 arc sec periodic error that you see in your first run with PEM off.

I hope this makes sense to you. There should be no interaction between the model and PEM. They are as separate as the Moon is from Mars. There is no reason why having PEM on would cause the drift to come back, unless somehow when you turned PEM on, you might have inadvertently also turned off the model. Ray might be able to illuminate this further.

So for a final test, try making a model and doing this same PHD test again. With the model active and PEM turned on, you should get a flat line for both RA and Dec for at least 10 minutes, if not more.

Roland


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

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

Stacey Mills
 

No, CP4 is in another observatory.  I would be a LITTLE easier to take the CP5 over to the other observatory and try it there.  I assume this won't change any settings on that system????  I'd rather not disturb a working system and think this is a longshot, though since the USB driver port doesn't work either and that's an entirely different setup.  Would there be any reason to redo the firmware on the CP5???

-Stacey
.  


Re: Mach2 Problem with RS232 Connections.

Ray Gralak
 

Hi Stacey,

Have you tried connecting APCC to your 1600 with CP4 using the same computer and cable(s)?

-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 7:55 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Mach2 Problem with RS232 Connections.

Flow control is "none." I should add that I have a 1600 mount with a CP4 so I've been down this road before. The
fact that neither of the RS232 ports on the CP5 works with multiple cables/PC ports AND the USB connection
doesn't work with properly setup driver sounds like a CP5 issue.

-Stacey


GTO vs AE/AEL data #Absolute_Encoders

RogerM
 

Hi folks:

I posted a similar question in CN; after a few responses I realized I might have to come to the source. 

Here is my question:

I currently own a 900GTO, have a 2018 AP1100 arriving soon and also a AP1100AEL due late this year, do you have any data from either PI or other source, that the actual FWHM or Eccentricity values were tighter/better with the encoders?

 

I would like concrete data at the image not PHD2 graphs which are meaningless anyway...

 

If you did see improvement: At what scale and what seeing conditions it took to see the improvement?

Thanks so much for your time and wisdom,

Roger M


Re: Mach2 Problem with RS232 Connections.

Stacey Mills
 

Flow control is "none."   I should add that I have a 1600 mount with a CP4 so I've been down this road before.  The fact that neither of the RS232 ports on the CP5 works with multiple cables/PC ports AND the USB connection doesn't work with properly setup driver sounds like a CP5 issue.

-Stacey


Re: Mach2 Problem with RS232 Connections.

michaeljhanson@...
 

Hi Stacy,

9600 baud, 1 stop bit, 8 data bits, and no parity are all correct.  In addition, please make sure handshaking is set to "none".

Regards,
Mike Hanson  


Mach2 Problem with RS232 Connections.

Stacey Mills
 

I got my Mach2 a couple of days ago!  What a thing of beauty.  However, I've encountered a problem.  Although the ethernet connection works perfectly, the RS232 connections do not.  With either of the CP5 RS232 ports or the USB->RS232 port I can connect to the mount, but it reports partially strange data such as going into "Lunar" tracking and changing my track/slew settings.  It won't accept commands to park/unpark and throws "no response" COM errors in APCC.  I've tried the supplied RS232 cable and several others that I have on different ports on my RocketPort RS232 board.  I know the RocketPort board works because I've used a null modem to talk from one port to another using test software. That plus the fact that the USB connection works exactly the same way (connects but doesn't function) makes me think there's an internal problem in the CP5 with RS232.  As I said, the ethernet connection works perfectly.  I don't see anything in the CP5 manual about baud rates but my com ports are defaulted to 9600, 8 data bits, 1 stop bit, no parity.

-Stacey  


Re: ISS Tracked using APCC Pro v1.9

Ray Gralak
 

Hi Dan,

you using apcc standard or do you need pro? my club has an AP1200 with a cp3. Be fun to image it with the clubs
C-14.
Real-time RA/Dec is supported for both APCC Standard and Pro, but you your APCC license must be dated August 1, 2020 or later. If
your license is dated earlier than that you would have to purchase a "subscription renewal", which is $50 for APCC Standard.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Daniel Marcus
Sent: Thursday, August 26, 2021 5:19 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] ISS Tracked using APCC Pro v1.9

you using apcc standard or do you need pro? my club has an AP1200 with a cp3. Be fun to image it with the clubs
C-14.

Dan


________________________________

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of jimmyjujames <jimmy_an@...>
Sent: Thursday, August 26, 2021 7:04 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] ISS Tracked using APCC Pro v1.9


That is a very good first try with poor seeing.
Looks like we will be getting some ISS pass movies from Astro-Physics scopes this year.
Thank you for your time and SkyTrack software.

https://heavenscape.com/
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fheavenscape.com%2F&data=04%7C01%7C
%7Cf6479935b25c47583b0508d968e5db07%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6376561586
89945170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
I6Mn0%3D%7C1000&sdata=ceQ%2BmaP2VYDZHMw%2BBmZe1H2%2FpmeIu7EGU1r4h1LsAdM%3D&reserved
=0>

Jimmy
Wisdom comes to those who seek it.


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

Ray Gralak
 

Rouz,

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.
Again, just eye-balling your screenshot, it looks like PE is now worse. Maybe you need to invert the curve?

If you created a new PEC curve and uploaded it to the mount that might take 40+ minutes. So, unless you slewed RA back to near where you did your earlier measurement, the RA drift will likely measure differently. You cannot reliably compare drift between two logs unless the hour angle and declination are similar.

That said, as expected, there is an insignificant change in drift between PEM on and off, which indicates that PEM does not cause residual drift.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Rouz
Sent: Saturday, August 28, 2021 2:40 AM
To: main@ap-gto.groups.io
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.

6461 - 6480 of 86888