Catching up on my email and this thread - I have also noticed this issue since I started using APCC Pro and models late last year, I just haven't had the time or reason to run it to ground until now

Andy, One other possibility is that the move axis rate was near the maximum of 999.99x. Then, when moving to the West, the tracking correction rate subtracted from 999x, which was a legal move rate.

Andy, I also tried using a serial port connection to the mount, which to APCC is the same as the virtual COM port in a USB connection. Again, there was no unexpected behavior. The only thing left is

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through USB.

Andy, Here's a video that I just created to try to reproduce the issue you are seeing. In my case, NINA and APCC work correctly: https://youtu.be/_LjjM42UPQE It was difficult to see any of your

Here is a brief video showing what I am seeing. I'm starting to get hang of YouTube video uploading! https://youtu.be/A-Q0RwHu8ik

Andy, That won't change the behavior. That simply changes how the rates are shown in the status fields. Assuming MoveAxis was being used, I have confirmed that the behavior is the same with or

This is a non issue to me because now I know to turn off tracking correction should I use the automated 3PPA in Nina. That should be done anyway as Ray pointed out. As far as I can tell other move

To the OP, A few weeks ago, I upgraded Windows 10 to 19043, and began having problems with a number of applications. This included the same sort of problems you have mentioned. I installed APCC and

The ASCOM MoveAxis method takes two parameters: an axis number and a rate in degrees/second. When initially defined (years ago) the rates were intended to be independent of sidereal rate, for anything

Ray said: So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where "supposed to" is apparently clouded in lack of a clear standard, but in this case

Hi Linwood and Andy, I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding the rate supplied to it whether or not pointing and/or tracking rate

Andrea wrote: Linwood, Can you remind me your mount type? About one year ago I saw something similar in Skyx but I thought was because the mount was new ( Mach 2). After that I learned to use the

Linwood, Can you remind me your mount type? About one year ago I saw something similar in Skyx but I thought was because the mount was new ( Mach 2). After that I learned to use the move commands in

Ray wrote: Ray wrote: Just to circle back around this one, I contacted the INDI developper and that specific issue (leading space character int the FITS header RA/DEC coordinates) has been fixed in

About 3 hours of integration of Ha.

Hi Ray, Last session was the first night of actual data capture. Bin1 scale is 0.47 arcsec/pixel PEM, Dec arc tracking, refraction all ON Model spacing was very small (attached). Tacking was good

Andrea, Did something similar didnt see much in 5 minutes or so. I can refine things more now. Thank, -Rouz

Testing last night and I got the same results...I am not sure where to go next. The plot is nearly identical to the one the night before. This is after I backed off the dec motor to allow

Ray: Yeah, I understand the feeling, I find it hard to believe you can get any actual development done with the volume of email. The mixed blessing of having people actually use the software you