Occasional error in guide speed - massive overcorrections


GuitsBoy
 

Hi All -

Ive searched on this topic a few times in the past, but not really getting any hits.  Please excuse me if this has already been covered, and I simply missed it.

I'm experiencing a strange issue on very rare occasions, and I cannot seem to find a pattern that causes this to happen.  I'll be all set up, and happily image my first target for the night using APT, PHD2 and Device Hub with the ASCOM driver. I'll finish my first run of subs, do a goto to the next target, and star guiding.  As soon as PHD2 issues the first small correction, the mount makes a MASSIVE correction, as if its guiding at full slew speed.   Ive attempted manually guiding at .5x, Ive attempted disconnecting the mount and issuing the :R1# command through Arduino Serial Monitor.  Ive disconnected and reconnected each program.  Nothing seems to help until I reboot the laptop, and power cycle the mount, starting from the home position.    This is really no big deal to do on occasion, since my telescope is just a few feet from my back door.  But how do people with remote observatories handle this?   BTW, I've experienced this same behavior with multiple onstep mounts, and different laptops, so I don't believe its isolated to my specific build, unless something was copied between the two.

Has anyone else experienced this?  Is there a common cause?  Any suggestions on how I can help narrow down the suspected software glitch?

Thanks,
-Tony


GuitsBoy
 

Just to update this, in case anyone else runs into the issue:

I found at least one cause of this pulse guide rate discrepancy. Seems if I issue any manual guide commands directly through APT, it will set OnStep pulse guide rate to whatever APT is configured for "m" or "s".  PHD wont realize this has changed and will attempt to guide expecting the normal slower rate.  To fix the issue on the fly, I have used the app to manually guide at the normal 0.5x rate, after which PHD2 guides correctly again. Additionally, you can manually guide through PHD2, however you need to change the guide rate and then change it back to the desired rate.   If you don't change the rate away and back, PHD2 will assume its already guiding at .5x and wont issue the command to set the guide rate.  At least that's the best I can figure.

So to sum up, its not an issue with OnStep, but a conflict between two different programs setting the guide rate and not knowing the other has changed it.

On 5/20/2021 8:11 AM, GuitsBoy via groups.io wrote:
Hi All -

Ive searched on this topic a few times in the past, but not really getting any hits.  Please excuse me if this has already been covered, and I simply missed it.

I'm experiencing a strange issue on very rare occasions, and I cannot seem to find a pattern that causes this to happen.  I'll be all set up, and happily image my first target for the night using APT, PHD2 and Device Hub with the ASCOM driver. I'll finish my first run of subs, do a goto to the next target, and star guiding.  As soon as PHD2 issues the first small correction, the mount makes a MASSIVE correction, as if its guiding at full slew speed.   Ive attempted manually guiding at .5x, Ive attempted disconnecting the mount and issuing the :R1# command through Arduino Serial Monitor.  Ive disconnected and reconnected each program.  Nothing seems to help until I reboot the laptop, and power cycle the mount, starting from the home position.    This is really no big deal to do on occasion, since my telescope is just a few feet from my back door.  But how do people with remote observatories handle this?   BTW, I've experienced this same behavior with multiple onstep mounts, and different laptops, so I don't believe its isolated to my specific build, unless something was copied between the two.

Has anyone else experienced this?  Is there a common cause?  Any suggestions on how I can help narrow down the suspected software glitch?

Thanks,
-Tony






Howard Dutton
 

Thanks for the heads up, I'll keep this interaction in mind.


GuitsBoy
 

While you're here, Howard, I was wondering if you might have any idea about a couple of things.

I know you don't use APT, but it seems I cannot use a slew rate slower than 2x sidereal, or 0.00835654 degrees/sec.  Anything lower than this results in an error.  I notice that the ASCOM device hub, under capabilities, it shows primary and secondary axis rates as .00833 - 2.00000.  Perhaps this is connected to the reason APT cant move slower than 2x?  Any way to adjust this?  I don't see anything obvious in the driver.  I assume this is a slew rate limitation and not a pulse guide rate limit, since I can manually pulse guide in PHD2 at 0.5x just fine.  However, confusingly, this seems to be what changes the pulse guide rate resulting in my wild overshoots while guiding.  I'm scratching my head trying to make sense of it.

Also, a quick side question that doesn't warrant it's own thread.  Is there any way to issue a Find/Home command or a Home/Reset command from ASCOM (device hub, poth, or any clients using the ASCOM driver)? 

Thanks for any insights,
-Tony



On 5/27/2021 10:37 AM, Howard Dutton wrote:
Thanks for the heads up, I'll keep this interaction in mind.


Khalid Baheyeldin
 

OnStep has a specific behaviour that people should keep in mind.
If you set the guide speed to anything less than 1X (i.e. 0.5X or 0.25X), it stays at what you selected.
But if you go and select 1X for any other reason, then 1X overrides 0.5X or 0.25X.

So mentally, I have to remember this, and do one of two workarounds:
- Never use 1X for any reason. That way the 0.5X I used for guiding 'sticks'.
- If I use 1X for whatever reason, then I go again and manually change the guiding speed to 0.5X again.


GuitsBoy
 

I was under the assumption that any guide speed was retained, be it .25x .5x or 1x.   I use .5x for guiding, but its quite possible that somethings was slewing at 1x.   However, the PHD over-corrections appear to be guiding at something like 4x or 8x, while the calibration was expecting 0.5x.  It does not appear to simply be double.  But I'll certainly keep this in mind.  Thanks.

On 5/27/2021 2:26 PM, Khalid Baheyeldin wrote:
OnStep has a specific behaviour that people should keep in mind.
If you set the guide speed to anything less than 1X (i.e. 0.5X or 0.25X), it stays at what you selected.
But if you go and select 1X for any other reason, then 1X overrides 0.5X or 0.25X.

So mentally, I have to remember this, and do one of two workarounds:
- Never use 1X for any reason. That way the 0.5X I used for guiding 'sticks'.
- If I use 1X for whatever reason, then I go again and manually change the guiding speed to 0.5X again.


Howard Dutton
 
Edited

On Thu, May 27, 2021 at 07:48 AM, GuitsBoy wrote:
I know you don't use APT, but it seems I cannot use a slew rate slower than 2x sidereal, or 0.00835654 degrees/sec.  Anything lower than this results in an error.  I notice that the ASCOM device hub, under capabilities, it shows primary and secondary axis rates as .00833 - 2.00000.  Perhaps this is connected to the reason APT cant move slower than 2x?  Any way to adjust this?
No.


Howard Dutton
 

On Thu, May 27, 2021 at 07:48 AM, GuitsBoy wrote:
Also, a quick side question that doesn't warrant it's own thread.  Is there any way to issue a Find/Home command or a Home/Reset command from ASCOM (device hub, poth, or any clients using the ASCOM driver)? 
ASCOM's FindHome() is implemented and this can be done.  I use my own software so not really sure about what others support it.


Howard Dutton
 
Edited

On Thu, May 27, 2021 at 11:32 AM, GuitsBoy wrote:
I was under the assumption that any guide speed was retained, be it .25x .5x or 1x.   I use .5x for guiding, but its quite possible that somethings was slewing at 1x.   However, the PHD over-corrections appear to be guiding at something like 4x or 8x, while the calibration was expecting 0.5x.  It does not appear to simply be double.  But I'll certainly keep this in mind.  Thanks.
I agree this seems like a bug.  Not sure if I want to fix it or not, for fear of breaking something in release-4.24 but the following is likely to be a low risk fix (untested.)

In the file Guide.ino add the following line just before enableGuideRate(guideRate); near lines 184 and 200.

if (pulseGuide) { guideTimerCustomRateAxis1=0.0; guideTimerCustomRateAxis2=0.0; activeGuideRate=-1; }

Let me know once you've checked it out.

For some background this is similar to the known issue with guide rates being wrong after spiral searches.  Easier to fix though, I think.

OnStepX has a guide subsystem design that should effectively address these annoying behaviors with custom guide rates (by virtue of its design.)


GuitsBoy
 

Thanks Howard.

I've downloaded the latest 4.24d, merged with my config and addons, and updated the guide.ino file.  I found that string on lines 164 and 200, and inserted the snippet of code directly above each instance found.   The changes compiled and flashed just fine on my test board.  Unfortunately I'm not sure how to test this other than under the stars, and no good weather on the horizon.  I'll reply once I've had a chance to test.

Thanks again,
-Tony


On 5/27/2021 3:52 PM, Howard Dutton wrote:
On Thu, May 27, 2021 at 11:32 AM, GuitsBoy wrote:
I was under the assumption that any guide speed was retained, be it .25x .5x or 1x.   I use .5x for guiding, but its quite possible that somethings was slewing at 1x.   However, the PHD over-corrections appear to be guiding at something like 4x or 8x, while the calibration was expecting 0.5x.  It does not appear to simply be double.  But I'll certainly keep this in mind.  Thanks.
I agree this seems like a bug.  Not sure if I want to fix it or not, for fear of breaking something in release-4.24 but the following is likely to be a low risk fix (untested.)

In the file Guide.ino add the following line just before enableGuideRate(guideRate); near lines 184 and 200.

if (pulseGuide) { guideTimerCustomRateAxis1=0.0; guideTimerCustomRateAxis2=0.0; activeGuideRate=-1; }

Let me know once you've checked it out.

For some background this is similar to the known issue with guide rates being wrong after spiral searches.  Easier to fix though, I think.

OnStepX has a guide subsystem design that should effectively address these annoying behaviors with custom guide rates.


Howard Dutton
 

On Thu, May 27, 2021 at 01:51 PM, GuitsBoy wrote:
Unfortunately I'm not sure how to test this other than under the stars, and no good weather on the horizon. 
I guess you could issue commands like this from the Arduino Serial Monitor:

Start tracking...
:Te#

Set rate 2 which is 1x sidereal then guide east for 2 seconds, RA axis (normally moving at 1x) should then stop for 2 seconds...
:R2#
:Mge2000#

Set axis1 custom guide rate to 2.0 degrees/second, then move east, then stop...
:RA2.0#
:Me#
:Q#

Without the new code the following should result in 2 seconds of rapid motion, with the new code it should act as before stopping tracking...
:Mge2000#