Date   

119FSA attachment

Pete Mumbower
 

Just wondering as I prepping to mount my 1100GTO. I have removed the old CGE-Pro from the pier and getting ready to mount the 119FSA adapter and wondered if everyone used all 8 1/4-20 bolt positions on the ring? For the last few months I figured just 4 in the outer corners, but now I am figuring why not just toss bolts into them all. Or is that just overkill? If it is, sure would save my arm some soreness from drilling and tapping four more holes...

Thanks,
Pete


Re: GTOCP4 Caps

Joe Zeglinski
 

Hi Mike,
 
    If anyone still has the original CP4 released WHITE case – consider drilling the two bottom corner holes, as Tony (a.k.a.  Harley-Davidson) shows in his CP4 video.
 
    My original, like yours,   i.e. the initial release batch’s CP4,  also did NOT have drainage holes, so when the circuit board inside  drowned,   in dew about an inch deep inside - probably from seeping past the exposed Ethernet socket edges.
  I had the original  CP4 board replaced, but unwisely re-installed back into that original-run WHITE case. Who knew what would happen,  again?
    A few outdoor sessions after arrival, the second CP4 board also drowned during a normal night’s use, inside the same CP4 case, ( which is always protected when not in use). That’s when I discovered that the first run CP4 cases were NOT like my old CP3 WHITE case, which DID  have drain holes, and drain plugs were provided in the old days.
 
    The MAIN mistake was replacing the original CP3 on top of the AP-1200 mount, with the new CP4, fully “reposed” there to the dew.
Finally, the now third circuit board is still fine – after AP drilled the two case holes  for me, and I have now silicone-sealed the edges of the panel’s Ethernet socket, for added protection.   The User Guide now strongly advises to NO LONGER use any  old mount’s  upper axis attachment position for a CP4 or later, but rather have it vertically  side-mounted - which is somewhat less prone to dew entry.
    It is those “seemingly trivial oversights”  that gets one in trouble.
 
    I did NOT insert those conical rubber drain plugs from the Kit – why would I ? There never have been any bugs,. not even tiny mites, inside my  old case for nearly a decade, completely exposed in the backyard gardens, and there won’t be, up here in the Ontario wilds. Perhaps the USA southern states have more aggressive bugs seeking a cozy upscale electronics nest. I suppose one could just periodically  pull out the provided rubber stoppers, to drain out any accumulated dew.
 
    Just kidding – tongue in cheek. VERY MUCH pleased with my newest CP4  controller, now high & dry, properly “bolted vertically” on the pier’s sidewall.
 
Joe
 

From: M Hambrick
Sent: Friday, April 23, 2021 9:05 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] GTOCP4 Caps
 
To Joe:

I believe I read or saw somewhere (Maybe Tony's video) that plugging the holes will keep bugs out. This would only be a factor for those who leave their mount set up in a permanent observatory. Interestingly enough, my GTOCP4 (purchased in 2017) has no drain holes in the bottom. I am going to have to go back and watch Tony's video again.

To Ken:

You are correct. The part number that Mouser is sending me is RM15TRD-C(71). It has the correct thread size (M20 X 2). When I entered the other part number (without the "D") in the Mouser search bar it must have brought up the one with the D in it, and I didn't notice. My apologies for any confusion.

Mike


Re: APPM model how many points portable?

ap@CaptivePhotons.com
 

Sounds like it is more measuring the accuracy of the mount and closed loop slew than the plate solving.

 

I would think you want to take a FITS image and plate solve with ASTAP and compare the answer to other plate solving programs.  Except of course you would need to try a bunch of FITS images in different parts of the sky, probably at different focal lengths, with different amounts of distortion, different image scales.

 

Then try to figure out which plate solver is the more authoritative when they all disagree with each other.

 

I thought about trying it, grabbed an image and tried PI and AStAP, but I saw all the associated data (not just center coordinates and PA) and decided I wasn’t competent to compare.   L

 

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jim Grubb via groups.io
Sent: Friday, April 23, 2021 11:03 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM model how many points portable?

 

Here is my proposed experiment to measure accuracy of different plate solvers.

 

1. Choose a star (A) mag ~9, plate solve, re-sync, and then slew back to it.  (in SkyX they call this closed loop plate solving)

 

2. Choose a second star (B), say 30ºs away, slew to it, plate solve, re-sync, and then slew back to it.

 

3. Slew back to star A, plate solve, re-sync, and slew back to it. Then use a tool to measure the difference between the center of the screen (reticle crosshair), and where the star actually is after the closed loop slew.

 

4. Repeat steps 1-3 a number of times to get an average error.

 

5. Repeat the experiment with each plate solver and compare the average error.

 

Does this sound like a sound experiment?

Jim


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




















Re: APPM model how many points portable?

Jim Grubb
 

Here is my proposed experiment to measure accuracy of different plate solvers.
 
1. Choose a star (A) mag ~9, plate solve, re-sync, and then slew back to it.  (in SkyX they call this closed loop plate solving)
 
2. Choose a second star (B), say 30ºs away, slew to it, plate solve, re-sync, and then slew back to it.
 
3. Slew back to star A, plate solve, re-sync, and slew back to it. Then use a tool to measure the difference between the center of the screen (reticle crosshair), and where the star actually is after the closed loop slew.
 
4. Repeat steps 1-3 a number of times to get an average error.
 
5. Repeat the experiment with each plate solver and compare the average error.
 
Does this sound like a sound experiment?

Jim


Re: GTOCP4 Caps

Karen Christen
 

Hi Joe,

 

In addition to Mike’s comments regarding bugs, I would add that some folks use their astro equipment in desert-like settings where dew is not a significant problem, but dust is.  Hence the cone-shaped plugs.  We try to think of everyone in our designs.

 

Karen

AP

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joe Zeglinski
Sent: Thursday, April 22, 2021 10:09 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] GTOCP4 Caps

 

Question to the group.

 

    Can anyone think of a logical  reason to plug “drainage holes”  with those rubber cones?

Do we really want to make sure that any dew or other source of moisture  leaking into the controller, should be kept inside? 

The only thing I can think of is to keep any itsy-bitsy bugs out – but then why drill the two holes into the case, in the first place?

Perhaps that is covered somewhere in the user guide :-)

 

Joe

 

From: M Hambrick

Sent: Thursday, April 22, 2021 8:50 PM

Subject: Re: [ap-gto] GTOCP4 Caps

 

Hi Pete

Those cone shaped plugs are used to plug the drain / vent holes in the bottom of the GTOCP4 housing. Tony (a.k.a. Harley Davidson) made an excellent video a couple years ago about the need to have drain holes in the housing to allow condensate to drain out.

Mike


--
Karen Christen
Astro-Physics


Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

Ray Gralak
 

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




















Re: Powering Remote Imaging Systems

Howard Hedlund
 

George runs a Shuttle fanless in his observatory.  AP has one in our observatory, and there is another one in our office.  All 3 have been absolutely flawless.  I haven't looked at the newer versions.  These are already 5 (?) years old. 


Re: AP1100 park position question

Jack Huerkamp
 

Don,

 

It should be adequate.  A friend of mine used a single 1000 Newton DL2 for his observatory and he had a Meade 14 on a Celestron CGX mount.  It worked well.  I opted for a dual column and I placed the colums with their long dimensions in the East-West position for additional lateral stability.  That worked well when I had a CGX mount and a 10” RC on top.  When I switched to the AP1600 with Lunt 152 and VRC-16, and all the needed 180# of counterweights, I exceeded the lifting capacity of the dual 1000 Newton system.  It still worked but I wanted it to have a positive factor of safety as well as longevity.  So I went with the 2500 Newton columns.  There was not a substantial price difference in the columns.  What does change is the speed of lift.  It use to take about 20 seconds to fully elevate the 1000 Newton columns.  The 2500 Newton columns take over 40 seconds.  Not a big difference, especially once the columns are elevated, they are generally left elevated until I close up for the night.

 

Also, you can make sure the columns are synchronized.  You lower them fully and they stop moving.  You then depress the down button again and you will see a slight dip and rebound in the columns.  That is them resetting.  This keeps them in sync.

 

Yours truly,

 

Jack

 

Jack Huerkamp

Jack's Astro Accessories, LLC

38388 Pine Street

Pearl River, LA 70452-5192

985-445-5063

mallincamusa@...

www.mallincamusa.com

30.37N  89.76W

 

All of us get lost in the darkness.
Dreamers learn to steer by the stars.

………………………………….Neil Peart

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Don Anderson via groups.io
Sent: Thursday, April 22, 2021 3:44 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100 park position question

 

Thanks for the info Jack. I would be lifting an AP900 with a 5" refractor and associated guide and finder scopes, cameras and controllers. All told about 90 lb. I may at some point get a 10" or 12" CDK or a larger 160 -175mm refractor. This may push the total weight to maybe 120lb or so. Would a 1000 be good enough? Is there much of a price difference between them?

Don

 

Don Anderson

 

 

On Thursday, April 22, 2021, 12:39:42 p.m. MDT, Jack Huerkamp <mallincamusa@...> wrote:

 

 

Don,

 

Note that the DL2 is available in three thrust capacities – 1000 Newton, 1500 Newton and 2500 Newton (220#, 333# and 555#).  I am using a dual column system so I went from a 440# lifting capacity to a 1111# lifting capacity.

 

Yours truly,

 

Jack

 

Jack Huerkamp

Jack's Astro Accessories, LLC

38388 Pine Street

Pearl River, LA 70452-5192

985-445-5063

mallincamusa@...

www.mallincamusa.com

30.37N  89.76W

 

All of us get lost in the darkness.
Dreamers learn to steer by the stars.

………………………………….Neil Peart

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Don Anderson via groups.io
Sent: Wednesday, April 21, 2021 7:34 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100 park position question

 

Thanks for the info Jack. I suspected as much. I checked ebay and they don't show and DL2s right now. I will have to keep my eyes open for one.

 

Don Anderson

 

 

On Wednesday, April 21, 2021, 07:51:02 a.m. MDT, Jack Huerkamp <mallincamusa@...> wrote:

 

 

Don,

 

When I purchased the original pair of lifting columns from Linak, I was over the engineering department of the local public works department in New Orleans and we did a lot of custom fabrications for all of our facilities.  As such, I was able to have them sell me two 1000 Newton columns and the associated controls.   Since I was already an established customer, I was able to get an upgraded set of 2500 Newton columns and associated controls last year.

 

I do not think Linak sells to the general public.

 

Yours truly,

 

Jack

 

Jack Huerkamp

Jack's Astro Accessories, LLC

38388 Pine Street

Pearl River, LA 70452-5192

985-445-5063

mallincamusa@...

www.mallincamusa.com

30.37N  89.76W

 

All of us get lost in the darkness.
Dreamers learn to steer by the stars.

………………………………….Neil Peart

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Don Anderson via groups.io
Sent: Tuesday, April 20, 2021 11:47 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100 park position question

 

Jack

Did Linak sell direct to you?

 

Don Anderson

 

 

On Tuesday, April 20, 2021, 09:36:40 p.m. MDT, Jack Huerkamp <mallincamusa@...> wrote:

 

 

Christopher,

 

The company is Linak out of Kentucky and the columns I used were the DL2 2500 Newton rated.  My original ones were rated at 1000 Newtons each when used with a non AP mount.  With the AP1600 and 150# of equipment on the dual column setup, I changed to the 2500 Newton thrust each – 5000 Newton total thrust.

 

DL2: Robust lifting column for desks, workstations and kitchens (linak-us.com)

 

Yours truly,

 

Jack

 

Jack Huerkamp

Jack's Astro Accessories, LLC

38388 Pine Street

Pearl River, LA 70452-5192

985-445-5063

mallincamusa@...

www.mallincamusa.com

30.37N  89.76W

 

All of us get lost in the darkness.
Dreamers learn to steer by the stars.

………………………………….Neil Peart

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Christopher Erickson
Sent: Tuesday, April 20, 2021 10:09 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100 park position question

 

Lymax columns. A lot cheaper to buy Lymax off of Ebay or wherever and make your own telescoping pier.


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

 

On Tue, Apr 20, 2021, 9:27 AM Worsel via groups.io <bryancashion=yahoo.com@groups.io> wrote:

Shailesh

I have used Park 4 for several years for exactly the roof height issues that you are evaluating.  This is for a 1100 mount with a 14 CDK scope.  There have been no problems.

I have a PierTech height adjustable pier (http://piertechinc.com/telescope-piers/).  When I need to tinker with equipment, I lower the mount and move it to P3, where it clears the roof. To remove equipment, I loosen the clutches (older style 1100) and rotate/lower the OTA to a separate support table before loosening the dovetail.  I normally leave the pier at almost max height, in order for the roof to clear on opening.

The adjustable piers are actually from another company, but I have forgotten the name.  I think Chris Erickson has these.

Bryan

 

Virus-free. www.avg.com


Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

W Hilmo
 

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










Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

Ray Gralak
 

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










Re: Interesting Behavior with APCC Pro and Pegasus Astro UPBv2

W Hilmo
 

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


Re: More APPM Results -- Can Someone Help Me Understand This?

Ray Gralak
 

Hi Don,

USNO-B1.0 has been taken off line by USNO. The only way to use B 1.0 is if you have a local version on you
computer.
USNO B1.0 is over 80 GBytes, consuming too much bandwidth to download from the USNO website.

Unfortunately, that leaves A2.0 as the outdated alternative, so UCAC4 is the better choice now.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Don Anderson via groups.io
Sent: Thursday, April 22, 2021 2:08 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] More APPM Results -- Can Someone Help Me Understand This?

USNO-B1.0 has been taken off line by USNO. The only way to use B 1.0 is if you have a local version on you
computer.

Don Anderson


On Thursday, April 22, 2021, 01:32:49 p.m. MDT, Ray Gralak <iogroups@siriusimaging.com> wrote:


Ray i think that comment refers to USNO-SA2.0

USNO-SA2.0 is a subset of USNO-A2.0
Yes, that is true about SA2.0, but A2.0 has been superseded by USNO-B1.0.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Brian Valente
Sent: Thursday, April 22, 2021 12:17 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] More APPM Results -- Can Someone Help Me Understand This?

Ray i think that comment refers to USNO-SA2.0

USNO-SA2.0 is a subset of USNO-A2.0


On Thu, Apr 22, 2021 at 12:13 PM Ray Gralak <iogroups@siriusimaging.com> wrote:


> For small fields of view with Pin Point, the USNO-A2.0 catalog is recommended by DC3 Dreams.

Bad information maybe?

According to the navy.mil website, USNO A2.0 is outdated:

https://www.usno.navy.mil/USNO/astrometry/information/catalog-info#usnoa2

-Ray



> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of George
> Sent: Thursday, April 22, 2021 12:05 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] More APPM Results -- Can Someone Help Me Understand This?
>
> For small fields of view with Pin Point, the USNO-A2.0 catalog is recommended by DC3 Dreams.
>
>
>
> Regards,
>
>
>
> George
>
>
>
> George Whitney
>
> Astro-Physics, Inc.
>
> Phone: 815-222-6538 (direct line)
>
> Phone: 815-282-1513 (office)
>
> Email: george@astro-physics.com <mailto:george@astro-physics.com>
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of mjb87 via groups.io
> Sent: Thursday, April 22, 2021 1:49 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] More APPM Results -- Can Someone Help Me Understand This?
>
>
>
> BTW, I am using PinPoint and they do NOT recommend UCAV4.
>
>










--

Brian



Brian Valente
portfolio brianvalentephotography.com <http://brianvalentephotography.com>







Re: GTOCP4 Caps

M Hambrick
 

To Joe:

I believe I read or saw somewhere (Maybe Tony's video) that plugging the holes will keep bugs out. This would only be a factor for those who leave their mount set up in a permanent observatory. Interestingly enough, my GTOCP4 (purchased in 2017) has no drain holes in the bottom. I am going to have to go back and watch Tony's video again.

To Ken:

You are correct. The part number that Mouser is sending me is RM15TRD-C(71). It has the correct thread size (M20 X 2). When I entered the other part number (without the "D") in the Mouser search bar it must have brought up the one with the D in it, and I didn't notice. My apologies for any confusion. 

Mike


Re: GTOCP4 Caps

Ken Sablinsky
 

Thanks Mike, I'd be curious if your model number has a D in it, as I think there's maybe a confusion in model numbers between Mouser and Digi-Key?

Howard's link from yesterday was for "RM15TR-C(71)" from Digi-Key


But on Mouser, at least where I search for it:
RM15TR-C(71) shows a diagram with 19mm x 1 internal thread and obsolete
RM15TRD-C(71) (with a D in the model name) shows 20mm x 2 thread.

In any event, I didn't stop the shipment in time, so I ordered the version "TRD" today.  Looks like I'll have both 19mm and 20mm, to cover all bases!

-Ken


Re: GTOCP4 Caps

Joe Zeglinski
 

Question to the group.
 
    Can anyone think of a logical  reason to plug “drainage holes”  with those rubber cones?
Do we really want to make sure that any dew or other source of moisture  leaking into the controller, should be kept inside? 
The only thing I can think of is to keep any itsy-bitsy bugs out – but then why drill the two holes into the case, in the first place?
Perhaps that is covered somewhere in the user guide :-)
 
Joe
 

From: M Hambrick
Sent: Thursday, April 22, 2021 8:50 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] GTOCP4 Caps
 
Hi Pete

Those cone shaped plugs are used to plug the drain / vent holes in the bottom of the GTOCP4 housing. Tony (a.k.a. Harley Davidson) made an excellent video a couple years ago about the need to have drain holes in the housing to allow condensate to drain out.

Mike


Re: GTOCP4 Caps

M Hambrick
 

Hi again Ken

I just received a shipment notice from Mouser for the RM15TR-C(71) caps. I was worried that they might substitute the same one that they recommended for you, but they are sending the ones that I ordered. I will find out when they arrive on Monday April 26. 

FYI - These caps shipped from Mouser Canada. I don't know if they have more than one location, but it is possible that they were only out of stock at the particular location you were trying to buy them from.

I will keep you posted.

Mike


Re: NASA's guide to Black Holes

Robert Sinitiere <bobstar9@...>
 

Thanks, Rolando.  Should I vacation near a Black Hole, I will “heed your advice”. Bob
⭐️👽😳


On Apr 22, 2021, at 7:12 PM, Roland Christen via groups.io <chris1011@...> wrote:


Enjoy!

https://www.youtube.com/watch?v=aMTwtb3TVIk

Rolando

--
Roland Christen
Astro-Physics


Re: APPM model how many points portable?

Bill Long
 

What is the best way to test the accuracy level? 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Thursday, April 22, 2021 5:40 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APPM model how many points portable?
 
If it isn't accurate to 1 arc sec or better then it will impact unguided imaging in a negative way.

Rolando



-----Original Message-----
From: Jim Grubb via groups.io <jimgrubb@...>
To: main@ap-gto.groups.io
Sent: Thu, Apr 22, 2021 7:21 pm
Subject: Re: [ap-gto] APPM model how many points portable?

Hi Rolando,

I'm not sure how to measure how accurate ASTAP is.  I guess I could run a solve with ANSVR or pinpoint and measure the difference in results? 

Jim

--
Roland Christen
Astro-Physics


Re: GTOCP4 Caps

M Hambrick
 

Hi Pete

Those cone shaped plugs are used to plug the drain / vent holes in the bottom of the GTOCP4 housing. Tony (a.k.a. Harley Davidson) made an excellent video a couple years ago about the need to have drain holes in the housing to allow condensate to drain out.

Mike

5161 - 5180 of 83222