Date   

Re: Separate power for mount - why?

ap@CaptivePhotons.com
 

On Mon, Jan 10, 2022 at 01:15 PM, Roland Christen wrote:
There is no risk to damage to the CP controller. The main problem is undervoltage, so if you run many applications from one battery, the terminal voltage might drop below the threshold for the CP to operate properly. It is almost always an issue when slewing, not usually during tracking.
Thank you, that makes perfect sense.  In this case, at a dark site, I'll have the battery right beside the mount, heavy gauge wire, and at 200ah (and LiFePO4 chemistry) there's going to be no unexpected drops unless I somehow run it dead also.  

To your later comment on switching power supplies, I take it that's one reason you recommend a dedicated power supply.  But those things are light, and it's all on one cart, there's no reason not to keep those separate. 

Saving me hauling an extra battery is a goodness.  Thank you for the quick response.

On Mon, Jan 10, 2022 at 01:24 PM, Emilio J. Robau, P.E. wrote:
I am curious if my practices are best management practices.   I keep my cameras on one power source, my dew heaters on another, and my mount on the third.  I don't mix the power sources.  Is this overly paranoid?
My difficulty with that is I use a Pegasus powerbox on the saddle as a dew controller, and also as a USB3 hub. While I have not experienced problems, it does worry me that a lot of noisy things come together there.  Running separate power to the dew heaters means a separate dew controller (or just running them 100%), and I still have the camera (and guide camera) and hub all together.

I just generally hope I can SEE the problem if one develops, e.g. as banding or something in images, and indeed I did in a case where the NUC noise affected a flat panel.  But a part of me always wonders if "all this noisy stuff is introducing some noise in my images that I cannot see"?   There are so many things we can do to mess up astro captures, it is very easy to be paranoid.  Murphy really is always after us. 

Which brings up this question:   Are these things any use in astrophotography? 

https://powerwerx.com/dc-line-noise-filter-powerpole-connectors

I think it's specifically aimed at noise in ham radios, I have no idea if it even filters the kind of noise we can get from PWM in a dew heater, or random noise from a NUC.  I've also got a bunch of ferrite cores I put around wires, but I am told they rarely actually do any good (but they are cheap and do no harm). 

But there is a point where I have to say "if I do not see  a problem, there isn't a problem" and actually take some images.  :) 

Linwood


Re: Separate power for mount - why?

Woody Schlom
 

Emilio,

 

“overly paranoid?”  Maybe, but your approach should also work very well and give the fewest problems.  Personally, if you can do what you’re doing (three separate power sources), I’d keep doing it.

 

Woody

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Emilio J. Robau, P.E.
Sent: Monday, January 10, 2022 10:24 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Separate power for mount - why?

 

I am curious if my practices are best management practices.   I keep my cameras on one power source, my dew heaters on another, and my mount on the third.  I don't mix the power sources.  Is this overly paranoid?


Re: Separate power for mount - why?

Roland Christen
 

Switching power supplies have very little or no output capacitor filtering, so they are very susceptible to ripple. In fact, some have ripple even when no load is applied. Linear power supplies are heavier, but do have large output capacitors which essentially eliminate any ripple on the DC voltage.

Roland

-----Original Message-----
From: Woody Schlom <woody_is@...>
To: main@ap-gto.groups.io
Sent: Mon, Jan 10, 2022 12:18 pm
Subject: Re: [ap-gto] Separate power for mount - why?

Linwood,
 
In my experience it’s the other way around from what you suggest.  It’s the MOUNT motors that dirty up the power – and the camera sees the “dirty” power as noise.  Something about mount motors (most, but not all) putting ripples in the power line.
 
Back when I was using live CCD video cameras, I could see the ripples in the power from the mounts.  And I could see that ripple disappear when I removed the mount from the same power source. 
 
But that said, I think there are ways of “filtering” power so this doesn’t happen.  All this is way above my knowledge levels, but in the past I was able to run all my equipment from the same power source without seeing ripple in the power.  I never singled out the “magic” configuration, but I think it had something to do with the type/s of power supplies.  I got the feeling that true old-school transformer power supplies (the ones that weigh a ton) were less susceptible to this than switching power supplies.  All I really know is that depending on the individual AC to DC power supplies I used in my configurations, every now and then I could power everything off the same power supply.  And other times I couldn’t.
 
But when I had the problem, giving the mount its own power supply stopped the ripple.  And when I stopped it, I mean I could look at my live video image and switch the mount’s power on and off – and watch the ripple come and go.  Mount ON, I had ripple.  Mount OFF, no ripple.  Simple as that.
 
Woody
 
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Monday, January 10, 2022 9:55 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Separate power for mount - why?
 
First, I take all advice from AP seriously, and use a separate power supply for my mount now (AP1100AE). 

After my first attempt at night at a dark site, I need to redo my battery planning.  I ran dead before midnight with a Group 27 Lead Acid battery.  It was a bit premature due to a fallacy in the SOC indication I was using, but on further measurements I was way under sized and would have been completely dead before morning.  So a big 200ah LiFePO4 is on the way.

But that brings up the mount.  I have a Group 24 FLA for it, and that is more than adequate with its miniscule draw.  But it is about 50 pounds I lug around to the dark site.  I might replace it as well, say a 50ah LiFePO4, much lighter and smaller.  But expensive if not needed.

So here is the question: The recommendation is to have a separate DC power supply, due to noise from cameras, etc.

Is the recommendation based on trying to prevent damage to the CP4 or mount?
Or is the recommendation because it may create anomalies in tracking/guiding? 

Bottom line: Is there any reason not to give it a try off the same big battery, and so long as tracking is its usual near perfect self, not bother hauling (or buying) the separate battery?  If there's a risk of damage, obviously I'll keep two. 

I'm well aware in terms of investment the cost of another LiFePO4 battery is negligible, it is more about one more piece of "stuff" to haul out, back, etc.  The last trip I spent more time packing and unpacking than imaging.  Working to streamline other aspects also, but this one came up when I was debating whether to go ahead and order a second LiFePO4 battery or not.

Linwood

--
Roland Christen
Astro-Physics


Re: Separate power for mount - why?

Emilio J. Robau, P.E.
 

I am curious if my practices are best management practices.   I keep my cameras on one power source, my dew heaters on another, and my mount on the third.  I don't mix the power sources.  Is this overly paranoid?


Re: Separate power for mount - why?

Dale Ghent
 

My own experience with running everything off a single, common power source has not given me any issues that could be attributable to doing that. I get the feeling that there are two main reasons behind this advice, though:

One is that it's given with the aim of avoiding some (common? maybe at some point?) electrical issues with certain gear configurations - current leaks, noise, stuff like that. Stuff that's also hard to identify and quantify if you're not an EE or know what to look for. But this, I feel, is largely a situational thing and not something that affects every setup out there.

The other is around battery chemistries where there can be a large-enough voltage drop when the current draw suddenly increases - such as when a mount starts slewing. This voltage drop can be large enough to knock other equipment offline, cause them to reset, or even lockout into a safe mode. It's not great for gear and their own voltage regulation circuits. But, chemistries such as LFP don't tend to suffer from such precipitous voltage drops under load so you might be ok there if you're running everything off of a single LFP battery. These kinds of batteries didn't really exist, at least commercially, 10, 15 years ago.

On Jan 10, 2022, at 12:55, ap@... <ap@...> wrote:

First, I take all advice from AP seriously, and use a separate power supply for my mount now (AP1100AE).

After my first attempt at night at a dark site, I need to redo my battery planning. I ran dead before midnight with a Group 27 Lead Acid battery. It was a bit premature due to a fallacy in the SOC indication I was using, but on further measurements I was way under sized and would have been completely dead before morning. So a big 200ah LiFePO4 is on the way.

But that brings up the mount. I have a Group 24 FLA for it, and that is more than adequate with its miniscule draw. But it is about 50 pounds I lug around to the dark site. I might replace it as well, say a 50ah LiFePO4, much lighter and smaller. But expensive if not needed.

So here is the question: The recommendation is to have a separate DC power supply, due to noise from cameras, etc.

Is the recommendation based on trying to prevent damage to the CP4 or mount?


Or is the recommendation because it may create anomalies in tracking/guiding?

Bottom line: Is there any reason not to give it a try off the same big battery, and so long as tracking is its usual near perfect self, not bother hauling (or buying) the separate battery? If there's a risk of damage, obviously I'll keep two.

I'm well aware in terms of investment the cost of another LiFePO4 battery is negligible, it is more about one more piece of "stuff" to haul out, back, etc. The last trip I spent more time packing and unpacking than imaging. Working to streamline other aspects also, but this one came up when I was debating whether to go ahead and order a second LiFePO4 battery or not.

Linwood



Re: Separate power for mount - why?

Woody Schlom
 

Linwood,

 

In my experience it’s the other way around from what you suggest.  It’s the MOUNT motors that dirty up the power – and the camera sees the “dirty” power as noise.  Something about mount motors (most, but not all) putting ripples in the power line.

 

Back when I was using live CCD video cameras, I could see the ripples in the power from the mounts.  And I could see that ripple disappear when I removed the mount from the same power source. 

 

But that said, I think there are ways of “filtering” power so this doesn’t happen.  All this is way above my knowledge levels, but in the past I was able to run all my equipment from the same power source without seeing ripple in the power.  I never singled out the “magic” configuration, but I think it had something to do with the type/s of power supplies.  I got the feeling that true old-school transformer power supplies (the ones that weigh a ton) were less susceptible to this than switching power supplies.  All I really know is that depending on the individual AC to DC power supplies I used in my configurations, every now and then I could power everything off the same power supply.  And other times I couldn’t.

 

But when I had the problem, giving the mount its own power supply stopped the ripple.  And when I stopped it, I mean I could look at my live video image and switch the mount’s power on and off – and watch the ripple come and go.  Mount ON, I had ripple.  Mount OFF, no ripple.  Simple as that.

 

Woody

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Monday, January 10, 2022 9:55 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Separate power for mount - why?

 

First, I take all advice from AP seriously, and use a separate power supply for my mount now (AP1100AE). 

After my first attempt at night at a dark site, I need to redo my battery planning.  I ran dead before midnight with a Group 27 Lead Acid battery.  It was a bit premature due to a fallacy in the SOC indication I was using, but on further measurements I was way under sized and would have been completely dead before morning.  So a big 200ah LiFePO4 is on the way.

But that brings up the mount.  I have a Group 24 FLA for it, and that is more than adequate with its miniscule draw.  But it is about 50 pounds I lug around to the dark site.  I might replace it as well, say a 50ah LiFePO4, much lighter and smaller.  But expensive if not needed.

So here is the question: The recommendation is to have a separate DC power supply, due to noise from cameras, etc.

Is the recommendation based on trying to prevent damage to the CP4 or mount?

Or is the recommendation because it may create anomalies in tracking/guiding? 

Bottom line: Is there any reason not to give it a try off the same big battery, and so long as tracking is its usual near perfect self, not bother hauling (or buying) the separate battery?  If there's a risk of damage, obviously I'll keep two. 

I'm well aware in terms of investment the cost of another LiFePO4 battery is negligible, it is more about one more piece of "stuff" to haul out, back, etc.  The last trip I spent more time packing and unpacking than imaging.  Working to streamline other aspects also, but this one came up when I was debating whether to go ahead and order a second LiFePO4 battery or not.

Linwood


Re: Separate power for mount - why?

Roland Christen
 

There is no risk to damage to the CP controller. The main problem is undervoltage, so if you run many applications from one battery, the terminal voltage might drop below the threshold for the CP to operate properly. It is almost always an issue when slewing, not usually during tracking.

There can be one situation that happens during tracking when a dew heater comes on or cycles on-off. They can sometimes draw so much current from a 12 volt battery that the voltage at the terminals drops below 11 volts (about 10.5 to 10.7 volts) and causes the CP to reset. This results in a momentary stopping of tracking during the undervoltage time. Having a battery that puts out more than 12 volts, like the Lithium batteries, will prevent this situations.

We have also seen situations where the power supply was situated some distance away from the mount and the wire was too small to carry the current of all the devices without causing a fairly large voltage drop. So even though the terminal voltage at the power source was high enough, the actual voltage at the CP controller was down near the 11 volt threshold and even lower in one case that we saw.

Roland

-----Original Message-----
From: ap@... <ap@...>
To: main@ap-gto.groups.io
Sent: Mon, Jan 10, 2022 11:55 am
Subject: [ap-gto] Separate power for mount - why?

First, I take all advice from AP seriously, and use a separate power supply for my mount now (AP1100AE). 

After my first attempt at night at a dark site, I need to redo my battery planning.  I ran dead before midnight with a Group 27 Lead Acid battery.  It was a bit premature due to a fallacy in the SOC indication I was using, but on further measurements I was way under sized and would have been completely dead before morning.  So a big 200ah LiFePO4 is on the way.

But that brings up the mount.  I have a Group 24 FLA for it, and that is more than adequate with its miniscule draw.  But it is about 50 pounds I lug around to the dark site.  I might replace it as well, say a 50ah LiFePO4, much lighter and smaller.  But expensive if not needed.

So here is the question: The recommendation is to have a separate DC power supply, due to noise from cameras, etc.

Is the recommendation based on trying to prevent damage to the CP4 or mount?

Or is the recommendation because it may create anomalies in tracking/guiding? 

Bottom line: Is there any reason not to give it a try off the same big battery, and so long as tracking is its usual near perfect self, not bother hauling (or buying) the separate battery?  If there's a risk of damage, obviously I'll keep two. 

I'm well aware in terms of investment the cost of another LiFePO4 battery is negligible, it is more about one more piece of "stuff" to haul out, back, etc.  The last trip I spent more time packing and unpacking than imaging.  Working to streamline other aspects also, but this one came up when I was debating whether to go ahead and order a second LiFePO4 battery or not.

Linwood


--
Roland Christen
Astro-Physics


Separate power for mount - why?

ap@CaptivePhotons.com
 

First, I take all advice from AP seriously, and use a separate power supply for my mount now (AP1100AE). 

After my first attempt at night at a dark site, I need to redo my battery planning.  I ran dead before midnight with a Group 27 Lead Acid battery.  It was a bit premature due to a fallacy in the SOC indication I was using, but on further measurements I was way under sized and would have been completely dead before morning.  So a big 200ah LiFePO4 is on the way.

But that brings up the mount.  I have a Group 24 FLA for it, and that is more than adequate with its miniscule draw.  But it is about 50 pounds I lug around to the dark site.  I might replace it as well, say a 50ah LiFePO4, much lighter and smaller.  But expensive if not needed.

So here is the question: The recommendation is to have a separate DC power supply, due to noise from cameras, etc.

Is the recommendation based on trying to prevent damage to the CP4 or mount?

Or is the recommendation because it may create anomalies in tracking/guiding? 

Bottom line: Is there any reason not to give it a try off the same big battery, and so long as tracking is its usual near perfect self, not bother hauling (or buying) the separate battery?  If there's a risk of damage, obviously I'll keep two. 

I'm well aware in terms of investment the cost of another LiFePO4 battery is negligible, it is more about one more piece of "stuff" to haul out, back, etc.  The last trip I spent more time packing and unpacking than imaging.  Working to streamline other aspects also, but this one came up when I was debating whether to go ahead and order a second LiFePO4 battery or not.

Linwood


Re: ASCOM Driver "freezing"?

Steve Reilly
 

Another suggestion worth looking into I hope is your power settings in Windows as I have found that USB connections can be powered off if not active after a period of time. Also check the Device Manager for the USB settings. I have issues with my Starlight Xpress guider not being found if idle too long and have found if I disconnect the cameras and immediately reconnect it brings it back to usable. This is the UltraStar which otherwise works great. Not hijacking the thread but may be the same issue.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Monday, January 10, 2022 11:54 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] ASCOM Driver "freezing"?

There's not enough information to say for sure, but the most likely reason is the serial port hung. Are you using a USB/serial converter on a USB hub with a USB connection to your camera? If so, try moving the mount's USB cable to its own USB port on your computer.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf
Of wbelhaven via groups.io
Sent: Monday, January 10, 2022 8:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] ASCOM Driver "freezing"?

I'm seeing the AP ASCOM driver "not responding" again, multiple times
a night now. Seems the cable replacement was not a permanent fix. Can
someone please help? Can't really automate image capture with this continuing to freeze up.

I just upgraded to the most recent version of the driver and ran it
for a few hours without freeze. Are there any bugfixes in the latest
version that would address this, or is this just happenstance (again)? Any help would be appreciated.

Thanks.


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

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


Re: Piertech3 Adjustable Pier with AP1600 Experience

Dale Ghent
 

I think Bob's point is more along the lines of don't trust *only* software to keep the unwanted from happening. If you're going to automate roof closures, make sure that your roof control system has the appropriate *hardware* safety interlocks installed to prevent the unintentional guillotining of your telescope. This would mean things like making it physically impossible for the roof motor to run if the mount isn't in the correct orientation.

On Jan 10, 2022, at 12:03, Brian Valente <bvalente@...> wrote:

Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof.
I'm not sure what to make of advice not to fully use automation software from an automation software supplier 🤔

On Mon, Jan 10, 2022 at 8:43 AM Jerome A Yesavage <yesavage@...> wrote:
Yes, I have the Pier and I get fine images in all positions.

I park at P5, but Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof. If I use automation, I have to have the pier lower so the roof always clears the scope no matter what the mount position. Now Vito, says you can put a park position sensor on the controller, but I have never gotten this to work. I have the proximity sensor and an extra toggle for showing the pier down, but I cannot get the roof controller to take these inputs reliably. It will open and then raise the pier, but it closes before the pier is down (notta so good).

This is the proximity sensor:

https://www.amazon.com/gp/product/B07CWT7KW6/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

The toggle sensor is the same Honeywell that is used on my roof. Rock solid.

If any of you have this working reliably, please show me your wiring and settings on the roof controller. I fear I am doing something dumb (again).




--
Brian



Brian Valente
portfolio brianvalentephotography.com


Re: Piertech3 Adjustable Pier with AP1600 Experience

 

>>> Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof. 

I'm not sure what to make of advice not to fully use automation software from an automation software supplier 🤔

On Mon, Jan 10, 2022 at 8:43 AM Jerome A Yesavage <yesavage@...> wrote:
Yes, I have the Pier and I get fine images in all positions. 

I park at P5, but Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof.  If I use automation, I have to have the pier lower so the roof always clears the scope no matter what the mount position.  Now Vito, says you can put a park position sensor on the controller, but I have never gotten this to work.  I have the proximity sensor and an extra toggle for showing the pier down, but I cannot get the roof controller to take these inputs reliably.  It will open and then raise the pier, but it closes before the pier is down (notta so good). 

This is the proximity sensor:

https://www.amazon.com/gp/product/B07CWT7KW6/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

The toggle sensor is the same Honeywell that is used on my roof.  Rock solid. 

If any of you have this working reliably, please show me your wiring and settings on the roof controller.  I fear I am doing something dumb (again).



--
Brian 



Brian Valente


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

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@...> 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: ASCOM Driver "freezing"?

Ray Gralak
 

There's not enough information to say for sure, but the most likely reason is the serial port hung. Are you using a USB/serial converter on a USB hub with a USB connection to your camera? If so, try moving the mount's USB cable to its own USB port on your computer.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of wbelhaven via groups.io
Sent: Monday, January 10, 2022 8:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] ASCOM Driver "freezing"?

I'm seeing the AP ASCOM driver "not responding" again, multiple times a night now. Seems the cable
replacement was not a permanent fix. Can someone please help? Can't really automate image capture with this
continuing to freeze up.

I just upgraded to the most recent version of the driver and ran it for a few hours without freeze. Are there any
bugfixes in the latest version that would address this, or is this just happenstance (again)? Any help would be
appreciated.

Thanks.


Re: Piertech3 Adjustable Pier with AP1600 Experience

Jerome A Yesavage
 

Yes, I have the Pier and I get fine images in all positions. 

I park at P5, but Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof.  If I use automation, I have to have the pier lower so the roof always clears the scope no matter what the mount position.  Now Vito, says you can put a park position sensor on the controller, but I have never gotten this to work.  I have the proximity sensor and an extra toggle for showing the pier down, but I cannot get the roof controller to take these inputs reliably.  It will open and then raise the pier, but it closes before the pier is down (notta so good). 

This is the proximity sensor:

https://www.amazon.com/gp/product/B07CWT7KW6/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

The toggle sensor is the same Honeywell that is used on my roof.  Rock solid. 

If any of you have this working reliably, please show me your wiring and settings on the roof controller.  I fear I am doing something dumb (again).


Re: ASCOM Driver "freezing"?

midmoastro
 

On Mon, Nov 29, 2021 at 03:06 PM, wbelhaven wrote:
FTDI-based
Didnt see it listed so just asking, Is the FTDI driver installed?


Re: ASCOM Driver "freezing"?

wbelhaven
 

I'm seeing the AP ASCOM driver "not responding" again, multiple times a night now. Seems the cable replacement was not a permanent fix. Can someone please help? Can't really automate image capture with this continuing to freeze up.

I just upgraded to the most recent version of the driver and ran it for a few hours without freeze. Are there any bugfixes in the latest version that would address this, or is this just happenstance (again)? Any help would be appreciated.

Thanks.


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

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


Re: NINA not Parking my 1100

Ray Gralak
 

Hi Alex,

For ASCOM client applications (NINA, SGPro, etc.), the ASCOM driver's Park Setting setting is used, not APCC's. So, as others have already mentioned, you should set the park position in the ASCOM driver.

-Ray


Re: NINA not Parking my 1100

ap@CaptivePhotons.com
 

There are two park positions defined when using APCC.  One is APCC and is the position it goes to when you hit Park on the same pane (brown arrow below).  But the one NINA uses is the one set on the AP Ascom V2 driver setup.   See the blue arrow below. 

I keep mine set differently, as below -- that way NINA parks to Park 2, which is safer for sitting in dew or if it rained (which is also where NINA will park on a safety initiated park since it has just the one position).  But when I'm done, I park with APCC to Park 3 which is where I load/unload. 

Be sure you check the ASCOM one with respect to NINA's parking.

Linwood

4001 - 4020 of 88034