Date   

Re: Separate power for mount - why?

Woody Schlom
 

Joseph,

 

And the non-adjustable Powerwerx is actually slightly variable inside the case.  I believe they ship set to 14.1v.  But I followed their instructions and went inside mine and lowered it to 12.88v – as low as it would go.  I also have and use one of their variable units which has a lot more range.

 

Woody

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joseph Beyer
Sent: Monday, January 10, 2022 5:19 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Separate power for mount - why?

 

Jim,

 

I was referring to the Powerwerx 25 amp variable voltage supply that is also available from Astro-Physics - https://www.astro-physics.com/psvpw25a

 

Joe

On Jan 10, 2022, at 5:11 PM, jimwc@... wrote:

On Mon, Jan 10, 2022 at 10:55 AM, ap@... wrote:

Linwood & all

you guys are talking about (A, and the power supply) no ware was there a mention of a model number for the power supply you are talking about. I am assuming the power supply you are talking about is the 13.8V nonadjustable voltage model. Am I correct?
Jim  


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

John Davis
 

Ah – very interesting.  Yes – that sounds like a good idea!

Thanks,
JD

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Monday, January 10, 2022 8:42 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

 

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.20.2 installed at home, but 0.20.3 installed on my remote computer.  Maybe try rolling back to 20.2 and see how it goes?
joel


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

John Davis
 

Yep – that is very good advice.  I think I shall probably follow that!

Thanks,
JD

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Monday, January 10, 2022 8:53 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

 

On Mon, Jan 10, 2022 at 08:47 PM, John Davis wrote:

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.

Admittedly in NINA not SGP, but I just slew to the same alt/az location every night, I do not bother to look if there are stars there (there are stars everywhere :) ).  I have a script that I run that slews, calibrates, guides for 2 minutes (just so I can see how it looks) and then is done.

Not trying to say "don't figure out the problem" just you might find that easier than having the human involved at all, much less Stellarium, if that's the only need.

Linwood


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

John Davis
 

Hi Joel,

  Yes I do agree that the preponderance of evidence would point to some issue with Stellarium being the culprit.  But there is the possibility that Stellarium is doing something perfectly legitimate – that PHD2 has never encountered, and PHD2’s code is not handling it correctly.  I don’t know what the breakdown would be when estimating the probability it is one piece of software vs the other.

 

The way that I’m looking at it:  PHD2 is the software that is misbehaving – it is failing to work correctly.  So to some degree, they should have at least a little  skin in the game of trying to figure out what is happening.  That’s my only frustration with those guys. 

 

So – if I go to the Stellarium guys and present this scenario – what are THEY going to do… probably say – well our software is communicating fine with the ASCOM driver, PHD2 is the one that is going crazy – you need to get THEM to look at THEIR problem.

 

Makes me think of that song from my High School Years  “Stuck in the middle with you…”  a One-Hit-Wonder from Stealers Wheel in 1972.

 

I’m glad that you have seem something similar – hope you can find out more next time you are out.  I plan to do some things tomorrow night (hopefully)… my problem is that I have so few chances to image – I hate to waste a night doing testing…

 

Thanks!

JD

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Monday, January 10, 2022 9:50 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,
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


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

ap@CaptivePhotons.com
 

On Mon, Jan 10, 2022 at 08:47 PM, John Davis wrote:
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.
Admittedly in NINA not SGP, but I just slew to the same alt/az location every night, I do not bother to look if there are stars there (there are stars everywhere :) ).  I have a script that I run that slews, calibrates, guides for 2 minutes (just so I can see how it looks) and then is done.

Not trying to say "don't figure out the problem" just you might find that easier than having the human involved at all, much less Stellarium, if that's the only need.

Linwood


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

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


Re: Separate power for mount - why?

ap@CaptivePhotons.com
 

On Mon, Jan 10, 2022 at 08:29 PM, <jimwc@...> wrote:
One person is using a variable voltage and one using a non-variable voltage model they both work equally well as a separate power supply. 
I use the variable one also, though I use it at the fixed 14.1 voltage.   I think the other one is a similar technology just with powerpoles and fixed voltage; I do not know if it existed when I ordered. 


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

Joel Short
 

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


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

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


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

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@...> 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@...> 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.





Re: Separate power for mount - why?

jimwc@...
 

Thanks for the clarification. One person is using a variable voltage and one using a non-variable voltage model they both work equally well as a separate power supply. 
Thanks
Jim 


Re: Separate power for mount - why?

thefamily90 Phillips
 

Yes, that is the one I use and is also the second one I ordered. 

JimP


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Joseph Beyer <jcbeyer2001@...>
Sent: Monday, January 10, 2022 8:18:52 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Separate power for mount - why?
 
Jim,

I was referring to the Powerwerx 25 amp variable voltage supply that is also available from Astro-Physics - https://www.astro-physics.com/psvpw25a

Joe
On Jan 10, 2022, at 5:11 PM, jimwc@... wrote:

On Mon, Jan 10, 2022 at 10:55 AM, ap@... wrote:
Linwood & all
you guys are talking about (A, and the power supply) no ware was there a mention of a model number for the power supply you are talking about. I am assuming the power supply you are talking about is the 13.8V nonadjustable voltage model. Am I correct?
Jim  


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

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


Re: Separate power for mount - why?

Joseph Beyer
 

Jim,

I was referring to the Powerwerx 25 amp variable voltage supply that is also available from Astro-Physics - https://www.astro-physics.com/psvpw25a

Joe

On Jan 10, 2022, at 5:11 PM, jimwc@... wrote:

On Mon, Jan 10, 2022 at 10:55 AM, ap@... wrote:
Linwood & all
you guys are talking about (A, and the power supply) no ware was there a mention of a model number for the power supply you are talking about. I am assuming the power supply you are talking about is the 13.8V nonadjustable voltage model. Am I correct?
Jim  


Re: Separate power for mount - why?

jimwc@...
 

On Mon, Jan 10, 2022 at 10:55 AM, ap@... wrote:
Linwood & all
you guys are talking about (A, and the power supply) no ware was there a mention of a model number for the power supply you are talking about. I am assuming the power supply you are talking about is the 13.8V nonadjustable voltage model. Am I correct?
Jim  


Re: Separate power for mount - why?

Peter Nagy
 

I always use one power source to power the following for about 10 years: 

A-P Mach1 and currently A-P 1100GTO using CP3 and currently CP4
SXVR-M25C, then QSI660wsg and currently QHY600M cameras
Optec Focus Boss II auto focuser 
USB hub
Ethernet switch 

Peter


Re: APCC / model

Craig Young
 

Hi Ray,
Excellent, exactly what I needed.  My application does interact with the V2 driver so I will use that method to load the model.

Eric, the reason I need this feature is because my 4 targets are part of my photometry research with the same 4 stars observed throughout the year.  It would not be practical for me to build a new model each night before a run so I make one set of models and then load them each run.  I have some metrics which show me at the end of a run how the model performed and if it drifts too far off due to changes in the mount or optics then I replace the model with a new one.

I am currently using Voyager to manage the night run but have been looking at Nina.  I developed an extensive script in Voyager to do all the things I needed and to date NINA does not provide all the script commands required.  But maybe one day it will, the guys are making great progress over there.  Dale's integration of NINA and APCC is the main draw card.  Just need to get some additional scripting functions.

Craig


Re: NINA not Parking my 1100

Dale Ghent
 

On Jan 10, 2022, at 17:12, Alex <groups@...> wrote:

Thanks folks, that was the issue. The ASCOM driver was set to park at the current position. That said, why would SGP go to park position one? I've never messed with the setting in the driver.
The only thing I can think of is that I usually start APCC first and connect it to the mount as well as connect the driver. It's possible I started and connected NINA first. Would that have made a difference? In any event I've configure the driver correctly. It's supposed to be clear tonight, so I'll give it a test.
This is likely the case. On APCC's window, you'll find the "AP V2 Driver" section. There's a checkbox there labeled Auto-Config. If APCC will configure the ASCOM driver with its settings IF APCC is the one that starts the ASCOM driver. It seems that was the case you described when using SGPro. When NINA (or any other app) starts the ASCOM driver, the driver loads its own settings and doesn't inherit anything from APCC.

You can still do it your previous way - APCC first, which then starts the driver, then you connect to it in NINA. You can do it either manually as you were or through the Advanced Sequencer using the Start APCC instruction in my Astro-Physics Tools plugin. You'd then use the Connector plugin's Connect to.. instruction to connect NINA to the then-launched ASCOM driver. You will want to be sure that the Auto-Connect and Auto-Config checkboxes are selected in the aforementioned AP V2 Driver area in APCC. There are some timeouts you can tweak in Astro-Physics Tools' options area if the ASCOM driver need some more time after appearing in the process table before anything can connect to it.

I gotta say I've been enjoying playing with NINA. Its new advanced sequencer appeals to my software engineer brain. The plugin model is great. It might get me to pick up C# to try some stuff. I'm a Java programmer in my day job, so it shouldn't be a big transition.
Cool! A few contributors cut their C# teeth with NINA after a having a Java-only background, so you'd be in good company. I'm a systems guy and my daily driver languages are C, python; even perl *spit*. All from the snug confines of vi. If I can hook into Visual Studio and get going with C#, anyone can ;)

/dale


Re: NINA not Parking my 1100

Alex
 

Thanks folks, that was the issue.  The ASCOM driver was set to park at the current position.  That said, why would SGP go to park position one?  I've never messed with the setting in the driver.

The only thing I can think of is that I usually start APCC first and connect it to the mount as well as connect the driver.  It's possible I started and connected NINA first.  Would that have made a difference?  In any event I've configure the driver correctly.  It's supposed to be clear tonight, so I'll give it a test.

I gotta say I've been enjoying playing with NINA.  Its new advanced sequencer appeals to my software engineer brain.  The plugin model is great.  It might get me to pick up C# to try some stuff.  I'm a Java programmer in my day job, so it shouldn't be a big transition.

Alex


Re: APCC / model

Eric Weiner
 

But then I realize that I doing a reasonably-detailed dec-arc model doesn't soak up a whole lot of time and the time-cost of creating a fresh one isn't a deal breaker.
This is most definitely true.  Even a relatively tight 130 point dec-arc model only takes my Mach2 ~45minutes to complete, which can easily be done shortly after the start of early evening nautical twilight. 

Eric

4761 - 4780 of 88823