Progress and Questions

[Mark McComiskey]

So, finally, progress.  ASA produced an updated version of their software, and I finally figured out the magic combination of settings in their software to make it work with PHD2 (largely thanks to your help!).

I ran a full session last night.  There is a physical problem with the RA axis of the mount, which shows up fairly clearly in the mount (its drift is 15x greater than spec, while the Dec axis is dead on). 

I spent some time slowly tweaking settings to try and dial in an optimal level of guiding performance, with more aggressive correction for RA given the problem.

Seeing as measured by a seeing monitor was between 1.7" and 2.3" all of last night.

Overall performance was fine, but a little disappointing for a mount of this caliber.  The ASA multistar guiding software is managing to get to about 25% lower RMS values, using 9 second exposures, no delay and 70% aggressiveness, but the software has no documentation so I don't know how to replicate that in PHD2, and their software is not user friendly, is unstable and is incompatible with any other software, so I am committed to Phd2.

I have two questions:

1. Are there any obvious settings I should look to change to improve performance here?  The logs will show several that I have tried.

2. At approximately 2:25am, the RA axis ran away, very quickly.  My attempt to parse the logs has failed to yield an explanation.  Any insight would be appreciated.

[Mark McComiskey]

This time with the logs:

https://openphdguiding.org/logs/dl/PHD2_logs_tw3M.zip

[Bruce Waddington]

You have a couple of problems remaining, one is minor.  Because of the settings you have in the mount driver, you need to enable the PHD2 option to 'Reverse Dec output after meridian flip' (Advanced Settings/Guiding).  Don't fiddle around with the mount driver options anymore, just check this box in PHD2 and move on.  This is why you were having to recalibrate after meridian flips.  The second problem you will need to track down is the abrupt excursions in RA,  As you noted, it happened at 02:25 but it also showed up during the Guiding Assistant run at 21:30.  Neither of these were caused by guiding.  The usual explanation is a cable pull or something else that is interfering with the sidereal tracking of the mount.  But with all the problems you're having with the driver, I suppose it could be causing the problem. 

Don't make the mistake of chasing guiding statistics, the results you are getting are normal for a mount of this class.  They are only roughly correlated with the results you will be getting for imaging.  If you want to increase your guide exposure times up to 9-10 sec, the statistics will probably look better but you won't see better results in your images.  And the downside is that operations like dithering will take much longer to complete.  These are some of the reasons we developed the variable delay feature.  Keep in mind that the seeing monitor results may not correlate with what you're doing because those measurements are taken at the NCP and "adjusted" to estimate seeing at the zenith.  This ignores the reality that seeing is quite often sensitive to sky location. IMO, you should be measuring FWHM and eccentricity in your main camera images to judge the quality of your imaging operation - a direct measure of what you actually care about.

Regards,

Bruce

[Mark McComiskey]

Thanks much!

[Mark McComiskey]

Okay, so still trying to work out what seems to be the last issue.  I set things up the way you suggested, and enabled the PHD2 option to 'Reverse Dec output after meridian flip.  Ran a calibration.  Mount tracks well when i start tracking before the meridian flip and also if I start tracking after the meridian flip (as you will be able to see in the logs).

However, when I am running a NINA sequence and the tracking starts on one side of the meridian and then resumes on the other side, it seems to go crazy.  If I just stop everything and restart it works well again.

I've moved the mount to the physical position where the problem occurs and can't find any bumps, cable catches or other physical factors that might be causing the problem.  The mount seems to move freely in that position.  

Any ideas what might be causing the problem?  It shows up at 23:02.

https://openphdguiding.org/logs/dl/PHD2_logs_3W9Q.zip

Best regards,

Mark

[Bruce Waddington]

Since you didn't have to re-calibrate or do anything else to fix the problem, I would say it doesn't have anything to do with guiding, the mount settings, or even the mount mechanics.  Is this problem 100% reproducible?  When you are chasing meridian flip related problems like this, you can't just manually slew the scope to the east side of the pier and start looking.  You have to put the mount and scope through a full meridian flip process in order to see any cable routing problems.  In other words, it isn't just a matter of where the scope was when the problem emerged, it's a matter of how the telescope reached that position.  The mount controller will move the scope on a particular path to execute the meridian flip, and that path may not be obvious to anyone.  These problems can be a real PITA to track down because they may not be reproducible even with an exact duplication of the beginning and ending positions.  Any time a cable or a cable bundle is dragging across a stationary surface, there is a possibility of trouble.  I can't think of anything else that would explain this assuming everything on your OAG assembly is locked down.

Good luck,

Bruce

[Brian Valente]

Mark remind me, are you using a rotator?

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/706972c2-c550-47cd-b806-af7a989b0c86n%40googlegroups.com.

--

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

nature portfolio brianvalentephotography.com 

other astronomy https://www.brianvalentephotography.com/astrophotography/ 

[Mark McComiskey]

No rotator. My astrophotography life is already complicated enough without that!

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Brian Valente <bval...@gmail.com>
Sent: Monday, April 22, 2024 12:53:00 PM
To: open-phd...@googlegroups.com <open-phd...@googlegroups.com>
Subject: Re: [open-phd-guiding] Re: Progress and Questions

 

You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/V8-ZHOO7sgU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i66wum57xC5O5-9O9ZX8B0qefzHRK4-Duw7o5Y2vM-OMA%40mail.gmail.com.

[Mark McComiskey]

So, same problem again tonight, and I had Ivan from Obstech actually sitting at the mount checking for any possible constrictions or other physical impediments.  There do not appear to be any.  Looking at the graphs, I wonder if PHD@ or the mount are confused about which side the mount is on.  But PHD2 seems to be reporting the switch in sides, and it must be getting that info from the mount, and the polarity for the mount is reported but PHD2 as the same both before and after the flip.  What is so strange is that if I stop guiding, and immediately restart it, everything starts working fine again. No adjustments to any settings anywhere, just stopping and restarting...

[mj.w...@gmail.com]

You are using NINA as well as PHD2.

Does NINA have side of pier setting ?

Michael 

Wiltshire UK

[Mark McComiskey]

It does and it is on. 

[bw_m...@earthlink.net]

This is getting mysterious although we probably have a hunch about where the problem will lie. 😊  I’d like to get way into the details of this particular meridian flip operation.  Can you send me the usual PHD2 log files along with the NINA log file for last night?  I assume the meridian flip is triggered by NINA in the usual way?  Can you tell me the criteria you’ve configured in NINA to determine when the sequence should be paused and the scope flipped?

 

Regards,

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/3d43b520-1ea0-42d6-953d-b7ab0b8a1c35n%40googlegroups.com.

[Mark McComiskey]

Absolutely!!

1. PHD2 log files:

https://openphdguiding.org/logs/dl/PHD2_logs_Cg5Q.zip

2. Screenshots of Meridian Flip Settings in NINA and the mount software

3. NINA log

4. Screenshot of runaway moment after meridian flip, which happens in the 22:50-11:00 period of time.

[Bruce Waddington]

I can't see anything wrong here, all the NINA commands look fine and PHD2 is getting the correct side of pier.  I do see some entries in the NINA log suggesting it may set the side-of-pier property but I don't know what to make of that.  What happens if you start a NINA sequence that ends while still on the west side of pier and then start a subsequent sequence on a second target that's already in the western sky - such that the slew to the second target will naturally flip the mount and NINA won't do anything about meridian flipping.  Does that work?  I believe you said earlier that without NINA running, you can manually flip the mount and the guiding works correctly on both sides. 

Bruce

[Mark McComiskey]

I will set up a sequence to do that and report back. Hanger roof is closed tonight so out of luck. 

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Bruce Waddington <bw_m...@earthlink.net>
Sent: Tuesday, April 23, 2024 10:48:59 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/0023382b-0896-4295-bb30-5719dd3fcbc6n%40googlegroups.com.

[Brian Valente]

Mark what roof are you in at Obstech?

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/MN2PR20MB3263D689AF25095DFF7E7253FC102%40MN2PR20MB3263.namprd20.prod.outlook.com.

[mccom...@gmail.com]

Roof 7.  You?

 

Not sure why it is closed.  Allsky camera seems clear….

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i6YFrCZxrcKi2jw%3D7qdGtZ%3D%2BpzoEHcEjy6wBmfWQFvGnQ%40mail.gmail.com.

[Brian Valente]

Roof 5 - who knows

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/002401da95f7%24b29486f0%2417bd94d0%24%40gmail.com.

[Dale Ghent]

Seems like high clouds or haze. The sky temperature has trended up since this afternoon into the "partly cloudy" band. I'm waiting for bay 7 to open as well.

https://www.obstech.org/weather/graphs.html

/dale

> On Apr 23, 2024, at 23:30, Brian Valente <bval...@gmail.com> wrote:
>
> Roof 5 - who knows
>
> On Tue, Apr 23, 2024 at 8:30 PM <mccom...@gmail.com> wrote:
> Roof 7. You?
> Not sure why it is closed. Allsky camera seems clear….
> From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Brian Valente
> Sent: Tuesday, April 23, 2024 11:28 PM
> To: open-phd...@googlegroups.com
> Subject: Re: [open-phd-guiding] Re: Progress and Questions
> Mark what roof are you in at Obstech?
> On Tue, Apr 23, 2024 at 8:27 PM Mark McComiskey <mccom...@gmail.com> wrote:
> I will set up a sequence to do that and report back. Hanger roof is closed tonight so out of luck.

> Get Outlook for iOSFrom: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Bruce Waddington <bw_m...@earthlink.net>

> Sent: Tuesday, April 23, 2024 10:48:59 PM
> To: Open PHD Guiding <open-phd...@googlegroups.com>
> Subject: Re: [open-phd-guiding] Re: Progress and Questions I can't see anything wrong here, all the NINA commands look fine and PHD2 is getting the correct side of pier. I do see some entries in the NINA log suggesting it may set the side-of-pier property but I don't know what to make of that. What happens if you start a NINA sequence that ends while still on the west side of pier and then start a subsequent sequence on a second target that's already in the western sky - such that the slew to the second target will naturally flip the mount and NINA won't do anything about meridian flipping. Does that work? I believe you said earlier that without NINA running, you can manually flip the mount and the guiding works correctly on both sides.
> Bruce
> On Tuesday, April 23, 2024 at 10:52:14 AM UTC-7 mccom...@gmail.com wrote:
> Absolutely!!
> 1. PHD2 log files:
> https://openphdguiding.org/logs/dl/PHD2_logs_Cg5Q.zip
> 2. Screenshots of Meridian Flip Settings in NINA and the mount software
> 3. NINA log
> 4. Screenshot of runaway moment after meridian flip, which happens in the 22:50-11:00 period of time.
> On Tuesday, April 23, 2024 at 11:04:48 AM UTC-4 bw_m...@earthlink.net wrote:
> This is getting mysterious although we probably have a hunch about where the problem will lie. 😊 I’d like to get way into the details of this particular meridian flip operation. Can you send me the usual PHD2 log files along with the NINA log file for last night? I assume the meridian flip is triggered by NINA in the usual way? Can you tell me the criteria you’ve configured in NINA to determine when the sequence should be paused and the scope flipped?
> Regards,
> Bruce
> From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Mark McComiskey
> Sent: Monday, April 22, 2024 9:31 PM
> To: Open PHD Guiding <open-phd...@googlegroups.com>
> Subject: Re: [open-phd-guiding] Re: Progress and Questions
> So, same problem again tonight, and I had Ivan from Obstech actually sitting at the mount checking for any possible constrictions or other physical impediments. There do not appear to be any. Looking at the graphs, I wonder if PHD@ or the mount are confused about which side the mount is on. But PHD2 seems to be reporting the switch in sides, and it must be getting that info from the mount, and the polarity for the mount is reported but PHD2 as the same both before and after the flip. What is so strange is that if I stop guiding, and immediately restart it, everything starts working fine again. No adjustments to any settings anywhere, just stopping and restarting...
> On Monday, April 22, 2024 at 1:04:00 PM UTC-4 Mark McComiskey wrote:
> No rotator. My astrophotography life is already complicated enough without that!

> Get Outlook for iOSFrom: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Brian Valente <bval...@gmail.com>

> To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i53LvKSJpY72qZqRKYSPiuK%2BQR3sLaHgLhP%2B%3Dt8p_BPRw%40mail.gmail.com.

[mccom...@gmail.com]

Dale - missed you at NEAIC! I was hoping to miss you in person. What scope do you use in Bay 7?

Unfortunately, I think it is lights out time for me. Back to trying to figure out this problem tomorrow.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/63E2D6C4-4DA9-49B7-A308-BC2FED37575D%40elemental.org.

[mccom...@gmail.com]

Rereading this.  Will try to run the test you describe tonight.  Not sure what your question is about setting the side of pier property?  I am not an expert, but I believe that NINA isn’t setting the property to a value, rather it is accomplishing the flip by sending a “side of pier” instruction to the mount software, and that it what the log is referring to when it says “setting pier side was successful”.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/0023382b-0896-4295-bb30-5719dd3fcbc6n%40googlegroups.com.

[Dale Ghent]

NINA doesn't set SideOfPier. In the general world of mount drivers, a settable SideOfPier is optional to implement, so NINA's flip logic does not rely on a settable SideOfPier. NINA just reads SideOfPier's value to know if a flip is required; using it as a source of truth regarding mount pointing state.

If it's a driver where SideOfPier lies, as has often been the case with certain mount drivers in the past because of some ambiguity around what "Side of pier" means, NINA offers an option to ignore that driver property and instead attempt to infer if a flip is needed based on time and the RA that the mount is reporting itself to be pointing at. As a rule, though, it is preferable to have NINA's "Use side of pier" option set ON unless one is inflicted with a mount that lies about its pointing state.

/dale

> On Apr 24, 2024, at 14:00, <mccom...@gmail.com> <mccom...@gmail.com> wrote:
>
> Rereading this. Will try to run the test you describe tonight. Not sure what your question is about setting the side of pier property? I am not an expert, but I believe that NINA isn’t setting the property to a value, rather it is accomplishing the flip by sending a “side of pier” instruction to the mount software, and that it what the log is referring to when it says “setting pier side was successful”.
> From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Bruce Waddington
> Sent: Tuesday, April 23, 2024 10:49 PM
> To: Open PHD Guiding <open-phd...@googlegroups.com>
> Subject: Re: [open-phd-guiding] Re: Progress and Questions
> I can't see anything wrong here, all the NINA commands look fine and PHD2 is getting the correct side of pier. I do see some entries in the NINA log suggesting it may set the side-of-pier property but I don't know what to make of that. What happens if you start a NINA sequence that ends while still on the west side of pier and then start a subsequent sequence on a second target that's already in the western sky - such that the slew to the second target will naturally flip the mount and NINA won't do anything about meridian flipping. Does that work? I believe you said earlier that without NINA running, you can manually flip the mount and the guiding works correctly on both sides. Bruce
> On Tuesday, April 23, 2024 at 10:52:14 AM UTC-7 mccom...@gmail.com wrote:
>>
>>
>> Absolutely!!
>> 1. PHD2 log files: https://openphdguiding.org/logs/dl/PHD2_logs_Cg5Q.zip
>> 2. Screenshots of Meridian Flip Settings in NINA and the mount software
>> 3. NINA log
>> 4. Screenshot of runaway moment after meridian flip, which happens in the 22:50-11:00 period of time.
>> On Tuesday, April 23, 2024 at 11:04:48 AM UTC-4 bw_m...@earthlink.net wrote:
>>>
>>>
>>> This is getting mysterious although we probably have a hunch about where the problem will lie. 😊 I’d like to get way into the details of this particular meridian flip operation. Can you send me the usual PHD2 log files along with the NINA log file for last night? I assume the meridian flip is triggered by NINA in the usual way? Can you tell me the criteria you’ve configured in NINA to determine when the sequence should be paused and the scope flipped?
>>> Regards,
>>> Bruce
>>> From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Mark McComiskey
>>> Sent: Monday, April 22, 2024 9:31 PM
>>> To: Open PHD Guiding <open-phd...@googlegroups.com>
>>> Subject: Re: [open-phd-guiding] Re: Progress and Questions
>>> So, same problem again tonight, and I had Ivan from Obstech actually sitting at the mount checking for any possible constrictions or other physical impediments. There do not appear to be any. Looking at the graphs, I wonder if PHD@ or the mount are confused about which side the mount is on. But PHD2 seems to be reporting the switch in sides, and it must be getting that info from the mount, and the polarity for the mount is reported but PHD2 as the same both before and after the flip. What is so strange is that if I stop guiding, and immediately restart it, everything starts working fine again. No adjustments to any settings anywhere, just stopping and restarting...
>>> On Monday, April 22, 2024 at 1:04:00 PM UTC-4 Mark McComiskey wrote:
>>>>
>>>>
>>>> No rotator. My astrophotography life is already complicated enough without that!

>>>> Get Outlook for iOSFrom: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Brian Valente <bval...@gmail.com>

> To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/00f901da9671%2442795650%24c76c02f0%24%40gmail.com.

[mccom...@gmail.com]

Very clear. Thank you. Gives me something else to try, thought the driver appears to be giving PHD2 the correct pierside. But then, for the sake of clarity, what does this NINA log entry mean when it says "Setting pier side was successful"?

2024-04-22T22:41:22.2652|INFO|AscomTelescope.cs|MeridianFlip|382|Finished slewing to coordinates. Slew was successful. Setting pier side was successful

-----Original Message-----
From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Dale Ghent
Sent: Wednesday, April 24, 2024 2:07 PM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding] Progress and Questions

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/BC11973F-B4E5-4DD7-95BD-70E7EE6AE99C%40elemental.org.

[bw_m...@earthlink.net]

Thanks for the clarification, Dale, that's how I thought NINA would probably work. I'm really grasping at straws on this problem and can't come up with a plausible explanation. I suspect it's another bug in this new driver that won't be apparent to anyone not having access to the source code.

Bruce

-----Original Message-----
From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Dale Ghent
Sent: Wednesday, April 24, 2024 11:07 AM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding] Progress and Questions

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/BC11973F-B4E5-4DD7-95BD-70E7EE6AE99C%40elemental.org.

[bw_m...@earthlink.net]

One other point for the next test.  If the problem recurs when you do the two consecutive NINA imaging sequences on opposite sides of the pier, could you re-affirm that it works correctly using just PHD2?  I know you tried that earlier and found that it worked but I’d like to double-check so that we don’t end up chasing our tails.

 

Thanks,

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/00f901da9671%2442795650%24c76c02f0%24%40gmail.com.

[Mark McComiskey]

Okay.  Homework complete.  This is beginning to drive me crazy.

Step 1:  Start a NINA sequence and have it follow a target through a meridian flip.  Guiding works fine until the meridian flip.  RA axis runs away like crazy.  NINA, the mount software and PHD2 all seem to report the MF happening, so all seem to be aware, but RA axis guide pulses send the mount in the wrong direction.

Step 2: leave NINA and mount software untouched, sequence still running, but stop and immediately restart guiding in PHD2.  Magically, the RA problem is fixed, and guide pulses now cause RA axis to move in correct direction. AGAIN - nothing changed in NINA or mount software, didn't even stop the NINA sequence.  Just toggled guiding on and off in PHD2 directly, and that resolves the problem.

Step 3: shut down NINA and PHD2, restart everything, and run the sequence you suggested, with imaging on one side of the meridian and then a slew to a target on the other side of the meridian.  PHD2 guiding works flawlessly.  

I am at a loss. 

Attaching NINA logs as well as the PHD2 log link above.  Would love any ideas here.

[Mark McComiskey]

Sorry, left out step 4: shut down everything and restart. No Nina. Slew to one side of meridian and start guiding. Everything okay. Stop guiding. Slew to other side of meridian and start guiding. Everything okay. 

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Mark McComiskey <mccom...@gmail.com>
Sent: Thursday, April 25, 2024 00:51

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/75465131-21ac-47f9-a1a9-aa1c3684d149n%40googlegroups.com.

[Mark McComiskey]

To make things more complicated:

https://openphdguiding.org/logs/dl/PHD2_logs_ciEf.zip

Before I went to bed last night, I shut down all programs, restarted and set NINA to work imaging a new target.  It ran all night, guiding, and went through a meridian flip around 3:10am.  guiding worked both before and after the flip.  No runaway RA axis issues.  Unlike the flip that happened around 10:40pm.

So, yeah.  Tearing my hair out.

Trying to reason this through:

1. The mount is in fact flipping physically (I can watch it on a camera).  NINA and PHD2 are reporting the correct side of the pier, and show the pier side changing as the flip completes.  So the mount driver appears to be giving correct information to NINA and PHD2.

2. When the runaway RA axis happens, I can fix it by going into PHD2, stopping guiding and restarting it immediately.  This seems to imply a copule of things.  First that this is not a physical issue, because if it were, it would not be resolved instantly by simply stopping and restarting guiding.  Also, that this is not a mount driver issue, because the mount driver has no way to know that I have stopped and restarted PHD2 guiding.

3. That leaves NINA and PHD2.  NINA is aware that guding is stopped and started, but to the best of my understanding, NINA is not an intermediary between PHD2 and the mount sriver.  NINA simply reports the status of each.  So NINA seems unlikely to be creating any issues.

4. That leaves PHD2.  I looked as closely as I know how at the logs immediately after the MF in the period when the RA axis is running away, and then the log for the immediately subsequent period (after stopping and restarting guiding) when the RA axis behaviour is as expected.  It seems to me like all the settings in PHD2 is the same in both instances.  Its understanding of the mount position and behavior seems to be the same in both instances.  

So I have no idea where to look from here.  Any thoughts?

[Dale Ghent]

The thing to keep in mind here is that the ASCOM driver interfaces that any app uses to guide, slew, or drive the axes of a mount around are *highly* abstracted interfaces. What I mean by that is that the use and operation of these different interfaces have very well-defined inputs and behaviors that result from those inputs.

PHD2's use of the PulseGuide interface for nudging a mount around to effect guiding corrections is expected to be handled the same way whether it's a sky-watcher EQ6, or an ASA, or a 10micron, and so on. If you lined up mounts A, B and C, each from different vendors, and they all act the same way but mount D goes off on a wild journey when the same action that performed correctly on mounts A-C is performed on it, then the eye of suspicion is immediately cast upon mount D. Something is up with either its driver or perhaps even its firmware. Unfortunately the driver might suffer from insufficient logging that might explain or hint at the problem, and the firmware is certainly going to be a black box of mystery so there's no telling what's going on inside it. This is where the vendor needs to be engaged to discern why the mount is reacting the way it is to otherwise sane or typical input.

In the case of your ASA, it's not completely out of the question that the mount's internal sense of its state gets upset, not updated, or just does something flatly wrong relating to crossing the meridian. The might be caused by a misconfiguration or even a bug in either the mount's ASCOM driver or firmware - again, the vendor is the subject-matter expert when it comes to their own products, so I would hope that they might be able to explain why the mount is reacting the way it is. You've narrowed it down to a specific sequence of events. Between their driver's logs and their own familiarity with the inner-workings of their product, they should be able to explain why this may be happening, or realize if there is a problem.

> On Apr 25, 2024, at 10:05, Mark McComiskey <mccom...@gmail.com> wrote:
>
> To make things more complicated:
>
> https://openphdguiding.org/logs/dl/PHD2_logs_ciEf.zip
>
> Before I went to bed last night, I shut down all programs, restarted and set NINA to work imaging a new target. It ran all night, guiding, and went through a meridian flip around 3:10am. guiding worked both before and after the flip. No runaway RA axis issues. Unlike the flip that happened around 10:40pm.
>
> So, yeah. Tearing my hair out.
>
> Trying to reason this through:
>
> 1. The mount is in fact flipping physically (I can watch it on a camera). NINA and PHD2 are reporting the correct side of the pier, and show the pier side changing as the flip completes. So the mount driver appears to be giving correct information to NINA and PHD2.
>
> 2. When the runaway RA axis happens, I can fix it by going into PHD2, stopping guiding and restarting it immediately. This seems to imply a copule of things. First that this is not a physical issue, because if it were, it would not be resolved instantly by simply stopping and restarting guiding. Also, that this is not a mount driver issue, because the mount driver has no way to know that I have stopped and restarted PHD2 guiding.
>
> 3. That leaves NINA and PHD2. NINA is aware that guding is stopped and started, but to the best of my understanding, NINA is not an intermediary between PHD2 and the mount sriver. NINA simply reports the status of each. So NINA seems unlikely to be creating any issues.
>
> 4. That leaves PHD2. I looked as closely as I know how at the logs immediately after the MF in the period when the RA axis is running away, and then the log for the immediately subsequent period (after stopping and restarting guiding) when the RA axis behaviour is as expected. It seems to me like all the settings in PHD2 is the same in both instances. Its understanding of the mount position and behavior seems to be the same in both instances.
>
> So I have no idea where to look from here. Any thoughts?
>
>
>
>
>
>
>
>
>
>
>
> On Thursday, April 25, 2024 at 1:01:23 AM UTC-4 Mark McComiskey wrote:
> Sorry, left out step 4: shut down everything and restart. No Nina. Slew to one side of meridian and start guiding. Everything okay. Stop guiding. Slew to other side of meridian and start guiding. Everything okay.
>
> Get Outlook for iOS

> To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/22caf925-c7d9-403f-9cbc-d6b96b0c0dc3n%40googlegroups.com.

[mccom...@gmail.com]

So, all of that makes sense, and I have reached out to ASA. And to be clear, based on past experience, I am deeply suspicious of ASA ASCOM drivers, and I recognize that PHD2 works reliably across many mounts.

Having said that, logically, if the problem is resolved immediately simply by stopping and starting guiding in PHD2, can it really be a mount driver issue? That is, I assume, completely invisible to the mount. Nothing about doing that could change anything in the mount driver in any way...

-----Original Message-----
From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Dale Ghent
Sent: Thursday, April 25, 2024 11:00 AM
To: open-phd...@googlegroups.com

Subject: Re: [open-phd-guiding] Progress and Questions

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/E2BC6C38-6062-4848-B2BF-E22D8936745D%40elemental.org.

[Brian Valente]

i’m not suggesting this is the answer, but restarting phd may re-query the mount position and side of pier

Brian 

Brian Valente

astronomy portfolio https://www.astrobin.com/users/bvalente/ 

nature portfolio brianvalentephotography.com 

other astronomy https://www.brianvalentephotography.com/astrophotography/ 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/005a01da9724%24ab1296f0%240137c4d0%24%40gmail.com.

[Bruce Waddington]

I completely agree with Dale and I'll add a few more comments pushing you in the direction of ASA.  You already know a couple of important things about the ASA software: it is new and it has already exhibited bugs precisely in the area of concern.  It has this oddball behavior of reversing the direction of RA movement commands after a meridian flip, something I've never seen before.  They fortunately provide a UI control to prevent that, but what if there is some part of their driver or mount controller software that doesn't check that option at some point?  And you've already seen an example where their own UI was reporting a side-of-pier value that was opposite to what was being reported to client applications and was wrong in any case.  Coming back to your big-picture characterization of where to look for the problem, I have a different view.  Both PHD2 and NINA are using the same abstract mount control interface (ASCOM) and that interface is used on thousands of mounts around the world by PHD2 and NINA.  Neither application has any special code to handle one particular kind of mount vs another so long as the mount has an ASCOM interface and behaves correctly.

I think the only way this is going to be fixed is by ASA having an aha moment.  In terms of continuing to isolate it in black box debugging mode - perhaps something you are already tired of doing - I can think of one other difference between the test cases that work and those that don't - and that's how close to the meridian the scope is pointing before and after the flip.  Each meridian flip will be somewhat different in terms of when the flip is started and how close to the meridian the scope is.  NINA has UI controls for this so you can specify how close to the meridian you can safely be.  So another possible test would be to enlarge that safety zone - for example by telling NINA you want to stop imaging when you're 10 minutes east of the meridian and then not flip the scope until the target is 10 minutes past the meridian.  That's probably an extreme example with a 20-minute safety window, but you get the idea. And this timing consideration might be why restarting PHD2 guiding works - depending on how long you let it run to confirm it isn't working, you have effectively changed the size of this timing window.

Good luck,

Bruce

[mccom...@gmail.com]

Yes, understood that PHD2 is abstracted from any special code.  Again, not in any way trying to imply that PHD2 is not doing what it should.  I have looked at the direction of the corrections in the RA axis that PHD2 is sending, and they are the same in the RA runaway case as in the RA normal case.  So It seems like PHD2 is chugging away consistently, but the mount is behaving divergently.

 

As you say, I am just trying to take a step back and use logic to at least identify conceptually where the breakdown might be happening, to facilitate focus on getting it resolved.  After the MF, I let guiding run away for less than 2 minutes before stopping and restarting it, and then everything worked perfectly.  Pierside reported by NINA and PHD2, which is coming from the mount, was the same across both the working and non working period.  So I thought there might be a clue to the cause of the problem in the fact that stopping and restarting guiding in PHD2 immediately solves the problem. 

 

I will give your suggestion on wait times a try, but the settings in NINA are currently “flip between 5 and 9 minutes after the meridian”.  These settings have resulted in a runaway RA axis every time there is a MF while tracking the antenna galaxies, but work perfectly well when there is a meridian flip while tracking  NGC 6164.  I am sure there is some informational content in it working on one target but not on another, but I am not sure what that might be.

 

But clear enough that this isn’t a PHD2 problem per se…

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d1ba0db5-436e-4d12-8eca-1478d21c3fe4n%40googlegroups.com.

[Dale Ghent]

> On Apr 25, 2024, at 11:24, mccom...@gmail.com wrote:
>
> So, all of that makes sense, and I have reached out to ASA. And to be clear, based on past experience, I am deeply suspicious of ASA ASCOM drivers, and I recognize that PHD2 works reliably across many mounts.
>
> Having said that, logically, if the problem is resolved immediately simply by stopping and starting guiding in PHD2, can it really be a mount driver issue? That is, I assume, completely invisible to the mount. Nothing about doing that could change anything in the mount driver in any way...

You'd be surprised. There's this thing in computing referred to as a "heisenbug" where merely trying to observe a system or problem alters a (mis)behavior it exhibits. It's a sort of half-joking reference to quantum physics, but these types of bugs are among the most annoying to root out, especially if some parts of the system in question are not very observable (eg; firmware).

I'm not terribly familiar with PHD2's code paths that it runs when guiding is stopped and then started, but I'm going to presume the resumption of guiding requires PHD2 to gather some facts from the mount driver regarding the state and capabilities of the mount. Guide rates, its notion of side of pier, and so on. Maybe Bruce can shed some light here. But it's very plausible that something - some property, perhaps related to guide rate or the like - in the mount driver is assigned or reinitialized with an inaccurate value upon the mount flipping across the meridian, and that something is not given its proper value until it is read by an external app - ie, a hypothetical PHD2 gathering information about the mount when it starts guiding. This again is where adequate logging by the ASCOM driver and the vendor's own special knowledge of its internals would be key to understanding what is happening.

/dale

[mccom...@gmail.com]

That is what I wondered, too. 

 

I’m not actually closing and restarting PHD2, to be clear. 

 

I am literally just hitting the stop button, restarting looping and guiding, all on the PHD2 control panel.  PHD2 reports the same pier side both before and after doing that, so it doesn’t appear to be changing its view on that matter.  The mount logs report the same side both before and after that procedure, which is no surprise given that is what is feeding the mount side info in PHD2, so they don’t seem to be changing…

 

As Dale says, perhaps the act of stopping guiding and restarting it somehow resets some non-displayed variable inside the mount.  But NINA already stops guiding before the MF, and then restarts it after.  So it would need to be a case of that happening only if you stopped and started twice after the MF, which would be weird.

 

And wouldn’t explain why this problem happens for one target and not another.

 

Not even sure where to start on figuring out what is going wrong.  I think I have found away to look at the servo logs for the mount.  I’ll be up later tonight checking if there is a clue there.  After that, I am going to dump a bunch of logs and this entire conversation on ASA and say “Please Fix”!

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/CAJa45i7m3eaO7xtGjU6uR8e9mH_M3_zLQr1S0SJGQT_a2WXizg%40mail.gmail.com.

[Bruce Waddington]

Whenever guiding is started, PHD2 interrogates the following mount properties: side-of-pier, declination, and mount guide speeds.  The mount guide speed check is only to be sure that the guide speeds haven't been changed since the last guiding sequence.  The side-of-pier and declination properties are used to adjust the internal PHD2 calibration parameters if necessary.  All of these property queries and the returned values are logged as are any adjustments to the internal calibration.

Bruce

[Mark McComiskey]

Yes. Checked those after the MF and they were the same both during the runaway and non runaway guiding sessions. 

So really left just confused. Will need to keep asking ASA to check for strange behavior. 

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Bruce Waddington <bw_m...@earthlink.net>
Sent: Thursday, April 25, 2024 12:40

To: Open PHD Guiding <open-phd...@googlegroups.com>

Subject: Re: [open-phd-guiding] Progress and Questions

 

--

You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/V8-ZHOO7sgU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/db8bb44a-9deb-4afa-83aa-3bef84e9a07en%40googlegroups.com.

[mccom...@gmail.com]

Fair enough. This is quite the Gremlin.

-----Original Message-----
From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Dale Ghent
Sent: Thursday, April 25, 2024 12:18 PM
To: open-phd...@googlegroups.com
Subject: Re: [open-phd-guiding] Progress and Questions

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/V8-ZHOO7sgU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/55DF7790-2836-4279-AB8A-90CF50981C1F%40elemental.org.

[Mark McComiskey]

Bruce, is there a way for the ASA software team to contact you directly/would you be willing to speak with them?  They were hoping to ask a few questions as they try to diagnose the issue.

[Bruce Waddington]

Yes, of course, I would be happy to help out.  I’m traveling at the moment but will be at my final destination tonight.  Probably the best way to start is via e-mail – they can send me mail at bw_m...@earthlink.net.  I will also be glad to talk to them on the phone if needed, we will just need to figure out the time zone difference – I’m on the US west coast, pacific daylight time.  It’s good to hear they are taking this seriously and are actively working to find the problem.  I think if we work together we should be able to figure it out pretty quickly.

 

Regards,

Bruce

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c0980539-4eb7-43d9-bd8a-0c9b244db566n%40googlegroups.com.

[Mark McComiskey]

Very kind. I will make the connection. 

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Bruce Waddington <bw_m...@earthlink.net>
Sent: Tuesday, May 7, 2024 4:41:01 PM
To: open-phd...@googlegroups.com <open-phd...@googlegroups.com>
Subject: RE: [open-phd-guiding] Progress and Questions

 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/001d01daa094%24f7020680%24e5061380%24%40earthlink.net.

[mccom...@gmail.com]

I passed along your contact information yesterday.  Hopefully thy reach out to you soon.

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Bruce Waddington

Sent: Tuesday, May 7, 2024 4:41 PM
To: open-phd...@googlegroups.com

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/001d01daa094%24f7020680%24e5061380%24%40earthlink.net.

[Bruce Waddington]

Ok, I’ll let you know.  One question for you: did you ever locate a log file for the ASCOM driver?  That’s a missing piece that I never saw and it could be important to figuring out the problem.

 

Bruce

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/00bd01daa15b%249b12d710%24d1388530%24%40gmail.com.

[Mark McComiskey]

It’s an ALPACA driver and it is completely blank. Every session, it records a blank log file. 

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Bruce Waddington <bw_m...@earthlink.net>
Sent: Wednesday, May 8, 2024 4:29:47 PM
To: open-phd...@googlegroups.com <open-phd...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/003801daa15c%248fa465f0%24aeed31d0%24%40earthlink.net.

[Mark McComiskey]

Bruce,

I found the attached log in the ASCOM folder (not the mount's log folder).  Does it give you the information you were looking for?

[Mark McComiskey]

This time with attachment.

[Bruce Waddington]

No, that’s the NINA log.  I’m looking for a log file that will document the interaction between the driver and the mount controller.  Have you looked in the Documents folder?  Can’t ASA tell you where it is?

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/72b35b06-ce1c-4baf-b327-74818f15bcban%40googlegroups.com.

[Mark McComiskey]

Apologies.  I had intended to provide this log:

ASCOM.AlpacaDynamic1.Telescope.1925.480040.txt

[Bruce Waddington]

I think the driver log just adds to the mystery rather than helping to understand what's going on.  Basically, it doesn't log anything at all about pulse-guide commands - nothing on receipt of the command, nothing on completion, just nothing.  Instead, at the precise times I know a pulse-guide command was issued and was being processed, there is a total absence of logging done by the driver - just a blank space in time (kind of like the Watergate tapes).  I can see commands and responses for querying whether pulse-guiding is active but only when it isn't active.  So I don't think I can do anything further by staring at this black box behavior.  The ASA people presumably know why pulse guiding is treated so oddly in terms of logging and, eventually, why it's causing your current problem.  I haven't heard from them so I think it's over-and-out until I do.  Sorry.

Bruce

[Mark McComiskey]

Okay, thanks. I saw the same thing, or rather, didn’t see the same thing, but wasn’t sure if I was just missing something. 

I’ve asked ASA once again to reach out to you. 

Get Outlook for iOS

---

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> on behalf of Bruce Waddington <bw_m...@earthlink.net>

Sent: Tuesday, May 14, 2024 12:04:10 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/ce7a9e7b-e8a4-445c-878d-55f87289ccean%40googlegroups.com.