Date   

Re: Encoder mount guiding with model active

Chris White
 

Wow.  Extremely cool.  Thank you. 


Re: Encoder mount guiding with model active

Roland Christen
 

The number at the bottom of the chart is in seconds, so for approx. 900 second run the Dec had one correction, the RA had 4. Correction pulse was sent only when the error exceeded 0.3 arc seconds. So, for many many guide cycles no corrections were sent, and then only occasionally.

Rolando

-----Original Message-----
From: Chris White <chris.white@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 1, 2021 6:19 am
Subject: Re: [ap-gto] Encoder mount guiding with model active

I'm not familiar with Maxim, so cant decipher the charts... but about how often do you find you are sending a guide pulse?  I.e.- With the encoder are you requiring a guidecorrection every few captures, or just rarely?  1600mm FL is pretty awesome to be able to run unguided. 

--
Roland Christen
Astro-Physics


Re: GTO vs AE/AEL data #Absolute_Encoders

George
 

Christopher,

 

You both need more counterweights to improve performance.   See:

https://www.astro-physics.info/tech_support/accessories/mounting_acc/balance-to-optimize-guiding.pdf

 

Regards,

 

George

 

George Whitney

Astro-Physics, Inc.

Phone:  815-222-6538 (direct line)

Phone:  815-282-1513 (office)

Email:  george@...

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Christopher M
Sent: Wednesday, September 1, 2021 10:46 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] GTO vs AE/AEL data #Absolute_Encoders

 

Thank you Mr Christen.  That helps me understand the benefits and differences of each of your Mach 2 and 1100 non-AE mounts which are similarly priced.  If I may summarise my understanding:  A Mach 2 w built in AE, will provide DYNAMIC wind resistance with the AE feedback system, while a larger and similarly priced 1100 non-AE will provide MECHANICAL wind resistance through its larger gear/drive system.  An 1100 non-AE can later be upgraded to AE to then provide both mechanical AND dynamic wind resistance.  I suspect that the 1100 w AE dynamic response would be a bit slower than the Mach 2's response with its faster motors (based on slew speed).  Is that correct?  Would the Mach 2's dynamic feedback then be even faster (ie tighter) at higher power supply voltages since its slew speeds are faster with them?

Wind resistance is important to me as my worst case is a long setup at over 55" from front of dew sheild to back of camera, and live on the prairies here in Alberta where still nights with clear skies are few and far between and no permanent observatory.  At just under 40# for my setup, it shows as being well within the Dec weight and inertial moment graph of the Mach 2, but I assumed that graph was for "general" loads, and does not factor in wind resistance.
Top photo for fun is my friend John's "ultimate wind resistance"package of a RedCat51 on his AP900.

And my (new to me) imaging package of an AP130EDT w an 8300 based camera on, yes, a G11, which has the wind resistance of a piece of tissue paper.  Note that I started with a much smaller setup so I didn't notice wind issues until I put this together.  (roll eyes)


Re: GTO vs AE/AEL data #Absolute_Encoders

Christopher M
 

Thank you Mr Christen.  That helps me understand the benefits and differences of each of your Mach 2 and 1100 non-AE mounts which are similarly priced.  If I may summarise my understanding:  A Mach 2 w built in AE, will provide DYNAMIC wind resistance with the AE feedback system, while a larger and similarly priced 1100 non-AE will provide MECHANICAL wind resistance through its larger gear/drive system.  An 1100 non-AE can later be upgraded to AE to then provide both mechanical AND dynamic wind resistance.  I suspect that the 1100 w AE dynamic response would be a bit slower than the Mach 2's response with its faster motors (based on slew speed).  Is that correct?  Would the Mach 2's dynamic feedback then be even faster (ie tighter) at higher power supply voltages since its slew speeds are faster with them?

Wind resistance is important to me as my worst case is a long setup at over 55" from front of dew sheild to back of camera, and live on the prairies here in Alberta where still nights with clear skies are few and far between and no permanent observatory.  At just under 40# for my setup, it shows as being well within the Dec weight and inertial moment graph of the Mach 2, but I assumed that graph was for "general" loads, and does not factor in wind resistance.
Top photo for fun is my friend John's "ultimate wind resistance"package of a RedCat51 on his AP900.

And my (new to me) imaging package of an AP130EDT w an 8300 based camera on, yes, a G11, which has the wind resistance of a piece of tissue paper.  Note that I started with a much smaller setup so I didn't notice wind issues until I put this together.  (roll eyes)


Re: Encoder mount guiding with model active

Chris White
 

I'm not familiar with Maxim, so cant decipher the charts... but about how often do you find you are sending a guide pulse?  I.e.- With the encoder are you requiring a guidecorrection every few captures, or just rarely?  1600mm FL is pretty awesome to be able to run unguided. 


Re: GTO vs AE/AEL data #Absolute_Encoders

Chris White
 

On Tue, Aug 31, 2021 at 08:24 PM, ap@... wrote:
So if I understand (and I maybe do not) the AP1100 production is done, you missed that. I think 1600’s are next, maybe then Mach 2 again, and that list is usually long.   So my GUESS is you will get a Mach 2 call before the AP1100 call, by months at least, and neither until next year.
I was actually on the list for the 1100 from last year but declined purchase in January when my name came up. I had just purchased a 900GTO and to be honest it is an exceptional mount and does everything I need it to.  I'm actually hoping that my name doesnt come up again for another year or more as I will be moving to darker skies and building a house where I can build a bigger observatory and have a second pier... so thankfully no rush on my end!

Going to the doctor is like the dentist.  My teeth are always fine until I go to the dentist... then I end up with a cavity.  Causation or correlation?


Re: APPM Run vs Plate Solve and Recal

Bill Long
 

APPM solving using ASTAP has been great. I did nothing to the settings either. Built a model at 0.87"/px and 0.6"/px and both times it worked like a champ. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <iogroups@...>
Sent: Tuesday, August 31, 2021 7:47 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APPM Run vs Plate Solve and Recal
 
> Ray, I did review the images from the failed solves.  The images from the failed solves will solve if I use
> ASTAP directly.

Geoff, APPM just starts ASTAP with the settings you have configured on APPM's tab. Either way, ASTAP is doing the plate solving, not APPM.

In my testing, ASTAP seemed to be a very finicky plate solver. Tweaking the settings can make or break plate-solving an image.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Geoffrey Collins via groups.io
> Sent: Tuesday, August 31, 2021 6:30 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM Run vs Plate Solve and Recal
>
> Ray, I did review the images from the failed solves.  The images from the failed solves will solve if I use
> ASTAP directly.
>
> The 30+ model run finished fine with only a failed couple of solves due to a tree obstruction.  I need to adjust
> the horizon limit a little more.  Right after I finished the 30+ point run I started a 178 point run.  The plate solves
> failed other than maybe the first.
>
> The next few nights I did not try another model run. I just imaged.
>
> Tonight I tried a 178 point run and it is working perfectly.  I have the settle time set to 10 seconds.  I assume
> this is terribly excessive, but I am just going to let it run and finish.
>
>
>
> On the night of the 26th, the near full moon had risen by the time I started the second run.  Do you think that
> was the problem with that attempt and the previous attempts that week?  I assume ASTAP would solve the
> same way APPM would solve.  I certainly am using ASTAP in APPM on most attempts and on my 2 current
> successful runs.  Anyway, I am glad to be able to use full frame and 1x1 through NINA.
>
>
>
> Can I send you the results of the run so you can tell me how much flexible etc I have?
>
>







Re: APCC move axis question

Andy Ermolli
 

Here are the zipped files. 

I copied all the logs just to be safe but the ones that matter are the one with time stamp around 8:11pm on 8/31/21
I had to use google drive because the APCC file is too large to attach to this message. I have also attached a screenshot showing the box for "Enable tracking correction" checked. I believe that is where I turn on tracking correction generated by the pointing model, correct?

https://drive.google.com/drive/folders/1oISK-px7Lr5F3j5JGzA6veCu9dCt98T8?usp=sharing


Re: APPM Run vs Plate Solve and Recal

Ray Gralak
 

Ray, I did review the images from the failed solves. The images from the failed solves will solve if I use
ASTAP directly.
Geoff, APPM just starts ASTAP with the settings you have configured on APPM's tab. Either way, ASTAP is doing the plate solving, not APPM.

In my testing, ASTAP seemed to be a very finicky plate solver. Tweaking the settings can make or break plate-solving an image.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Geoffrey Collins via groups.io
Sent: Tuesday, August 31, 2021 6:30 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Run vs Plate Solve and Recal

Ray, I did review the images from the failed solves. The images from the failed solves will solve if I use
ASTAP directly.

The 30+ model run finished fine with only a failed couple of solves due to a tree obstruction. I need to adjust
the horizon limit a little more. Right after I finished the 30+ point run I started a 178 point run. The plate solves
failed other than maybe the first.

The next few nights I did not try another model run. I just imaged.

Tonight I tried a 178 point run and it is working perfectly. I have the settle time set to 10 seconds. I assume
this is terribly excessive, but I am just going to let it run and finish.



On the night of the 26th, the near full moon had risen by the time I started the second run. Do you think that
was the problem with that attempt and the previous attempts that week? I assume ASTAP would solve the
same way APPM would solve. I certainly am using ASTAP in APPM on most attempts and on my 2 current
successful runs. Anyway, I am glad to be able to use full frame and 1x1 through NINA.



Can I send you the results of the run so you can tell me how much flexible etc I have?


Re: APPM Run vs Plate Solve and Recal

Geoffrey Collins
 

Ray, I did review the images from the failed solves.  The images from the failed solves will solve if I use ASTAP directly. 

The 30+ model run finished fine with only a failed couple of solves due to a tree obstruction.  I need to adjust the horizon limit a little more.  Right after I finished the 30+ point run I started a 178 point run.  The plate solves failed other than maybe the first. 

The next few nights I did not try another model run. I just imaged.  

Tonight I tried a 178 point run and it is working perfectly.  I have the settle time set to 10 seconds.  I assume this is terribly excessive, but I am just going to let it run and finish.

On the night of the 26th, the near full moon had risen by the time I started the second run.  Do you think that was the problem with that attempt and the previous attempts that week?  I assume ASTAP would solve the same way APPM would solve.  I certainly am using ASTAP in APPM on most attempts and on my 2 current successful runs.  Anyway, I am glad to be able to use full frame and 1x1 through NINA.

Can I send you the results of the run so you can tell me how much flexible etc I have?


Re: APCC move axis question

Andy Ermolli
 

Yep I am sure but I will redo it later and post. Sorry about not using the APCC log zipper, I wasn't aware that it existed.


Re: APCC move axis question

Ray Gralak
 

Andy,

Are you sure you have the correct log file? I don’t see any of the tracking rate debug output. In fact, the log indicates there is no tracking rate correction.

And can you please use the APCC Log Zipper instead of the ASCOM log zipper? You can run the APCC log zipper from APCC's tool menu.

Thanks,

-Ray

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

Here are my most recent logs. I tried move axis with NINA and tracking corrections enabled in APCC.
I pushed each direction button for about 15 seconds. The move axis speed was set to 3 degrees per second.
NINA 64 bit 1.11 nightly #135.
AP Mach1 GTOCP3 with V2 chip. The mount did not move.


Re: GTO vs AE/AEL data #Absolute_Encoders

ap@CaptivePhotons.com
 

Chris wrote:

 

  • > Once you go ahead and get on both lists, you can celebrate with a nice dinner where someone will offer desert of Apple Pie or Ice Cream.  You will be prepared for this choice, and quickly say: Both.
  • The good news is, I put my name on both lists earlier this summer!  So... now onto more important discussion:  Pie or cake? 

_._,_._,_

So if I understand (and I maybe do not) the AP1100 production is done, you missed that. I think 1600’s are next, maybe then Mach 2 again, and that list is usually long.   So my GUESS is you will get a Mach 2 call before the AP1100 call, by months at least, and neither until next year.

 

You might want to call and check, they may not tell you precisely when, but they will probably give you a rough idea. I’m guessing you have a little more time to do the analytical modeling based on desert choices before you have to actually say “yes” to either mount.

 

With the exception of Apple pie, which I usually take over most anything, I would say “Cake”.  Well, if “both” is not an option.

 

The good news is that even despite Covid, we generally do not need to be on a waiting list months long to get desert.  😊

 

The bad news is that I have a physical coming up, and I have not been on a waiting list for desert.  

 

Linwood


Re: GTO vs AE/AEL data #Absolute_Encoders

Chris White
 

On Tue, Aug 31, 2021 at 08:39 AM, ap@... wrote:
Once you go ahead and get on both lists, you can celebrate with a nice dinner where someone will offer desert of Apple Pie or Ice Cream.  You will be prepared for this choice, and quickly say: Both.
The good news is, I put my name on both lists earlier this summer!  So... now onto more important discussion:  Pie or cake? 


Re: APCC move axis question

Andy Ermolli
 

Here are my most recent logs. I tried move axis with NINA and tracking corrections enabled in APCC.
I pushed each direction button for about 15 seconds. The move axis speed was set to 3 degrees per second. NINA 64 bit 1.11 nightly #135. 
AP Mach1 GTOCP3 with V2 chip. The mount did not move.


Re: APCC move axis question

Dale Ghent
 

Certainly a good data point. Thanks Brent.

NINA's polar alignment plugin uses MoveAxis() because it's the only way to move a specific axis of the mount without another axis also moving by some mysterious (to the app) amount. Such things might happen with SlewToCoordinates() and pointing models or other such stuff in the mix.

On Aug 31, 2021, at 15:57, Brent Boshart <bboshart@...> wrote:

If this is helpful to the conversation, I have done extensive testing with APCC 1.9 with my Mach2 using the Moveaxis command with software I am working on. My software is satellite tracking at significant magnification so I am expecting precise responses from Moveaxis commands. Programming through the RS232 to the mount firmware (no APCC, no ASCOM), I get excellent responses with the :RR and :RD commands (moveaxis). Using APCC 1.9 and ASCOM, I get the same excellent responses using the ASCOM moveaxis command with "Enable Pointing Correction" checked only. If I check "Enable Tracking Correction" I get unexpected responses from the moveaxis command. For my application only pointing correction is important to me so I can tracking correction off. Another observation, if I turn sidereal tracking off (in the case of a geostationary satellite) then the position coordinates displayed no longer have pointing correction applied - this appears to be by design though.


Re: APCC move axis question

Brent Boshart
 
Edited

If this is helpful to the conversation, I have done extensive testing with APCC 1.9 with my Mach2 using the Moveaxis command with software I am working on. My software is satellite tracking at significant magnification so I am expecting precise responses from Moveaxis commands.  Programming through the RS232 to the mount firmware (no APCC, no ASCOM), I get excellent responses with the :RR and :RD commands (moveaxis).   Using APCC 1.9 and ASCOM, I get the same excellent responses using the ASCOM moveaxis command with "Enable Pointing Correction" checked only.  If I check "Enable Tracking Correction" I get unexpected responses from the moveaxis command.  For my application only pointing correction is important to me so I can turn tracking correction off.  Another observation, if I turn sidereal tracking off (in the case of a geostationary satellite) then the position coordinates displayed no longer have pointing correction applied - this appears to be by design though.


Encoder mount guiding with model active

Roland Christen
 

Hi All,

Per our recent discussions, I had a chance to image last night under fair to good seeing (3 out of 5 to 4 out of 5 on Clear Sky Chart). I'm doing 20 minute exposures, in this case M13, to test guiding with a model active. The settings are as follows:

Mount - Mach2 Encoder mount
Scope - 10 inch F6.3 Mak-Cass astrograph, 1600mm focal length
Model points - 8 points each on 2 Dec lines on either side of the object.
Guide settings - 5 second guide exposures, 0.02 sec (0.3 arc sec) Min move
Guider scale -  0.95 arc sec per pixel

The mount is not precisely polar aligned, so there is drift in both axes as the object moves toward the western horizon. The measured drift at the midpoint of my imaging session was 24 arc sec per hour RA and 60 arc sec per hour Dec. The model created a curve that compensated for this drift, and without guiding the 20 minute exposures had approximately 0.75 arc second drift error. Without the model the Dec would have drifted 20 arc seconds in a 20 minute period.

Adding the guider into the loop increases the accuracy somewhat, depending on the seeing. Last night varied a bit but was generally good until the object was down in the western sky at midnight. Below are some guide results along with guider settings that I was using. With .02 sec Min Move the system will only send a correction pulse when the guide star has exceeded 0.3 arc seconds of error. On perfect nights (which are extremely rare here) I can set the Min Move to .01 sec (0.15 arc sec) and can have guide graphs with well under 0.1 rms guide errors. On average to poor nights I set the Min Move to 0.03 seconds.

I hope this gives a bit of insight into the different ways you can set up your guiding during an imaging session. If polar alignment is good, and you are not far from the zenith, and your focal length is short, you might be able to get decent results without any kind of guiding. If you want better precision, then guiding by itself can produce good results. In my case I'm testing the resolution capabilities of a 1600 mm focal length instrument and want to have as tight a guiding as possible. In that case I'm willing to spend a bit of time creating a quick model so that the guider only has to tweak the guide star every once in a while.

First and second images show the settings and results of a typical 20 minute exposure. The 3rd image shows a 20 minute unguided exposure with just the model running.

Roland










20 minute unguided exposure:


--
Roland Christen
Astro-Physics


Re: APCC move axis question

Ray Gralak
 

The APCC log you provided does not include any moves with tracking correction enabled.

So, please redo the test with tracking correction enabled and provide logs for both APCC and ASCOM. You do not need to perform tests with tracking correction disabled.

Also, as part of the test, press and hold the East and West buttons for several seconds each so that APCC has time to query RA and Dec values for several seconds in the log.

Thanks,

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Tuesday, August 31, 2021 9:05 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray, yes the mount moved in all directions when I turned off the model correction. When I turned it back on
the mount did not move.

With the correction on, the driver was showing a custom rate but apcc did not register any movement and the
mount did not move.




Re: GTO vs AE/AEL data #Absolute_Encoders

Jeff B
 

Interesting and thanks Roland.  

Jeff

On Tue, Aug 31, 2021 at 11:53 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
If you are under-mounted the encoders may not help much. They won't respond to high frequency vibrations but will damp out low frequency motions and always bring the axes back to the commanded positions.

Rolando



-----Original Message-----
From: Jeff B <mnebula946@...>
To: main@ap-gto.groups.io
Sent: Tue, Aug 31, 2021 10:36 am
Subject: Re: [ap-gto] GTO vs AE/AEL data #Absolute_Encoders

Thanks Roland, I'm a visual user for now and there are sometimes some vibrations while focusing, which, if the system is bouncy enough, can make focusing at high power a bit challenging, especially if it's a sort of high frequency ringing.   I was just wondering if the encoders might effectively dampen some of the jiggles.  

Jeff

On Tue, Aug 31, 2021 at 11:22 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
When you focus manually you are moving the camera. Ideally the focuser drawtube moves exactly back and forth and never side to side. However, the world is not ideal, sooo you will get some star motions but not necessarily axis motions. The encoder cannot pick up camera motion, only axis motion.

Also, the disturbance is at the end of a long moment arm and will always be somewhat erratic, so the encoders are chasing random motions that are coming fast and furious. When you let go of the focus knob and lock the focuser back down, then things settle and the guide star should appear on the same pixel again - unless locking down the focuser shifts the camera sideways a tiny amount. Again the encoders cannot pick this up either.

Practically speaking, I try not to focus manually while the camera is taking an image.

Rolando



-----Original Message-----
From: Jeff B <mnebula946@...>
To: main@ap-gto.groups.io
Sent: Tue, Aug 31, 2021 8:33 am
Subject: Re: [ap-gto] GTO vs AE/AEL data #Absolute_Encoders

Yes, a great description Roland and thanks.  Now if the encoders are engaged, do they also respond similarly to vibrations induced when manually focusing?  Curious.

Jeff

On Tue, Aug 31, 2021 at 8:39 AM ap@... <ap@...> wrote:
Chris White wrote:
 
  • I've been flipping a coin about going with a Mach2 or an 1100GTO (Non-AE) for a while now, and the coin has not landed yet.  Since I dont expect to get a really big scope (Happy with my 130 and Edge 925) I'm likely leaning towards the M2.  Your description has been helpful to describe the real benefit of Encoders. 
 
Deciding by careful analysis, mathematical simulations, a bit of game theory.  Throw in some non-parametric probability theory to maximize the expected benefits….
 
Then ignore it all and do the obvious:  Both.
 
In all seriousness, unless that’s a magic coin, it’s not like you can get both at once anyway.  Take the one you can get first, use it while waiting on the second, you can always then switch easily as you would not have trouble selling the first if you decided, with that experience, you want the other, or if not, give up your place in line for the other for someone else.  Or by then you might actually want both.
 
Once you go ahead and get on both lists, you can celebrate with a nice dinner where someone will offer desert of Apple Pie or Ice Cream.  You will be prepared for this choice, and quickly say: Both.
 
😊
 
Linwood
 
 
 
 
 
 

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

9921 - 9940 of 90472