1. main@ap-gto.groups.io
   Date   
Re: Close up of M81 without CCDT67

Stuart <stuart.j.heggie@...>
 

Robert, these are both super shots but the Running Man is my favorite for sure.


On Fri, 14 Feb 2020 at 16:47, Robert Chozick via Groups.Io <rchozick=aol.com@groups.io> wrote:
So, would you say the new advantages of the small pixel CMOS cameras is that they bring high sensitivity to small pixels?

I also got a shot of the Running Man with the 1600mm setup:


I got M101 at 1600 but the seeing was worse and guiding not as good. 


Robert



On Feb 14, 2020, at 3:10 PM, uncarollo2 via Groups.Io <chris1011@...> wrote:

You are running 0.6 arc sec per pixel, which to me is not oversampling for high resolution imaging. In fact, for galaxies i prefer 0.3 to 0.4 arc sec per pixel which really brings out fine detail. My 17"F8 astrograph and the QSI 683 has such pixel scale and really does a superb job on small faint galaxies, even here in Northern Illinois. You have to have good tracking, of course, and on the best nights I can get below 0.15 arc sec RMS with the 1600 encoder mount.

I see a lot of images that are way undersampled (3 to 4 arc sec per pixel) with poor guiding that produces thick stars and very little resolution. To me these images resemble Brownie camera snapshots versus images taken with an 8x10 view camera. (shows my age, doesn't it)  :^))

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 2:14 pm
Subject: Re: [ap-gto] Close up of M81 without CCDT67

Thanks Roland.  My last dark sky outing was my first use of this scope and camera.   I am really confused on the whole image scale question.  I bought this camera because it has the largest pixels of any of the CMOS cameras. The image scale is .6 with this camera and 1600mm.   My scale is about 1.8 with my FSQ 106 - 530mm.  If the recommended guidance of a scale of 1-2 for image scale is used the 1600mm should be too small an image scale.  Most CMOS cameras have only 2.5-3.5 micron pixels vs 4.63 on my ASI294.  Is oversampling bad?  The .6 scale in my image sure looks ok.    What about .4 or .3?  I intentionally did not get larger than a 1600mm focal length because of this issue (and yes, guiding issues are not as bad vs 2000 and over).  Everyone asks why I got an 8 RC instead of a 10 or 12 inch RC.  The above reason is why.   Each new CMOS camera that comes out still has really small pixels.   How good would 2.5 micron pixels look on a 2500 mm scope?  

Robert

On Feb 14, 2020, at 1:18 PM, uncarollo2 via Groups.Io <chris1011@...> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@...




Robert Chozick
rchozick@...




Robert Chozick




--

Stuart
http://www.astrofoto.ca/stuartheggie/
Re: Close up of M81 without CCDT67

Robert Chozick
 

So, would you say the new advantages of the small pixel CMOS cameras is that they bring high sensitivity to small pixels?

I also got a shot of the Running Man with the 1600mm setup:


I got M101 at 1600 but the seeing was worse and guiding not as good. 


Robert



On Feb 14, 2020, at 3:10 PM, uncarollo2 via Groups.Io <chris1011@...> wrote:

You are running 0.6 arc sec per pixel, which to me is not oversampling for high resolution imaging. In fact, for galaxies i prefer 0.3 to 0.4 arc sec per pixel which really brings out fine detail. My 17"F8 astrograph and the QSI 683 has such pixel scale and really does a superb job on small faint galaxies, even here in Northern Illinois. You have to have good tracking, of course, and on the best nights I can get below 0.15 arc sec RMS with the 1600 encoder mount.

I see a lot of images that are way undersampled (3 to 4 arc sec per pixel) with poor guiding that produces thick stars and very little resolution. To me these images resemble Brownie camera snapshots versus images taken with an 8x10 view camera. (shows my age, doesn't it)  :^))

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 2:14 pm
Subject: Re: [ap-gto] Close up of M81 without CCDT67

Thanks Roland.  My last dark sky outing was my first use of this scope and camera.   I am really confused on the whole image scale question.  I bought this camera because it has the largest pixels of any of the CMOS cameras. The image scale is .6 with this camera and 1600mm.   My scale is about 1.8 with my FSQ 106 - 530mm.  If the recommended guidance of a scale of 1-2 for image scale is used the 1600mm should be too small an image scale.  Most CMOS cameras have only 2.5-3.5 micron pixels vs 4.63 on my ASI294.  Is oversampling bad?  The .6 scale in my image sure looks ok.    What about .4 or .3?  I intentionally did not get larger than a 1600mm focal length because of this issue (and yes, guiding issues are not as bad vs 2000 and over).  Everyone asks why I got an 8 RC instead of a 10 or 12 inch RC.  The above reason is why.   Each new CMOS camera that comes out still has really small pixels.   How good would 2.5 micron pixels look on a 2500 mm scope?  

Robert

On Feb 14, 2020, at 1:18 PM, uncarollo2 via Groups.Io <chris1011@...> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@...




Robert Chozick
rchozick@...




Robert Chozick
1200GTO worm gear thrust washer?

Mike Shade
 

The flat washer, the one with two holes on it at the end of the worm shaft (under the little screw on cover) continues to loosen up causing some degree of backlash.  It has done it for both RA and DEC.  Any ideas how to tighten this properly and prevent it from doing this in the future?

 

Mike J. Shade: mshade@q.com

Mike J. Shade Photography:

mshadephotography.com

 

In War: Resolution

In Defeat: Defiance

In Victory: Magnanimity

In Peace: Goodwill

Sir Winston Churchill

Already, in the gathering dusk, a few of the stars are turning on their lights.

Vega, the brightest one, is now dropping towards the west.  Can it be half

a year since I watched her April rising in the east?  Low in the southwest

Antares blinks a sad farwell to fall...

Leslie Peltier, Starlight Nights

 

International Dark Sky Association: www.darksky.org

 

 
Re: Close up of M81 without CCDT67

Roland Christen
 

You are running 0.6 arc sec per pixel, which to me is not oversampling for high resolution imaging. In fact, for galaxies i prefer 0.3 to 0.4 arc sec per pixel which really brings out fine detail. My 17"F8 astrograph and the QSI 683 has such pixel scale and really does a superb job on small faint galaxies, even here in Northern Illinois. You have to have good tracking, of course, and on the best nights I can get below 0.15 arc sec RMS with the 1600 encoder mount.

I see a lot of images that are way undersampled (3 to 4 arc sec per pixel) with poor guiding that produces thick stars and very little resolution. To me these images resemble Brownie camera snapshots versus images taken with an 8x10 view camera. (shows my age, doesn't it)  :^))

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 2:14 pm
Subject: Re: [ap-gto] Close up of M81 without CCDT67

Thanks Roland.  My last dark sky outing was my first use of this scope and camera.   I am really confused on the whole image scale question.  I bought this camera because it has the largest pixels of any of the CMOS cameras. The image scale is .6 with this camera and 1600mm.   My scale is about 1.8 with my FSQ 106 - 530mm.  If the recommended guidance of a scale of 1-2 for image scale is used the 1600mm should be too small an image scale.  Most CMOS cameras have only 2.5-3.5 micron pixels vs 4.63 on my ASI294.  Is oversampling bad?  The .6 scale in my image sure looks ok.    What about .4 or .3?  I intentionally did not get larger than a 1600mm focal length because of this issue (and yes, guiding issues are not as bad vs 2000 and over).  Everyone asks why I got an 8 RC instead of a 10 or 12 inch RC.  The above reason is why.   Each new CMOS camera that comes out still has really small pixels.   How good would 2.5 micron pixels look on a 2500 mm scope?  

Robert

On Feb 14, 2020, at 1:18 PM, uncarollo2 via Groups.Io <chris1011@...> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@...




Robert Chozick
rchozick@...
Re: Close up of M81 without CCDT67

Roland Christen
 

In my experience when I was using my 10" F14 Mak-Cass under very good seeing conditions I was able to resolve tiny doubles separated by 0.8 arc seconds in a deep sky image with a 7.5 micron pixel camera (ST10). If that's the case, then the same aperture at F7 could do this with a 3.75 micron pixel camera.

That's close to a 1600mm focal length. To me that would be a sweet spot for imaging at high resolution.

Rolando



-----Original Message-----
From: Dale Ghent <daleg@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 1:37 pm
Subject: Re: [ap-gto] Close up of M81 without CCDT67


Perhaps... probably would be fine. The 2.5-5um pixel size range of the common CMOS sensors these days will demand good seeing at that kind of focal length, but it's workable. What I would do is always image at 1x1and bin in post-processing (PixInsight's IntegerResample process, for example) on an as-needed basis if the pixel scale needs to be worked up a little due to the conditions.

1600 would be great for detail studies of all kinds of nebula, too.

For reference, Robert's camera sports 4.63um pixels. I have the same one, but QHY's version of it, and its Sony IMX294 is a really nice and super clean 4/3 format, 14 bit sensor with dual gain modes.

> On Feb 14, 2020, at 2:18 PM, uncarollo2 <chris1011@...> via Groups.Io <chris1011@...> wrote:
>
> That's really nice. Sharp and great color.
>
> A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.
>
> Rolando
>
>
>
> -----Original Message-----
> From: Robert Chozick via Groups.Io <rchozick@...>
> To: main <main@ap-gto.groups.io>
> Sent: Fri, Feb 14, 2020 12:06 am
> Subject: [ap-gto] Close up of M81 without CCDT67
>
> I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.
>
> https://pbase.com/image/170419535
>
> Robert Chozick
> rchozick@...
>
>
>
>



Re: Close up of M81 without CCDT67

Dale Ghent
 

How good would 2.5um pixels look on a 2.5m focal length at 0.21"/pixel? Pretty good provided you have the extra time that will be required to expose the target and if "normal" seeing for you is also in the realm of "pretty good." You'll certainly have the roundest stars on the block, assuming your mount and other mechanics are also up to the task.

Oversampling isn't inherently bad if you're blessed with time and stability. Most people in that situation would start at 2x2 binning, maybe 3x3... at which point you must ask yourself if you're really using the right tool for the job because you would be paying for a lot of sensor real estate that is being used just to make up for the time and conditions.

On Feb 14, 2020, at 3:14 PM, Robert Chozick via Groups.Io <rchozick=aol.com@groups.io> wrote:

Thanks Roland. My last dark sky outing was my first use of this scope and camera. I am really confused on the whole image scale question. I bought this camera because it has the largest pixels of any of the CMOS cameras. The image scale is .6 with this camera and 1600mm. My scale is about 1.8 with my FSQ 106 - 530mm. If the recommended guidance of a scale of 1-2 for image scale is used the 1600mm should be too small an image scale. Most CMOS cameras have only 2.5-3.5 micron pixels vs 4.63 on my ASI294. Is oversampling bad? The .6 scale in my image sure looks ok. What about .4 or .3? I intentionally did not get larger than a 1600mm focal length because of this issue (and yes, guiding issues are not as bad vs 2000 and over). Everyone asks why I got an 8 RC instead of a 10 or 12 inch RC. The above reason is why. Each new CMOS camera that comes out still has really small pixels. How good would 2.5 micron pixels look on a 2500 mm scope?

Robert

On Feb 14, 2020, at 1:18 PM, uncarollo2 via Groups.Io <chris1011@aol.com> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick=aol.com@groups.io>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@aol.com




Robert Chozick
rchozick@aol.com
Re: Close up of M81 without CCDT67

Robert Chozick
 

Thanks Roland.  My last dark sky outing was my first use of this scope and camera.   I am really confused on the whole image scale question.  I bought this camera because it has the largest pixels of any of the CMOS cameras. The image scale is .6 with this camera and 1600mm.   My scale is about 1.8 with my FSQ 106 - 530mm.  If the recommended guidance of a scale of 1-2 for image scale is used the 1600mm should be too small an image scale.  Most CMOS cameras have only 2.5-3.5 micron pixels vs 4.63 on my ASI294.  Is oversampling bad?  The .6 scale in my image sure looks ok.    What about .4 or .3?  I intentionally did not get larger than a 1600mm focal length because of this issue (and yes, guiding issues are not as bad vs 2000 and over).  Everyone asks why I got an 8 RC instead of a 10 or 12 inch RC.  The above reason is why.   Each new CMOS camera that comes out still has really small pixels.   How good would 2.5 micron pixels look on a 2500 mm scope?  

Robert

On Feb 14, 2020, at 1:18 PM, uncarollo2 via Groups.Io <chris1011@...> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@...




Robert Chozick
Re: Close up of M81 without CCDT67

Dale Ghent
 

Yeah, those are working out to be great sensors (the mono or color ~61mp IMX455, or the color-only 26.8mp IMX571, both with 3.76um pixels). I still keep dreaming that Sony (or someone) will release a mono, 16bit, BSI, APS-C format sensor. My 36mm filters would appreciate that because upgrading 3nm narrowbands to 50mm to suit a full-frame sensor such as the mentioned ones is a bit... oof.

On Feb 14, 2020, at 2:52 PM, dvjbaja <jpgleasonid@gmail.com> wrote:

I would look seriously at the new 16bit cmos cameras from QHY and ZWO.

Jg

On Fri, Feb 14, 2020, 11:37 AM Dale Ghent <daleg@elemental.org> wrote:

Perhaps... probably would be fine. The 2.5-5um pixel size range of the common CMOS sensors these days will demand good seeing at that kind of focal length, but it's workable. What I would do is always image at 1x1and bin in post-processing (PixInsight's IntegerResample process, for example) on an as-needed basis if the pixel scale needs to be worked up a little due to the conditions.

1600 would be great for detail studies of all kinds of nebula, too.

For reference, Robert's camera sports 4.63um pixels. I have the same one, but QHY's version of it, and its Sony IMX294 is a really nice and super clean 4/3 format, 14 bit sensor with dual gain modes.

On Feb 14, 2020, at 2:18 PM, uncarollo2 <chris1011@aol.com> via Groups.Io <chris1011=aol.com@groups.io> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick=aol.com@groups.io>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@aol.com
Re: Close up of M81 without CCDT67

dvjbaja
 

I would look seriously at the new 16bit cmos cameras from QHY and ZWO.  

Jg

On Fri, Feb 14, 2020, 11:37 AM Dale Ghent <daleg@...> wrote:

Perhaps... probably would be fine. The 2.5-5um pixel size range of the common CMOS sensors these days will demand good seeing at that kind of focal length, but it's workable. What I would do is always image at 1x1and bin in post-processing (PixInsight's IntegerResample process, for example) on an as-needed basis if the pixel scale needs to be worked up a little due to the conditions.

1600 would be great for detail studies of all kinds of nebula, too.

For reference, Robert's camera sports 4.63um pixels. I have the same one, but QHY's version of it, and its Sony IMX294 is a really nice and super clean 4/3 format, 14 bit sensor with dual gain modes.

> On Feb 14, 2020, at 2:18 PM, uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:
>
> That's really nice. Sharp and great color.
>
> A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.
>
> Rolando
>
>
>
> -----Original Message-----
> From: Robert Chozick via Groups.Io <rchozick=aol.com@groups.io>
> To: main <main@ap-gto.groups.io>
> Sent: Fri, Feb 14, 2020 12:06 am
> Subject: [ap-gto] Close up of M81 without CCDT67
>
> I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.
>
> https://pbase.com/image/170419535
>
> Robert Chozick
> rchozick@...
>
>
>
>




Re: Close up of M81 without CCDT67

Dale Ghent
 

Perhaps... probably would be fine. The 2.5-5um pixel size range of the common CMOS sensors these days will demand good seeing at that kind of focal length, but it's workable. What I would do is always image at 1x1and bin in post-processing (PixInsight's IntegerResample process, for example) on an as-needed basis if the pixel scale needs to be worked up a little due to the conditions.

1600 would be great for detail studies of all kinds of nebula, too.

For reference, Robert's camera sports 4.63um pixels. I have the same one, but QHY's version of it, and its Sony IMX294 is a really nice and super clean 4/3 format, 14 bit sensor with dual gain modes.

On Feb 14, 2020, at 2:18 PM, uncarollo2 <chris1011@aol.com> via Groups.Io <chris1011=aol.com@groups.io> wrote:

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick=aol.com@groups.io>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@aol.com
Re: Close up of M81 without CCDT67

Roland Christen
 

That's really nice. Sharp and great color.

A question: do you think that 1600mm is a sweet spot for all kinds of deep sky imaging, especially for high resolution work? Especially since the newer Cmos cameras have such small pixels and would be able to take advantage of a high resolution optic for small faint galaxies.

Rolando



-----Original Message-----
From: Robert Chozick via Groups.Io <rchozick@...>
To: main <main@ap-gto.groups.io>
Sent: Fri, Feb 14, 2020 12:06 am
Subject: [ap-gto] Close up of M81 without CCDT67

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.

https://pbase.com/image/170419535

Robert Chozick
rchozick@...
Re: PEMProV3 error message

steven ho
 

Please disregard my last email it was sent to the wrong group. Late night and no coffee.

steve

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of steven ho <StevenHoffman53@...>
Sent: Friday, February 14, 2020 9:41 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] PEMProV3 error message
 
Two things....
There is no way to make the PDF file available, I converted the PDF to a "picture" so it could be posted.
I could put a button to forward them to our website where they could get the PDF (but the website is not working yet).
In other words they cannot "easily" print off the form to mail in.

Second, we could pay $5 to have facebook promote the event to 500 people in the state of NY (nothing more local than that).


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <groups3@...>
Sent: Friday, February 14, 2020 7:41 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] PEMProV3 error message
 
Ted,

>    "Failure to write mount definitions: Access to path is denied"

You might want to check permissions on the folders you mention. Here is a link to some other things to try:

https://support.microsoft.com/en-us/help/2669244/windows-cannot-access-the-specified-device-path-or-file-error-when-you

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3:  https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ted Mickle via Groups.Io
> Sent: Thursday, February 13, 2020 8:41 AM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] PEMProV3 error message
>
> Ray,
>
> I've used PEMProV3 from with APCC Pro in the past without difficulty but now am encountering an error message
> when attempting to access the CCDWare website, check for updates, etc from within APCC Pro/PEMProV3:
>
>    "Unable to open browser: access to path "C:\Users\Documents\CCDWare\PEMProV3\temp.htm" is denied
>
> Also, when I attempt to acquire data, set the image scale, etc, I encounter this error message:
>
>    "Failure to write mount definitions: Access to path is denied"
>
> My guess is that a configuration has changed somewhere in Windows 10 -- any suggestions to remedy are
> welcome.
>
> Thanks,
>
> Ted
>




Re: PEMProV3 error message

steven ho
 

Two things....
There is no way to make the PDF file available, I converted the PDF to a "picture" so it could be posted.
I could put a button to forward them to our website where they could get the PDF (but the website is not working yet).
In other words they cannot "easily" print off the form to mail in.

Second, we could pay $5 to have facebook promote the event to 500 people in the state of NY (nothing more local than that).


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <groups3@...>
Sent: Friday, February 14, 2020 7:41 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] PEMProV3 error message
 
Ted,

>    "Failure to write mount definitions: Access to path is denied"

You might want to check permissions on the folders you mention. Here is a link to some other things to try:

https://support.microsoft.com/en-us/help/2669244/windows-cannot-access-the-specified-device-path-or-file-error-when-you

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3:  https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ted Mickle via Groups.Io
> Sent: Thursday, February 13, 2020 8:41 AM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] PEMProV3 error message
>
> Ray,
>
> I've used PEMProV3 from with APCC Pro in the past without difficulty but now am encountering an error message
> when attempting to access the CCDWare website, check for updates, etc from within APCC Pro/PEMProV3:
>
>    "Unable to open browser: access to path "C:\Users\Documents\CCDWare\PEMProV3\temp.htm" is denied
>
> Also, when I attempt to acquire data, set the image scale, etc, I encounter this error message:
>
>    "Failure to write mount definitions: Access to path is denied"
>
> My guess is that a configuration has changed somewhere in Windows 10 -- any suggestions to remedy are
> welcome.
>
> Thanks,
>
> Ted
>




Re: PEMProV3 error message

Ray Gralak
 

Ted,

"Failure to write mount definitions: Access to path is denied"
You might want to check permissions on the folders you mention. Here is a link to some other things to try:

https://support.microsoft.com/en-us/help/2669244/windows-cannot-access-the-specified-device-path-or-file-error-when-you

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ted Mickle via Groups.Io
Sent: Thursday, February 13, 2020 8:41 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] PEMProV3 error message

Ray,

I've used PEMProV3 from with APCC Pro in the past without difficulty but now am encountering an error message
when attempting to access the CCDWare website, check for updates, etc from within APCC Pro/PEMProV3:

"Unable to open browser: access to path "C:\Users\Documents\CCDWare\PEMProV3\temp.htm" is denied

Also, when I attempt to acquire data, set the image scale, etc, I encounter this error message:

"Failure to write mount definitions: Access to path is denied"

My guess is that a configuration has changed somewhere in Windows 10 -- any suggestions to remedy are
welcome.

Thanks,

Ted
Close up of M81 without CCDT67

Robert Chozick
 

I got another shot of M 81 on the same trip as the M81-82 image, this time at f/8 1620mm.


Robert Chozick
Re: Erratic parking of the mount

Dale Ghent
 

The built-in NTP client and their respective default servers in Windows and macOS (and any other modern OS for that matter) is more than sufficient for most needs, including practical and pedestrian astronomy needs. The Dimension 4 client I think is from a time when Windows didn't include a time client, and then later did but it was off by default.

The only reason to use alternative time servers is mainly for security reasons, where you have to trust the time source because it's utilized in part by security (authentication) systems or where transactional control must have a consistent, singular time references (many of the popular NTP servers aren't single servers; but pools of multiple servers, each with their own delay and jitter characteristics) and even then most systems use a completely different protocol called PTP (Precision Time Protocol) when synchronized resolution down to the picosecond is desired... but those usually employ local rubidium clock sources.

If you want good resolution and without the reliance on external time services/network availability, stick a cheap GPS/GNSS receiver on your computer and use a NMEA 0183 client to synchronize the time from it to your computer's clock. Doing this on non-Windows is simple but, on Windows, one must use a 3rd party tool such as NMEATime2 from VisualGPS. I do this with a $15 USB GNSS dongle from Amazon (DIYmall VK-172).

/dale

On Feb 13, 2020, at 4:49 PM, Brian Valente <bvalente@gmail.com> wrote:

We use Dimension 4 free/donationware to keep our computer clocks accurate

http://www.thinkman.com/dimension4/

it's easy to use, runs in background, and is free (though a donation would be nice)

I think Ray Graylak originally turned me on to this

clocks have been sub-second accurate since installing

Brian

On Thu, Feb 13, 2020 at 1:25 PM uncarollo2 <chris1011@aol.com> via Groups.Io <chris1011=aol.com@groups.io> wrote:
Computer clocks by themselves are not accurate. You will need to update the time on your computer via one of the national time services.

Rolando



-----Original Message-----
From: Bruce Donzanti <donza2735@gmail.com>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 1:43 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Thanks all for the advice and tips. I know my PA is very good and clutches are not slipping, so it sounds like it limits it to a re-alignment issue and possibly a clock issue. I need to confirm that as well.

On Thu, Feb 13, 2020 at 2:00 PM uncarollo2 <chris1011@aol.com> via Groups.Io <chris1011=aol.com@groups.io> wrote:

SkySafari has limited choices for initiating and unparking.
They are actually working to change that and will have other park and resume options soon.

Rolando


-----Original Message-----
From: Donald Rudny <mkea13800@gmail.com>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 12:20 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Hi Bruce,

Just saw this and agree that it’s probably your re-aligning or recal when you are in different parts of the sky. I noticed that even when I use APCC to initiate. When I would start another session and pick start from position 3, alignment was off. What I needed to pick was “last parked”. I could see from the marks on the axes that the park 3 position was off a little. Once I used last park, it worked perfectly.

Unfortunately, SkySafari has limited choices for initiating and unparking. You would need to reset your park 4 position each new session unless you didn’t re-align during the prior one. One thing you could try is to realign on a star near the park 4 position before you shut down. That would be low in the southern sky. That should at least get the next startup closer.

Don Rudny

On Feb 13, 2020, at 7:54 AM, Bruce Donzanti <donza2735@gmail.com> wrote:


Great- good to understand what is probably causing this and that a solution is forthcoming.

Thank you


On Feb 13, 2020, at 12:05 PM, uncarollo2 <chris1011@aol.com> via Groups.Io <chris1011=aol.com@groups.io> wrote:



Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).
All sky positions are calculated from the previous object that you did a Recal on. That includes park positions. If the last object that you Recal on is off by 1 degree when you pressed Recal, then every object that you go to including all park positions will also have that 1 degree error.

Your errant Recal could be the result of an error on your part or deliberate if you wanted to center a nebulous object and then did a recal on it. What you might think was the center might not be the center as defined in the database, so that throws off everything else following that move.

We are working on changing the way parks are generated so that they are not affected by errant recals or syncs. The software will be available for the CP4 and will be standard in the Mach2 CP5 controllers.

Rolando


-----Original Message-----
From: Bruce Donzanti <donza2735@gmail.com>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 5:42 am
Subject: [ap-gto] Erratic parking of the mount

In my permanent setup, I use SkySafari 6 Pro as my planetarium program to slew my AP1100 with no issues (connected to the GTOCP4 via RS232). It parks and unparks from position 4 with no issues. I also use PHD2 for guiding by linking it as required to the mount to my capture and live viewing software (SGPro or SharpCap) which are connected to mount via USB with no issues. However, I have had random problems with shutting down the system. I first park the scope using SkySafari 6 Pro and then close PHD2 followed by the capture software. Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level). I can't seem to figure out what is the cause as it is very infrequent but annoying as it misaligns the scope for the next time I startup Skysafari 6 Pro to slew to an object (i.e., the mount is lost and I need to realign). Any thoughts as to what is going on? Is my shutdown sequence wrong?

Bruce



--
Brian



Brian Valente
portfolio brianvalentephotography.com

Re: Erratic parking of the mount

Brian Valente
 

We use Dimension 4 free/donationware to keep our computer clocks accurate


it's easy to use, runs in background, and is free (though a donation would be nice)

I think Ray Graylak originally turned me on to this

clocks have been sub-second accurate since installing

Brian 


On Thu, Feb 13, 2020 at 1:25 PM uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:
Computer clocks by themselves are not accurate. You will need to update the time on your computer via one of the national time services.

Rolando



-----Original Message-----
From: Bruce Donzanti <donza2735@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 1:43 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Thanks all for the advice and tips.  I know my PA is very good and clutches are not slipping, so it sounds like it limits it to a re-alignment issue and possibly a clock issue.  I need to confirm that as well.   

On Thu, Feb 13, 2020 at 2:00 PM uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:

SkySafari has limited choices for initiating and unparking.
They are actually working to change that and will have other park and resume options soon.

Rolando


-----Original Message-----
From: Donald Rudny <mkea13800@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 12:20 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Hi Bruce,

Just saw this and agree that it’s probably your re-aligning or recal when you are in different parts of the sky.  I noticed that even when I use APCC to initiate.  When I would start another session and pick start from position 3, alignment was off.  What I needed to pick was “last parked”.  I could see from the marks on the axes that the park 3 position was off a little.  Once I used last park, it worked perfectly.

Unfortunately, SkySafari has limited choices for initiating and unparking.  You would need to reset your park 4 position each new session unless you didn’t re-align during the prior one.  One thing you could try is to realign on a star near the park 4 position before you shut down.  That would be low in the southern sky.  That should at least get the next startup closer.

Don Rudny

On Feb 13, 2020, at 7:54 AM, Bruce Donzanti <donza2735@...> wrote:


Great- good to understand what is probably causing this and that a solution is forthcoming.  

Thank you 


On Feb 13, 2020, at 12:05 PM, uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:



Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).
All sky positions are calculated from the previous object that you did a Recal on. That includes park positions. If the last object that you Recal on is off by 1 degree when you pressed Recal, then every object that you go to including all park positions will also have that 1 degree error.

Your errant Recal could be the result of an error on your part or deliberate if you wanted to center a nebulous object and then did a recal on it. What you might think was the center might not be the center as defined in the database, so that throws off everything else following that move.

We are working on changing the way parks are generated so that they are not affected by errant recals or syncs. The software will be available for the CP4 and will be standard in the Mach2 CP5 controllers.

Rolando


-----Original Message-----
From: Bruce Donzanti <donza2735@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 5:42 am
Subject: [ap-gto] Erratic parking of the mount

In my permanent setup,  I use SkySafari 6 Pro as my planetarium program to slew my AP1100 with no issues (connected to the GTOCP4 via RS232).  It parks and unparks from position 4 with no issues.  I also use PHD2 for guiding by linking it as required to the mount to my capture and live viewing software (SGPro or SharpCap) which are connected to mount via USB with no issues.  However, I have had random problems with shutting down the system.  I first park the scope using SkySafari 6 Pro and then close PHD2 followed by the capture software.  Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).  I can't seem to figure out what is the cause as it is very infrequent but annoying as it misaligns the scope for the next time I startup Skysafari 6 Pro to slew to an object (i.e., the mount is lost and I need to realign).  Any thoughts as to what is going on?  Is my shutdown sequence wrong?

Bruce   



--
Brian 



Brian Valente
Re: Erratic parking of the mount

Roland Christen
 

Computer clocks by themselves are not accurate. You will need to update the time on your computer via one of the national time services.

Rolando



-----Original Message-----
From: Bruce Donzanti <donza2735@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 1:43 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Thanks all for the advice and tips.  I know my PA is very good and clutches are not slipping, so it sounds like it limits it to a re-alignment issue and possibly a clock issue.  I need to confirm that as well.   

On Thu, Feb 13, 2020 at 2:00 PM uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:

SkySafari has limited choices for initiating and unparking.
They are actually working to change that and will have other park and resume options soon.

Rolando


-----Original Message-----
From: Donald Rudny <mkea13800@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 12:20 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Hi Bruce,

Just saw this and agree that it’s probably your re-aligning or recal when you are in different parts of the sky.  I noticed that even when I use APCC to initiate.  When I would start another session and pick start from position 3, alignment was off.  What I needed to pick was “last parked”.  I could see from the marks on the axes that the park 3 position was off a little.  Once I used last park, it worked perfectly.

Unfortunately, SkySafari has limited choices for initiating and unparking.  You would need to reset your park 4 position each new session unless you didn’t re-align during the prior one.  One thing you could try is to realign on a star near the park 4 position before you shut down.  That would be low in the southern sky.  That should at least get the next startup closer.

Don Rudny

On Feb 13, 2020, at 7:54 AM, Bruce Donzanti <donza2735@...> wrote:


Great- good to understand what is probably causing this and that a solution is forthcoming.  

Thank you 


On Feb 13, 2020, at 12:05 PM, uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:



Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).
All sky positions are calculated from the previous object that you did a Recal on. That includes park positions. If the last object that you Recal on is off by 1 degree when you pressed Recal, then every object that you go to including all park positions will also have that 1 degree error.

Your errant Recal could be the result of an error on your part or deliberate if you wanted to center a nebulous object and then did a recal on it. What you might think was the center might not be the center as defined in the database, so that throws off everything else following that move.

We are working on changing the way parks are generated so that they are not affected by errant recals or syncs. The software will be available for the CP4 and will be standard in the Mach2 CP5 controllers.

Rolando


-----Original Message-----
From: Bruce Donzanti <donza2735@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 5:42 am
Subject: [ap-gto] Erratic parking of the mount

In my permanent setup,  I use SkySafari 6 Pro as my planetarium program to slew my AP1100 with no issues (connected to the GTOCP4 via RS232).  It parks and unparks from position 4 with no issues.  I also use PHD2 for guiding by linking it as required to the mount to my capture and live viewing software (SGPro or SharpCap) which are connected to mount via USB with no issues.  However, I have had random problems with shutting down the system.  I first park the scope using SkySafari 6 Pro and then close PHD2 followed by the capture software.  Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).  I can't seem to figure out what is the cause as it is very infrequent but annoying as it misaligns the scope for the next time I startup Skysafari 6 Pro to slew to an object (i.e., the mount is lost and I need to realign).  Any thoughts as to what is going on?  Is my shutdown sequence wrong?

Bruce   

Re: Erratic parking of the mount

Bruce Donzanti
 

Thanks all for the advice and tips.  I know my PA is very good and clutches are not slipping, so it sounds like it limits it to a re-alignment issue and possibly a clock issue.  I need to confirm that as well.   

On Thu, Feb 13, 2020 at 2:00 PM uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:

SkySafari has limited choices for initiating and unparking.
They are actually working to change that and will have other park and resume options soon.

Rolando


-----Original Message-----
From: Donald Rudny <mkea13800@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 12:20 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Hi Bruce,

Just saw this and agree that it’s probably your re-aligning or recal when you are in different parts of the sky.  I noticed that even when I use APCC to initiate.  When I would start another session and pick start from position 3, alignment was off.  What I needed to pick was “last parked”.  I could see from the marks on the axes that the park 3 position was off a little.  Once I used last park, it worked perfectly.

Unfortunately, SkySafari has limited choices for initiating and unparking.  You would need to reset your park 4 position each new session unless you didn’t re-align during the prior one.  One thing you could try is to realign on a star near the park 4 position before you shut down.  That would be low in the southern sky.  That should at least get the next startup closer.

Don Rudny

On Feb 13, 2020, at 7:54 AM, Bruce Donzanti <donza2735@...> wrote:


Great- good to understand what is probably causing this and that a solution is forthcoming.  

Thank you 


On Feb 13, 2020, at 12:05 PM, uncarollo2 <chris1011@...> via Groups.Io <chris1011=aol.com@groups.io> wrote:



Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).
All sky positions are calculated from the previous object that you did a Recal on. That includes park positions. If the last object that you Recal on is off by 1 degree when you pressed Recal, then every object that you go to including all park positions will also have that 1 degree error.

Your errant Recal could be the result of an error on your part or deliberate if you wanted to center a nebulous object and then did a recal on it. What you might think was the center might not be the center as defined in the database, so that throws off everything else following that move.

We are working on changing the way parks are generated so that they are not affected by errant recals or syncs. The software will be available for the CP4 and will be standard in the Mach2 CP5 controllers.

Rolando


-----Original Message-----
From: Bruce Donzanti <donza2735@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 5:42 am
Subject: [ap-gto] Erratic parking of the mount

In my permanent setup,  I use SkySafari 6 Pro as my planetarium program to slew my AP1100 with no issues (connected to the GTOCP4 via RS232).  It parks and unparks from position 4 with no issues.  I also use PHD2 for guiding by linking it as required to the mount to my capture and live viewing software (SGPro or SharpCap) which are connected to mount via USB with no issues.  However, I have had random problems with shutting down the system.  I first park the scope using SkySafari 6 Pro and then close PHD2 followed by the capture software.  Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).  I can't seem to figure out what is the cause as it is very infrequent but annoying as it misaligns the scope for the next time I startup Skysafari 6 Pro to slew to an object (i.e., the mount is lost and I need to realign).  Any thoughts as to what is going on?  Is my shutdown sequence wrong?

Bruce   

Re: Erratic parking of the mount

Roland Christen
 


SkySafari has limited choices for initiating and unparking.
They are actually working to change that and will have other park and resume options soon.

Rolando


-----Original Message-----
From: Donald Rudny <mkea13800@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 12:20 pm
Subject: Re: [ap-gto] Erratic parking of the mount

Hi Bruce,

Just saw this and agree that it’s probably your re-aligning or recal when you are in different parts of the sky.  I noticed that even when I use APCC to initiate.  When I would start another session and pick start from position 3, alignment was off.  What I needed to pick was “last parked”.  I could see from the marks on the axes that the park 3 position was off a little.  Once I used last park, it worked perfectly.

Unfortunately, SkySafari has limited choices for initiating and unparking.  You would need to reset your park 4 position each new session unless you didn’t re-align during the prior one.  One thing you could try is to realign on a star near the park 4 position before you shut down.  That would be low in the southern sky.  That should at least get the next startup closer.

Don Rudny

On Feb 13, 2020, at 7:54 AM, Bruce Donzanti <donza2735@...> wrote:


Great- good to understand what is probably causing this and that a solution is forthcoming.  

Thank you 


On Feb 13, 2020, at 12:05 PM, uncarollo2 <chris1011@...> via Groups.Io <chris1011@...> wrote:



Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).
All sky positions are calculated from the previous object that you did a Recal on. That includes park positions. If the last object that you Recal on is off by 1 degree when you pressed Recal, then every object that you go to including all park positions will also have that 1 degree error.

Your errant Recal could be the result of an error on your part or deliberate if you wanted to center a nebulous object and then did a recal on it. What you might think was the center might not be the center as defined in the database, so that throws off everything else following that move.

We are working on changing the way parks are generated so that they are not affected by errant recals or syncs. The software will be available for the CP4 and will be standard in the Mach2 CP5 controllers.

Rolando


-----Original Message-----
From: Bruce Donzanti <donza2735@...>
To: main <main@ap-gto.groups.io>
Sent: Thu, Feb 13, 2020 5:42 am
Subject: [ap-gto] Erratic parking of the mount

In my permanent setup,  I use SkySafari 6 Pro as my planetarium program to slew my AP1100 with no issues (connected to the GTOCP4 via RS232).  It parks and unparks from position 4 with no issues.  I also use PHD2 for guiding by linking it as required to the mount to my capture and live viewing software (SGPro or SharpCap) which are connected to mount via USB with no issues.  However, I have had random problems with shutting down the system.  I first park the scope using SkySafari 6 Pro and then close PHD2 followed by the capture software.  Usually, this is fine but every now and then I noticed the scope does not park in position 4 exactly as it should (i.e., the RA axis is slightly off level).  I can't seem to figure out what is the cause as it is very infrequent but annoying as it misaligns the scope for the next time I startup Skysafari 6 Pro to slew to an object (i.e., the mount is lost and I need to realign).  Any thoughts as to what is going on?  Is my shutdown sequence wrong?

Bruce   

7321 - 7340 of 75667  
More
Home Guidelines Messages Hashtags Subgroups About Features Pricing Updates Terms Help Twitter