Date   

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

Roland Christen
 

I would have added the 4th harmonic for a better fit.

Roland



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

Ill try to read the CP4 data "from mount".

Here was my previous data, did save the file.

My FWHM values are typically around 2.4". Rarely goes just below 2".

I just manually focused last night without running an AF routine, yes I suspect with smaller FWHM the errors will show up more.

Overall, I'm glad the stars are points now vs streaks as they were previously.

Will work in fine tuning the system soon.

--
Roland Christen
Astro-Physics


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

Rouz
 

Ill try to read the CP4 data "from mount".

Here was my previous data, did save the file.

My FWHM values are typically around 2.4". Rarely goes just below 2".

I just manually focused last night without running an AF routine, yes I suspect with smaller FWHM the errors will show up more.

Overall, I'm glad the stars are points now vs streaks as they were previously.

Will work in fine tuning the system soon.


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

Roland Christen
 

With a scope of this aperture, when the seeing gets good you should get FWHM of 1.2 arc sec, and then you will see the effects of a proper PE correction.

Rolando



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

Measured eccentricity is still acceptable with PEM off at a scale of 0.92 arcsec/pixel.

Subs were 300s, seeing was quite poor and cloudy.


PEC training should tighten that up further I'm sure.

--
Roland Christen
Astro-Physics


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

Roland Christen
 


I ran PEMPRO at near Dec 10 but some 20 to 30 degrees due west. 
It will work there. I'm almost sure that your previous PEMPro run was fine, but it probably did NOT load into the CP4. Therefore the curve in the CP4 did not get changed and may have bogus data in it. Remember, you can make a PEMPro curve without having the mount connected, but you cannot download it without a proper connection - USB or serial.

Roland


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

Roland,

Thank you for the post.
Coming from a mechanical background I appreciate Pempro and PEC.

At this point I'm glad the source of the error seems to have been introduced by the PEM (bogus PEC as you said). I hadn't guessed it was so critical in making the model.

I can now concentrate on that knowing it wasn't PA, mirror shift, focuser sag, etc. (I tightened the focuser reload bearing so much that it cracked!).

A fresh PEC curve was recorded on the previous session but I didn't verify it by playing it back as was running out of dark sky. Will attempt to make another one.




"It must be taken at or near Declination zero (Celestial equator) and at or near the meridian"

Unfortunately Dec 0 at the meridian is not visible and I ran PEMPRO at near Dec 10 but some 20 to 30 degrees due west. 

Will work on making a good PEC next.






--
Roland Christen
Astro-Physics


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

Rouz
 

Measured eccentricity is still acceptable with PEM off at a scale of 0.92 arcsec/pixel.

Subs were 300s, seeing was quite poor and cloudy.


PEC training should tighten that up further I'm sure.


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

Rouz
 

Roland,

Thank you for the post.
Coming from a mechanical background I appreciate Pempro and PEC.

At this point I'm glad the source of the error seems to have been introduced by the PEM (bogus PEC as you said). I hadn't guessed it was so critical in making the model.

I can now concentrate on that knowing it wasn't PA, mirror shift, focuser sag, etc. (I tightened the focuser reload bearing so much that it cracked!).

A fresh PEC curve was recorded on the previous session but I didn't verify it by playing it back as was running out of dark sky. Will attempt to make another one.




"It must be taken at or near Declination zero (Celestial equator) and at or near the meridian"

Unfortunately Dec 0 at the meridian is not visible and I ran PEMPRO at near Dec 10 but some 20 to 30 degrees due west. 

Will work on making a good PEC next.






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

Roland Christen
 

The function of PEM is to remove the small variation of tracking speed in RA. It should not be turned off, rather it should be properly applied.

In a non-encoder mount the tracking rate is not constant, but varies slightly over a period of 6.4 minutes. The variation is due to microscopic worm errors that cause the tracking speed to increase and decrease in a cyclical fashion as the worm turn over that 6.4 minute time span. This results in the stars moving back and forth on your imaging chip, and cannot be "tuned out" with sky modeling in APCC, or by proper polar alignment. In your case it is on the order of 2 to 3 arc seconds, and will manifest itself as a slight back and forth motion of the stars in your image over that time span - and result in oval stars.

PEMPro is a program that can measure this small periodic motion and create a curve that opposes that motion quite precisely so that the tracking speed variation is eliminated. But there are 3 steps that must be followed in applying PEMPro in order to create a meaningful curve that actually works.

1) you must measure the speed variation by allowing PEMPro to gather data over many worm cycles - 3 is the absolute minimum, 5 or more is recommended. each cycle is 6.4 minutes,  so 5 cycles will take about 1/2 hour. The data is not much affected by poor seeing or poor transparency or light pollution etc. None of these matter. What matters most is where in the sky you take this data. It must be taken at or near Declination zero (Celestial equator) and at or near the meridian. That will produce the most accurate data.

2) once the data is taken, you need to create a proper PE curve. For that you need to follow the procedure that is outlined in the software manual. A proper PE curve needs to have the fundamental and all the relevant harmonics in it. The information on how to create a proper curve is readily available and has been discussed for many years here and other places. The curve is then loaded into the CP4 controller and activated by turning PEM to ON.

3) once the curve is in the controller the last and most vital step is to run your mount again in PEMPro for at least 2 or 3 worm cycles to see what the new periodic error looks like. If everything was done correctly, the PE curve should look flat and should have an average value of under 1 arc sec after doing the analysis of the data.

If the result is worse, then something went wrong, perhaps loaded an inverted curve or a mistake in the data analysis. Or perhaps for some reason the curve was not loaded at all which could be due to a faulty connection to the CP4. PEMPro has the ability to store the PE curve on your computer and can bring up the curve that was loaded into the CP4. Almost always when we have a mount that tracks erratically, we discover that there was bogus data in the CP4 PE Memory.

Step #3 is most often not done, but is the most important one. Once you have a properly tracking mount with tracking errors under 1 arc sec for a 6.4 minute worm period, then it's time to add APCC modeling and do unguided imaging. Leaving PEM off is not the best way to accomplish this, especially at your image scale.

I hope you read this and take a moment to understand the importance of PEM when you want to do unguided imaging.

Rolando



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

PEM OFF

Here is a clip with 5 minute subs over a 45 minute period (shooting through the clouds).
200% screen zoom.

--
Roland Christen
Astro-Physics


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

Rouz
 

PEM OFF

Here is a clip with 5 minute subs over a 45 minute period (shooting through the clouds).
200% screen zoom.


Backup port won't "stick" as none, changes to COM3

ap@CaptivePhotons.com
 

Cosmetic nit: 

There is a dropdown option for backup COM port, which in my case defaulted to COM3.  I do not have a backup port wired, as if I lose the LAN my session is kind of hosed anyway, and I changed it to "none".

However, each time I open APCC it changes it back to COM3.  

I assume it should actually stick.

Unless I'm missing a step or something?

Linwood






Re: APPM Run vs Plate Solve and Recal

ap@CaptivePhotons.com
 

Geoffrey Collins wrote:

 

  • On initialization it unparks automatically.  I have it set not to unpark.  I remember from this group that there is a way to prevent automatic unpacking on initialization, but I have not gone back to review that post again.  After initialization during the night, I always unpark in APCC with Park 3 on the park tab rather than picking unpark from last position.

 

I recently tracked both down so while fresh in my mind here’s a screen shot.  Left (from Settings,  Initialize Mount Settings) is for initialization, Park tab is for regular.   On the left the dropdown also has a “don’t unpark” available.  Tracking (or not) is on both also.

 


Re: [FAQ] Using NINA with Astro-Physics mounts

annaski
 

Finally got a clear night and this worked beautifully! Thank you!


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

Rouz
 

Hi Craig,

I just got some 30 to 40 minutes now without any drift for the first time (few pixels). There was no elongation in 300s subs, eccentricity was around 0.4. 
Previously, some stars were almost streaks and would shift a lot from sub to sub.
The clouds have now rolled in and I shut down.

I'll look into that in the next sessions, but at least now I can sleep easy! 
I'm sure it can be fine-tuned from here.


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

Craig Young
 

Hi Rouz,
Were you able to get a graph using PHD (or PEMPRO) that shows the movement of the main camera over the long exposure time?  What we want to make sure is that the tracking is actually moving in one direction and the elongation not due to something else like atmospheric or optical distortion of some sort.  The final image is an integration of the stellar flux over a period of time.  We need to see how the tracking is doing at much shorter time intervals.
Craig


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

Rouz
 
Edited


Now with 7 x 300s = 35 minutes. The star has moved 1.05 pixels.

This is a model with PEM off and tracking of PEM off (Dec priority).

All corrections are ON (Model, Refraction, Dec-arc).

I'm assuming it was PEM and hopefully don't need to make a model with points 1 degree apart.

But that's the only parameter that changed (PEM) this session. I just decreased the Ra spacing from 5 to 4 degrees which shouldn't have such a large impact.

I'm assuming the PEC wasn't right. The factory curve was a couple of years old and my new recording must have not been very accurate either due to the mediocre seeing that night or curve parameters I set.


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

Rouz
 
Edited

Ok look's like I got something!

Made another model slight tighter. 1 degree in Dec and 4 in Ra.

But this time I turned PEM off for both APPM and image capture.

The target stopped moving.

I now see 1-2 pixel shift in random directions from 1 300 sec frame to the next.

After 20 minutes of 300s subs, a star moved some 2-3 pixels.

I think the PEM was the cause.

The model is not very practical and would require too many points at this spacing (thousands maybe).

The clouds rolled in but I got 6 x 300s subs with minimal shift.


- Rouz


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

Rouz
 

Dominique,

Yes


-Rouz


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

Dominique
 

Hi Rouz,
I could not this information, but with corrections (All) and without corrections it drifts in an identical way?

Dominique


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

Rouz
 

Ok, Ray had mentioned at some point to have points much closer together than my previous model.

Made a model tonight concentrating either side of the Dec of the target with the points are very close together.  1 degree for Dec - 5 degrees in Ra.

The mode scatter graph also looks good.

I tried all combinations like model correction on - Dec arc and refraction corrections on and off.  Also tried PEM on vs off.

Target still moves in 1 direction at a slower pace. about 45 degrees diagonal. Eccentricity is about 0.5 to 0.6 for 300s subs and 0.92" image scale. 




Re: APPM Run vs Plate Solve and Recal

Ray Gralak
 

Geoffrey,

 

> The mount accuracy/RMS without the model is still great but not as good as it was when I had a model with only 32

> points.  Pointing with the model was perfect.  Now it is a little off.

 

All-sky modeling has not changed between 1.8.8.17 to 1.9.0.1 so whatever difference you are seeing is in the data you are collecting. If you are using a different plate solver, for instance, accuracy will be different.

 

> the error log solved max solve time exceeded but maybe I didn’t look in the correct place.

 

APPM should report an error. If you are using ASTAP I explained how to find the error in a previous post to you. Here is that information again:

 

"If you haven't already, you can prevent APPM from deleting the FITS image by saving failed images as shown in the screen shot below. Then look for the file with the same name as the fits file but with an “.INI” extension. Open that file and look for a line that says “WARNING=” and that should contain the reason for the failed plate solve."

 

 

-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 24, 2021 8:29 PM

> To: main@ap-gto.groups.io

> Subject: Re: [ap-gto] APPM Run vs Plate Solve and Recal

>

> Ray,

>

> I can plate solve and the pointing is spot on for that particular point from then on.  If I try do do a mapping run the

> plate solves fail.  I can stop the mapping run at any point and do a plate solve that will solve.  I assume I have

> something is set up wrong in the mapping run.  But I could do a mapping run before the update.

>

>

> 2s is the settle time.

>

> I did try the high accuracy slew tonight.

>

> The plate solve when I press the Plate Solve or Plate Solve and Recal button is fractions of a second.  The max

> solve time is currently set to 35 seconds.

>

> the error log solved max solve time exceeded but maybe I didn’t look in the correct place.

>

> The mount accuracy/RMS without the model is still great but not as good as it was when I had a model with only 32

> points.  Pointing with the model was perfect.  Now it is a little off.

>

>

>


Re: APPM Run vs Plate Solve and Recal

Geoffrey Collins
 

Ray,

I can plate solve and the pointing is spot on for that particular point from then on.  If I try do do a mapping run the plate solves fail.  I can stop the mapping run at any point and do a plate solve that will solve.  I assume I have something is set up wrong in the mapping run.  But I could do a mapping run before the update.  


2s is the settle time.

I did try the high accuracy slew tonight. 

The plate solve when I press the Plate Solve or Plate Solve and Recal button is fractions of a second.  The max solve time is currently set to 35 seconds.

the error log solved max solve time exceeded but maybe I didn’t look in the correct place.  

The mount accuracy/RMS without the model is still great but not as good as it was when I had a model with only 32 points.  Pointing with the model was perfect.  Now it is a little off.

 

8381 - 8400 of 88738