Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin


John Davis
 

Hello,
   I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.

**NOTE: I have also sent this same post to the PHD2 support group **  
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

   To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.
 
What I am seeing is that after I run a full calibration in PHD2, then let the guiding assistant run for 3-4 minutes - apply the suggested parameters, then PHD2 will begin to guide, but after period of time (it varies) - the RA tracking seems to stop and the graph tracks totally off the scale (even set to +- 16").  I stop and re-start, the same thing happens.  
 
I'm using 
PHD2 version 2.6.10
Stellarium version 0.21.2 with version 0.4.2 of the Telescope Control plug-in.
Mach1 ASCOM Driver 5.30.10
 
I have used the combination of PHD2/Stellairum and Mach1 for over a year - originally was using the Stellarium Scope software to communicate between the ASCOM driver and Stelliarum - but switched to the Telescope Control plug-in when I upgraded to a new version of Stellarium.  I don't think that the problem exactly coincides with starting to use the Telescope Control plug-in.  It seems to roughly coincide with when I upgraded to PHD2 2.6.10 with the multi-star guiding feature.
 
Further detail on my observations:  Tonight I:
1). started up SGP, connected to all the hardware (camera, filter wheel, focuser, mount) and tested the imaging camera. 
2). started PHD2 and connected to the mount and guide camera (ASI120mm) to verify that connection.  
3). started Stellarium and connected to the mount.  Using Stellarium I selected a star near the Meridian and Celestial Equator - then had the mount slew to that location using the Telescope Control Interface
4). Had PHD2 autoselect main and other guide stars - and do a calibration run. Everything went fine.
5). After calibration - let it guide for about 30 seconds (guided ok) - then invoked the Guiding assistant.  Let it run for about 4 minutes and then stopped - after the backlash calibration - I accepted the reccomendations and let PHD2 begin guiding.
6). After about 2 minutes - the RA started tracking off of the graph (I see "MountGuidingEnabled = false and MultiStar = false on the Log viewer).  
7). I stopped guiding and re-selected stars - started again - guiding ran a few seconds and the same thing happened again.
8). I started a 3rd time and this time - there were wild swings in the RA guiding and a little in DEC.  I stopped again.
9). I re-ran Calibratoin - it ran fine
10). started guiding again - again the wild fluctuations in RA.
 
11). I disconnected Stellarium from the mount and shut it down.
12). I disconnected PHD2 from the camera and mount and shut it down
13). I shutdown SGP after disconnecting to all devices
14). I powered down the Mach1 mount and started it back up
 
15). Restarted SGP and reconnected to all devices.
16). Restarted PHD2 and connected to the guide camera and mount
 
17). Manually slewed to a location near the meridian and equator... had PHD2 autoselect star and calibrate.
18).  monitored guiding for  90 seconds - no problems - stopped guiding
19). slewed to imaging object - had SGP platesolve and run a sequence.
20). PHD2 guided FINE for 1h 36m until clouds ended the session.
 
SO - I'm almost positive that there is some problem - conflict - something between PHD2 and Stellarium.  Question is - where is the problem?
 
NOTE:  I have (in prior sessions with this same problem) - just tried disconnecting the Telescope Control plugin in Stellarium, and also exiting Stellarium.  This does NOT seem to fix the problem.  It requires at least a restart of PHD2 - and maybe also the Mach1 mount software).
 
If this is a known problem - sorry for the long post.  I attempted to search for this problem in prior posts - but I couldn't find this particular issue.
 
I really like being able to monitor the mount position with Stellarium during a session - so I would really like to get this problem fixed.  Help would be greatly appreciated.
 
Thanks!
John D.
 


Joel Short
 

Oh my word John!  I MIGHT have observed something similar, but this is with a different mount (CEM120EC).  When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:
PHD2_Stellarium_TrackingProblem.png

The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths.  This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening.  It is unnerving.  
After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot).  The stars stayed bang on immediately.  No having to wait a minute for the mount to stop moving and no oscillation.  

I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes.  Thanks for posting this.
joel


On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@...> wrote:
Hello,
   I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.

**NOTE: I have also sent this same post to the PHD2 support group **  
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

   To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.


John Davis
 

Unfortunately the knee-jerk response from the PHD2 support forum is “oh it’s a Stellarium problem – go ask them” or they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

As a software tester – I’m used to developers always assuming that it CAN’T be THEIR software that has the bug…. Sigh.

 

 

Seeing what you have experienced, I have seen some odd behaviors like that as well – not *exactly* the same – but cases where stars just start tracking off without any explanation.

I know that PHD2 is good – but I got to think that the new multi-star guiding code just might still have some bugs in it.  I’m just skeptical that PHD2 has NOTHING to do with any of this.

 

I’ll let you know if I find anything else on another board.

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Saturday, January 8, 2022 11:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

 

Oh my word John!  I MIGHT have observed something similar, but this is with a different mount (CEM120EC).  When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:

 

The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths.  This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening.  It is unnerving.  

After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot).  The stars stayed bang on immediately.  No having to wait a minute for the mount to stop moving and no oscillation.  

 

I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes.  Thanks for posting this.

joel

 

On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@...> wrote:

Hello,

   I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.


**NOTE: I have also sent this same post to the PHD2 support group **  
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

   To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.

 


 

Hi John

>>>> they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

i wrote that response. i wasn't suggesting that you are not using the ascom driver, You specifically mentioned you were using a plugin, which for a while was distributed separately. i was simply suggesting to check that you aren't using a deprecated way to connect your scope. 

PHD hasn't seen issues like this in multi-star guiding that I know of (I've been a regular on those forums for quite some time), but if you suspect multi-star you can always disable it and see if the condition goes away.

I have personally experienced similar situations where tracking "gets turned off"on my ap1600 without guiding (I don't usually use PHD because i have encoders) so i'm wondering if it is something elsewhere. The challenge is always there are many variables so it's hard to know what to isolate. 

Brian


On Sat, Jan 8, 2022 at 9:39 PM John Davis <johncdavis200@...> wrote:

Unfortunately the knee-jerk response from the PHD2 support forum is “oh it’s a Stellarium problem – go ask them” or they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

As a software tester – I’m used to developers always assuming that it CAN’T be THEIR software that has the bug…. Sigh.

 

 

Seeing what you have experienced, I have seen some odd behaviors like that as well – not *exactly* the same – but cases where stars just start tracking off without any explanation.

I know that PHD2 is good – but I got to think that the new multi-star guiding code just might still have some bugs in it.  I’m just skeptical that PHD2 has NOTHING to do with any of this.

 

I’ll let you know if I find anything else on another board.

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Saturday, January 8, 2022 11:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

 

Oh my word John!  I MIGHT have observed something similar, but this is with a different mount (CEM120EC).  When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:

 

The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths.  This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening.  It is unnerving.  

After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot).  The stars stayed bang on immediately.  No having to wait a minute for the mount to stop moving and no oscillation.  

 

I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes.  Thanks for posting this.

joel

 

On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@...> wrote:

Hello,

   I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.


**NOTE: I have also sent this same post to the PHD2 support group **  
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

   To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.

 



--
Brian 



Brian Valente


 

PS I should also mention PHD does not have any facility for starting/stopping or adjusting tracking rates, so I don't see how it could stop tracking on the mount. 

I will keep a look for any similar issues that come up and do some testing myself



On Sat, Jan 8, 2022 at 10:01 PM Brian Valente via groups.io <bvalente=gmail.com@groups.io> wrote:
Hi John

>>>> they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

i wrote that response. i wasn't suggesting that you are not using the ascom driver, You specifically mentioned you were using a plugin, which for a while was distributed separately. i was simply suggesting to check that you aren't using a deprecated way to connect your scope. 

PHD hasn't seen issues like this in multi-star guiding that I know of (I've been a regular on those forums for quite some time), but if you suspect multi-star you can always disable it and see if the condition goes away.

I have personally experienced similar situations where tracking "gets turned off"on my ap1600 without guiding (I don't usually use PHD because i have encoders) so i'm wondering if it is something elsewhere. The challenge is always there are many variables so it's hard to know what to isolate. 

Brian


On Sat, Jan 8, 2022 at 9:39 PM John Davis <johncdavis200@...> wrote:

Unfortunately the knee-jerk response from the PHD2 support forum is “oh it’s a Stellarium problem – go ask them” or they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

As a software tester – I’m used to developers always assuming that it CAN’T be THEIR software that has the bug…. Sigh.

 

 

Seeing what you have experienced, I have seen some odd behaviors like that as well – not *exactly* the same – but cases where stars just start tracking off without any explanation.

I know that PHD2 is good – but I got to think that the new multi-star guiding code just might still have some bugs in it.  I’m just skeptical that PHD2 has NOTHING to do with any of this.

 

I’ll let you know if I find anything else on another board.

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Saturday, January 8, 2022 11:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

 

Oh my word John!  I MIGHT have observed something similar, but this is with a different mount (CEM120EC).  When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:

 

The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths.  This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening.  It is unnerving.  

After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot).  The stars stayed bang on immediately.  No having to wait a minute for the mount to stop moving and no oscillation.  

 

I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes.  Thanks for posting this.

joel

 

On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@...> wrote:

Hello,

   I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.


**NOTE: I have also sent this same post to the PHD2 support group **  
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

   To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.

 



--
Brian 



Brian Valente



--
Brian 



Brian Valente


midmoastro
 

John, I thought I noticed similar several weeks back but wrote it off to something I was possibly doing. The difference for me is that I was not running Stellarium, that I recall. I was running NINA and PHD would launch via NINA. Guiding would start out normal, then just stop. Mine would auto pick back up and start tracking again though. It was very odd and was repeatable. I was suspecting some kind of issue between NINA and PHD as I believe I ran just PHD to test. My memories are vague but I thought PHD by itself ran fine and the issue only occurred when I launched it via NINA and had them running together. Again vague memories here but if I ever get clear skies again I will test to try and clarify or see if it happens again.
Todd


ap@CaptivePhotons.com
 

On Sun, Jan 9, 2022 at 10:06 AM, midmoastro wrote:
I was running NINA and PHD would launch via NINA. Guiding would start out normal, then just stop. Mine would auto pick back up and start tracking again though. It was very odd and was repeatable.
There are many things in NINA that stop guiding, depending on your options setting.  Most stop it and restart it (e.g. an autofocus run might do that).  If you can reproduce that, it may be worth posting on NINA's discord the log files from NINA (or just look through them to see if it was aware it stopped guiding). 

But isn't the original issue that tracking stops, not that guiding stops?   Or did I misunderstand?   What happens if you look in APCC or Ascom's display, does the mount THINK it is tracking?  Did the rate change?  Does it park or stop entirely, or momentarily? 

But it is important to distinguish between stopping guiding, and stopping tracking, as they are going to have different causes I think.

There's all sorts of data in the ascom driver log, might be a clue there. 


Cheng-Yang Tan
 

I think the problem is that there are so many variables :( One possibility is the guide camera not downloading the image and so PHD freezes. I use SBIG St-i and SC-2 for guiding and have not seen this problem.

On Sunday, January 9, 2022, 9:06 AM, midmoastro <teche70@...> wrote:

John, I thought I noticed similar several weeks back but wrote it off to something I was possibly doing. The difference for me is that I was not running Stellarium, that I recall. I was running NINA and PHD would launch via NINA. Guiding would start out normal, then just stop. Mine would auto pick back up and start tracking again though. It was very odd and was repeatable. I was suspecting some kind of issue between NINA and PHD as I believe I ran just PHD to test. My memories are vague but I thought PHD by itself ran fine and the issue only occurred when I launched it via NINA and had them running together. Again vague memories here but if I ever get clear skies again I will test to try and clarify or see if it happens again.
Todd


John Davis
 

I think that possibility has been eliminated by the tests which all involve the same guide camera operating with the same settings. There are no problems in the system until Stellarium is added to the mix with its connection to the Mach1 ASCOM driver. For me the question is how to determine if it is PHD2 or Stellarium that is causing the problem. The PHD2 guys naturally assume that it’s Stellarium, but I’m not convinced you can conclude that from the symptoms 


On Jan 9, 2022, at 10:15 AM, Cheng-Yang Tan via groups.io <cytan299@...> wrote:

 I think the problem is that there are so many variables :( One possibility is the guide camera not downloading the image and so PHD freezes. I use SBIG St-i and SC-2 for guiding and have not seen this problem.

cytan


Sent from Yahoo Mail for iPad

On Sunday, January 9, 2022, 9:06 AM, midmoastro <teche70@...> wrote:

John, I thought I noticed similar several weeks back but wrote it off to something I was possibly doing. The difference for me is that I was not running Stellarium, that I recall. I was running NINA and PHD would launch via NINA. Guiding would start out normal, then just stop. Mine would auto pick back up and start tracking again though. It was very odd and was repeatable. I was suspecting some kind of issue between NINA and PHD as I believe I ran just PHD to test. My memories are vague but I thought PHD by itself ran fine and the issue only occurred when I launched it via NINA and had them running together. Again vague memories here but if I ever get clear skies again I will test to try and clarify or see if it happens again.
Todd


Steven Panish
 

I don't have this particular issue but the AP-V2/Stellarium ASCOM addition has some issues.  I'm using the first Stellarium version that included the code (and thanks to the guy who did it!).  It works fine for me - but only when I connect Stellarium AFTER I've connected to the mount with Cartes du Ciel!  If I don't do that Stellarium connects to the "scope" but won't slew.  This is with a 1200 CP3.  Since it works fine with this workaround, I haven't messed with it further.  I tried a later version of Stellarium and couldn't get it to drive the mount at all.

Steve

On Sun, Jan 9, 2022 at 12:26 PM John Davis <johncdavis200@...> wrote:
I think that possibility has been eliminated by the tests which all involve the same guide camera operating with the same settings. There are no problems in the system until Stellarium is added to the mix with its connection to the Mach1 ASCOM driver. For me the question is how to determine if it is PHD2 or Stellarium that is causing the problem. The PHD2 guys naturally assume that it’s Stellarium, but I’m not convinced you can conclude that from the symptoms 


On Jan 9, 2022, at 10:15 AM, Cheng-Yang Tan via groups.io <cytan299=yahoo.com@groups.io> wrote:

 I think the problem is that there are so many variables :( One possibility is the guide camera not downloading the image and so PHD freezes. I use SBIG St-i and SC-2 for guiding and have not seen this problem.

cytan


Sent from Yahoo Mail for iPad

On Sunday, January 9, 2022, 9:06 AM, midmoastro <teche70@...> wrote:

John, I thought I noticed similar several weeks back but wrote it off to something I was possibly doing. The difference for me is that I was not running Stellarium, that I recall. I was running NINA and PHD would launch via NINA. Guiding would start out normal, then just stop. Mine would auto pick back up and start tracking again though. It was very odd and was repeatable. I was suspecting some kind of issue between NINA and PHD as I believe I ran just PHD to test. My memories are vague but I thought PHD by itself ran fine and the issue only occurred when I launched it via NINA and had them running together. Again vague memories here but if I ever get clear skies again I will test to try and clarify or see if it happens again.
Todd


John Davis
 

JUST AN UPDATE for any following this thread.

 

Disappointingly – but not unsuspected… the guys over at the PHD2 group looked at my guiding and debug logs – and blamed the problem, as they almost *always* do – on some cabling problem with the mount/scope. 

 

Now – I appreciate their help – and I guess I understand their position – but that is such a cop-out.  Frustrates me greatly. 

 

The session I sent them logs for – I was *very* careful with my cabling.  I was just using a very light weight setup:  200mm Canon lens attached to an ASI1600mm camera/filterwheel and using an ASI 200mm fl guidescope with and asi120mm guide camera.  AND – I had the problem early… then took Stellarium out of the picture – restarted – recalibrated – then successfully guided for 1 hour 30 minutes – WITHOUT changing anything physically on the scope.   So to me – logically that does not hold water.

 

So – I guess I’m on my own to figure this out.

 

If I were using a cheap lower end mount, I might be more willing to accept their suggestions… but this is a Mach1 and I generally have *GREAT* performance out of it.

 

Sorry – just wanted to rant a little.  PHD2 is an AWESOME piece of software – but it is not perfect… all software has bugs.

 

I’ll post to this further if I find anything more.

 

I do see that I am behind releases on the ASCOM platform and on the AP drivers – so I guess I will do some updates and see if that fixes anything.  I have 2 laptops that I use – one as a backup, so I will apply all the changes to the backup first – to make sure it doesn’t screw up anything.

 

Thanks for your responses, I appreciate your information

JD


Joel Short
 

John,
Doesn't it seem as if the issue lies with Stellarium, not PHD2?  I have no evidence for this statement but I suspect that Stellarium is the problem.  The internal telescope control is a relatively new feature (vs the old Stellarium Scope) and I've only been using it for a few months.  I haven't noticed this issue with my AP1100 at home, but I've noticed it with a CEM120EC at my remote location.  Next clear night I'm hoping to do some more testing.
joel


Geof Lewis
 

John,
I've followed your thread both here and over on the OpenPHD forum. I have to agree with Joel; the below extract of the steps you took to diagnose the problem and get a successful guiding session state....
'......then took Stellarium out of the picture – restarted – recalibrated – then successfully guided for 1 hour 30 minutes...'
It seems that the only thing you need to do to fix the problem was stop using Stellarium. I don't use Stellarium as a planetarium for telescope control, as I use SGP to run my observatory and capture images, but I do use Cartes du Ceil (CdC) when I just want to quickly use a planetarium to select targets and control the mount, which works almost flawlessly. CdC is what I used to use regularly several years ago when I too had a mobile rig and need to set up afresh each session, so maybe that's an alternative solution for you.
Regards,

Geof


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Joel Short <buckeyestargazer@...>
Sent: 10 January 2022 14:50
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin
 
John,
Doesn't it seem as if the issue lies with Stellarium, not PHD2?  I have no evidence for this statement but I suspect that Stellarium is the problem.  The internal telescope control is a relatively new feature (vs the old Stellarium Scope) and I've only been using it for a few months.  I haven't noticed this issue with my AP1100 at home, but I've noticed it with a CEM120EC at my remote location.  Next clear night I'm hoping to do some more testing.
joel


Dale Ghent
 

Just looking through your posts, my first inclination is to check the tracking rate that the AP ASCOM driver is reporting while this condition is happening and verify that it's in sidereal; not lunar, solar, or some other tracking rate. I just looked at the source code for Stellarium's TelescopeControl plugin and it does not manipulate tracking rates at all. PHD2 doesn't manipulate tracking rates at all, so if the driver is reporting a sidereal tracking rate and not some other or custom rate, then tracking rates can then be excluded from a possible cause.

As for your frustrations, I think one must appreciate the many-layered cake that astro software stacks are. This necessitates some solid demarcation of responsibility among software maintainers when it comes to these different components interacting between each other. In this case, things work fine when Stellarium isn't in the mix, but go south when it is. Since the stack is designed such that PHD2 should not have to do anything special if Stellarium (or any other particular item of software) is involved in running things, the first advice is to determine why the act of using Stellarium alters the situation.

There is often a "shoot the messenger" mentality because one piece of software is surfacing a bug or misconfiguration that exists in a different part of a kind-of-complex stack. The best way to debug these kinds of issues is to deconstruct things and first look at the common components such as the driver and verify that its reporting sane settings - it is, after all, the canonical source of information about the mount. There is also the completeness of the problem description to consider. There's often a tertiary actor involved that the user leaves out of the description because they think it's irrelevant, but that can very well not be the case.

On Jan 9, 2022, at 00:38, John Davis <johncdavis200@gmail.com> wrote:

Unfortunately the knee-jerk response from the PHD2 support forum is “oh it’s a Stellarium problem – go ask them” or they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

As a software tester – I’m used to developers always assuming that it CAN’T be THEIR software that has the bug…. Sigh.





Seeing what you have experienced, I have seen some odd behaviors like that as well – not *exactly* the same – but cases where stars just start tracking off without any explanation.

I know that PHD2 is good – but I got to think that the new multi-star guiding code just might still have some bugs in it. I’m just skeptical that PHD2 has NOTHING to do with any of this.



I’ll let you know if I find anything else on another board.







From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Saturday, January 8, 2022 11:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin



Oh my word John! I MIGHT have observed something similar, but this is with a different mount (CEM120EC). When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:

<image001.png>


The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths. This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening. It is unnerving.

After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot). The stars stayed bang on immediately. No having to wait a minute for the mount to stop moving and no oscillation.



I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes. Thanks for posting this.

joel



On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@gmail.com> wrote:

Hello,

I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.


**NOTE: I have also sent this same post to the PHD2 support group **
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.





Peter Nagy
 

Have you tried ASCOM Device Hub? I use it and works great. I only use it for connecting multiple software related to ASCOM mounts like A-P V2 mount driver, PHD2, Stellarium, etc. It seems to help stabilizing ASCOM mount drivers.

https://ascom-standards.org/FAQs/DevHub.htm

It's possible ASCOM part of Stellarium is interfering with other ASCOM mount related drivers and ASCOM Device Hub can help.

Ray said Device Hub may conflict or block APCC unique commands to the mount. I don't use APCC so I never had issues. Or I never heard of APCC/Device Hub conflicts as well.

Peter


John Davis
 

Interesting idea – I will have to investigate.  Thanks for the heads up!

JD

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Peter Nagy
Sent: Monday, January 10, 2022 12:15 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

 

Have you tried ASCOM Device Hub? I use it and works great. I only use it for connecting multiple software related to ASCOM mounts like A-P V2 mount driver, PHD2, Stellarium, etc. It seems to help stabilizing ASCOM mount drivers.

https://ascom-standards.org/FAQs/DevHub.htm

It's possible ASCOM part of Stellarium is interfering with other ASCOM mount related drivers and ASCOM Device Hub can help.

Ray said Device Hub may conflict or block APCC unique commands to the mount. I don't use APCC so I never had issues. Or I never heard of APCC/Device Hub conflicts as well.

Peter


John Davis
 

Hi Dale,
Thanks for the response...

I was frustrated when I posted - I do understand what an incredibly complex thing we are trying to do with all these different pieces of software - developed by different groups of people, mostly free, open source software. It is INCREDIBLE that it works as well as it does. I'm greatly appreciative of the PHD2 folks and all the people who contribute to the ASCOM platform. We are so fortunate to have all those dedicated and talented people who work so hard on the software and then are willing to try to help people like me get it working in their environment. Hats off to them.

I also realize that if all the other software works w/o Stellarium in the mix - and then goes south when Stellarium is added - the high probability is that the problem lies with Stellarium. But there is a non-zero possibility that (in this case) PHD2 is encountering some condition when Stellarium is present that was not expected - and is not the fault of Stellarium. Would just be nice for somebody to acknowledge that possibility.

I've discovered that I'm not at the latest release of some of the software - the ASCOM platform mainly, and the AP ASCOM driver... so I suppose I must update those to the latest version to make sure that some change in those pieces don’t fix the problem. It just makes me very nervous any time I upgrade or patch software...

Appreciate the comments and suggestions!
JD

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Monday, January 10, 2022 12:02 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin


Just looking through your posts, my first inclination is to check the tracking rate that the AP ASCOM driver is reporting while this condition is happening and verify that it's in sidereal; not lunar, solar, or some other tracking rate. I just looked at the source code for Stellarium's TelescopeControl plugin and it does not manipulate tracking rates at all. PHD2 doesn't manipulate tracking rates at all, so if the driver is reporting a sidereal tracking rate and not some other or custom rate, then tracking rates can then be excluded from a possible cause.

As for your frustrations, I think one must appreciate the many-layered cake that astro software stacks are. This necessitates some solid demarcation of responsibility among software maintainers when it comes to these different components interacting between each other. In this case, things work fine when Stellarium isn't in the mix, but go south when it is. Since the stack is designed such that PHD2 should not have to do anything special if Stellarium (or any other particular item of software) is involved in running things, the first advice is to determine why the act of using Stellarium alters the situation.

There is often a "shoot the messenger" mentality because one piece of software is surfacing a bug or misconfiguration that exists in a different part of a kind-of-complex stack. The best way to debug these kinds of issues is to deconstruct things and first look at the common components such as the driver and verify that its reporting sane settings - it is, after all, the canonical source of information about the mount. There is also the completeness of the problem description to consider. There's often a tertiary actor involved that the user leaves out of the description because they think it's irrelevant, but that can very well not be the case.



On Jan 9, 2022, at 00:38, John Davis <johncdavis200@gmail.com> wrote:

Unfortunately the knee-jerk response from the PHD2 support forum is “oh it’s a Stellarium problem – go ask them” or they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

As a software tester – I’m used to developers always assuming that it CAN’T be THEIR software that has the bug…. Sigh.





Seeing what you have experienced, I have seen some odd behaviors like that as well – not *exactly* the same – but cases where stars just start tracking off without any explanation.

I know that PHD2 is good – but I got to think that the new multi-star guiding code just might still have some bugs in it. I’m just skeptical that PHD2 has NOTHING to do with any of this.



I’ll let you know if I find anything else on another board.







From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel
Short
Sent: Saturday, January 8, 2022 11:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1
mount using Stellarium's Telescope Control plugin



Oh my word John! I MIGHT have observed something similar, but this is with a different mount (CEM120EC). When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:

<image001.png>


The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths. This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening. It is unnerving.

After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot). The stars stayed bang on immediately. No having to wait a minute for the mount to stop moving and no oscillation.



I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes. Thanks for posting this.

joel



On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@gmail.com> wrote:

Hello,

I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.


**NOTE: I have also sent this same post to the PHD2 support group **
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.





Joel Short
 
Edited

John,
Another data point.  I mentioned that I did not see this behavior with my AP1100 at my home, but I did see it with my remote observatory mount.  I have Stellarium 0.21.2 installed at home, but 0.21.3 installed on my remote computer.  Maybe try rolling back to 20.2 and see how it goes?
joel


Joel Short
 

Scratch that. I just saw that you are already on 21.2.
joel


John Davis
 

Hi Geof,

  Yes – as the joke goes –

Me: “Doctor, it hurts when I do that…”

Doctor: “Well don’t DO that…”

 

I understand that might be the “fix” – if only for now – and I’m prepared to do that.  Right now, the only thing I actively use Stellarium for (with the mount control) is to have the mount slew to the location that I want to use to calibrate PHD2 against.  It’s also nice to be able to easily see where the mount is pointing during an imaging session, but that is really not necessary.

 

I also use SGP to manage my imaging sessions, and I’ve gotten it working to the point that it handles slewing and centering of the targets, so I don’t need Stellarium for that process.

 

I’ve used Cartes du Ceil before – but frankly – I dislike the user interface a LOT.  Compared to Stellarium it is a very poor substitute (in my opinion). 

 

I’ve used Stellarium (with the Stellarium Scope software) for years without any of these problems.  But now that I switched to communicating with the mount directly from Stellarium (via the ASCOM driver), the problems began to happen.

 

BUT – at the same time I upgraded Stellarium and started using direct communication via ASCOM to the mount – I upgraded PHD2 to the new version that supported multi-star guiding.  So both packages changed a lot… which is why I’m not 100% ready to blame Stellarium.  Could be some condition that PHD2 is not expecting – but is perfectly legitimate – occurring when Stellarium is present… hence triggered by the presence of Stellarium – but caused by PHD2’s inability to handle the condition.  Might be a longshot – but I’ve seen that before in my nearly 25 years of software testing experience… 

 

So I will probably just try to figure out how to do w/o using the Stellarium connection to the mount.

 

JD

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Geof Lewis
Sent: Monday, January 10, 2022 11:10 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

 

John,

I've followed your thread both here and over on the OpenPHD forum. I have to agree with Joel; the below extract of the steps you took to diagnose the problem and get a successful guiding session state....

'......then took Stellarium out of the picture – restarted – recalibrated – then successfully guided for 1 hour 30 minutes...'

It seems that the only thing you need to do to fix the problem was stop using Stellarium. I don't use Stellarium as a planetarium for telescope control, as I use SGP to run my observatory and capture images, but I do use Cartes du Ceil (CdC) when I just want to quickly use a planetarium to select targets and control the mount, which works almost flawlessly. CdC is what I used to use regularly several years ago when I too had a mobile rig and need to set up afresh each session, so maybe that's an alternative solution for you.

Regards,

 

Geof


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Joel Short <buckeyestargazer@...>
Sent: 10 January 2022 14:50
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

 

John,
Doesn't it seem as if the issue lies with Stellarium, not PHD2?  I have no evidence for this statement but I suspect that Stellarium is the problem.  The internal telescope control is a relatively new feature (vs the old Stellarium Scope) and I've only been using it for a few months.  I haven't noticed this issue with my AP1100 at home, but I've noticed it with a CEM120EC at my remote location.  Next clear night I'm hoping to do some more testing.
joel