Date   

Re: AP1100 autoguiding

Christopher Erickson
 

Just for general FYI, RCOS OTA's have terrible secondary mirror-based focusers that are notorious for going berserk and slamming into one extreme of the focus range and then jamming. Best fix is adding a Moonlight Crayford and stop using the secondary-based focus mechanism.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Thu, May 19, 2022, 8:29 AM Kent Kirkley via groups.io <kgkirkley=aol.com@groups.io> wrote:
Steven
I hope the "RC" is one of the great ones; ie. An RCOS which were/are incredibly stable.
RCOS' motto was "Focus and forget it", as well a no optical flexure issues.
If a Chinese RC, you probably won't experience this.
Kent Kirkley



-----Original Message-----
From: Steven Panish <scpanish1@...>
To: main@ap-gto.groups.io
Sent: Thu, May 19, 2022 1:06 pm
Subject: Re: [ap-gto] AP1100 autoguiding

Chris's points are good.  I'm hoping the RC arriving shortly will be stable. 
Steve

On Wed, May 18, 2022 at 1:32 PM Christopher Erickson <christopher.k.erickson@...> wrote:
Dovetail bars and radius blocks or rings are just about always quite a ways farther apart than the ends of dovetail brackets and hence a better place to attempt fine adjustments of cone error. Further, the actual error is almost always in the OTA and its support structure, not the mount and dovetail bracket. Routinely swapping OTA's on the same mount (as I often do) would be a real problem.

And make sure that OTA is precisely collimated before attempting any cone error adjustments.

And a compound OTA with a floating primary might have a lot of variability in its cone error as it points around the sky and shifts the primary mirror's orientation to gravity.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, May 18, 2022, 5:06 AM Andrew J <andjones132@...> wrote:
On Sun, May 15, 2022 at 02:40 PM, Steven Panish wrote:
Unfortunately it is rare  to find cone adjustment screws actually on plates or rings. 
@steven Panish. You make a good point. I wish the saddle plates came with adjustment screws to be able to correct for cone error. It would be so easy to adjust if there where screws that would allow you to adjsut the angle of the dovetail plate in the saddle. Shims are OK, but it woudl be much easier if this was built into the saddle plate. Just my 2 cents....

Andrew J


--
PLEASE NOTE MY NEW EMAIL ADDRESS!!!
Due to Google eliminating cheap domain serving, Virginia and I are changing to regular gmail addresses.  The old panishnet address will forward to this address for a short while, but please add the new address, scpanish1@..., to your contact list.


Re: AP1100 autoguiding

Kent Kirkley
 

Steven
I hope the "RC" is one of the great ones; ie. An RCOS which were/are incredibly stable.
RCOS' motto was "Focus and forget it", as well a no optical flexure issues.
If a Chinese RC, you probably won't experience this.
Kent Kirkley



-----Original Message-----
From: Steven Panish <scpanish1@...>
To: main@ap-gto.groups.io
Sent: Thu, May 19, 2022 1:06 pm
Subject: Re: [ap-gto] AP1100 autoguiding

Chris's points are good.  I'm hoping the RC arriving shortly will be stable. 
Steve

On Wed, May 18, 2022 at 1:32 PM Christopher Erickson <christopher.k.erickson@...> wrote:
Dovetail bars and radius blocks or rings are just about always quite a ways farther apart than the ends of dovetail brackets and hence a better place to attempt fine adjustments of cone error. Further, the actual error is almost always in the OTA and its support structure, not the mount and dovetail bracket. Routinely swapping OTA's on the same mount (as I often do) would be a real problem.

And make sure that OTA is precisely collimated before attempting any cone error adjustments.

And a compound OTA with a floating primary might have a lot of variability in its cone error as it points around the sky and shifts the primary mirror's orientation to gravity.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, May 18, 2022, 5:06 AM Andrew J <andjones132@...> wrote:
On Sun, May 15, 2022 at 02:40 PM, Steven Panish wrote:
Unfortunately it is rare  to find cone adjustment screws actually on plates or rings. 
@steven Panish. You make a good point. I wish the saddle plates came with adjustment screws to be able to correct for cone error. It would be so easy to adjust if there where screws that would allow you to adjsut the angle of the dovetail plate in the saddle. Shims are OK, but it woudl be much easier if this was built into the saddle plate. Just my 2 cents....

Andrew J


--
PLEASE NOTE MY NEW EMAIL ADDRESS!!!
Due to Google eliminating cheap domain serving, Virginia and I are changing to regular gmail addresses.  The old panishnet address will forward to this address for a short while, but please add the new address, scpanish1@..., to your contact list.


Re: AP1100 autoguiding

Christopher Erickson
 

When adjusting cone error on OTA's, I often make thin shims from the sides of aluminum pop cans. They are easily cut with scissors and paper punches. And don't stack too many shims together or you might end up with a slightly compressible spacer that will introduce some additional flexure.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Thu, May 19, 2022, 8:06 AM Steven Panish <scpanish1@...> wrote:
Chris's points are good.  I'm hoping the RC arriving shortly will be stable. 
Steve

On Wed, May 18, 2022 at 1:32 PM Christopher Erickson <christopher.k.erickson@...> wrote:
Dovetail bars and radius blocks or rings are just about always quite a ways farther apart than the ends of dovetail brackets and hence a better place to attempt fine adjustments of cone error. Further, the actual error is almost always in the OTA and its support structure, not the mount and dovetail bracket. Routinely swapping OTA's on the same mount (as I often do) would be a real problem.

And make sure that OTA is precisely collimated before attempting any cone error adjustments.

And a compound OTA with a floating primary might have a lot of variability in its cone error as it points around the sky and shifts the primary mirror's orientation to gravity.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, May 18, 2022, 5:06 AM Andrew J <andjones132@...> wrote:
On Sun, May 15, 2022 at 02:40 PM, Steven Panish wrote:
Unfortunately it is rare  to find cone adjustment screws actually on plates or rings. 
@steven Panish. You make a good point. I wish the saddle plates came with adjustment screws to be able to correct for cone error. It would be so easy to adjust if there where screws that would allow you to adjsut the angle of the dovetail plate in the saddle. Shims are OK, but it woudl be much easier if this was built into the saddle plate. Just my 2 cents....

Andrew J



--
PLEASE NOTE MY NEW EMAIL ADDRESS!!!
Due to Google eliminating cheap domain serving, Virginia and I are changing to regular gmail addresses.  The old panishnet address will forward to this address for a short while, but please add the new address, scpanish1@..., to your contact list.


Re: AP1100 autoguiding

Steven Panish
 

Chris's points are good.  I'm hoping the RC arriving shortly will be stable. 
Steve

On Wed, May 18, 2022 at 1:32 PM Christopher Erickson <christopher.k.erickson@...> wrote:
Dovetail bars and radius blocks or rings are just about always quite a ways farther apart than the ends of dovetail brackets and hence a better place to attempt fine adjustments of cone error. Further, the actual error is almost always in the OTA and its support structure, not the mount and dovetail bracket. Routinely swapping OTA's on the same mount (as I often do) would be a real problem.

And make sure that OTA is precisely collimated before attempting any cone error adjustments.

And a compound OTA with a floating primary might have a lot of variability in its cone error as it points around the sky and shifts the primary mirror's orientation to gravity.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, May 18, 2022, 5:06 AM Andrew J <andjones132@...> wrote:
On Sun, May 15, 2022 at 02:40 PM, Steven Panish wrote:
Unfortunately it is rare  to find cone adjustment screws actually on plates or rings. 
@steven Panish. You make a good point. I wish the saddle plates came with adjustment screws to be able to correct for cone error. It would be so easy to adjust if there where screws that would allow you to adjsut the angle of the dovetail plate in the saddle. Shims are OK, but it woudl be much easier if this was built into the saddle plate. Just my 2 cents....

Andrew J



--
PLEASE NOTE MY NEW EMAIL ADDRESS!!!
Due to Google eliminating cheap domain serving, Virginia and I are changing to regular gmail addresses.  The old panishnet address will forward to this address for a short while, but please add the new address, scpanish1@..., to your contact list.


Re: [ap-ug] ZWO color camera problem - Update

Roland Christen
 

It's a 6200C astro-imaging camera which has a color chip. It does not have a shutter, so can take exposures as fast as .001 seconds as well as video. Same chip is used in high end Canon digital cameras.

Roland

-----Original Message-----
From: M Hambrick <mhambrick563@...>
To: main@ap-gto.groups.io
Sent: Thu, May 19, 2022 4:31 am
Subject: Re: [ap-gto] [ap-ug] ZWO color camera problem - Update

Is the ZWO camera an astro-imaging camera ? Out of curiosity what kind of exposure time do you have to use to take images of objects during daylight, or is there something you have to do with the stretching ?

Mike

--
Roland Christen
Astro-Physics


Re: JPL Horizon wont launch in APCC

Peter Gottstein
 

The newest update of apcc did the trick. Thank you everybody. 


Re: [ap-ug] ZWO color camera problem - Update

thefamily90 Phillips
 

I use ZWO monochrome and color cameras for all my Lunar, planetary and solar images. I have never done any imaging, except solar, during daylight hours.

JimP 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of M Hambrick <mhambrick563@...>
Sent: Thursday, May 19, 2022 5:31:59 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] [ap-ug] ZWO color camera problem - Update
 
Is the ZWO camera an astro-imaging camera ? Out of curiosity what kind of exposure time do you have to use to take images of objects during daylight, or is there something you have to do with the stretching ?

Mike


Re: [ap-ug] ZWO color camera problem - Update

M Hambrick
 

Is the ZWO camera an astro-imaging camera ? Out of curiosity what kind of exposure time do you have to use to take images of objects during daylight, or is there something you have to do with the stretching ?

Mike


Re: ZWO color camera problem

Calypte
 

Hmm.  I have a ZWO 2600 MCP that I bought several months ago.  My original intent was to do a Hyperstar setup, totally independent of my observatory.  But nobody has scopes.  I've only tested the 2600 MCP to the extent of plugging it in and seeing that the LED lights up.  I haven't looked at this forum much recently.  You now have my attention.  I'll be following your posts about this.


Re: AIC 2022

Calypte
 

When they announced that AIC registration was open, I was within minutes of signing up.  But then I got an invitation for a major family event on the same weekend.  Family comes first.  I know another regular attendee who now lives in Oz, and he informed me that he won't be going to AIC, either.  Family matters back in the UK for him.  Had I signed up, I would have been sorely disappointed at not seeing the fine crew from Astro-Physics.  But knowing that you guys won't be there mitigates my personal regret at not attending AIC.  I hope they get a good turnout anyway.  I look forward to trying again in a couple of years, or whenever they schedule the next one.


Re: [ap-ug] ZWO color camera problem - Update

Roland Christen
 

Hello fellow astronuts,

I could not get deep sky images to come out right with this color camera. So I went back to basics and imaged a known daytime object with known colors. Ross was right, the key really was the X and Y offset numbers. As you can see below, with X and Y set to 0, the colors of blue and red are reversed. With X and Y set to 1, the proper colors appear on the daytime shots of the water tower. The preview image of the star doesn't change, and it was difficult to see the changes on a deep sky object. But now my galaxies have red cores instead of blue.

So, I thank Ross again for pointing out the solution, and although I am a little dense, I can sometimes find the Reese's cup hidden in the back of the cupboard.

Rolando






-----Original Message-----
From: Ross Salinger <rgsalinger@...>
To: main@ap-ug.groups.io
Sent: Wed, May 18, 2022 2:34 pm
Subject: Re: [ap-ug] ZWO color camera problem

MaximDL gives you a little 2 field popup that lets you choose 1 or 0 in each box. Go through all 4 possibilities and one should look pretty good. My own experience with MDL is that they have gotten way behind the curve with regards to these cameras. 
See below.
On 5/18/2022 12:30 PM, Roland Christen via groups.io wrote:

Sounds like the color matrix is set wrong in Maxim-DL
yes, but I can't see any way to change it in Maxim.

Roland

-----Original Message-----
From: Stacey Mills <w4sm@...>
To: main@ap-ug.groups.io
Sent: Wed, May 18, 2022 2:12 pm
Subject: Re: [ap-ug] ZWO color camera problem

Sounds like the color matrix is set wrong in Maxim-DL.  I use PixInsight.  I believe the ZWO matrix is "RGGB."  PixInsight has an option for a "BGGR" matrix which seems to be what you're encountering since red and blue are switched.. 

--
Roland Christen
Astro-Physics


Re: ZWO color camera problem

Frank Widmann
 

From the MDL manual:

Many cameras produce images that are offset slightly from the nominal starting position. This results in a misalignment of the Bayer pattern, which in turn produces grossly incorrect colors. This can be corrected in the Convert Color command by adjusting the Offset X and Offset Y values; simply dial in different values until you get reasonable looking color. More often you simply need to tweak the color balance; this can be done in the Convert Color command as well.

Frank

On May 18, 2022, at 11:55 AM, Roland Christen via groups.io <chris1011@...> wrote:


Hi astro-imagers,

I have been using a ZWO 6200C color camera here at our factory observatory to test scopes, flatteners etc. I recently aimed it at a nearby blue water tower and was shocked to find that the color image showed the tower red, along with a red sky. The red lights on top of the tower came out blue. The green grass came out green. I did the color conversion in MaximDL from the raw image. After splitting the color image into RGB channels, I mapped the red to the blue channel and vice versa. That resulted in a proper color image.

I can't for the life of me figure out how Maxim-DL could mix up the conversion or whether it's something in the ZWO ASCOM driver that is amiss. Clearly the red pixels are being assigned to the blue channel, and the blue to the red channel in the color image.

Anyone know where to look for a solution, other than re-mapping every image?

Rolando



Re: ZWO color camera problem

 

I suggest fiddling with the offsets would be a fallback approach if changing the bayer pattern did not work



On Wed, May 18, 2022 at 1:03 PM Frank Widmann via groups.io <fjwidmann=aol.com@groups.io> wrote:
From the MDL manual:

Many cameras produce images that are offset slightly from the nominal starting position. This results in a misalignment of the Bayer pattern, which in turn produces grossly incorrect colors. This can be corrected in the Convert Color command by adjusting the Offset X and Offset Y values; simply dial in different values until you get reasonable looking color. More often you simply need to tweak the color balance; this can be done in the Convert Color command as well.

Frank

On May 18, 2022, at 11:55 AM, Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:


Hi astro-imagers,

I have been using a ZWO 6200C color camera here at our factory observatory to test scopes, flatteners etc. I recently aimed it at a nearby blue water tower and was shocked to find that the color image showed the tower red, along with a red sky. The red lights on top of the tower came out blue. The green grass came out green. I did the color conversion in MaximDL from the raw image. After splitting the color image into RGB channels, I mapped the red to the blue channel and vice versa. That resulted in a proper color image.

I can't for the life of me figure out how Maxim-DL could mix up the conversion or whether it's something in the ZWO ASCOM driver that is amiss. Clearly the red pixels are being assigned to the blue channel, and the blue to the red channel in the color image.

Anyone know where to look for a solution, other than re-mapping every image?

Rolando





Re: ZWO color camera problem

Frank Widmann
 

From the MDL manual:

Many cameras produce images that are offset slightly from the nominal starting position. This results in a misalignment of the Bayer pattern, which in turn produces grossly incorrect colors. This can be corrected in the Convert Color command by adjusting the Offset X and Offset Y values; simply dial in different values until you get reasonable looking color. More often you simply need to tweak the color balance; this can be done in the Convert Color command as well.

Frank

On May 18, 2022, at 11:55 AM, Roland Christen via groups.io <chris1011@...> wrote:


Hi astro-imagers,

I have been using a ZWO 6200C color camera here at our factory observatory to test scopes, flatteners etc. I recently aimed it at a nearby blue water tower and was shocked to find that the color image showed the tower red, along with a red sky. The red lights on top of the tower came out blue. The green grass came out green. I did the color conversion in MaximDL from the raw image. After splitting the color image into RGB channels, I mapped the red to the blue channel and vice versa. That resulted in a proper color image.

I can't for the life of me figure out how Maxim-DL could mix up the conversion or whether it's something in the ZWO ASCOM driver that is amiss. Clearly the red pixels are being assigned to the blue channel, and the blue to the red channel in the color image.

Anyone know where to look for a solution, other than re-mapping every image?

Rolando



Re: ZWO color camera problem

Gregg Ruppel
 

Convert color under the color tab….

Gregg

Visit my astronomy & astrophotography site
www.greggsastronomy.com

On May 18, 2022, at 12:50 PM, Dean Jacobsen <deanjacobsen@...> wrote:

On Wed, May 18, 2022 at 12:33 PM, Roland Christen wrote:
would love to set the debayering to RGGB, but nowhere in Maxim is this setting possible. I have looked everywhere, no settings in either the ZWO driver or in Maxim.
 
Roland
 
It is RGGB.  Check out SharpCap.  I think that they have a free version [I use the Pro version with the polar align tool]  SharpCap will debayer it for you.
 
--
Dean Jacobsen
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/

--
Clear skies,
Gregg
www.greggsastronomy.com


Re: ZWO color camera problem

Dean Jacobsen
 

On Wed, May 18, 2022 at 12:33 PM, Roland Christen wrote:
would love to set the debayering to RGGB, but nowhere in Maxim is this setting possible. I have looked everywhere, no settings in either the ZWO driver or in Maxim.
 
Roland
 
It is RGGB.  Check out SharpCap.  I think that they have a free version [I use the Pro version with the polar align tool]  SharpCap will debayer it for you.
 
--
Dean Jacobsen
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/


Re: 3D View error #APCC

 
Edited

The laptop is at the scope, controlling it, and I'm accessing it from my indoor desktop.

P.S. Thanks to Ray for suggesting the possible cause of the error.


Re: 3D View error #APCC

 

Jerome is your laptop the one at the scope or the one accessing the scope computer via Remote Desktop?



On Wed, May 18, 2022 at 12:41 PM Jerome Allison <jallison@...> wrote:
I recently had basically the same problem.  I was using Remote Desktop to control my imaging laptop.  The 3D view in APCC would produce the error and clicking "OK" would close APCC down.  I got different messages, but for example the most common one was "Load Library failed with error 126: The specified module could not be found."  I wish the O.P. had posted their solution, but I did find a workaround.

My laptop CPU has built-in AMD Radeon graphics, as well as an nVidia GeForce GTX 1660 Ti graphics set.  Disabling the nVidia video in Device Manager cured the problem.  So now the choice is either disable that (and remember to re-enable later) or not use the 3D view when in APCC over Remote Desktop.

Jerome




Re: 3D View error #APCC

 

I recently had basically the same problem.  I was using Remote Desktop to control my imaging laptop.  The 3D view in APCC would produce the error and clicking "OK" would close APCC down.  I got different messages, but for example the most common one was "Load Library failed with error 126: The specified module could not be found."  I wish the O.P. had posted their solution, but I did find a workaround.

My laptop CPU has built-in AMD Radeon graphics, as well as an nVidia GeForce GTX 1660 Ti graphics set.  Disabling the nVidia video in Device Manager cured the problem.  So now the choice is either disable that (and remember to re-enable later) or not use the 3D view when in APCC over Remote Desktop.

Jerome


Re: ZWO color camera problem

Roland Christen
 


I always manually select the RGGB just to minimize any possible errors.  Kevin Cook
I would love to set the debayering to RGGB, but nowhere in Maxim is this setting possible. I have looked everywhere, no settings in either the ZWO driver or in Maxim.

Roland

-----Original Message-----
From: Kevin Cook <kvc3509@...>
To: main@ap-gto.groups.io
Sent: Wed, May 18, 2022 2:23 pm
Subject: Re: [ap-gto] ZWO color camera problem

Roland - Gregg is right.  I think most ASI cameras, including your 6200MC camera, use the RGGB pattern for the Bayer mosaic.  Possibly something in Maxim DL reset your Debayering pattern to something other than RGGB?   Maybe a software update to Maxim DL reset that parameter.  There could have been a driver update in ASCOM, but hard to imagine that ZWO would input the incorrect Bayer pattern for their own camera.  Even when some processing software has a Automatic setting for Debayering, I always manually select the RGGB just to minimize any possible errors.  Kevin Cook

On Wed, May 18, 2022 at 11:55 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
Hi astro-imagers,

I have been using a ZWO 6200C color camera here at our factory observatory to test scopes, flatteners etc. I recently aimed it at a nearby blue water tower and was shocked to find that the color image showed the tower red, along with a red sky. The red lights on top of the tower came out blue. The green grass came out green. I did the color conversion in MaximDL from the raw image. After splitting the color image into RGB channels, I mapped the red to the blue channel and vice versa. That resulted in a proper color image.

I can't for the life of me figure out how Maxim-DL could mix up the conversion or whether it's something in the ZWO ASCOM driver that is amiss. Clearly the red pixels are being assigned to the blue channel, and the blue to the red channel in the color image.

Anyone know where to look for a solution, other than re-mapping every image?

Rolando



--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics

2501 - 2520 of 88774