Date   

Re: Mach2 with CP five jiggling while tracking

Brent Boshart
 

I had/have the same issue with my Mach2.  Roland sent me some APCC commands to help dampen the encoders.  It affected both axes for me.  I thought it was totally solved but have since seen some remaining "judder" after a fast slew - I need to make further adjustments with commands. It takes up to 30 seconds to settle.  This is with a C8 mounted so no where near the limit of the Mach2. Before the APCC commands,  it took a while to even settle after a dither while tracking.  


Re: Mach2 with CP five jiggling while tracking

Jeffc
 



Here’s the video of the oscillation in RA.  It’s kinda short.  I’d like to acquire more data/info for troubleshooting.  


Btw… this Mach2 is unguided.   In this case it is almost like the goto for the moon overshoots a bit.. then corrects and the correction overshoots, and it continues. 

Back in September I had a similar problem when doing the gotos while building the model.   The image would have short lines for the stars.  Not all points in the model had this problem , but I didn’t see any pattern such as close the horizon , specific part of the sky, etc. 

I’m not using any auto guiding with the Mach2.  (Been thinking about it for longer exposures tho.)

At the time, I was using the latest APPC etc. (I don’t have the version handy — it’s on the other computer, but can get it if needed.)

-jeff 

On Nov 7, 2021, at 11:27 AM, Jeffc via groups.io <jeffcrilly@...> wrote:

I have the same issue.   

I found if I slightly imbalance the RA (move counterweights down) the problem is mitigated.   Also fwiw I’m using a 12” SCT which I think is just at the limit of the Mach2. 

However, I discovered this back in late September and have only had the mount out for a short session in October.  

During the October session I was trying to image the moon.  I did a goto to the moon, then noticed on the live video the moon flopping back and forth.   I had the patio lights on and could see the RA oscillating a few degrees.   I tried to capture this on a smartphone video but it’s not noticeable. 

I’ll upload a video of the moon flopping when I find it.  

(I had some conversation with Roland on this but I haven’t followed up on my part as I wanted to gather more info.)

-jeff


On Nov 7, 2021, at 9:44 AM, Allen Ruckle <aruckle@...> wrote:



Last night while setting up my telescope for Astro photography I noticed, while trying to calibrate PhD 2,  I noticed the stars were short dashes in the east west axis. I had started the telescope up using the V2 ASCOM driver and I had started PhD, as I started PhD2 looping I noticed all the stars in the frame were dashes which I then tried to calibrate to see if that would alleviate the problem, however it would calibrate on the dashes as if they were stars.
      I then checked the image  from the main camera, the stars seem to be jumping back-and-forth. I then connected the hand controller to see if that would calm anything down, no luck, so all I could do to proceed by turning off the APV 2 ASCOM driver and PhD 2 and run the telescope unguided, under only the control of the hand pad.

it was as if the tracking was the result of two systems fighting for control.

has anyone seen this issue before with the Mach2 p, and corrected the problem.

thank you for any help you can provide
aruckle


Re: Mach2 with CP five jiggling while tracking

Jeffc
 

I have the same issue.   

I found if I slightly imbalance the RA (move counterweights down) the problem is mitigated.   Also fwiw I’m using a 12” SCT which I think is just at the limit of the Mach2. 

However, I discovered this back in late September and have only had the mount out for a short session in October.  

During the October session I was trying to image the moon.  I did a goto to the moon, then noticed on the live video the moon flopping back and forth.   I had the patio lights on and could see the RA oscillating a few degrees.   I tried to capture this on a smartphone video but it’s not noticeable. 

I’ll upload a video of the moon flopping when I find it.  

(I had some conversation with Roland on this but I haven’t followed up on my part as I wanted to gather more info.)

-jeff


On Nov 7, 2021, at 9:44 AM, Allen Ruckle <aruckle@...> wrote:



Last night while setting up my telescope for Astro photography I noticed, while trying to calibrate PhD 2,  I noticed the stars were short dashes in the east west axis. I had started the telescope up using the V2 ASCOM driver and I had started PhD, as I started PhD2 looping I noticed all the stars in the frame were dashes which I then tried to calibrate to see if that would alleviate the problem, however it would calibrate on the dashes as if they were stars.
      I then checked the image  from the main camera, the stars seem to be jumping back-and-forth. I then connected the hand controller to see if that would calm anything down, no luck, so all I could do to proceed by turning off the APV 2 ASCOM driver and PhD 2 and run the telescope unguided, under only the control of the hand pad.

it was as if the tracking was the result of two systems fighting for control.

has anyone seen this issue before with the Mach2 p, and corrected the problem.

thank you for any help you can provide
aruckle


Re: Auto meridian flips with SGP

Marcelo Figueroa
 

The latest beta version of APCC allows to set a time window for the flip so that SGP can run it without conflict between the two. Personally I have not tested it, I am waiting for the final version (not beta).
 
In the meantime I simply disable the meridian limits option in APCC and let SGP do it all on its own, it works perfect.


Mach2 with CP five jiggling while tracking

Allen Ruckle
 

Last night while setting up my telescope for Astro photography I noticed, while trying to calibrate PhD 2,  I noticed the stars were short dashes in the east west axis. I had started the telescope up using the V2 ASCOM driver and I had started PhD, as I started PhD2 looping I noticed all the stars in the frame were dashes which I then tried to calibrate to see if that would alleviate the problem, however it would calibrate on the dashes as if they were stars.
      I then checked the image  from the main camera, the stars seem to be jumping back-and-forth. I then connected the hand controller to see if that would calm anything down, no luck, so all I could do to proceed by turning off the APV 2 ASCOM driver and PhD 2 and run the telescope unguided, under only the control of the hand pad.

it was as if the tracking was the result of two systems fighting for control.

has anyone seen this issue before with the Mach2 p, and corrected the problem.

thank you for any help you can provide
aruckle


Re: APPM Model sanity check (suggestion)

Tom Zepf
 

That is an interesting addition to the NINA Plugin. The Ground Control plugin with PushOver support is great too. Thanks Dale!

If I have a "single target night", I might use that instead of generating a whole model. I was experimenting last night and found that I could build my 52 point model (20° increments with my wonky horizon)  easily in the time between nautical and astronomical twilight, so I may just stick with that. One thing that did take me by surprise is that it looks like APPM parks the scope when finished so I had to add another instruction to unpack the scope later on so imaging would succeed.

   Tom


Re: APPM Model sanity check (suggestion)

ap@CaptivePhotons.com
 

Dale Ghent wrote:

So I created a new sequencer instruction for my AP mount plugin for NINA called "Create Dec Arc Model". It will get the RA and dec of the current target and have APPM create a model plan based on that info. You would place this instruction at the start of a target's run so that a dec-arc model is created and put in place prior to getting down to business.
Now that's intriguing. Your prior one, to build a whole sky model automates a function I would do infrequently enough building manually was no real task. But this sounds short enough to include, especially in the early part of the evening before full dark, and build a target specific one and just do it routinely.

This cooperative effort between NINA and APPM is starting to look even better.

On a related note, last night I ran about 9 points of the verify with pointing/tracking on and off against an old model. It was a bit of a mixed bag... most points were substantially further off in the "off" mode (like 0.9" vs 0.3" as kind of an eyeball estimate), but a few were slightly worse with the model on. Bear in mind the model was made weeks ago on a portable rig, so the whole idea was to see if it remained valid, so the answer may be a definite "sort of maybe" and "needs a better test run". I was in a hurry last night.

Some night with a lot of moon or other reason not to image, I may build a much larger model to test against, but really for how I image, Dale's automation and Ray's Dec Arc may be a much more elegant solution. Generally I do not need to know about the whole sky, just a tiny portion of it.

(Skeptic in me has to add: if I even need that, guided accuracy is so good, this all may be moot; those that do not guide YMMV).

Linwood


Re: Auto meridian flips with SGP

Tom Zepf
 
Edited

I have struggled with this a great deal as well. This may not the best configuration for your circumstance, but the following screenshots of APCC and SGPro settings work reliably for me now.

I could be off-base, but I believe *not* checking the box to send updates to SGPro and allowing counterweight up slews were what finally got this working. There seems to be some sort of race condition I could never work around.

In my case, I am using a meridian limits file I tweaked in an editor to just be a simple 2 degree limit east and west, but this should work with any set of limits. Be aware, if you aren't, that SGPro cannot do a meridian flip "underneath" the pole. But this configuration is rare and will cause the scope to stop tracking in that case, so it should fail safe.

I did spend a great deal of time using the very useful ASCOM Sky Simulator to debug this in daylight hours. https://sourceforge.net/projects/sky-simulator/

Now, because I'm a glutton for punishment, I'm working on replicating my workflow in N.I.N.A. which seems much more flexible, speedy, and has developers actively working on it.

Good luck and clear skies!

   Tom











Re: Concrete pier

Howard Ritter
 

Thanks for the report of your experience, Clif. It certainly supports Nick Iversen’s suggestion of a wooden pier, and would greatly simplify things as well as drastically lower the cost. A wooden pier in concrete would also make the un-doing of it easier if we ever decide to sell the house.

How did you secure the mount to the posts?

—howard

On Nov 7, 2021, at 9:33 AM, Arnold C. Ashcraft <wa2guf@...> wrote:

I have a pier in my observatory that was installed in 2001. It consists of four 6 ft long 4x4’s of pressure treated yellow pine posts fastened together with timber-lock screws and liquid nails to make a composite pier that is 7 inches square. I dug a hole about 18 inches in diameter and 3-1/2 ft deep, put about 4” of gravel in the bottom and placed the wooden pier on top of the gravel. I then filled the hole up to ground level with concrete and built my observatory around it. The observatory is a simple 6’x8’ structure with a fold off roof and the raised floor not touching the pier at any point. There is no appreciable vibration of the pier and it has remained solid without any problem for 20 years, supporting my 10” Meade fork mount and the C11 fork mount reliably over the years.

Note that when I bought the 4x4 posts back in 2001, the chromated copper arsenical pressure impregnant (CCA) was still legal. It was banned in 2003 for uses involving human contact and has been replaced by alkaline copper quaternary (ACQ), copper azole (CA) or micronized copper azole (MCA). The posts you buy in Home Depot are treated with one of these safer impregnants. They are supposed to last a long time in contact with the soil, but I don’t know if they last as long as the CCA treated wood.

Clif Ashcraft, NJ, USA




Re: APCC Pro Error FindFreeQacindex: no free entries!

David Johnson
 

Thanks


Re: Concrete pier

Arnold C. Ashcraft
 

I have a pier in my observatory that was installed in 2001. It consists of four 6 ft long 4x4’s of pressure treated yellow pine posts fastened together with timber-lock screws and liquid nails to make a composite pier that is 7 inches square. I dug a hole about 18 inches in diameter and 3-1/2 ft deep, put about 4” of gravel in the bottom and placed the wooden pier on top of the gravel. I then filled the hole up to ground level with concrete and built my observatory around it. The observatory is a simple 6’x8’ structure with a fold off roof and the raised floor not touching the pier at any point. There is no appreciable vibration of the pier and it has remained solid without any problem for 20 years, supporting my 10” Meade fork mount and the C11 fork mount reliably over the years.

Note that when I bought the 4x4 posts back in 2001, the chromated copper arsenical pressure impregnant (CCA) was still legal. It was banned in 2003 for uses involving human contact and has been replaced by alkaline copper quaternary (ACQ), copper azole (CA) or micronized copper azole (MCA). The posts you buy in Home Depot are treated with one of these safer impregnants. They are supposed to last a long time in contact with the soil, but I don’t know if they last as long as the CCA treated wood.

Clif Ashcraft, NJ, USA


Re: Time change today...

Patrick Spencer
 

Hi Tom,

The exact same thing happened to me this morning. My mount is in a remote observatory, so I can't just step outside and reset Park 3 using the clutches. I followed the procedure Ray outlined in this post back in May:

https://ap-gto.groups.io/g/main/message/78466

Worked like a charm.

Patrick Spencer


Re: Concrete pier

Nick Iversen
 

I don't have any experience with pole piers. But for a Mach1 and 130mm refractor I can't image them flexing much. I should go and observe some telephone poles in the wind. But vibration - why do you think a pole would vibrate? What frequencies? I have a wooden Berlebach tripod which is made of much less wood than a pole. I can't image a pole being less steady than that.


Auto meridian flips with SGP

Peter Bresler
 

I have yet to program a successful auto meridian flip with SGP. Should APCC meridian be set to execute a flip? What should the telescope settings in SGP be? An ancillary problem is that if PHD2 guiding is set in SGP, and the guide star is lost, the sequence aborts.


Time change today...

Tom Blahovici
 

I was imaging until 3 am this morning and if course the time changed back to Eastern standard Time. I then did a Park 3 and the mount is clearly one hour off.
So how does one correct for this?
Do I just change time in apcc and do a sync?
Tom


Re: APPM Model sanity check (suggestion)

Dale Ghent
 

Ack! I didn't realize that imgur reduced the video resolution to potato mode. Here's a better view:

https://youtu.be/OoJCp6sZhuo

On Nov 7, 2021, at 02:38, Dale Ghent <daleg@...> wrote:


I meant to get this rolling sooner, but life threw me a curveball last month. Thanks to Ray's additions to the upcoming APCC Pro 1.9.1.x, there's now an easy way to programmatically feed model creation parameters to APPM so that it can produce a model plan using that also considers the other things you might have configured in APPM - horizons, limits, ordering strategy and so on.

So I created a new sequencer instruction for my AP mount plugin for NINA called "Create Dec Arc Model". It will get the RA and dec of the current target and have APPM create a model plan based on that info. You would place this instruction at the start of a target's run so that a dec-arc model is created and put in place prior to getting down to business.

It'll currently create 3 arcs - 1 centered on or (or at least very near) the target's declination, and 2 additional arcs - one on the north side and the other on the south side of the target's declination, separated from the center arc by a configurable number of degrees. Point density along the arcs, in the RA, is another parameter that can be tuned. The arcs will begin (ie, their eastern-most extent) slightly before the target's current hour angle and extend to the configured minimum altitude or the western horizon limit, whichever is hit first. Obviously it's quite advantageous to use your local horizon limits in order to cut down on pointless (ha ha) map points.

Below is a short video of me futzing around with the new code. In it, I select a target in Stellarium (the CA nebula) and import it into NINA's Framing Assistant. I then create a target session using a small sequence template I made that has just the "Create Dec Arc Model" instruction in it. I then run that sequence. With debug logging on, the APPM configuration gets quoted in NINA's log file, so I copy and pasted that config into its own text file and loaded it into APPM to look at the point map. Presto, there's a 3-arc wide dec model based on the CA nebula's location at that time. Obviously this would all be automatic in practice, with a temporary config file being made and fed to APPM directly... this just lets me debug at each step as I work on the code.

I'll put some more polish and testing on it over the next days. If any NINA user here is interested in trying it out, see me on the NINA Discord chat.

https://i.imgur.com/jU1UQTa.mp4

On Nov 6, 2021, at 15:35, Ray Gralak <iogroups@...> wrote:

Hi Linwood,

Or... am I just crazy to consider reusing a model after a tear down and reassembly?
You could do a simple test to find out! Specifically, you could do a Verify run in APPM with a much smaller number of points than your model. That is, a Verify run does not have to use the same points as your active model. When you do this, take a look at the measured pointing errors in the table that APPM creates in the verify run.

BTW, in case anyone is wondering, there are two main differences between a normal APPM run and a verify:

1) The Verify run keeps the active model on, while a normal run would have modeling off.

2) The Verify run will not replace your active model. That is, APPM won't ask to load it into APCC, and APPM will even warn you if you try to load a verify run.

Also, a verify run will probably be much less useful if you are checking a few Dec Arc rows, because it wouldn't take much longer to create new Dec Arcs.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Saturday, November 6, 2021 8:33 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM Model sanity check (suggestion)

The discussion on refreshing reminds me to ask this.

I set up and tear down nightly, but fairly precisely in the same setup (example: I usually land within 5' of polar
aligned after I put things together).

I have built a nice model of the sky, but for just time constraints (and I guide) I do not build a new model each
night, and because I worry the model is no longer good, I generally do not use one at all.

I know that APPM has a verify process, that will check each model point for consistency (presumably to flush
out equipment variability that may be invalidating it from run to run).

Would it be possible to have a similar process, perhaps a "model sanity check", which would take 10% (or
some specified number of model points), and check just those. The idea is to see if your model is still good
but in far less time than a complete verify run (which basically takes the same time it would to build a model).

I am not sure how to interpret it, but some kind of correlation calculation could tell you if it looks good or bad,
and is worth using. The idea is spending 10 minutes to validate a fairly large model rather than 60-90 minutes
to build a new one.

Or... am I just crazy to consider reusing a model after a tear down and reassembly?

Linwood









Re: APPM Model sanity check (suggestion)

Dale Ghent
 

I meant to get this rolling sooner, but life threw me a curveball last month. Thanks to Ray's additions to the upcoming APCC Pro 1.9.1.x, there's now an easy way to programmatically feed model creation parameters to APPM so that it can produce a model plan using that also considers the other things you might have configured in APPM - horizons, limits, ordering strategy and so on.

So I created a new sequencer instruction for my AP mount plugin for NINA called "Create Dec Arc Model". It will get the RA and dec of the current target and have APPM create a model plan based on that info. You would place this instruction at the start of a target's run so that a dec-arc model is created and put in place prior to getting down to business.

It'll currently create 3 arcs - 1 centered on or (or at least very near) the target's declination, and 2 additional arcs - one on the north side and the other on the south side of the target's declination, separated from the center arc by a configurable number of degrees. Point density along the arcs, in the RA, is another parameter that can be tuned. The arcs will begin (ie, their eastern-most extent) slightly before the target's current hour angle and extend to the configured minimum altitude or the western horizon limit, whichever is hit first. Obviously it's quite advantageous to use your local horizon limits in order to cut down on pointless (ha ha) map points.

Below is a short video of me futzing around with the new code. In it, I select a target in Stellarium (the CA nebula) and import it into NINA's Framing Assistant. I then create a target session using a small sequence template I made that has just the "Create Dec Arc Model" instruction in it. I then run that sequence. With debug logging on, the APPM configuration gets quoted in NINA's log file, so I copy and pasted that config into its own text file and loaded it into APPM to look at the point map. Presto, there's a 3-arc wide dec model based on the CA nebula's location at that time. Obviously this would all be automatic in practice, with a temporary config file being made and fed to APPM directly... this just lets me debug at each step as I work on the code.

I'll put some more polish and testing on it over the next days. If any NINA user here is interested in trying it out, see me on the NINA Discord chat.

https://i.imgur.com/jU1UQTa.mp4

On Nov 6, 2021, at 15:35, Ray Gralak <iogroups@...> wrote:

Hi Linwood,

Or... am I just crazy to consider reusing a model after a tear down and reassembly?
You could do a simple test to find out! Specifically, you could do a Verify run in APPM with a much smaller number of points than your model. That is, a Verify run does not have to use the same points as your active model. When you do this, take a look at the measured pointing errors in the table that APPM creates in the verify run.

BTW, in case anyone is wondering, there are two main differences between a normal APPM run and a verify:

1) The Verify run keeps the active model on, while a normal run would have modeling off.

2) The Verify run will not replace your active model. That is, APPM won't ask to load it into APCC, and APPM will even warn you if you try to load a verify run.

Also, a verify run will probably be much less useful if you are checking a few Dec Arc rows, because it wouldn't take much longer to create new Dec Arcs.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Saturday, November 6, 2021 8:33 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM Model sanity check (suggestion)

The discussion on refreshing reminds me to ask this.

I set up and tear down nightly, but fairly precisely in the same setup (example: I usually land within 5' of polar
aligned after I put things together).

I have built a nice model of the sky, but for just time constraints (and I guide) I do not build a new model each
night, and because I worry the model is no longer good, I generally do not use one at all.

I know that APPM has a verify process, that will check each model point for consistency (presumably to flush
out equipment variability that may be invalidating it from run to run).

Would it be possible to have a similar process, perhaps a "model sanity check", which would take 10% (or
some specified number of model points), and check just those. The idea is to see if your model is still good
but in far less time than a complete verify run (which basically takes the same time it would to build a model).

I am not sure how to interpret it, but some kind of correlation calculation could tell you if it looks good or bad,
and is worth using. The idea is spending 10 minutes to validate a fairly large model rather than 60-90 minutes
to build a new one.

Or... am I just crazy to consider reusing a model after a tear down and reassembly?

Linwood





Re: New AP1100 Guiding Great on Very Windy Night

ap@CaptivePhotons.com
 

For comparison tonight it is far more windy than anticipated.  Average is about 7mph, erratic, gusts to 20-23mph.  My 1100AE is carrying a 4" refractor so not a big sail like my C11 would be.  So far I'm running at 0.67" RMS with peaks at 1.4/1.48" and the stars are round at 100% (not completely so at 200%). 

The graph looks awful compared to a calm night, but it is coping reasonably we.. 



Here's what the wind has been like since I started: 



That's measured about 3' off the ground beside the scope.  Here's a small crop at 100% (1.4"/pix scale): 



I don't know how much of this is the encoders reacting, how much is just that it is well built, but very happy.  I got the encoders to do better in wind (since our dry season is more windy than the wet, ironically). 

Very happy. 

Open to suggestions of guiding parameters for wind.  I think I'm chasing the wind tonight with the settings, frankly, but hoping it will die down.  Normally I get around 0.2-0.25" average at 3s intervals. 

Wind is still the enemy, but I am more prepared than I used to be with the new AP mount.  Thank you!

Linwood


Re: APPM Model sanity check (suggestion)

ap@CaptivePhotons.com
 

Ray Gralak wrote:

You could do a simple test to find out! Specifically, you could do a Verify run in APPM with a much smaller number of points than your model. That is, a Verify run does not have to use the same points as your active model. When you do this, take a look at the measured pointing errors in the table that APPM creates in the verify run.
I had no idea, that's exactly what I was looking for. I just assumed the 'verify' had to rerun exactly the same points that built it.

Thank you!

Linwood


Re: How often do people refresh their All-Sky Pointing Model? (Observatory)

Worsel
 

Chris

I gen a new model every 6 months.  That occurs more frequently than any of the other events in your list.

Bryan

4141 - 4160 of 86825