Date   

Rescue an old 400QMD?

alan137
 

Hello folks, 
There's an old 400 QMD near me for sale that was probably acquired at an estate sale or whatever and the seller doesn't know much about it.  It seems to include literally the mount head only and no accessories like counterweight shaft, hand controller, etc.
Are these parts still available?
Can this mount be converted / updated into a modern imaging platform with GOTO and computer control and guiding?
I think the original specs were that the motors only slew up to 16x.


Date-time format / APCC issues #APCC

Rodolphe
 

Hi
A recent Windows 10 update wrecked the date/time settings of my imaging PC. I discovered that after hours of investigation. My Mach1 stopped tracking for no obvious reason in the middle of the night… Noticed several errors in the APCC log and in the APCC pop up window that appears when things go really bad. 
However, even after fixing the W10 issue, rebooting, APCC seems lost as if the settings for various limits were sticking with the previous / wrong date/time Windows 10 settings.
Is there an easy way to reset APCC and the CP4 to the default factory settings altogether?
Other suggestions?
Thanks in advance 
Rodolphe


Re: Back Focus Troubles #Absolute_Encoders

M Hambrick
 

Hi David

I am out of town until tomorrow evening. I will send some information when I get back home.

Mike


On Jun 11, 2021, at 8:02 PM, David Diaz <night.skywatcher@...> wrote:

Mike

Awesome chart; thanks.

Can you please tell me how to communicate to PreciseParts items ‘C’ and ‘D?’

Thanks!

David D


Re: NINA and utilizing APCC meridian limits

Francesco Meschia
 

What does it do about timing of the flip itself. It will stop early, which is good. But does it wait to send the flip commands (pierside or new slew or both) until the target will be out of the prohibited area?

(Again, I can experiment when I get it).
Yes it’s designed to stop tracking and wait until the target has an HA that would let the scope clear any obstruction on the other side of the pier. Only then the actual flip happens.
Francesco


Re: Back Focus Troubles #Absolute_Encoders

David Diaz
 

Mike

Awesome chart; thanks.

Can you please tell me how to communicate to PreciseParts items ‘C’ and ‘D?’

Thanks!

David D


Re: NINA and utilizing APCC meridian limits

ap@CaptivePhotons.com
 

In this case, the flip will occur when the target reaches an angle on the other side of the mount that is clear of any defined obstruction. The target will then get recentered and such (if that option is on) and the session resumes.
That's terrific. I am hoping I have zero such spots -- with the MyT on the same mount I did not, though it is really close. I'll find out, but good to know there's a workaround. I hated the idea of building in (say) 30 minute gap for all angles when it's just one tiny area. This is really nice.

< Case in point: a person I once worked with got an hour of imaging time back just by rotating his filter wheel 180 degrees, turning the long side of it "up" and therefore away from the tripod legs. He could then image to the meridian instead of having to stop 30 minutes prior to it and waiting 30 minutes afterwards.

I've got a filter wheel and a guide camera 180 degrees from each other, both of which stick out (the guide camera much less). And frankly this is a nice "feature" of the manual rotator -- it forces me to go outside and turn it, and I can look and see whether 180 degrees off would be a better angle with regard to collisions (with an automated system I might never notice).

Another issue will be whether going to odd-leg-north instead of odd-leg-south. I get a significant amount of extra clearance with the odd-leg-south on the MyT. I'm worried the larger AP1100 will require I go odd-leg-north for balance (i.e. when no OTA but all the CW's on). George tells me I'll be good so optimistic. Time will tell.

But I'm really happy to see this synergy between the meridian limits in APCC and NINA's flip (or smart flip -- you do realize the name implies the other is "dumb" right?).

Linwood


Re: NINA and utilizing APCC meridian limits

Dale Ghent
 

On Jun 11, 2021, at 18:53, ap@captivephotons.com <ap@CaptivePhotons.com> wrote:

IF you've mapped out these collision areas using APCC's meridian limit config tool, then SMF will observe these limits and flip (or stop) the scope 10 seconds prior to encountering them. This is why I mentioned the plugin having two time statuses: one for any pre-meridian pause, the other for the actual flip time. Optimally they would be the same, meaning you don't have to stop work to avoid a collision while you wait for the target to sail through the meridian and get low enough so that you can then safely flip and resume.
What does it do about timing of the flip itself. It will stop early, which is good. But does it wait to send the flip commands (pierside or new slew or both) until the target will be out of the prohibited area?
In this case, the flip will occur when the target reaches an angle on the other side of the mount that is clear of any defined obstruction. The target will then get recentered and such (if that option is on) and the session resumes.

So yeah the scope will be sitting there with tracking off, watching the sky go by until the target "emerges" from any collision zone on the other side of the mount whereupon the flip will happen. The time this will occur is displayed by the plugin.

It's plausible that we could do something like park the scope for that duration if it's a long time to wait for the flip, just so it's not staring up into the sky while it does nothing. But I don't honestly know how common this kind of situation is because it's highly undesirable to be in in the first place and should be avoided or minimized with a proper hardware configuration (ie, getting rid of such large obstructions)

Case in point: a person I once worked with got an hour of imaging time back just by rotating his filter wheel 180 degrees, turning the long side of it "up" and therefore away from the tripod legs. He could then image to the meridian instead of having to stop 30 minutes prior to it and waiting 30 minutes afterwards.


Re: NINA and utilizing APCC meridian limits

ap@CaptivePhotons.com
 

IF you've mapped out these collision areas using APCC's meridian limit config tool, then SMF will observe these limits and flip (or stop) the scope 10 seconds prior to encountering them. This is why I mentioned the plugin having two time statuses: one for any pre-meridian pause, the other for the actual flip time. Optimally they would be the same, meaning you don't have to stop work to avoid a collision while you wait for the target to sail through the meridian and get low enough so that you can then safely flip and resume.
What does it do about timing of the flip itself. It will stop early, which is good. But does it wait to send the flip commands (pierside or new slew or both) until the target will be out of the prohibited area?

(Again, I can experiment when I get it).

shameless plug for the A-P Eagle tripod with extension
I actually spent a lot of time staring at that as it looked very attractive, but I really love my Planet. Going to give it a go first. Not sure if I could get a mini-pier extension to work on it or not.

Linwood


Re: NINA and utilizing APCC meridian limits

Francesco Meschia
 

I am the developer of SMF. I am very happy if this plugin helps you AP users. Keep in mind it’s still a very early beta, and needs more testing – in particular for the cases of meridian flipping “under the pole”. When used with APCC, APCC should still provide a “safety net” if SMF misbehaves, but be careful. Do let me know if there’s something clearly wrong.
Thanks,
Francesco 


Re: NINA and utilizing APCC meridian limits

Dale Ghent
 

Right, in NINA and other apps, the parameters for a vanilla meridian flip are straight forward: You specify a desired flip delay once for when you reach the meridian, and an optional pause-before value (also in minutes) in case you have to suspend things as the mount approaches the meridian because the west side of your mount has clearance issues at the declination you're imaging at. This is common for tripods where the camera can crash into a leg. The real solution here is to convert to a pier or tri-pier type of setup that either removes the legs as obstructions or lifts your gear sufficiently above them (*shameless plug for the A-P Eagle tripod with extension*)

IF you've mapped out these collision areas using APCC's meridian limit config tool, then SMF will observe these limits and flip (or stop) the scope 10 seconds prior to encountering them. This is why I mentioned the plugin having two time statuses: one for any pre-meridian pause, the other for the actual flip time. Optimally they would be the same, meaning you don't have to stop work to avoid a collision while you wait for the target to sail through the meridian and get low enough so that you can then safely flip and resume.

Without SMF, you have to set up the vanilla meridian flip parameters for your worst-case scenario, even thought your target of the moment might be at a low or high enough declination that avoids any obstruction. In this case, the vanilla flip would be premature and interrupt imaging the target when it's at the best place in the sky to image it.

On Jun 11, 2021, at 11:48, ap@captivephotons.com <ap@CaptivePhotons.com> wrote:

As for slews, this has no effect on slews, so starting in a cw-up position is something this plugin doesn't care about or influence. Its only concern at the moment is dictating when the flip happens.
One of the things I have yet to find out (as I don't have the mount yet) is whether I will have the opposite problem -- a need to limit tracking before meridian to avoid collisions at certain DEC angles. Which I think I can code for, right? Different limits based on DEC?

Let's hypothesize that at certain angles I need to stop 15 minutes before transit and resume 15 minutes afterwards to avoid the collision area.

Will this new smart flip accommodate the opposite case -- where you enter limits at certain angles which will not quite allow counterweight level, much less up.

I can do that in NINA now, I think, but it's uniform -- all DEC angles. So I'd have my (example only) 30 minute gap for all flips.

I'm likely to need it (if I need it at all) just in a small area, which is attractive -- I could put in limits once, and it would image to transit and flip in all other areas, but in that area it will stop early and continue later to honor the limits?

Linwood






Re: NINA and utilizing APCC meridian limits

ap@CaptivePhotons.com
 

APCC allows you to create totally custom meridian limits.
Exactly, it's one of the things I'm excited about.

My curiosity is how they will interact with a meridian flip from NINA.

And yes... I could just wait and try it. But waiting is hard..... 😊


Re: NINA and utilizing APCC meridian limits

George
 

Linwood,

APCC allows you to create totally custom meridian limits.

Regards,

George

George Whitney
Astro-Physics, Inc.
Phone:  815-222-6538 (direct line)
Phone:  815-282-1513 (office)
Email:  george@astro-physics.com

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@CaptivePhotons.com
Sent: Friday, June 11, 2021 10:49 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] NINA and utilizing APCC meridian limits

As for slews, this has no effect on slews, so starting in a cw-up position is something this plugin doesn't care about or influence. Its only concern at the moment is dictating when the flip happens.
One of the things I have yet to find out (as I don't have the mount yet) is whether I will have the opposite problem -- a need to limit tracking before meridian to avoid collisions at certain DEC angles. Which I think I can code for, right? Different limits based on DEC?

Let's hypothesize that at certain angles I need to stop 15 minutes before transit and resume 15 minutes afterwards to avoid the collision area.

Will this new smart flip accommodate the opposite case -- where you enter limits at certain angles which will not quite allow counterweight level, much less up.

I can do that in NINA now, I think, but it's uniform -- all DEC angles. So I'd have my (example only) 30 minute gap for all flips.

I'm likely to need it (if I need it at all) just in a small area, which is attractive -- I could put in limits once, and it would image to transit and flip in all other areas, but in that area it will stop early and continue later to honor the limits?

Linwood


Re: NINA and utilizing APCC meridian limits

ap@CaptivePhotons.com
 

As for slews, this has no effect on slews, so starting in a cw-up position is something this plugin doesn't care about or influence. Its only concern at the moment is dictating when the flip happens.
One of the things I have yet to find out (as I don't have the mount yet) is whether I will have the opposite problem -- a need to limit tracking before meridian to avoid collisions at certain DEC angles. Which I think I can code for, right? Different limits based on DEC?

Let's hypothesize that at certain angles I need to stop 15 minutes before transit and resume 15 minutes afterwards to avoid the collision area.

Will this new smart flip accommodate the opposite case -- where you enter limits at certain angles which will not quite allow counterweight level, much less up.

I can do that in NINA now, I think, but it's uniform -- all DEC angles. So I'd have my (example only) 30 minute gap for all flips.

I'm likely to need it (if I need it at all) just in a small area, which is attractive -- I could put in limits once, and it would image to transit and flip in all other areas, but in that area it will stop early and continue later to honor the limits?

Linwood


Re: NINA and utilizing APCC meridian limits

Dale Ghent
 

On Jun 11, 2021, at 09:11, KHursh via groups.io <khursh=yahoo.com@groups.io> wrote:

I think it may be time for me to switch to 1.11. I am usually wary of anything in beta, but I think I will give it a go as we approach the full moon. The SMF has the "killer app" feel to it, so I applaud the devs over at NINA for this one. Somewhat off-topic, does this affect the ability to start a sequence CW up?
To be fair, this kind of thing has been in SGPro for a while now as well, but it's done through a different mechanism (APCC send the limits to SGPro's network API, where this plugin reads and interprets the MLM file directly). NINA doesn't have a network API yet. It's on the docket but it's something we want to take our time with and focus on in terms of design, and this development cycle has been centered around the new Advanced Sequencer and other structural improvements. There's a lot of wrong ways to architect an API and it's critical to get it right since things external to the app will be relying on it.

As for slews, this has no effect on slews, so starting in a cw-up position is something this plugin doesn't care about or influence. Its only concern at the moment is dictating when the flip happens.

/dale


Re: Help phd2 900 gto

Worsel
 

Vincent

You can also post on the PHD2 forum at https://groups.google.com/g/open-phd-guiding

Bryan


Re: NINA and utilizing APCC meridian limits

KHursh
 

I think it may be time for me to switch to 1.11. I am usually wary of anything in beta, but I think I will give it a go as we approach the full moon. The SMF has the "killer app" feel to it, so I applaud the devs over at NINA for this one. Somewhat off-topic, does this affect the ability to start a sequence CW up?


NINA and utilizing APCC meridian limits

Dale Ghent
 

Hi all, this aimed at users of APCC and NINA; specifically those who are using the current development train of NINA, version 1.11.

I've been working with another NINA contributor on a plugin for NINA's Advanced Sequencer that replaces the standard meridian flip trigger with a new one called Smart Meridian Flipper.

SMF can read in an APCC .mlm file or one in SMF's own obstruction definition format. It will then dynamically adjust the flip time based on the target's declination and what that corresponds with in the MLM file in terms of a meridian limit.

Flips will happen 10 seconds prior to the mount reaching the defined limit so as not to trigger an adverse reaction from APCC, which itself can be configured to do anything from emit a warning to halting tracking or parking the mount - the latter two being not-helpful when it comes to unattended imaging.

If you are a 1.11+Advanced Sequencer user, use (or aspire to use) meridian limits in APCC, and are interested in having your sequences' meridian flips take advantage of these limits and the wild and crazy world of counterweight-up imaging, I've made the plugin available to try out and test. It seems to work fine on my setup (MLM generated in APCC Pro, driving a Mach1+CP3) but I'm interested in seeing how it works for people who might not have the typical hourglass-shaped limits and perhaps something more funky or asymmetrical going on.

When you run a sequence, SMF will display two time values in its status area:

1. The local time when there would be a suspension of activity and tracking is halted before reaching the meridian if the limits dictate there will be a need for that
2. The local time when the flip will occur

I think in normal settings, most people will not have any need to pause on approach to the meridian so both times will be the same. That's fine. It just means you'll image straight through the meridian until the specified time, which is when the flip will happen. So if your target transits at 1am and it's at a declination that gives you 2 hours of room past the meridian, then the flip will happen at 3am (or really, 2:59:49, due to the 10 second buffer prior to hitting the limit.)

You can download the plugin here:
https://daleghent.com/misc/nina/SmartMeridianFlip.zip

To install it:

1. Make sure you're running NINA 1.11 build 92
2. Create the folder %LOCALAPPDATA%\NINA\Plugins if it does not already exist
3. Unzip the download and drop the DLL file into the above folder, then start NINA

Once NINA is opened:

4. Go to Options > Plugins > SmartMeridianFlipper and configure it with the .mlm you want to use for your meridian limits.
5. Go to Options > Imaging > Meridian Flip Settings and change both Minutes After Meridian and Max. Minutes After Meridian to 1.
6. In the same section, make sure that Pause Before Meridian is 0
7. In your Advanced Sequencer sequence, *replace* any instance of the standard Meridian Flip trigger with the Smart Meridian Flipper trigger
8. Go about your business as you would normally do. If everything goes according to plan, you'll image right up until you hit the meridian limit (minus 10 seconds) for your target's declination.

The plugin system in NINA is being finalized in its design and there will be some major changes soon, so this specific plugin file that I linked above may not work in builds of 1.11 past the current build 92. It will be updated as the plugin system evolves over the next few weeks, which will include an automated way to download and update plugins as new versions are made available by their respective authors. I wanted to make this plugin available to interested persons early to get it some wider testing. Any testing and feedback is greatly appreciated, of course, and that feedback can be given directly to me (daleg@elemental.org) or on the NINA Discord server.

A quick and dirty FAQ:

Q: Will I still have the standard Meridian Flip trigger available if I want to go back to using it?
A: Yes, it'll still be there. Drag SMF to the trash icon to remove it and drop the standard Meridian Flip trigger back in to your sequence in its place. Essentially the reverse of step 7 above.

Q: Will this be available for NINA 1.10?
A: No. This is a plugin and NINA's plugin system is new as of more recent builds of 1.11. 1.10 is in bug fix-only mode anyway

Q: Will I be able to use this in NINA 1.11's Simple Sequencer?
A: No. As with all plugins, this is available for use only within the Advanced Sequencer

Q: If I'm having a problem with this, what info do you need?
A: Your .mlm file and the target's declination would be great, otherwise I would have no way to replicate your conditions/configuration

Q: CCD or CMOS?
A: ...

Thanks and happy imaging.

/dale


Re: Mach2 stuck in a slew while parked (APCC Pro)

Ray Gralak
 

Unfortunately, because of the misconfiguration, the error would have persisted. And since the slew never reached the destination, it is probably as good a reason as any to stop the client application from proceeding. If the park was reported then there would have likely been further errors in SGP that would have made it more time consuming to locate the original source of the problem. At least now you know what to do to solve the problem.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Luca Marinelli
Sent: Thursday, June 10, 2021 7:26 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Mach2 stuck in a slew while parked (APCC Pro)

One more thing, in a case like this when APCC parks the mount in the middle of a slew, shouldn't APCC
communicate to the ASCOM driver that the slew was aborted and the mount parked? Two hours later, SGP was
still patiently waiting for the mount to complete the slew. The roof was still open when the sun came up and the
roof controller ultimately closed the roof due to unsafe sunny conditions but the sequence in SGP never
completed, as it was still waiting the the mount to report that the slew to the target had completed or failed.

Thanks,

Luca


Re: Mach2 stuck in a slew while parked (APCC Pro)

Luca Marinelli
 

On Thu, Jun 10, 2021 at 10:15 AM, Ray Gralak wrote:
Hi Luca,

You may want to start from scratch by deleting the Settings.apcc file in this folder:

C:\ProgramData\Astro-Physics\APCC

If needed, your can recover your settings from the Backups folder.

-Ray
Thank you!


Re: Mach2 stuck in a slew while parked (APCC Pro)

Luca Marinelli
 

One more thing, in a case like this when APCC parks the mount in the middle of a slew, shouldn't APCC communicate to the ASCOM driver that the slew was aborted and the mount parked? Two hours later, SGP was still patiently waiting for the mount to complete the slew. The roof was still open when the sun came up and the roof controller ultimately closed the roof due to unsafe sunny conditions but the sequence in SGP never completed, as it was still waiting the the mount to report that the slew to the target had completed or failed.

Thanks,

Luca

3281 - 3300 of 82280