1. main@ap-gto.groups.io
  2. Messages
   Date   
Re: Mount won't connect to new(er) laptop #APCC

Roland Christen
 

I have a Lenovo also, and i usually use device Manager to find which com port Windows has decided to use for the new USB connection. Once I find that port number, I set APCC to that number. If I'm using just the ASCOM driver, I select that port number in the driver. That always establishes the connection for me.

Rolando

-----Original Message-----
From: David Woolf <go4itbass@...>
To: main@ap-gto.groups.io
Sent: Sun, Jun 20, 2021 4:32 pm
Subject: [ap-gto] Mount won't connect to new(er) laptop #APCC

Was using an older Dell, "upgraded" to Lenovo because I needed USB3 for my ZWO camera.  Now mount won't connect.  Using APCC Standard and USB connection.  I get "No response from mount"  Swapped cables twice to no effect.  Old laptop connected just fine.  Got it to connect briefly by setting primary port to COM4, which has only appeared in the dropdown list occasionally.  Dev. manager says best drivers are installed.   What's the trick?  

--
Roland Christen
Astro-Physics
Mount won't connect to new(er) laptop #APCC

David Woolf
 

Was using an older Dell, "upgraded" to Lenovo because I needed USB3 for my ZWO camera.  Now mount won't connect.  Using APCC Standard and USB connection.  I get "No response from mount"  Swapped cables twice to no effect.  Old laptop connected just fine.  Got it to connect briefly by setting primary port to COM4, which has only appeared in the dropdown list occasionally.  Dev. manager says best drivers are installed.   What's the trick?  
Re: #Mach2GTO C14Edge HD rig - A Couple Questions #Mach2GTO

Greg Vaughn
 

Hi Deonb,

 

Thanks for sharing the photos of your rig.  Very impressive.

 

Wanted to ask just a few questions about your rig:

 

  1. The mirror locks on your Edge 14 appear to have been converted from the pointed plastic ones to flat knobs.   Can I ask where you found these or whether they came with the C14 Edge?   I have a C11 Edge and those locks are important but often seem to get in the way when changing equipment in the image train.
  2. I just recently assembled a ZWO MM CMOS camera, a filter wheel and an OAG with guide camera.   I used a very similar ZWO camera for the guide camera, but it looks like I oriented it differently than yours.   Mine has the long dimension tangential to the image circle.  It looks like you have it orthogonal.   Is this to make sure that your sensor dips into the image circle?  Curious about your thought process and any common practices in this choice that I may not be aware of.
  3. Is the ‘Saggita’ OPTEC device a focuser for your guide camera?   If so, what are you using for your primary focuser (is that the OPTEC Leo?) and any thoughts or lessons learned about these choices?  No problem fitting everything in within the backfocus spec for the reducer?

 

Again, thanks for sharing quality photos of your rig and your observatory – looks very efficient and tidy as well.  Clearly oriented for remote and unattended operation!

 

Clear skies!

 

Cheers,

Greg

 

Greg Vaughn

Alexandria, VA


Virus-free. www.avast.com

Re: Understanding automation-based corrections/sync #Keypad #Mach2GTO

Dale Ghent
 

On Jun 19, 2021, at 22:18, deonb <deonb@...> wrote:

Thanks Dale,

I'll try tonight with the 'prevent syncing' on in N.I.N.A. I figured N.I.N.A does something simple like this - and that does seem to me that it could cause cumulative errors - through no fault of NINA.

Out of curiosity - if sync is turned off, how does NINA center after plate-solve? Does it then just slew to offset coordinates instead? (And will those thus instead be reflected in the FITS file?)

Either way, I'm looking more for an overall safety from the APCC side here. Even if the 'prevent syncing' solves the specific NINA case, I still want APCC to prevent NINA, Stellarium, PHD2 or whatever from deviating the overall correction to more than e.g. 0.5 degree from the A.E.
I'm confused by what your goal is here - it sounds like you still want centering in some form, but on the other hand you want the mount to be authoritative, which means the centering operation becomes superfluous and should be removed or turned off entirely.

I think the main question here is why or how is this gross deviation working its way into the system in the first place. Normally a centering operation will plate solve and check the solved coordinates against the target's coordinates and sync+reslew to the target coordinates if they are outside your Pointing Tolerance, which is configured under Options > Plate Solving in NINA. In other apps this is referred to as a "close loop slew."

With an encoder mount and especially with a pointing model, this centering check should essentially be a no-op as your mount ought to be spot on at any given time and certainly within NINA's default pointing tolerance, which I think is 1 arcmin. The only time when this isn't the case is if your model is screwed up, your Observing Conditions temperature measurements are in F instead of C like with Wade's recent experience, or your polar alignment is off. There are probably some other perturbations to the system that can throw things off, but APCC logs would probably help sort that out.
Re: Understanding automation-based corrections/sync #Keypad #Mach2GTO

deonb
 

On Sun, Jun 20, 2021 at 09:09 AM, Ray Gralak wrote:
There's something else going on if errors have accumulated to that extent. I suggest you turn off syncing in NINA until the source of the issue can be determined.
I feel like we're focusing on the wrong issue here. I was just using NINA as an example. This doesn't have to do with NINA. 

You can do the following to reproduce the issue in just APCC:
In APCC, go to GoTo/Recall, click Load Mount RA/Dec, add 12 degrees to Dec, click Sync. Voila, the mount sync is now off by 12 degrees.

So going back to the crux of the questions:
a) How do I see this? (i.e. How do I see the delta between the Absolute Encoder coordinates and the Synced coordinates).
b) How do I prevent this at the APCC (or even better, at the Hardware) level?
Re: Setting Park Position for ACP Script

Roland Christen
 


but the next time I need to balance the mount
prior to a recal, I'll start in the recommended Park 4.
Personally I like Park5. It points north, same as Park1 and is easier on the cables.

Rolando


-----Original Message-----
From: Mike Dodd <mike@...>
To: main@ap-gto.groups.io
Sent: Sat, Jun 19, 2021 10:23 pm
Subject: Re: [ap-gto] Setting Park Position for ACP Script

On 6/19/2021 10:56 PM, Jerome A Yesavage wrote:
> Thanks, that did it.  BTW, I could not find the documentation of why
> Part 1 is frowned upon?

My understanding is that, within seconds of starting tracking from Park
1, the mount goes into a counterweight-up position, which can cause
problems for the ASCOM driver.

I've never had problem, but the next time I need to balance the mount
prior to a recal, I'll start in the recommended Park 4.

--- Mike








--
Roland Christen
Astro-Physics
Re: Setting Park Position for ACP Script

Ray Gralak
 

My understanding is that, within seconds of starting tracking from Park
1, the mount goes into a counterweight-up position, which can cause
problems for the ASCOM driver.
Park 1 is not a problem for the ASCOM driver. However, if the mount tracks into a counterweight up position before the mount is unparked, the mount (not the ASCOM driver) will assume the scope is on the other side of the pier. Thus, the mount would *appear* to be lost on the next slew.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Mike Dodd
Sent: Saturday, June 19, 2021 8:23 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Setting Park Position for ACP Script

On 6/19/2021 10:56 PM, Jerome A Yesavage wrote:
Thanks, that did it. BTW, I could not find the documentation of why
Part 1 is frowned upon?
My understanding is that, within seconds of starting tracking from Park
1, the mount goes into a counterweight-up position, which can cause
problems for the ASCOM driver.

I've never had problem, but the next time I need to balance the mount
prior to a recal, I'll start in the recommended Park 4.

--- Mike
Re: Understanding automation-based corrections/sync #Keypad #Mach2GTO

Ray Gralak
 

There is not enough information to say for sure why the pointing errors accumulated but this is not typical behavior seen with other ASCOM client applications.

1) How do I see what sync updates NINA (Automation Software in general) did to APCC? Specifically, what is the
active correction value (or points) from the sync? (Not just logs)

2) How do I clear it?
If you need to correct the mount's position, I suggest you use APPM's "Plate Solve and RECAL" button on APPM's Run tab.

3) Are the NINA correction it does per point? i.e. Does APCC build an internal pointing model for every correction,
or is it just a single correction value with a last-one-wins?
APCC's pointing models are static once created. Sync's into the model just adjust the an offset into the model.

4) How does NINA correction integrate with the APPM pointing model?
There is no integration, nor does there need to be. NINA is not even aware that there is a pointing model.

5) Is the effect of NINA corrections cumulative? It appears to be, I can't imagine APCC or NINA having missing a
single slew/plate-solve by 12 degrees in order to finally end up with a 12 degree error. Cumulative seems ok on
any other mount, but on a mount with A.E. this doesn't seem like the best strategy.
There's something else going on if errors have accumulated to that extent. I suggest you turn off syncing in NINA until the source of the issue can be determined.

-Ray
Re: Setting Park Position for ACP Script

Jerome A Yesavage
 

Thanks, hard to believe I am into this level of detail on the mount, but is there a reason why 4 is recommended?  I have moved to 5 but could use 4 also.  I used to use 3 and that was easy to get an approximate position is I have to recal.  Come to think of it, 4 or 5 might be easier since I could verify their position with a level. 

I am moving to the horizontal position to raise my pier eventually 8" to get maximum view low on the horizon over the edge of my ROR observatory. 

BTW again since I have had to rediscover polar alignment I have been using the latest version of PemPro, taht plus careful balancing makes the job of the Mach1 a lot easier.
Re: Paducah Skies Observatory

Robert Chozick <rchozick@...>
 

Thanks.  After 100s of hours of work I can now start enjoying it.

Robert

On Jun 19, 2021, at 9:26 PM, Kenneth Tan <ktanhs@...> wrote:

Nice! How I wish I can have one like this!

On Sun, 20 Jun 2021 at 06:52, Mike Dodd <mike@...> wrote:
On 6/19/2021 4:01 PM, Robert Chozick via groups.io wrote:
> This is a link to a gallery showing details of my observatory:
>
> https://pbase.com/rchozick/image/171730847
>
> If you click on an image it will go back to the gallery of other pictures.

Robert, Nice to chat with you this afternoon. Many of the photos are
sideways or upside-down on my browser.

--- mike
Re: Setting Park Position for ACP Script

Mike Dodd
 

On 6/19/2021 10:56 PM, Jerome A Yesavage wrote:
Thanks, that did it. BTW, I could not find the documentation of why
Part 1 is frowned upon?
My understanding is that, within seconds of starting tracking from Park 1, the mount goes into a counterweight-up position, which can cause problems for the ASCOM driver.

I've never had problem, but the next time I need to balance the mount prior to a recal, I'll start in the recommended Park 4.

--- Mike
Re: #Mach2GTO C14Edge HD rig #Mach2GTO

deonb
 
Edited

Couple of people asked about photos of the C14 on the Mach2GTO.

I've put them on:
https://www.dropbox.com/sh/k5zrsg54nwzqc04/AADNKSZGTSw021W4xV203eOVa?dl=0

The scope is in balance as shown - all the clutches are loose for all the pics.

I have 10lbs in front right now since I didn't pay attention last time I mounted the scope and put it on too too far back. This drops too 7lbs when the scope is in the most forward position just clear of the dome roof.

The main counter-weights are reversed (non-optimal) since it's easier that way to switch between a lighter and heavier load without taking off any weight. But it works fine like that.
Re: Setting Park Position for ACP Script

Jerome A Yesavage
 

Thanks, that did it.  BTW, I could not find the documentation of why Part 1 is frowned upon? 
Re: Understanding automation-based corrections/sync #Keypad #Mach2GTO

Joseph Beyer
 

I had a similar observation with NINA several nights ago.  While running an APPM model and selecting targets and triggering slews from CdC the go-tos with my Mach1 were perfectly centered.  If the same coordinates were pulled from CdC into NINA (by initially selecting an object as a target in CdC then pulling those coordinates into the framing assistant) then using those coordinates in a target sequence the go-tos were not centered.  The only way I was able to have the objects centered after slewing to the target when starting the imaging sequence was to first drag the object into the center of the framing assistant and click "recenter".  I checked the coordinates used by CdC and NINA and they appeared to be the same.  I will follow up with the developers on Discord but this sounds similar to what I was observing as well.
Re: Paducah Skies Observatory

Kenneth Tan
 

Nice! How I wish I can have one like this!

On Sun, 20 Jun 2021 at 06:52, Mike Dodd <mike@...> wrote:
On 6/19/2021 4:01 PM, Robert Chozick via groups.io wrote:
> This is a link to a gallery showing details of my observatory:
>
> https://pbase.com/rchozick/image/171730847
>
> If you click on an image it will go back to the gallery of other pictures.

Robert, Nice to chat with you this afternoon. Many of the photos are
sideways or upside-down on my browser.

--- mike
Re: Understanding automation-based corrections/sync #Keypad #Mach2GTO

deonb
 

Thanks Dale,

I'll try tonight with the 'prevent syncing' on in N.I.N.A. I figured N.I.N.A does something simple like this - and that does seem to me that it could cause cumulative errors - through no fault of NINA.

Out of curiosity - if sync is turned off, how does NINA center after plate-solve? Does it then just slew to offset coordinates instead? (And will those thus instead be reflected in the FITS file?)

Either way, I'm looking more for an overall safety from the APCC side here. Even if the 'prevent syncing' solves the specific NINA case, I still want APCC to prevent NINA, Stellarium, PHD2 or whatever from deviating the overall correction to more than e.g. 0.5 degree from the A.E. 
Re: Understanding automation-based corrections/sync #Keypad #Mach2GTO

Dale Ghent
 

Hi Deon,

Syncs are done by NINA or any other app via the ASCOM driver's SyncToCoordinates() method:

https://ascom-standards.org/Help/Developer/html/M_ASCOM_DriverAccess_Telescope_SyncToCoordinates.htm

The existence of a pointing model or anything else is not visible to NINA or any other app that uses the ASCOM driver, and there is no programmatic way in ASCOM for NINA to be aware of this even if it wanted to be. That stuff is all managed behind the scenes by APCC and NINA should never need to know about these things. The steps that NINA takes during a plate solve+sync operation are very pedestrian:

1. Image is captured
2. Image is fed to the configured plate solver
3. Plate solver responds with the solved coordinates in J2000
4. NINA precesses the coordinates to the equatorial system that is advertised by the ASCOM driver's EquatorialSystem property. For A-P and the vast majority of other mounts, this is JNOW.
5. The solved coordinates are then synced to the mount by calling the driver's SyncToCoordinatesI() method with the RA an dec as arguments

And that's it. I don't have an AE-equipped mount yet so I don't know of this issue you're running into. I do run APPM pointing models on my Mach1 and don't really have any noticeable issues like what you describe. I should be receiving an 1100GTO-AE in the fall, so will of course experiment with that.

We put an option in NINA under Options > Equipment > Telescope that prevents syncing in all cases. This was added because (apparently) T-Point gets confused by those. Does this 12 degree deviation (which is absolutely huge and not-subtle) occur with that on? If you want the mount to be authoritative on things and ignore any outside influences in the form of syncs, this is one way to do it. But the real question is *how* you're getting into this situation in the first place. I'll have to leave it to Ray to speak on this part.

/dale

On Jun 19, 2021, at 18:07, deonb <deonb@...> wrote:

I'm going to use N.I.N.A below as a stand-in example here for automation software, but I saw similar issues with other automation software I've tried in the past.

Ok, so I found out last night that I got into a situation where N.I.N.A drifted my Mach2GTO alignment out by 12 degrees. NINA always centers after slew, so you won't immediately notice since it appears to work, until this slew "corrections" got so far away from reality that my dome slit alignment became impossible. I did start to see an error complaining about a >5 degree correction inside APCC. I also confirmed the 12 degrees by parking, manually pushing the mount to the south-east, then doing an All-Sky solve using TheSkyX.

I tried to clear/reset it by unticking everything on the Pointing Model page inside APCC (no idea if that's the right thing). It still was off, until I restarted APCC, which then zero'd out that table. This previously survived reboots/power cycles of everything. After I did this step though everything was good again. Slews were almost perfect again, slit and scope lined up again, I then did a APPM and the worse correction point was 23" so my mount level and polar alignment appears relatively good from a hardware perspective. And of course after APPM, all slews were dead-on again.

It made me realize though that I don't really know what NINA (automation software in general) does after it plate solves and sync coordinates back to the scope, how APCC coordinates the values from there with the APPM pointing model, and how it coordinates with the Absolute Encoder.

So a few questions:

1) How do I see what sync updates NINA (Automation Software in general) did to APCC? Specifically, what is the active correction value (or points) from the sync? (Not just logs)

2) How do I clear it?

3) Are the NINA correction it does per point? i.e. Does APCC build an internal pointing model for every correction, or is it just a single correction value with a last-one-wins?

4) How does NINA correction integrate with the APPM pointing model?

5) Is the effect of NINA corrections cumulative? It appears to be, I can't imagine APCC or NINA having missing a single slew/plate-solve by 12 degrees in order to finally end up with a 12 degree error. Cumulative seems ok on any other mount, but on a mount with A.E. this doesn't seem like the best strategy.

I guess what I want is the following:

a) I still want NINA to be able to plate solve and center after slew to get the last few pixels aligned (important for OAG stars).
b) BUT I need the A.E. to be much more authoritative. Either:
1) I want every slew of the mount to be based on just the AE + APPM, and never the NINA added corrections.
-or-
2) If the NINA corrections have to be there, I don't want it to be cumulative, but instead if the total corrections (NINA + APPM) disagrees by the absolute encoder values by more than let's say 0.5 degree, then I want a flat-out error state. Go Directly To Park, don't collect $200 type of thing.

Again just using NINA here as an example. This isn't because of NINA, and I don't want to just flip a NINA setting to fix this. Well, I could, but I still want APCC to error if my settings are wrong, since 12 degrees off can run a scope into the mount. But I've had similar issues with SGP and especially Stellarium as well.

Anything that syncs coordinates back to any mount can cause these kinds of issue of course, but in the case of the Mach2GTO it has an A.E... So I want that A.E. (or A.E + Pointing Model) to be an overwhelming source of truth. If something deviates more than e.g. 0.5 degree from A.E. it is either a configuration mistake or my pier fell over. In either case I don't want "correct" beyond that, it should just be a flat-out error and park, even if it was accumulated over time. How can I achieve something close to this?
Re: Paducah Skies Observatory

Marcelo Figueroa
 

I am viewing your photos in Safari Mac OS and all the photos look correctly oriented.
 
(and by the way, the observatory is looking great).
Re: Paducah Skies Observatory

Christopher Erickson
 

Apple devices/apps often flip displayed photos to what they think is the correct orientation. 

Non-Apple devices/apps assume the originator of the photo has provided it in the orientation they wanted it displayed.

"My advice is always free and worth every penny!"

-Christopher Erickson
Observatory Engineer
Summit Kinetics
Waikoloa, Hawaii


Virus-free. www.avg.com


On Sat, Jun 19, 2021 at 1:23 PM Robert Chozick via groups.io <rchozick=aol.com@groups.io> wrote:
I fixed it for my phone and iPad but it is messed up on my browser.  Very strange.


On Jun 19, 2021, at 6:08 PM, Robert Chozick via groups.io <rchozick=aol.com@groups.io> wrote:

I noticed that it’s right side up on my computer and all which ways on my phone or iPad. I need to figure it out
> On Jun 19, 2021, at 5:52 PM, Mike Dodd <mike@...> wrote:
>
> On 6/19/2021 4:01 PM, Robert Chozick via groups.io wrote:
>> This is a link to a gallery showing details of my observatory:
>>
>> https://pbase.com/rchozick/image/171730847
>>
>> If you click on an image it will go back to the gallery of other pictures.
>
> Robert, Nice to chat with you this afternoon. Many of the photos are sideways or upside-down on my browser.
>
> --- mike
>
>
>
>
>
>
>












Re: Paducah Skies Observatory

Robert Chozick <rchozick@...>
 

I fixed it for my phone and iPad but it is messed up on my browser. Very strange.

On Jun 19, 2021, at 6:08 PM, Robert Chozick via groups.io <rchozick@...> wrote:

I noticed that it’s right side up on my computer and all which ways on my phone or iPad. I need to figure it out
On Jun 19, 2021, at 5:52 PM, Mike Dodd <mike@...> wrote:

On 6/19/2021 4:01 PM, Robert Chozick via groups.io wrote:
This is a link to a gallery showing details of my observatory:

https://pbase.com/rchozick/image/171730847

If you click on an image it will go back to the gallery of other pictures.
Robert, Nice to chat with you this afternoon. Many of the photos are sideways or upside-down on my browser.

--- mike
7721 - 7740 of 86813