Date   

Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray:

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

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

Linwood


Re: APCC move axis question

Ray Gralak
 

Linwood,

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

-Ray

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

Ray said:

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

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

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

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

I just tried a trivial example:

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

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

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

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

Linwood

PS. Logs available if desired from that brief test.





#ASCOM_V2_Driver #ASCOM_V2_Driver

 


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


Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray said:

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

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

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

I just tried a trivial example:

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

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

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

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

Linwood

PS. Logs available if desired from that brief test.


Re: GTO vs AE/AEL data #Absolute_Encoders

J. Belden
 

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

Joe Belden


Re: APCC move axis question

Ray Gralak
 

Andy,

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

BTW, changing polar alignment invalidates the model anyway.

-Ray

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

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


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

Ray Gralak
 

Hi Rouz,

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

-Ray

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

Here is the Model.



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

Andrea Lucchetti
 

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

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


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

Rouz
 

Here is the Model.


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

Rouz
 
Edited

Ok some more tests and positive results.

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

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

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

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

Capturing data now.


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

Rouz
 

Clear tonight.

1-Checked PEC file from mount, was ok
2-PHD guide assistant with main scope and PEM ON, near Dec 0 and Meridian, relatively flat (except for drift).
3-Dense model Declination -Graduated Ra density, 128 points, PEM ON
4-Model numbers look reasonable 

5-Slew to Bubble nebula at Dec 62 (within model) 300s subs 

PEM ON, refraction on, Dec arc tracking OFF = elongated stars
PEM ON, refraction off, Dec arc tracking OFF = elongated stars
PEM ON, refraction off, Dec arc tracking ON = elongated stars
PEM OFF, refraction on, Dec arc tracking on = elongated stars





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

Rouz
 

Got them Bill thanks.

I'll use my horizons and make something similar, perhaps a bit denser.

Point order strategy:
Declination - (Equal Ra density) - (Graduated Ra density)  shouldn't matter right?  As long as its not Hour Angle.


-Rouz


Re: GTO vs AE/AEL data #Absolute_Encoders

Chris White
 

It would be interesting to see a comparison between Non AE mount and AE mount, however using my experience with my 900GTO where I regularly guide at around 0.3"/px and EVERY single sub, night after night has tiny pinpoint stars and seeing limited FWHM I can't imagine that an encoder would do any better.... except when it comes to unguided imaging. 

I had a CEM60 and CEM70 prior to buying my 900GTO, and frankly, the GTO blows the doors off the CEM mounts. 

So, I am happy to be corrected, but I think the real benefit of AE is so that you dont need to guide.  If you plan on guiding I dont expect any difference visible (or measurable) in the final data.  That said, I'm also using a 200 point model with APCC as well as PEC correction... so even with my 900GTO I stack the deck in my favor. 

Granted, I have average seeing here in the Northeast, so that's my real limiter for high resolution imaging.  Maybe in NM or Chile you could see a more meaningful improvement when comparing the two mounts. 


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

Bill Long
 

I can send you and export of the points I use if you want them.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Rouz <rbidshahri@...>
Sent: Saturday, August 28, 2021 5:45 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] #APCC - V1.9 Tracking Error
 
Ok Ray, I won't change that variable at this point. Lets see how it performs with the previous PE curve as Roland suggsted.


-Rouz


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

Rouz
 

Ok Ray, I won't change that variable at this point. Lets see how it performs with the previous PE curve as Roland suggsted.


-Rouz


Re: GTO vs AE/AEL data #Absolute_Encoders

ap@CaptivePhotons.com
 

@Roger M wrote:

  • I’m looking for solid data of GTO vs AE/AEL. In other words, at what scale and at what seeing quality do you see an improvement with the absolute encoders vs. a fully guided setup?_._,_._,_

Roger and I corresponded a bit off line as well, and I am curious as well.

The MyT was much better than the CEM70G (even with their revised RA/DEC controller boards), but absolutely I can say that so far my results with the AP1100 are much more consistent than the MyT.  But… is that the heavier, better engineered mount or the encoders (or both, which is my guess).

My main motivation in choosing the encoders was a hope that in the dry season here, which also comes with a bit more wind at night, I would have more ability to image despite the sail I have on my tripod (otherwise known as a C11 with dew shield).  Previously, both CEM70G and MyT, it did not take much wind at all to show up as all sorts of eccentricity issues.  Gusts would show a spiderweb of protrusions from a star; steadier wind would just be ovals.

So my logic (aka rationalization) was I’d rather end up regretting spending extra money not needed than finding my new fancy AP mount did not really improve my wind performance.

I’ve had very few nights out so far, and exactly one of them started with some wind that quickly died down; nothing learned.  Perversely summer here, when everyone would love a breeze, often has nights with 100% humidity and no wind.

To date I have no idea, in calm winds, if I would see any difference (guided) with encoders off and on.  My GUESS is no difference in star visible shape, not sure if measurable.  I base that on endless reports how good non-encoder AP mounts are.  

But when the wind picks up a bit, it will all be worth it if I get another 3-4mph tolerance.  We do not have MUCH wind most winter nights, just too much for the non-encoder mounts that came before. 3-4mph might double the usable nights I get, easily.

So ask me again when (if) I ever get some time with clear nights.

(And yes, observatories, wind shields, all sort of discussions could be had here – but HOA rules and nightly teardowns limit what I can do, let’s please not go there for now).

Linwood


Re: APCC move axis question

Andy Ermolli
 

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


Re: GTO vs AE/AEL data #Absolute_Encoders

RogerM
 

Hi Roland:

Linwood’s data compares a CEM70 vs the 1100AE. I would argue that an AP mount, be a 900GTO or 1100AE should show an improvement in FWHM m/eccentricity over a CEM. 

I’m looking for solid data of GTO vs AE/AEL. In other words, at what scale and at what seeing quality do you see an improvement with the absolute encoders vs. a fully guided setup?

Thanks, Roger M


Re: GTO vs AE/AEL data #Absolute_Encoders

Roland Christen
 


I was hoping for concrete data
Linwood's chart showed concrete data of star sizes. What kind of data are you looking for?

Roland


-----Original Message-----
From: RogerM <rogezeus2003@...>
To: main@ap-gto.groups.io
Sent: Sat, Aug 28, 2021 5:13 pm
Subject: Re: [ap-gto] GTO vs AE/AEL data #Absolute_Encoders

Hi Roland:

Thanks for your reply. I was hoping for concrete data but up to now, nobody has had much of a data set or even a good comparison. I will keep fishing :)

--
Roland Christen
Astro-Physics


Re: GTO vs AE/AEL data #Absolute_Encoders

RogerM
 

Hi Roland:

Thanks for your reply. I was hoping for concrete data but up to now, nobody has had much of a data set or even a good comparison. I will keep fishing :)

6441 - 6460 of 86909