Date   

Re: What is the current status for Linux / Mac support via INDI or similar?

 

Howdy,

Our mount driver is ASCOM compatible, which in current state is suitable for Windows only.  However, our latest utilities are compatible with Mac and Linux computers since they run on Java. First is our FindMounts utility, which can help you with networking diagnostics by finding your CP4 or CP5 on the network. Second is our Serial Utility, which can do a number of really nifty things over serial; loading new CP4/CP5 firmware, a built in command terminal, networking features, and more. It isn't as great as the full APCC suite, but it does allow us to assist customers when we know they may not have the same computers that we do. Finally, the Keypad Update software has been totally overhauled from the ground up for the V5 release, and is tested to work on Windows, Linux and Mac computers, making these latest upgrades more available for the people that need them. 

There are numerous planetarium programs for Linux that interact through INDI, that use the community built AP INDI driver.  However, we've not invested significant efforts in testing these options and would have difficulty providing support. Perhaps there are others on this forum that can speak to their experiences with these programs?

In the future, we do intend to release an improved version of our command documentation to the public. New commands for interfacing with the advanced P02 firmware, as well as further detail and explanation of how the commands work, would be the goal. We can't make any hard commitments for a release date or contents for this, but it is on the table. I expect that when this is available, community developers will be quick to implement them into their projects. 

Thanks, 
Liam Plybon
Astro-Physics





From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Micheal Fields Jr via groups.io <mpfjr@...>
Sent: Tuesday, February 9, 2021 10:56 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] What is the current status for Linux / Mac support via INDI or similar?
 
APCC Pro for Linux would be great too.  Being able to do everything on a Raspberry Pi would be great.


Re: Dec limit in Mach2

Ray Gralak
 

Hi Joe,

That’s an interesting warning about selecting different APCC Settings folders.
I'm sorry if I implied differently, but there is only one root settings folder.

However, you can create different settings files, one for each mount. You must then load the appropriate settings file for the mount you are using.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Joe Zeglinski
Sent: Tuesday, February 9, 2021 10:04 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Dec limit in Mach2

Hi Ray,

That’s an interesting warning about selecting different APCC Settings folders.

I meant to post this yesterday, but a "clean" install is not strictly necessary. (BTW, In addition
to uninstalling/reinstalling APCC, a "clean" install would include deleting the settings folder:
c:\ProgramData\Astro-Physics\APCC).

First, this only matters if the computer with APCC has been previously configured for use
with another A-P mount. In this case, some of the old APCC settings won't apply to the Mach 2.


I use the same laptop to control my “Home based AP-1200” mount most of the time, but I also own a “Travel
AP-900”, for occasional use.
Since both mounts rely on the same laptop and its APCC, could you not add some code to APCC or the driver, to
... “confirm or ask for the mount’s serial number”?

There could be a short “AP mounts settings ID list”, saved to APCC to choose from. Then automatically
switch APCC Settings to a previous config folder, or ask the user for the alternate APCC settings if there is a
mount serial number mismatch. Otherwise, pop up a warning/question during initialization if the alternate
mount’s Settings list, was never saved.

Not sure if this “serial number check” would still work with an older controller like CP-3 (if the serial is not
encoded), but maybe it could with a CP-4/5. This might avoid a possibly incorrect automatic APCC settings
configuration change, being forgotten, when travelling or upon return to home base, saving a lot of hassle or
confusion about sudden unexpected performance, if missed during the trips out & back.

I realize the user should be relied upon to always remember to switch his APCC settings folder, but this would
make using APCC easier and more reliably used ... for the “travelling public” :-)

Joe Z.

From: Ray Gralak
Sent: Tuesday, February 9, 2021 11:43 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Dec limit in Mach2

Thanks for the update. We just heard from another user of the Mach2 who had stalling problems. He did the
same thing: complete un-install of APCC from a previous mount and a new clean install. His stalling problems
went away also.
I meant to post this yesterday, but a "clean" install is not strictly necessary. (BTW, In addition to
uninstalling/reinstalling APCC, a "clean" install would include deleting the settings folder: c:\ProgramData\Astro-
Physics\APCC).

First, this only matters if the computer with APCC has been previously configured for use with another A-P
mount. In this case, some of the old APCC settings won't apply to the Mach 2.

In both cases where Mach 2's stalled or had limit issues, the APCC's mount limits settings were enabled for a
previous A-P mount. The problem is that APCC's mount limit values use gear angles that only made sense for
the old mount. This resulted in limit actions because APCC thought a limit had been reached.

To prevent this issue you should either rename or delete APCC's default settings file. This will cause APCC to
automatically create a new settings file. The settings file is located here:

c:\ProgramData\Astro-Physics\APCC\Settings.apcc.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Roland Christen via groups.io
Sent: Monday, February 8, 2021 9:06 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Dec limit in Mach2

Thanks for the update. We just heard from another user of the Mach2 who had stalling problems. He did the
same thing: complete un-install of APCC from a previous mount and a new clean install. His stalling problems
went away also.


Rolando




-----Original Message-----
From: Luca Marinelli <photo@lucamarinelli.com>
To: main@ap-gto.groups.io
Sent: Sun, Feb 7, 2021 9:12 pm
Subject: Re: [ap-gto] Dec limit in Mach2


Circling back on the runaway Dec axis issue when APCC connects to the mount. On Friday, I went ahead and
completely uninstalled APCC, including deleting the folders with all the APCC data and log files - I only copied
the horizon and meridian limit files to the Desktop so I could reload them later. I then proceeded to reinstall
APCC from scratch. I reloaded the meridian and horizon limits and then tested the mount. Everything worked
fine, APCC connected to the mount without inducing a Dec axis rotation. I imaged on Friday, Saturday nights
and
I just launched another imaging run tonight. In all cases APCC connected to the mount without problems.

At this point, it appears that a plausible explanation for the behavior I encountered was an instability in APCC
due
to some stale files when I switched from the Mach1 to the Mach2. Hopefully reinstalling APCC has taken care
of
the problem for good.

Thank you to everyone for the advice!

Luca

--
Roland Christen
Astro-Physics






Re: Dec limit in Mach2

Joe Zeglinski
 

Hi Ray,
 
    That’s an interesting warning about selecting different APCC Settings folders.
I meant to post this yesterday, but a "clean" install is not strictly necessary. (BTW, In addition to uninstalling/reinstalling APCC, a "clean" install would include deleting the settings folder: c:\ProgramData\Astro-Physics\APCC).

First, this only matters if the computer with APCC has been previously configured for use with another A-P mount. In this case, some of the old APCC settings won't apply to the Mach 2.

    I use the same laptop to control my “Home based AP-1200” mount most of the time, but I also own a “Travel AP-900”, for occasional use.
Since both mounts rely on the same laptop and its APCC, could you not add some code to APCC or the driver, to ... “confirm or ask for the mount’s serial number”?
 
     There could be a short “AP mounts settings ID list”,  saved to APCC  to choose from. Then automatically switch APCC Settings to a previous config folder, or ask the user for the alternate APCC settings if there is a mount serial number mismatch. Otherwise,  pop up a warning/question during initialization if the alternate mount’s Settings list,  was never saved.
 
    Not sure if this “serial number check” would still work with an older controller like CP-3 (if the serial is not encoded), but maybe it could  with a CP-4/5. This might avoid a possibly incorrect  automatic  APCC settings configuration change,  being forgotten, when travelling or upon return to home base, saving a lot of hassle or confusion about sudden unexpected performance, if missed during the trips out & back.
 
    I realize the user should be relied upon to always remember to switch his APCC settings folder,  but this would make using APCC easier and more reliably used ... for the “travelling public”  :-)
 
Joe Z.
 
From: Ray Gralak
Sent: Tuesday, February 9, 2021 11:43 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Dec limit in Mach2
 
> Thanks for the update. We just heard from another user of the Mach2 who had stalling problems. He did the
> same thing: complete un-install of APCC from a previous mount and a new clean install. His stalling problems
> went away also.

I meant to post this yesterday, but a "clean" install is not strictly necessary. (BTW, In addition to uninstalling/reinstalling APCC, a "clean" install would include deleting the settings folder: c:\ProgramData\Astro-Physics\APCC).

First, this only matters if the computer with APCC has been previously configured for use with another A-P mount. In this case, some of the old APCC settings won't apply to the Mach 2.

In both cases where Mach 2's stalled or had limit issues, the APCC's mount limits settings were enabled for a previous A-P mount.  The problem is that APCC's mount limit values use gear angles that only made sense for the old mount. This resulted in limit actions because APCC thought a limit had been reached.

To prevent this issue you should either rename or delete APCC's default settings file. This will cause APCC to automatically create a new settings file. The settings file is located here:

c:\ProgramData\Astro-Physics\APCC\Settings.apcc.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Roland Christen via groups.io
> Sent: Monday, February 8, 2021 9:06 AM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] Dec limit in Mach2
>
> Thanks for the update. We just heard from another user of the Mach2 who had stalling problems. He did the
> same thing: complete un-install of APCC from a previous mount and a new clean install. His stalling problems
> went away also.
>
>
> Rolando
>
>
>
>
> -----Original Message-----
> From: Luca Marinelli <photo@...>
> To: main@ap-gto.groups.io
> Sent: Sun, Feb 7, 2021 9:12 pm
> Subject: Re: [ap-gto] Dec limit in Mach2
>
>
> Circling back on the runaway Dec axis issue when APCC connects to the mount. On Friday, I went ahead and
> completely uninstalled APCC, including deleting the folders with all the APCC data and log files - I only copied
> the horizon and meridian limit files to the Desktop so I could reload them later. I then proceeded to reinstall
> APCC from scratch. I reloaded the meridian and horizon limits and then tested the mount. Everything worked
> fine, APCC connected to the mount without inducing a Dec axis rotation. I imaged on Friday, Saturday nights and
> I just launched another imaging run tonight. In all cases APCC connected to the mount without problems.
>
> At this point, it appears that a plausible explanation for the behavior I encountered was an instability in APCC due
> to some stale files when I switched from the Mach1 to the Mach2. Hopefully reinstalling APCC has taken care of
> the problem for good.
>
> Thank you to everyone for the advice!
>
> Luca
>
> --
> Roland Christen
> Astro-Physics
>






Re: Counterweight Shaft Case

Stone, Jack G
 

Regardless – this is a projectile under transport.  Usually kept in a case of some sort – like one of those handy storage boxes.

But I like the idea of reducing the exposure to humidity and other corrosives this is nice. 

But Wondering – where would you keep the end cap?

 

Jack ~

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Barry Megdal
Sent: Tuesday, February 09, 2021 10:02 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Counterweight Shaft Case

 

The purpose is both – to protect the beautiful look of the counterweight shaft during transportation, as well as keeping it from damaging the vehicle or other equipment.

 

Barry

 

 

 

Nice! 

Is this to protect the counterweight shaft during transportation?
 Or to protect whatever other things that sit next to the counterweight shaft?

 

Dr. Barry Megdal

 

President

Shb Instruments, Inc.

19215 Parthenia St.  Suite A

Northridge, CA 91324

www.shbinstruments.com

(818) 773-2000  (818)773-2005 fax

bmegdal@...

 

Faculty (retired)

Dept. of Electrical Engineering

Caltech

 


Re: Counterweight Shaft Case

Barry Megdal
 

The purpose is both – to protect the beautiful look of the counterweight shaft during transportation, as well as keeping it from damaging the vehicle or other equipment.

 

Barry

 

 

 

Nice! 

Is this to protect the counterweight shaft during transportation?
 Or to protect whatever other things that sit next to the counterweight shaft?

 

Dr. Barry Megdal

 

President

Shb Instruments, Inc.

19215 Parthenia St.  Suite A

Northridge, CA 91324

www.shbinstruments.com

(818) 773-2000  (818)773-2005 fax

bmegdal@...

 

Faculty (retired)

Dept. of Electrical Engineering

Caltech

 


Re: What is the current status for Linux / Mac support via INDI or similar?

Micheal Fields Jr
 

APCC Pro for Linux would be great too.  Being able to do everything on a Raspberry Pi would be great.


Re: Dec limit in Mach2

Ray Gralak
 

Thanks for the update. We just heard from another user of the Mach2 who had stalling problems. He did the
same thing: complete un-install of APCC from a previous mount and a new clean install. His stalling problems
went away also.
I meant to post this yesterday, but a "clean" install is not strictly necessary. (BTW, In addition to uninstalling/reinstalling APCC, a "clean" install would include deleting the settings folder: c:\ProgramData\Astro-Physics\APCC).

First, this only matters if the computer with APCC has been previously configured for use with another A-P mount. In this case, some of the old APCC settings won't apply to the Mach 2.

In both cases where Mach 2's stalled or had limit issues, the APCC's mount limits settings were enabled for a previous A-P mount. The problem is that APCC's mount limit values use gear angles that only made sense for the old mount. This resulted in limit actions because APCC thought a limit had been reached.

To prevent this issue you should either rename or delete APCC's default settings file. This will cause APCC to automatically create a new settings file. The settings file is located here:

c:\ProgramData\Astro-Physics\APCC\Settings.apcc.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Roland Christen via groups.io
Sent: Monday, February 8, 2021 9:06 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Dec limit in Mach2

Thanks for the update. We just heard from another user of the Mach2 who had stalling problems. He did the
same thing: complete un-install of APCC from a previous mount and a new clean install. His stalling problems
went away also.


Rolando




-----Original Message-----
From: Luca Marinelli <photo@lucamarinelli.com>
To: main@ap-gto.groups.io
Sent: Sun, Feb 7, 2021 9:12 pm
Subject: Re: [ap-gto] Dec limit in Mach2


Circling back on the runaway Dec axis issue when APCC connects to the mount. On Friday, I went ahead and
completely uninstalled APCC, including deleting the folders with all the APCC data and log files - I only copied
the horizon and meridian limit files to the Desktop so I could reload them later. I then proceeded to reinstall
APCC from scratch. I reloaded the meridian and horizon limits and then tested the mount. Everything worked
fine, APCC connected to the mount without inducing a Dec axis rotation. I imaged on Friday, Saturday nights and
I just launched another imaging run tonight. In all cases APCC connected to the mount without problems.

At this point, it appears that a plausible explanation for the behavior I encountered was an instability in APCC due
to some stale files when I switched from the Mach1 to the Mach2. Hopefully reinstalling APCC has taken care of
the problem for good.

Thank you to everyone for the advice!

Luca

--
Roland Christen
Astro-Physics


Re: First light for a new camera

Dean Jacobsen
 

On Mon, Feb 8, 2021 at 06:50 PM, Don Anderson wrote:
Up to now, it has been hard to beat the 694 for sensitivity and low noise until the most recent CMOS offerings have come out. I will be watching The developments closely
Don, when you are ready to get a new camera I think you will be pleased with the excellent choices that are available these days.
 
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/ 
Amateur Radio Call Sign - W6DBJ


Re: Counterweight Shaft Case

Astrobob
 

Clever common sense!

 

Sent from Mail for Windows 10

 


Re: How long for UNGUIDED imaging with non AE mounts?

Roland Christen
 

I have gone up to an hour with 1000mm FL and 5.4 micron pixel camera. Some nights and in some places in the sky it doesn't work out as well. Theoretically if you have a good path mapped, you can go all night. Practically you will probably need to refocus every 20 minutes. In the early part of the night you will also have satellite trails, so it's better to have lots of 15 minute shots that can be Median combined to eliminate them.

Rolando



-----Original Message-----
From: astro@...
To: main@ap-gto.groups.io
Sent: Mon, Feb 8, 2021 10:49 pm
Subject: [ap-gto] How long for UNGUIDED imaging with non AE mounts?

Following on from an earlier thread, does anyone have any info on the length of unguided imaging possible using a 1100GTO or similar with a focal length of up to about 700mm? Assuming the mount is very well aligned.

Thanks
Bob

--
Roland Christen
Astro-Physics


Re: Counterweight Shaft Case

weihaowang
 

Nice! 

Is this to protect the counterweight shaft during transportation?  Or to protect whatever other things that sit next to the counterweight shaft?

--

Homepage:

http://www.asiaa.sinica.edu.tw/~whwang/

Astrobin gallery:
http://www.astrobin.com/users/whwang/


Re: Counterweight Shaft Case

Woody Schlom
 

Barry,

 

I LIKE it!

 

Woody

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Barry Megdal
Sent: Monday, February 8, 2021 9:44 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Counterweight Shaft Case

 

I posted this long ago when I was using a 1200 as a “portable” mount.  Since then I have a 1600 mount in an observatory.

But I recently received the very impressive Mach 2 which I intend to transport on occasion.

 

So what type of case to use for the mount and its accessories has come up again.  Below is a picture of the case I made for the 1200 counterweight shaft (and will shorten for the Mach 2 shaft).

 

It is made from readily available 2” Schedule 80 PVC pipe parts glued together.  The counterweight shaft is an almost airtight fit inside that size pipe, and the screw-on cap is very convenient.

 

Put a small piece of foam in the bottom and it is ready to go.

 

 

  • Barry

 

 

 

Dr. Barry Megdal

 

President

Shb Instruments, Inc.

19215 Parthenia St.  Suite A

Northridge, CA 91324

www.shbinstruments.com

(818) 773-2000  (818)773-2005 fax

bmegdal@...

 

Faculty (retired)

Dept. of Electrical Engineering

Caltech

 


Counterweight Shaft Case

Barry Megdal
 

I posted this long ago when I was using a 1200 as a “portable” mount.  Since then I have a 1600 mount in an observatory.

But I recently received the very impressive Mach 2 which I intend to transport on occasion.

 

So what type of case to use for the mount and its accessories has come up again.  Below is a picture of the case I made for the 1200 counterweight shaft (and will shorten for the Mach 2 shaft).

 

It is made from readily available 2” Schedule 80 PVC pipe parts glued together.  The counterweight shaft is an almost airtight fit inside that size pipe, and the screw-on cap is very convenient.

 

Put a small piece of foam in the bottom and it is ready to go.

 

 

-        Barry

 

 

 

Dr. Barry Megdal

 

President

Shb Instruments, Inc.

19215 Parthenia St.  Suite A

Northridge, CA 91324

www.shbinstruments.com

(818) 773-2000  (818)773-2005 fax

bmegdal@...

 

Faculty (retired)

Dept. of Electrical Engineering

Caltech

 


How long for UNGUIDED imaging with non AE mounts?

Bob
 

Following on from an earlier thread, does anyone have any info on the length of unguided imaging possible using a 1100GTO or similar with a focal length of up to about 700mm? Assuming the mount is very well aligned.

Thanks
Bob


Re: RAPAS for use in the South

Bob
 

Thanks Mike and Len.

Takeaway then is order the RAPAS I think.


Re: First light for a new camera

Dean Jacobsen
 

We have some nice tools available to us these days.
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin Image Gallery - https://www.astrobin.com/users/deanjacobsen/ 
Amateur Radio Call Sign - W6DBJ


Re: First light for a new camera

Don Anderson
 

Great explanation on CMOS sensor performance Dale. I have been thinking about a larger format camera for a few years now. With the demise of Truesense CCD production last year, I was torn between getting a camera based on the existing CCD technology before they were no longer available or waiting for one with the rapidly improving CMOS sensor. I currently use a Sony icx694 based mono camera with my TV NP127is with a .8X reducer as well as native FL on my AP900GOTO. I shoot narrow band from my heavily polluted (Bortle 8) big city skies so a sensitive camera is a must. Up to now, it has been hard to beat the 694 for sensitivity and low noise until the most recent CMOS offerings have come out. I will be watching The developments closely
Thanks

Don Anderson


On Monday, February 8, 2021, 01:22:29 p.m. MST, Dale Ghent <daleg@...> wrote:



I have the ASI1600 with the Panasonic chip, 294 color, and IMX455-based QHY600 which is the same sensor as the ASI6200.

The Panasonic chip that's in the ASI1600 and other cameras has been a fantastic chip over the years and, like you said, the microlensing effect on super bright stars has been the only major complaint about it. The 12bit nature of its ADCs can be compensated with by just making more exposures. For what it is/was, it has been a very good standard in the CMOS realm.  It was a sensor designed in the early 2010's with tech of that era, and despite that, it has decently controlled amp glow and dark current. And as a chip of that era, it is a front-illuminated design with a single gain domain. These are outdated designs now.

The IMX294/492 is back-illuminated which means more photons actually fall into the pixels, which raises the QE. The vast majority of current era designs from Sony are back-illuminated. The other thing that many current-era chips have in their corner is dual conversion gain. Dual conversion gain is where a good bit of the magic occurs in these sensors and lets them be flexible. DCG sensors came about to address the need for a sensor that can perform well in both bright and dim settings. The Low Conversion Gain (LCG) domain grants you a large full well, with the trade-off being read noise. The High Conversion Gain (HCG) domain gives you lower read noise at the cost of a shallower well. Both have DR curves that largely mirror each other. LCG is meant for exposing in bright environments where the deep well would be best suited, where the HCG domain is for dark scenes, where sensitivity and low read noise is needed. Both the IMX294/492 and IMX455, as well as others, are dual conversion gain sensors.

You can spot these types of sensors by looking at the graphs commonly posted by ZWO, QHY, and others. They have two distinct areas, like this one for the IMX455-based ASI6200MM:

https://astronomy-imaging-camera.com/wp-content/uploads/ASI6200-Performance.png

You can see the two domains clearly in the DR and Read Noise charts. LCG is on the left, starting at gain=0, and then the transition to HCG happens at what looks like gain=100. You can see that LCG and HCG start out more or less similarly, with the LCG having a larger well. Once you get to gain=100, the read noise drops, DR (mostly) recovers, and the downward progression resumes as gain increases. The difference is that at gain=0, you have a 50k e- well, and at gain=100 (the start of the HCG domain) you have what looks like a ~15k well. These charts aren't the greatest but that's my guess assuming they're on a log scale. But you can see the difference nonetheless.

So what does this mean in practice? You can shoot in two different ways:

1. At gain=0 and with long exposures
2. At gain=100 and with shorter exposures

both will yield effectively equivalent results. Which one is best to use (note: I'm purposefully avoiding the word "better" here) largely comes down to personal preferences. Personally I shoot at the start of HCG (the equivalent of gain=100 here) because that's where the sensor performs its best. The very slight hit to DR compared to gain=0 is more than made up by the larger number of exposures I can rip through.  People doing photometry or planetary with these kinds of sensors might find the LCG domain a more useful place for their purposes. In this way, you can look at LCG vs. HCG more in terms of what's best for the use case.

If you have one of these kinds of dual conversion gain sensors and are not entirely sure where the LCG->HCG transition is on the gain scale, it's easy enough to figure out for yourself. Cap off the camera and run bias exposures in loop. Look at the histogram or image stats as you steadily increase the gain. As you increase the gain, you will likely also see an increase in the measured standard deviation. At some point, the stddev will suddenly drop. The gain value in which that drop in stddev happens marks the entry into the HCG domain, as stddev is a representation of the read noise.

As for IMX294/492 vs. IMX455, the 455 (and its APS-C analog, the IMX571) are hands-down the best we have on the consumer market right now. With zero amp glow, a good middling pixel size that applies to a wide range of focal lengths, QEs in the mid-70s for Ha/Sii and mid-80s for Oiii, and 16bit ADCs, they're really cement the fact that modern and highly compelling CMOS tech has arrived and is available. There's not much left to want for the amateur. These sensors are absolute monsters on fast optics as well.


> On Feb 8, 2021, at 10:55, Terri Zittritsch <theresamarie11@...> wrote:
>
> [Edited Message Follows]
>
> Dean, thanks for posting the information.
> Can you say what you think you're getting by replacing the ASI1600MM with the ASI294MM?    I have the ASI1600 and many great images are taken with this camera.  The biggest downside that I've noticed is the micro-lensing effect you can get on bright stars.    I know the ASI294 shows deeper well depth, and better DR, but do these directly relate to better images?    I know that some poo poo-ed the ASI1600 because it only has 12 bits of depth, but that didn't keep people from producing great images.    Since you've owned both, what are the benefits that you can see in the images?
> Maybe a tough question.    I wonder if there is any micro-lensing?
>
> I've recently purchase an ASI6200MM which is on my stowaway now.. and waiting to get a first image. 
>
> Terri
>







Re: How Good Can Guiding be With Non-AE Mount

Roland Christen
 

Depends how much the mount is used. Over time the periodic error changes shape, so what was in the mount when it was manufactures is not going to be accurate now. You have a super easy way to determine what is the PE and whether turning the PE correction on will make it better. All you need is a guide program like PHD2 or MaximDL.

Simply run the mount with guide corrections turned off for 15 - 20 minutes and record the cyclical motion of the guide star (ignore drift, just look at the cycles). You will see every 6.4 minutes the start of a new cycle, with each new cycle resembling the last one. Do this with PE OFF and then repeat with PE ON. Examine the results and make your judgement of what to do.

Rolando



-----Original Message-----
From: M Hambrick <mhambrick563@...>
To: main@ap-gto.groups.io
Sent: Mon, Feb 8, 2021 6:30 pm
Subject: Re: [ap-gto] How Good Can Guiding be With Non-AE Mount

Thanks Roland

Is there a recommended time limit for how long a PE curve can be used before it should be updated ? I am still using the original PE curve that was programmed into the mount when I bought it in March, 2017.

Mike

--
Roland Christen
Astro-Physics


Re: How Good Can Guiding be With Non-AE Mount

M Hambrick
 

Thanks Roland

Is there a recommended time limit for how long a PE curve can be used before it should be updated ? I am still using the original PE curve that was programmed into the mount when I bought it in March, 2017.

Mike


Re: RAPAS for use in the South

Len Fulham
 

Bob,
I have the RAPAS and have used it in Mount Isa and S-E Qld areas (dark skies). Sig Oct is hard to identify unless you have studied the star patterns well, and is faint enough that the reticule (at min brightness) with good batteries will obscure it. I find I have to turn reticule on/off and use reticule 'after glow' to make adjustments - quite doable. Easier as the batteries get low. Not something I can do in twilight and I expect harder if there is serious light pollution but should be doable.

If you are arbitrarily panning the mount to try and find Sig Oct, I think it is impossible. You need to be 'almost' polar aligned using a daytime routine or careful adjustment with a smart phone level & compass. Once you recognise the correct star pattern in the RAPAS, then alignment is quick and accurate (provided you have calibrated your RAPAS via a proper drift alignment first).

Cheers
Len.

6121 - 6140 of 82279