Date   

Re: Keypad 4.19.5 unsuccessful upload

Suresh Mohan
 

Peter ,
     I did that two years ago had hell , I’m trying to recall how I finally did it. If im not mistaken it was a cable issue . How do u connect to the pc ?
Suresh 


On Nov 2, 2021, at 8:29 AM, Peter Nagy <topboxman@...> wrote:

Hello,

I've been trying to upload Keypad version 4.19.5 firmware to my Keypad that was previously version 4.19.3 but no success yet. The first two times I tried to upload Keypad version 4.19.5 to my Keypad was unsuccessful and I allowed two hours each time for uploading when it should have taken about 20 minutes according to A-P instructions.

I followed A-P "Upgrading Your Keypad to 4.19.5 - Code Only Java Keypad Loader" documentation as close as possible. I got as far as to Step #7 under "Keypad Code Load" and it stayed stuck at "Completed 20% of Code Load" as shown in first screenshot.

Here are the two screenshots of trying to upload to Keypad version 4.19.5 to my keypad.

The first screenshot showed only 20% completion of upload after two hours of trying. The second screenshot shows status of Keypad after two hours of uploading without success.

Please advise me what I could do for successful uploading of Keypad version 4.19.5. Now my Keypad is totally useless because it does not any longer boot to previous 4.19.3 version. My Keypad serial number is 3771GTO which is well above the minimum Keypad serial number of 1565GTO.

I have been successful uploading three previous versions Keypad in the past without issues since owning first run A-P1100GTO mount (October 2013). This is my first time using Java Keypad Loader and it was not successful.

Thank you,
Peter


Keypad 4.19.5 unsuccessful upload

Peter Nagy
 

Hello,

I've been trying to upload Keypad version 4.19.5 firmware to my Keypad that was previously version 4.19.3 but no success yet. The first two times I tried to upload Keypad version 4.19.5 to my Keypad was unsuccessful and I allowed two hours each time for uploading when it should have taken about 20 minutes according to A-P instructions.

I followed A-P "Upgrading Your Keypad to 4.19.5 - Code Only Java Keypad Loader" documentation as close as possible. I got as far as to Step #7 under "Keypad Code Load" and it stayed stuck at "Completed 20% of Code Load" as shown in first screenshot.

Here are the two screenshots of trying to upload to Keypad version 4.19.5 to my keypad.

The first screenshot showed only 20% completion of upload after two hours of trying. The second screenshot shows status of Keypad after two hours of uploading without success.

Please advise me what I could do for successful uploading of Keypad version 4.19.5. Now my Keypad is totally useless because it does not any longer boot to previous 4.19.3 version. My Keypad serial number is 3771GTO which is well above the minimum Keypad serial number of 1565GTO.

I have been successful uploading three previous versions Keypad in the past without issues since owning first run A-P1100GTO mount (October 2013). This is my first time using Java Keypad Loader and it was not successful.

Thank you,
Peter


Re: Mach2 CP5 Orthogonality Model #Mach2GTO #Keypad

John Upton
 

Mike,

   Thanks again. The method worked perfectly. I have been using this feature of the V5 Keypad since I set up anew each night for the most part and found that my cone error changed slightly night to night. (In addition to any dovetail induced cone error, I am also using an 11" SCT with mirror flop until I tighten the mirror clutches/clamps.) This feature has been helping with pointing until I get a model built. That is ... until I messed it up the other night. It is great to be able to recover so easily. It took very little time.

John


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

David
 

John, 

I used to use Platesolve 2 all the time as well, but switched to ASTAP. It’s free, is WAY faster at solving, and just seems to work better.  You should give it a look and try it.  Plus, I didnt think Platesolve 2 was being supported anymore, but I may be wrong.

David

On Nov 1, 2021, at 1:45 PM, John Upton <upton@...> wrote:

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


Re: Mach2 CP5 Orthogonality Model #Mach2GTO #Keypad

Peter Nagy
 

This should be mentioned in A-P manuals either in Mach2 or Keypad documentations. This is useful information.

Peter


Electro-Static Discharge Protection for Older Mounts

Scott Cooke
 

All,
If anyone has a 900 or 1200 mount and perhaps other older GTO mounts, AP is offering an Electro-Static Discharge board to be installed in the motor-gearbox assemblies.  The Dec motor on my 900 decided to stop working so after a conversation with Howard in tech support, I sent both my RA and Dec assemblies.  It turns out that the motor encoder on the Dec had gone bad.  They had to replace the motor and encoder so they moved the old motor to the Dec and installed the new motor in the RA and installed new protection boards in both to help prevent this from happening again.  I would recommend this board change to avoid paying for new motors and encoders.  I know it is available for the 900, 1200, and I believe they said the 3600, but it is not available for the 400.
Scott


New AP1100 Guiding Great on Very Windy Night

Mark Lamb
 

Last night, my new AP1100 (base) peformed great on very windy night.  I got the AP1100 a couple of weeks ago, and I am very early on the learning curve.  Per George's recommendation, I have yet to try any of APCC modeling, and using it just as I would my G11.  I was imaging with a tiny scope, Vixen FL55ss at 237mm, f/4.3, and using my QHY268M capturing the Question Mark nebula in narrowband, using 8 min subs.

A couple nights earlier, I tried using an old ST80 (just purchased) as a guidescope, but the results were not that good, even though PHD2's total RMS was in the 0.4-0.5" range.  I had to throw out ~40% of the subs for eccentricity.  I did not know if the issue was the night's bad seeing (~2.9" according to MeteoBlue; the worst I had encountered in 3 years) or the long focuser cantilever on the ST80; I had to add ~100mm of M42 extensions and rack the focuser fairly far out to focus.  Previous attempts with a generic 60mm/240mm guidescope did not have eccentricity issues, though sky conditions were much more typical at ~1.5" seeing.  

My 1st attempts using the AP1100 with a generic 60mm/240mm guidescope was similar to my G11 guiding with OAG, but more consistent.  It is nice to have practically zero backlash compared to my G11's ~800ms typical (400-1200ms range).  My only disappointment so far is the single bad night using the ST80 as guidescope, but I do not think the AP1100 had anything to do with the bad results.

With the single night's bad experiment with ST80 guiding, I decided to use a QHY OAG instead of guidescope.  Even with the bad wind conditions, PHD2's total RMS was in the 0.2" range, and I only threw out 1 of 60, 8 min subs, and the sub that I deleted was not that bad.   Even though it was very windy, the online seeing estimates were in my typical range at ~1.4".  So here on, I will be using an OAG even on my very short FL scopes.

I know I benefited from the very tiny FL55ss lack of much wind surface, but I had to add much to get it balance in DEC, as well as balance in RA.  I am glad I got the 10" combo saddle instead of the larger saddle, as this tiny scope train gets very back heavy with OAG/CFW/QHY268.  I end up mounting the FL55ss on back end of a 14" DUP using a camera mount clamp, with additional pair of ~140mm CNC rings with 8" Vixen bar on top (very forward on DUP) with heavy Vixen clamp on the Vixen bar and Losmandy D clamp attached to the underside of the DUP.  For AP, I guess one can never have enough additional clamps, bars, tubes, etc....

I am very please at how the AP1100 without encoders handled last night's windy conditions!


Re: APCC Meridian Tracking Limits and Sequence Generator Pro

Ray Gralak
 

Hi Steve,

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.
It doesn't work that way. The mount's flip point is controlled by the meridian delay set in the mount. The cause of the flip failure is probably a time discrepancy between the mount's meridian delay value and when SGPro thinks it is okay to flip. If there is even a split-second difference between the two times, that could prevent the pier flip from occurring if SGPro sends the slew command at the exact moment a flip should work. If SGPro delayed a few seconds, it might solve the problem. The new flip padding control in the 1.9.1.3 beta tries to address this timing issue.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of steve.winston@...
Sent: Monday, November 1, 2021 9:15 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Meridian Tracking Limits and Sequence Generator Pro

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: 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

Patrick Sparkman
 

Ok, thanks Ray.

6581 - 6600 of 89107