Hi Bill,

I just went through all of my settings and the only thing I could see that was off, was the polling for my elevation. It
was being reported to APPM by the driver as 0, and now its properly reporting 172 meters. I dont suppose this
would have any impact?

That is irrelevant for dec arc tracking. Maybe the only room for error is in the accuracy of the plate solutions.

-Ray

I had an unexpected clear night, with clouds threatening, so decided to burn a few hours collecting data on this subject.

The short version of what I found was: I don't know what I found and think I have no useful data.  But this is a long ramble about what I did collect: 

About 2/3rds of the way through all this I decided to go back and redo the polar alignment (I was using NINA).  I started with 23" of total error, and built a model and did a bunch of testing and maybe 2 hours later reran the polar alignemnt and was off by about 2'.

I did numerous slews, and returns and reruns of the polar alignment and it moved around a fair amount, e.g. 

1'43" x -1'08"
57" x 43"
1'24" x 1.07"

Those are consecutive runs after slewing 10 degrees or so away and back.

I did some more tests and then ran PA again in NINA, adjusted to nearly zero, reran (minimal slews) and was off 7", then ran sharpcap and it said 47" off.  Reran NINA and it now said 2'13".

I just have no clue what is going on, but I suspect it invalidates anything I am doing with the models.  Either that or NINA's polar alignment routine is not working well, but it was consistent when i reran it more or less in place, without slewing around.

This is a 4" refractor, using an OAG, nice hefty M68 image train on a reasonably quality OTA (NP101is). It really doesn't seem like it should be moving all around.  The mount is on a Berlebach Planet with the spikes in holes (to self center) on pavers which in turn are in a bed of gravel, and have been undisturbed for over a year.  

Anyway, in the FWIW department, in terms of modeling - I did a 74 point DEC Arc, 3 arcs, 1 degree spacing.  I grabbed the second image it took and ran through astrometry.net and it agreed with astap: 

At worst that last DEC angle has a different rounding, but basically they agreed.  It's too tedious to run them all through astrometry to test, but this spot check said it was on point.

I then did a whole series of 400s guide assistant runs, first aimed east, then aimed west, both times about an hour away from the meridian.   Seeing was very good (for example now that I'm guiding I am getting 0.16" RMS error even though i just realized I forgot and left it on 1.5s exposures -- really good seeing (lousy transparency, but good seeing).  I did not refocus during any of those (so no shift from focusing, though it really does not shift significantly even if I did). 

Tests ((east and west are imaging direction not pierside): 

1) With model, east, error 2.1", -2.62"   (these are peak RA and DEC error, not peak-to-peak, just peak). 
2) Without model, east, error 1.77", -2.63"   (effectively no difference)
3) With model, PA adjustments off, east, error 0.80", -3.53" 
4) With model (repeat of 1), -1.10", -4.43"

Approaching meridian, checked PA, adjusted back (at least in theory it now matched where I started) 

5) With model, west, error -5.76", 1.04"
6) Without model, west, error -6.1", 2.07"

Did PA check again, clouds came in, moved back east: 

7) Without model, east, 2.15", 1.5"
8) With model, east, 2.13", 2.05"
9) With model, without PA terms, east, 1.74", 2.37"

The bottom line for me is I see so much variation that I do not think the differences in with/without the model, with/without the PA terms, or east/west make any difference.  Since I think the PA runs itself are likely to be consistent calculations, I think something else is moving around.  I am just at a loss as to what. 

Fortunately I am happy to guide.  Still at 0.16" RMS guiding, happy. 

But puzzled.  I will give it a more thoroughly look in the morning, but just not sure what could be moving around.  Especially in azimuth -- I might believe there's give in the ground for the heavy leg to settle a bit, but left/right? 

Anyway... Apparently I have nothing useful to contribute to the "what's wrong with the DEC Arc models". I'm on the "what part of my setup is put together with rubber instead of metal". 

Linwood

PS. If anyone wants to guess at the problem with the setup, I suspect photos will help: 

https://photos.smugmug.com/AstroEquipment/i-8CC6BMk/0/2f978863/X5/PXL_20220709_002945842.MP-X5.jpg
https://photos.smugmug.com/AstroEquipment/i-D7KwHGg/0/2800ffd1/X5/PXL_20220709_003003935-X5.jpg
https://photos.smugmug.com/AstroEquipment/i-VpN4DMn/0/6d841d0b/X5/PXL_20220709_003019197-X5.jpg
https://photos.smugmug.com/MyT/i-FgWvLKk/0/8ddc992f/X2/A9B00797_111541-X2.jpg

During the start of APCC, I get the a message, Virtual Serial Port ActiveX Control is not registered in this system, see attached file 2. then I get a second message, Error creating virtual port 1 control. You must have a license to use this Active control. I would appreciate any help with this matter.

Thank you

John Maikner

Looks like I may have to upgrade my 900 to a CP4. Is there any word on when the next batch will be available? The website has it in “register to be notified” mode. 

Chip 

Hi,
I am trying upgrade GTOCP4 firmware to VCPx-PO2-13 using download options.  USB/Serial Utility with Auto-download option. I connect to the mount with no problem. The utility states that a firmware update is available. Use the load tab to update and click on Update from Internet to update firmware automatically and I get the following message.

Getting files on-line
Exception tempFile.zip (ACCESS is denied)
Unable to get updates from internet. 

Thank you for all your future help.

John Maikner

I had similar issues with my C14, and it was creep with the mirror.  My C14 is not an Edge, so I made my own mirror locks that lock the mirror pretty effectively.  Now I have no issues and only have a 1 second settle time.   

Hi Chris,

My mount was polar aligned. Within 30 arcseconds for AZ and 20 for Alt, according to the APPM model. Sharpcap
said I was below 10 arcseconds for both (which I don't trust fully).

Why would you misalign to test this?

The presumption made by Bill is that the tracking rate correction for polar misalignment is incorrect.

So, building a model when the mount is not well polar aligned should cause even dramatic tracking errors that exceed the magnitude of the other types of errors. If I can reproduce the tracking error, I can confirm a fix by seeing that tracking works well with poor polar alignment.

-Ray

On Tue, Jul 19, 2022 at 09:42 PM, Ray Gralak wrote:

Chris,

I suggest you not launch the AP V2 driver from APCC. It seemed like a good idea when I put that feature in, but it's really not needed.

Regarding APCC not closing, that can happen if the ASCOM driver was left open because of another application closing or getting aborted without properly disconnecting from the driver.

-Ray

All of my current testing is with APCC only.  No other applications are connected to the V2 Driver.  Just APCC.  In the case that I just experienced I manually disconnected the driver and mount prior to closing APCC.  The driver window closed.  Then I shut APCC down (successfully)  The next launch of APCC failed, and thats when I found the driver as a background process. 

Chris,

I suggest you not launch the AP V2 driver from APCC. It seemed like a good idea when I put that feature in, but it's really not needed.

Regarding APCC not closing, that can happen if the ASCOM driver was left open because of another application closing or getting aborted without properly disconnecting from the driver.

-Ray

--

I have both of the "auto" boxes checked, but have not tried clicking the "Now" button when I experience this issue.  I can try that next time APCC opens and does not launch the driver.  Although, I'm not sure how that would help if the driver is running as a background process an inaccessible by APCC. 

--

On Tue, Jul 19, 2022 at 09:21 PM, Brian Valente wrote:

Chris - when you open apcc, are you opening it directly (i.e., clicking on apcc) or are you opening it via an external app like NINA, SGP, etc. where it opens up APCC and then it attempts to connect to the ascom driver?

toggle quoted messageShow quoted text

 

On Tue, Jul 19, 2022 at 6:17 PM Chris White <chris.white@...> wrote:

Ray,

A little more information on this issue.  It just happened to me again.  APCC opened, connected to the mount but did not connect to the driver.  No pop-ups, no error messages.

I tried to close APCC, and it opened the "closing" pop up and then froze.  Nothing additional happened and no additional pop-ups.

I found in task manager that the ASCOM driver was an active background process despite the driver not opening or connecting. 

I suspect that when I disconnected and shut APCC down the previous time, that for some reason the driver didnt close and this prevented APCC from being able to connect on the next startup. 

The good news is, that I was able to close just the driver with task manager, and this immediately allowed APCC to finish it's own shut down.  Also, the virtual port was not lost for good, and when I launched APCC again, everything connected perfectly, and the old virtual port was used. 

Why the driver isnt closing for me, and causing this issue... I have no idea. 

 

 

 

--

Brian 

Brian,

I always open it directly.  Thanks for the help!

--

Hi Bill,

Based on the log data it shows Dec Arc was indeed active. While the rate values in the UI did not change the
images certainly did after disabling those terms.

The rate values displayed in the UI are calculated from values read back from the mount. If the rate shown in the UI did not change,
then the mount's rate did not change.

If you are within a valid Dec Arc region, the polar alignment terms have *absolutely* no effect. I have confirmed this by stepping
through the code. So, I cannot explain why you saw drift when unchecking the checkboxes except that it was coincidence.

-Ray

Ray,

A little more information on this issue.  It just happened to me again.  APCC opened, connected to the mount but did not connect to the driver.  No pop-ups, no error messages.

I tried to close APCC, and it opened the "closing" pop up and then froze.  Nothing additional happened and no additional pop-ups.

I found in task manager that the ASCOM driver was an active background process despite the driver not opening or connecting. 

I suspect that when I disconnected and shut APCC down the previous time, that for some reason the driver didnt close and this prevented APCC from being able to connect on the next startup. 

The good news is, that I was able to close just the driver with task manager, and this immediately allowed APCC to finish it's own shut down.  Also, the virtual port was not lost for good, and when I launched APCC again, everything connected perfectly, and the old virtual port was used. 

Why the driver isnt closing for me, and causing this issue... I have no idea.