Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2


W Hilmo
 

189 points.

Can I do dec-arc modeling with the current APPM version? Is it as simple as making a model with just a bunch of points on my target's declination? Or do I need to wait for the next CP4 firmware and accompanying APCC release to use it?

Also, are you and the AP folks thinking about automating the modeling process? It would be very cool to have automation run a script at the start of the sequence to build the dec-arc model specifically for that target.

Thanks,
-Wade

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Friday, April 23, 2021 7:15 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

How many sky data points?

10-minute exposures at 0.88 arc-sec/pixel may be a challenge without Dec-Arc modeling.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of W Hilmo
Sent: Friday, April 23, 2021 6:51 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and Pegasus
Astro UPBv2

My mount is an AP1600GTO-CP4 with Absolute Encoders. The scope is an
AP130GTX. The camera is a
QSI690-wsg8 at 0.88 arc seconds per pixel. I'm doing 10 minute exposures.

On the next full, clear night, I'll do the "Model 5x and Park". Since
my camera as a built-in OAG, it's just a coupe of check boxes to guide
(and when I do, stars are perfectly round), but I want to see how far I can go with unguided imaging.

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray
Gralak
Sent: Friday, April 23, 2021 6:35 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and Pegasus
Astro UPBv2

Hi Wade,

Question for Ray: Would it be interesting to validate the current model before making a new one?
Remind me, which scope, image scale, and exposure duration are you using?

If you are going to do a validate, you would want to do a "Model 5x
and Park", which is an option in APPM. This will repeat the points five times and then park. This provides a measure of pointing accuracy and repeatability.
For instance, if something is loose or optics are moving, variations from each pass may indicate this.

After doing this, you would have to send your logs and PNT files to Howard or me for analysis.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of W Hilmo
Sent: Friday, April 23, 2021 6:16 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and Pegasus
Astro UPBv2

One more update:

tl;dr: Inconclusive.

The last couple of nights has been tough. We had a weather change
and Wednesday night was a loss. Early evening was clouded over, so
when NINA started the run, the centering and focusing failed. I
stopped the sequence, changed the start time to 1:00am and then
started the sequence again. It should have been
clear at 1:00, and it probably was, but the second run of the sequence
failed. Specifically, it didn't unpark the mount.
This is probably my fault, for using the mount while NINA was paused
waiting for time. I suspect that NINA thought that it had already
unparked the mount, but I had manually parked it to avoid it
tracking past the meridian, since my target transited just before
midnight. Anyway, at least I learned a few things
about my automation software. I'll avoid changing the state of the system while NINA is waiting.

Last night was clear, but seriously windy. I have a few subs where
the stars have tails in the RA direction on both sides. I'm
guessing that these were particularly strong gusts, and I'm seeing
the encoder putting the mount back where it belongs. The good news
is that, even though the wind was howling all night long. Only
about 3, out of 48, ten minute exposures show this
behavior. The system in general seems pretty resilient to wind. Once
I get the observatory built, I suspect that I won't have any wind problems.

As far as unguided tracking, I have a few subs with round stars, and
I have lots of them with egg shaped stars, elongated in a different
direction that the RA oscillations I mentioned above. The magnitude
of the elongation seems smaller than it
was before I discovered that refraction correction was disabled.

At this point, it's going to be a few days before we get clear skies
again. I think that I'm going to redo the model for the next run
(and I did verify in the PNT files, that the temperature was correct
at the time I made the current one). I'm using a
portable field pier, so it's possible some settling has occurred (but it's been there for a while).

Question for Ray: Would it be interesting to validate the current model before making a new one?

Thanks,
-Wade

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of
Dale Ghent
Sent: Wednesday, April 21, 2021 2:29 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and Pegasus
Astro UPBv2


Thanks for the update on this.

Wow, so I thought they had fixed this in the past because it was
reported by some NINA users, then I was informed that Pegasus fixed
it. I guess not. I run my own gear in metric all the time so I never
noticed that it actually hadn't been fixed. I just tested on my
UPBv2 and, yeah, the fahrenheit value does
make its way through the ASCOM driver.

Ugh. The hold-up for a fix really validates me putting my foot down and saying "no, get them to fix their bug"
whenever a user asks us to implement a workaround a vendor's bug.
Downstack defects should be addressed directly where they are, and
here's a rather perfect illustration as to why. Getting it fixed
might take longer, but everyone upstream wins in the end. IMO
Pegasus should just press on and issue a fix
because it's critical data that is impacting other apps in an operational way.

I will be very interested to see your refraction-compensated results.
I'm now trying to convince my club to spring for APCC Pro so we can
do unguided imaging on the serviced 1200GTO. Brian's image was a
fantastic example of this, and you A/B'ing with refraction comp.
might help drive home the point if it is indeed
the source of your slight tracking imperfection.

On Apr 21, 2021, at 16:12, W Hilmo <y.groups@hilmo.net> wrote:

I wanted to revisit this topic with an update.

I reached out to Pegasus Astro, and they are aware of the issue
with unit in the temperature value. At this
time, they can’t fix it because SGP apparently has a dependency on
the current behavior. They are reaching out to the SGP folks to see if they can coordinate a proper fix.

Regarding my unguided imaging results, I switched the units back
to metric in the Pegasus Astro software,
and that fixed the incorrect temperature in APCC Pro. I ran
unguided again last night, and it was a slight improvement over the
previous unguided session, but still wasn’t satisfactory. I forgot
to note yesterday that I have my camera oriented so that declination
in up/down in the frame. The elongation is diagonal, and flips 90
degrees after the meridian flip. That means
that the components of drift are not isolated to either axis in particular.

So I went back to take a closer look at the model in APCC. I
played with setting and clearing different terms
to see the effect on the model. When I was doing this, I noticed
that the “Correct for Refraction” checkbox was cleared. When I
checked that box, the east and west scatter plots dropped from 53.35
and 50.20 arc seconds, respectively, to 9.42
and 6.32 arc seconds.

In my head, I assume that drift due to refraction will be aligned
perpendicular to the horizon, instead of being
aligned with one of the axes. If that’s true, then my elongation
might be up/down, relative to the horizon. I’m going to give it
another run tonight and see if I get better
results with refraction correction enabled.

Thanks,
-Wade

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of W
Hilmo
Sent: Tuesday, April 20, 2021 7:10 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and
Pegasus Astro UPBv2

Thanks for the response.

I’m using the latest version of the Pegasus Astro software for the
UPBv2, so it sounds like I need to contact
them regarding the temperature reporting issue. I’ve not yet
confirmed that after switching back to Celcius, that it restores the
unguided accuracy. I should be able to
give that a try tonight.

As for the Advanced Sequencer, I saw it for the first time
yesterday. I was expecting a UI similar to the
original sequencer, which it’s not – but I think that it’s better.
I really like to flexibility. I’m already thinking ahead to when
Astro-Physics updates APCC to support the new few-stars tracking
model that they introduced with the Mach2. It would be really cool
to write a script to sample and plate solve 6 or 8 points along the
target’s declination for unguided imaging, and then
have NINA invoke the script at the start of an imaging session.

-Wade

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of
Dale Ghent
Sent: Tuesday, April 20, 2021 4:34 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Interesting Behavior with APCC Pro and
Pegasus Astro UPBv2

Hi Wade,

You may need to update your Pegasus software to fix this issue.

Older versions of the Pegasus UPBv2 console app and
ObservingConditions driver will relay the Fahrenheit
temperature to downstream consumers such as NINA or APCC when the
console app is set to display units in Fahrenheit.

The ASCOM ObservingConditions interface specification specifies
that the values for its various
meteorological properties must be in SI units (ie, Celsius when it
comes to temperature), so that is what APCC is expecting. Pegasus
issued a fix for this last year so you might just need an update
unless they’ve reintroduced the bug in a
recent version.

This issue was even more obvious to those who have NINA set to
convert the SI units too imperial for
display. This caused NINA to convert the Fahrenheit temperature to
Fahrenheit again, resulting in some outlandish temperature values being reported.

Aside from that, your description is quite an interesting
depiction of how much temperature can alter the
tracking of the mount under a model, though. Glad you were able to
work out the cause. Hope you like the Advanced Sequencer, too. It is
of course a work in progress but it’s
maturing nicely.


On Apr 20, 2021, at 00:35, W Hilmo <y.groups@hilmo.net> wrote:

I've been doing some unguided imaging with my AP1600 w/Absolute
Encoders and APCC Pro and have seen
some interesting behavior with unguided imaging.

The first few nights that I run unguided after building a model of
about 180 points, everything was great. I
was blown away by how well it worked. The last few nights, not so
much. I am seeing elongated stars and some image drift over the course of the night.

I do not believe that this is flexure. I'm imaging with my
AP130GTX, and I've double checked all
connections.
I've double checked to make sure that the pointing model is enabled.
I verified that the polar alignment is still spot on. It's a bit
difficult to troubleshoot because, without guiding, there aren't any
log files to examine. All I have are the
subs that I can inspect.

Since we're getting into more moonlight, I've done some software
updates (switched to the daily builds for
NINA so that I can use the advanced scheduler). I've also set up
for doing tonight's run with the guider enabled so that I can get
some logs. As I was watching the session get started, I noticed
something odd. Specifically, I noticed that APCC reported the
temperature at over 40 degrees C, which is very wrong. I
am using the Pegasus Astro Ultimate PowerBox v2 as the weather sensor.

It occurred to me that I made a change to the Pegasus software a
few days ago to change from reporting the
temperature in C, to reporting the temperature in F. It looks like
both APCC and NINA are reporting the Fahrenheit value as Celcius. I
am wondering if the significantly incorrect temperature
interpretation has effected the model such that it's lost accuracy.
I have reverted the Pegasus software back to reporting in C, and
after tonight's run, I'm going back to unguided operation to
see if I get that great result back that I was getting the first couple of nights.

-Wade



















Join main@ap-gto.groups.io to automatically receive all group messages.