Date   

Re: AP1100 / APCC Wired Ethernet Connection to Laptop Turning Off WiFi

Mark Lamb
 

Disabling the LAN-WLAN switching setting in BIOS did not fix the issue.  Since this is a convenience issue only, I do not babysit outside in the cold, and having other things to do, I will leave this for now.


Re: APPM and NINA Plate Solving -- Possible to use PlateSolve2?

Sébastien Doré
 

Hi John,

APPM steers its own instance of the platesolver you have configured, so its not using NINA as a "proxy" similarly to what it does with the "camera" function or even with the SGP platesolver (if I understand this right - I am not an SGP user).

The only supported platesolvers are the following and need to be configured in the Plate Solve Settings tabs directly in APPM:
  • PinPoint
  • TheSkyX Image Link
  • Sequence Generator Pro (which is probably what you have configured right now and the reason for the error you are getting)
  • ASTAP
So in short, there are currently no ways to use the solver you have configured in NINA (e.g. Platesolve2 in your case) to run a model in APPM. Might be a good candidate request for future enhancements though... 

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de John Upton <upton@...>
Envoyé : 1 novembre 2021 14:45
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : [ap-gto] APPM and NINA Plate Solving -- Possible to use PlateSolve2?
 
HI,

   I am attempting to learn NINA to try it out after using SGP for the past 8 years. I still like SGP but NINA (1.11) is looking more feature rich and I think I should at least try it out.

   I have Plate Solving working in NINA using PlateSolve2. I can take and image a solve it within NINA. I wanted to try to build a simple model in APPC (via APPM) as I have been doing with SGP.

   I set up the camera control in APPM to use NINA and it connected to the NINA server just fine. I already had APPM configured to use PlateSolve2 (when I was using SGP) so just tried a Plate Solve and Recal to see what happens. That is when I discovered that APPM seems to be locked to use ASTAP when using NINA. Even with the APPM camera set to NINA, APPM threw an error saying SGP was not running (which was true but unexpected).

   Is there a way to use my working PlateSolve2 through NINA in APPM or must I install yet another plate solver (ASTAP) just to do modeling in APPM with NINA?

John


APPM and NINA Plate Solving -- Possible to use PlateSolve2?

John Upton
 

HI,

   I am attempting to learn NINA to try it out after using SGP for the past 8 years. I still like SGP but NINA (1.11) is looking more feature rich and I think I should at least try it out.

   I have Plate Solving working in NINA using PlateSolve2. I can take and image a solve it within NINA. I wanted to try to build a simple model in APPC (via APPM) as I have been doing with SGP.

   I set up the camera control in APPM to use NINA and it connected to the NINA server just fine. I already had APPM configured to use PlateSolve2 (when I was using SGP) so just tried a Plate Solve and Recal to see what happens. That is when I discovered that APPM seems to be locked to use ASTAP when using NINA. Even with the APPM camera set to NINA, APPM threw an error saying SGP was not running (which was true but unexpected).

   Is there a way to use my working PlateSolve2 through NINA in APPM or must I install yet another plate solver (ASTAP) just to do modeling in APPM with NINA?

John


Guider Settings

M Hambrick
 

I read in a recent discussion thread where Roland recommended that the minimum move in the guider settings should never be less than 0.3 seconds in either RA or DEC. I believe that the discussion was pertaining to the guider settings in PHD, but do the same guidelines also apply for MaxIm DL ? The screen shot below shows my current guider settings ion MaxIm DL. I have never changed any of these settings except for the delay between exposures which I changed from zero to 1 second.

What about the Maximum move ? Any guidelines there ?

Should I also have the Enable simultaneous RA and DEC corrections box checked ?

Mike


Re: Mach2 CP5 Orthogonality Model #Mach2GTO #Keypad

John Upton
 

Mike,

   Thanks! That makes perfect sense. It just never occurred to me to try that...

John


Re: NINA or APCC

ap@CaptivePhotons.com
 

michael mccann wrote:

I learned there was a problem while I was learning PI PhotometricColorCalibration process and the tool kept failing on my M33 image. I resolved the coordinates and found my fits header’s RA and DEC values were a degree off in RA and a few minutes in DEC. so where does NINA obtain the values in the Fits heading, from Ascom driver or the Framing, or plate solving? Or is there some other process involved.
The slew and center using plate solves to align the mount to the target works great. However I notice some over-shoot, often more than 5°. I suspect that understanding where the fits RA/DEC values comes from then I’ll isolate the issue faster.
My understanding is that NINA records the FITS headers from what the mount is reporting at that time. You can double check by looking in the equipment tab while taking a specific image, then check the headers.

The center functionality with plate solving will adjust pointing, again as I understand, irrespective of the telescopes reported position. So if it slews to RA/DEC and finds the target 1 degree off, it will tell the telescope to move 1 degree until the plate solve centers, leaving the telescope reported position (absent a sync) off by 1 degree from the target's actual position. Then when imaged, the target may be centered, but the fits header will show the 1 degree off.

In NINA in the Options, Equipment tab, for telescope, there is a "Do not sync" option normally set to Off. Se if yours is On. With TSX and MyT (which I used before) "on" is correct as TSX is supposedly already running a full tPoint model recalibrated for that night's session, so you do not want syncs to upset it. With APPM that may or may not be true, and I think the proper setting is Off. This will cause the first live plate solve to sync, which in your Ascom V2 driver is probably set to a recal, and should make the coordinates align.

Another option you have that might fix it is (assuming you are using APPM at all) is to go into APPM and on some representative part of the sky (is it better toward the equator?) do a plate-solve-and-recal. This should have a similar effect. You can check its reported dec/ra and see if it changes when you do.

I discovered this issue (with my sync in NINA to On) because of meridian flip timing. Some nights NINA and APPC would be off by a few minutes of time in what time transit was. This was because APPM was not actually synced to the sky, its coordinates were wrong because after assembling the mount and polar aligning I never did a sync (recal) at all.

Linwood


Re: Mach2 CP5 Orthogonality Model #Mach2GTO #Keypad

Mike Hanson
 

Hi John,

You don't need to capture a "good" ortho model to "erase" it.  Just run the keypad procedure, but do NOT make any N-S-E-W centering corrections.  This will produce an ortho model with zero correction - same as "erasing".  It only takes as long as the slews take.  No need to use the scope or camera, can be done in daylight or in your living room.

Regards,
Mike Hanson


NINA or APCC

michael mccann
 

I learned there was a problem while I was learning PI PhotometricColorCalibration process and the tool kept failing on my M33 image. I resolved the coordinates and found my fits header’s RA and DEC values were a degree off in RA and a few minutes in DEC. so where does NINA obtain the values in the Fits heading, from Ascom driver or the Framing, or plate solving? Or is there some other process involved.

The slew and center using plate solves to align the mount to the target works great. However I notice some over-shoot, often more than 5°. I suspect that understanding where the fits RA/DEC values comes from then I’ll isolate the issue faster.

Cheers
Mike


Mach2 CP5 Orthogonality Model #Mach2GTO #Keypad

John Upton
 

Hi AP folks,

  I have a follow up question related to a previous thread I started a few months back.
(Interactions Between Keypad and APCC Orthogonality Models?)

   In that thread, Roland said "the Ortho is always on regardless of whether you use or turn off any of the other keypad models. Once you enter ortho data it stays there until you overwrite it by doing a new ortho routine."

   My new question is whether there "is any other way to zero out the Ortho Model data stored inside the CP5"?

   I have gotten myself into a situation where pointing is off by quite a bit making it difficult to even perform a new Otho Model with the keypad. (I accidentally identified a different/wrong  star in the second part of the procedure.) The pointing error is causing long Plate Solves when I build an APCC model or simply do a Plate Solve and Recal. The resulting APCC Model pointing is good and works very well but building it takes longer because of the CP5 Ortho Model pre-corrections for each slew.

   Is there a quicker way to reset the Ortho parameters to zero / default without doing a good new Ortho Model with the Keypad?

John


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

steve.winston@...
 

Hi Ray,

>That's not going to work because you can't guarantee that SGPro won't issue a slew after the meridian.

That's fine as this is exactly the expected and documented behavior for SGP:  If the mount is at or past SGP's configured meridian limit, then issuing a slew command should result in a meridian flip.  

In the current implementation of APCC it appears that APCC is basically intercepting the slew command when "CW up slews within West limits" box is checked, preventing the meridian flip from completing, and causing SGP to abort.

Is there a way to configure APCC to ensure that when SGP reaches it's configured meridian limit and issues the slew command, the meridian flip can complete?

thanks!

Steve



Re: APPM and ASTAP #APCC

Bill Conrad
 

Got a model built using ASTAP with Beta 1.9.1.3. Did not work at bin 2, but did work at bin 1 with min star at 1.0.
Thanks Ray.

BC


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

psparkman@...
 

Ok, thanks Ray.


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

Ray Gralak
 

Honestly, I'm pretty busy working on software now. But I don't think there is anything to discuss. APCC sends the mount's flip point to SGPro, which is exactly what SGPro expects. Changing the meaning of that would invalidate the purpose of that SGPro API, so I do not think it is the right thing to do.

BTW, A-P will soon start a new website where people can suggest features and others can vote on them. When it's available, you can describe your feature request there and have others vote for it.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of psparkman via groups.io
Sent: Sunday, October 31, 2021 9:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Meridian Tracking Limits and Sequence Generator Pro

It might be more efficient if we could talk. Would you be willing to send your phone number and time to talk
to my email address listed?


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

psparkman@...
 

It might be more efficient if we could talk.  Would you be willing to send your phone number and time to talk to my email address listed?


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

Ray Gralak
 

That's not going to work because you can't guarantee that SGPro won't issue a slew after the meridian.

Without APCC actually setting the meridian delay SGPro would not expect the mount to flip if it had to recenter the image, or slew to another target that normally would not require a pier flip because it is within the West limit.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of psparkman via groups.io
Sent: Sunday, October 31, 2021 8:50 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Meridian Tracking Limits and Sequence Generator Pro

Ray, I am not sure why I can't communicate the issue to you properly, but I will continue to try. I don't want to
check the CW up slew west box. I do want any slew command issued by SGP past the meridian to cause a
meridian flip as that is how SGP initiates a flip. However, I do want the mount to track past the meridian to the
APCC limit minus the offset and pass that value to SGP so that it will invoke the flip at the delayed point and
take advantage of the ability to track past the meridian.

The problem that I have is that without having the CW up slews within West limits box checked, APCC does
not pass the additional meridian delay as shown in my first screenshot above. I feel that this is a bug. Also,
why does checking the CW Up slew limits for the East automatically check the one for the West?


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

psparkman@...
 

Ray, I am not sure why I can't communicate the issue to you properly, but I will continue to try.  I don't want to check the CW up slew west box.  I do want any slew command issued by SGP past the meridian to cause a meridian flip as that is how SGP initiates a flip.  However, I do want the mount to track past the meridian to the APCC limit minus the offset and pass that value to SGP so that it will invoke the flip at the delayed point and take advantage of the ability to track past the meridian.

The problem that I have is that without having the CW up slews within West limits box checked, APCC does not pass the additional meridian delay as shown in my first screenshot above.  I feel that this is a bug.  Also, why does checking the CW Up slew limits for the East automatically check the one for the West? 


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

Ray Gralak
 

So all of that makes sense, but the CW up slews within West check box clearly does not cooperate with SGP.
So why did I check that in the first place?
"CW up slews" invokes APCC to change the meridian delay. With it off, the appropriate action will be taken when the limit is reached, but any slew to the West side from a counterweight-up position will cause a pier flip.

So, "CW up slews in West" MUST be selected or any slew that SGPro issues after the meridian will cause a pier flip.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of psparkman via groups.io
Sent: Sunday, October 31, 2021 8:23 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APCC Meridian Tracking Limits and Sequence Generator Pro

I have posted a couple of times about Meridian Flip issues with APCC v1.9.0.11 and Sequence Generator Pro.
This worked reliably for several months with the previous version, but I now think that was related to my
settings at that time. I took advantage of a cloudy night to learn more about how the Meridian tracking limits
in APCC work and relate to SGP. I now think that I understand how it works, but am not sure why it works the
way it does in relation to the "Counterweight Up Slews within:" check boxes for East and West and how they
interact with the "Send Limit with offset to SGPro" checkbox.

I now clearly understand why I was having Meridian flip failures with the settings set in a way to take
advantage of the variable Meridian limits versus Dec position. First, it must be understood that SGP issues a
Meridian Flip by sending a slew command to same target coordinates that it is currently tracking. Thus relying
on the mount to do the flip and come back to the same coordinates. This is the issue with my flip failures.
When I set the CW up slews within check box for West and set the send limit to SGP box with a flip offset of
my longest exposure plus five minutes to keep from tracking into the meridian limit before a flip; SGP sends
a slew command to the same location it is currently tracking and the mount does a safety slew back to the
meridian, then comes right back counterweight up because of the CW up slew within West limit check box.
This causes SGP to see that the scope is still on the west side of the pier and it aborts, parks, and shuts
down.

So all of that makes sense, but the CW up slews within West check box clearly does not cooperate with SGP.
So why did I check that in the first place?

This is where I don't understand why a couple of things function the way they do with APCC. I really never
want to do CW up slews within West limits for imaging. It might save a flip if you are going between close
objects, but I would rather it go ahead and put the scope on the east and it will not work with the slew in place
meridian flip design of SGP. The problem is that if I check the "Send limit to with offset to SGPro" check box
WITHOUT the CW Up slews within West limits box checked, APCC just sends a 0.0 offset to SGP and I don't
get to take advantage of the tracking limits being set automatically to match the limits that I have set for my
scope and mount.

pastedGraphic.png<blob:https://ap-gto.groups.io/8b047c01-5345-4a4a-9826-0dfc32cfc854>

The only way to get the Dec specific offset to pass to SGP is to check the West Limits box, but that will not
work for SGP Meridian flips.

Why doesn't this just pass the current limit offset to SGP without having to check the West Limits check box?
So checking the Send Limit with offset to SGPro check box doesn't seem to do anything unless the West
Limits box is checked.

Here is how it looks with the box checked showing the correct offset, but the West box needing to be
checked.

pastedGraphic_1.png<blob:https://ap-gto.groups.io/3613deea-33e3-4609-82d2-190b37dc6e83>

So, next I thought that I would try checking the East limits box. At least that makes some sense from an
imaging perspective as it could allow the imaging to start with the CW up and the scope on the East side and
avoid the flip all together. But the problem is that if you check that box, it forces the West Limits box to be
checked for some reason. So that option will not work. I noticed another little issue when I tried the CW Up
slews East box checked with SGP. When SGP slews then centers on a target, I don't get within the 20 pixel
limit with the first plate solve. Usually with a 60 point APPM model I get within 100-200 pixels, so SGP sends
a new calibrated slew command to get it within 20 pixels. This invokes the safety slew, so the mounts has to
take the time to go back to the meridian, then move back. Sometimes this can take 2 or more tries and the
safety slew does take more time.

What I expect should happen is that I can check either East or West Limits without the East forcing the West.
Also, I should be able check the Send Limits to SGPro box and have the offsets pass correctly without
having either CW Up limit box checked. That would then work fine with the SGP Meridian flip function, and
allow the mount to track CW up to the limits APCC sets and take advantage of that capability.

With the way that it currently works, I am just unchecking the CW slew limits and Send Limits to SGPro boxes
and setting a fixed 1 hour offset in SGP since that is my smallest time past Meridian limit. But I would much
rather these functions work as expected.




APCC Meridian Tracking Limits and Sequence Generator Pro

psparkman@...
 

I have posted a couple of times about Meridian Flip issues with APCC v1.9.0.11 and Sequence Generator Pro.  This worked reliably for several months with the previous version, but I now think that was related to my settings at that time.  I took advantage of a cloudy night to learn more about how the Meridian tracking limits in APCC work and relate to SGP.  I now think that I understand how it works, but am not sure why it works the way it does in relation to the "Counterweight Up Slews within:" check boxes for East and West and how they interact with the "Send Limit with offset to SGPro" checkbox.

I now clearly understand why I was having Meridian flip failures with the settings set in a way to take advantage of the variable Meridian limits versus Dec position.  First, it must be understood that SGP issues a Meridian Flip by sending a slew command to same target coordinates that it is currently tracking.  Thus relying on the mount to do the flip and come back to the same coordinates.  This is the issue with my flip failures.  When I set the CW up slews within check box for West and set the  send limit to SGP box with a flip offset of my longest exposure plus five minutes to keep from tracking into the meridian limit before a flip; SGP sends a slew command to the same location it is currently tracking and the mount does a safety slew back to the meridian, then comes right back counterweight up because of the CW up slew within West limit check box.  This causes SGP to see that the scope is still on the west side of the pier and it aborts, parks, and shuts down.

So all of that makes sense, but the CW up slews within West check box clearly does not cooperate with SGP.  So why did I check that in the first place?

This is where I don't understand why a couple of things function the way they do with APCC.  I really never want to do CW up slews within West limits for imaging.  It might save a flip if you are going between close objects, but I would rather it go ahead and put the scope on the east and it will not work with the slew in place meridian flip design of SGP.  The problem is that if I check the "Send limit to with offset to SGPro" check box WITHOUT the CW Up slews within West limits box checked, APCC just sends a 0.0 offset to SGP and I don't get to take advantage of the tracking limits being set automatically to match the limits that I have set for my scope and mount.

pastedGraphic.png

The only way to get the Dec specific offset to pass to SGP is to check the West Limits box, but that will not work for SGP Meridian flips.
 
Why doesn't this just pass the current limit offset to SGP without having to check the West Limits check box?  So checking the Send Limit with offset to SGPro check box doesn't seem to do anything unless the West Limits box is checked.

Here is how it looks with the box checked showing the correct offset, but the West box needing to be checked.

pastedGraphic_1.png

So, next I thought that I would try checking the East limits box.  At least that makes some sense from an imaging perspective as it could allow the imaging to start with the CW up and the scope on the East side and avoid the flip all together.  But the problem is that if you check that box, it forces the West Limits box to be checked for some reason.  So that option will not work.  I noticed another little issue when I tried the CW Up slews East box checked with SGP.  When SGP slews then centers on a target, I don't get within the 20 pixel limit with the first plate solve.  Usually with a 60 point APPM model I get within 100-200 pixels, so SGP sends a new calibrated slew command to get it within 20 pixels.  This invokes the safety slew, so the mounts has to take the time to go back to the meridian, then move back.  Sometimes this can take 2 or more tries and the safety slew does take more time. 

What I expect should happen is that I can check either East or West Limits without the East forcing the West.  Also, I should be able check the Send Limits to SGPro box and have the offsets pass correctly without having either CW Up limit box checked.  That would then work fine with the SGP Meridian flip function, and allow the mount to track CW up to the limits APCC sets and take advantage of that capability.

With the way that it currently works, I am just unchecking the CW slew limits and Send Limits to SGPro boxes and setting a fixed 1 hour offset in SGP since that is my smallest time past Meridian limit.  But I would much rather these functions work as expected.


Re: A-P Guide scope bracket/Baader guide scope

Joseph Beyer
 

Thanks for the confirmation Roberto.  I was assuming that would be the case but thought I'd check with someone who has more experience with it.  My setup is quite compact and I've done as much as I can to reduce the moment arm so the small amount of added weight is not likely to be a factor in guiding.

Joe


Re: A-P Guide scope bracket/Baader guide scope

R Botero
 

Joe

I doubt the mount will notice the difference; I would not worry. I have changed my Vario finder/guider a number of times as I add/change my tandem setup and the guiding is as good as ever (been using it since 2014). I’ve had it on an 1100GTO and now on a 1600GTO; both with and without APPM and it just works. No differential flexure versus the imaging scopes. As long as you have everything tightened up fine and no loose cables, you’ll be fine. 

Roberto

4341 - 4360 of 86859