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:
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
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
|
|
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
|
|
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
|
|
John Upton
Hi AP folks,
|
|
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.
toggle quoted messageShow quoted text
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-----
|
|
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.
toggle quoted messageShow quoted text
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-----
|
|
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."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-----
|
|
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.
|
|
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
|
|