Date   

Re: M 81

Jeff B
 

Yes, very nice.  

Was the optic the doublet or triplet?

Jeff

On Mon, Apr 19, 2021 at 9:46 AM Howard Hedlund <howard@...> wrote:
Nicely done!  That first good image is always a special one.  Print it; frame it; and hang it on your astro-trophy wall!


Re: ETA on ASTAP Native?

Bill Long
 

SkyX does some really odd things that you cannot control well. 

Last night, for example, at an agressive imaging scale of 0.46"/px it continually cropped the image 25% yet there was nowhere I could find a setting at all in Image Link to stop that. It completely prevented any usage of APPM at all with that one factor. 

I hooked up SGP, and it can use ASTAP.  You know what did not happen? I did not have to turn off APCC Alt and Az model data for Polar Alignment. It worked as it should have. The previous models were all SkyX and I had to turn that off to do unguided imaging like I emailed you about. So there is that.

So if I were to give a one night (or one week as it were) vs the other experience in unguided imaging, I would actually say ASTAP solving worked better. Not worse. 

Bill

PS -- I can send cookies and coffee if it helps. 🙂 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <iogroups@...>
Sent: Monday, April 19, 2021 7:02 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] ETA on ASTAP Native?
 
Hi Bill,

I'm testing with ASTAP, but I don't have a completion date because there are too many other variables in my day-to-day stuff.

Have you compared the accuracy of ASTAP to SkyX plate solving? ASTAP seems to be less accurate, especially if there are lens
distortions.  Unlike SkyX and PinPoint, ASTAP does not handle high-order distortions even if they are small. If plate-solving is
less accurate, unguided imaging quality may suffer.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Bill Long
> Sent: Sunday, April 18, 2021 11:43 PM
> To: AP-GTO Groups.io
> Subject: [ap-gto] ETA on ASTAP Native?
>
> Really getting tired of dealing with SkyX for plate solving, it is a really poor experience, as you get into 0.6" - 0.4"/px
> imaging. Meanwhile ASTAP works excellent. I have resorted to using SGP as a middle man to allow ASTAP to work
> with APPM.
>
> Can we please get a timeline on native ASTAP support?
>
> Thanks,
> Bill
>







Re: APPM Image Scale Question and Suggestions

John Jennings
 

I'm really confused about the terminology in this post. I've been using a QHY294C Pro  since it was released. In 11mp mode, A pixel is defined as 4.63um*4.63um. In unlocked 47mp mode, A pixel is defined as 2.314um*2.315um by the manufacturer. I always use these as the Bin x 1 values in plate solver settings (depending on camera driver mode) everywhere just like a monochrome camera. I do understand that underneath the driver at the hardware level, in the 11mp mode, the pixels in "this camera only" (SONY IMX294 BSI CMOS  (Color version)), are Binned x 2. But that's irrelevant at the image level after the driver output.

As I mentioned before, I've had the same issue with these small pixel settings with my Mewlon 300. However, the new QHY Beta drivers are allowing 4x4 color binning on some of the new color cameras. I've not checked this out on my 294C Pro. This will make a big difference in plate solving slow scopes. In general, I do not treat my color cameras any different than my monochrome camera and always use the manufacturers specified pixel size.


Re: ETA on ASTAP Native?

Ray Gralak
 

Hi Bill,

I'm testing with ASTAP, but I don't have a completion date because there are too many other variables in my day-to-day stuff.

Have you compared the accuracy of ASTAP to SkyX plate solving? ASTAP seems to be less accurate, especially if there are lens
distortions. Unlike SkyX and PinPoint, ASTAP does not handle high-order distortions even if they are small. If plate-solving is
less accurate, unguided imaging quality may suffer.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Bill Long
Sent: Sunday, April 18, 2021 11:43 PM
To: AP-GTO Groups.io
Subject: [ap-gto] ETA on ASTAP Native?

Really getting tired of dealing with SkyX for plate solving, it is a really poor experience, as you get into 0.6" - 0.4"/px
imaging. Meanwhile ASTAP works excellent. I have resorted to using SGP as a middle man to allow ASTAP to work
with APPM.

Can we please get a timeline on native ASTAP support?

Thanks,
Bill


Re: M 81

Howard Hedlund
 

Nicely done!  That first good image is always a special one.  Print it; frame it; and hang it on your astro-trophy wall!


Re: Questions.....does wireless now work correctly with latest updates AND does your Sky Safari 6 Pro allow multiple Park positions now.

Howard Hedlund
 

Hi Gentlemen!  I've been working with a team here at AP and a software developer from Sky Safari.  For the present, they have added Mach2 support, Park 3 and Park in place to the existing Park 4.  They also now have resume from last parked.  This should all prove a great benefit to Sky Safari users.
We have also learned through continued testing that one issue with the WiFi was too much signal!  Since you generally operate Sky Safari in very close proximity, much like our keypad, the best thing to do is to fold the antenna into its travel orientation.  
Clear, Dark and Steady Skies!
Howard


ETA on ASTAP Native?

Bill Long
 

Really getting tired of dealing with SkyX for plate solving, it is a really poor experience, as you get into 0.6" - 0.4"/px imaging. Meanwhile ASTAP works excellent. I have resorted to using SGP as a middle man to allow ASTAP to work with APPM.

Can we please get a timeline on native ASTAP support?

Thanks,
Bill 


Re: APPM model how many points portable?

Robert Berta
 

I have a RAPAS on my 1100. I run lots of wires (around 6) through the mount and no issue. There is a plastic segmented "separator" that comes with the mount that allows you to run the cables through and keep them clear of the RAPAS. The reason I have so many cables is I have two interchangeable setups....one for a 6" APO refractor and another for a 11" SCT equipped with Hyperstar so one set is used for each to make it faster to switch setups without rerouting wires. I also have  wires for wireless focuser power. Of course you can also run external wires like I do on my 900 mount if you run out of room. For a permanent setup internal wiring makes it neater but for a portable mount it takes longer to run all the wires through instead of just hanging them off the mount and restraining with Velcro ties.


Re: Mach2 thru-mount USB when using USB 3.0 ? (and an M51)

Jeffc
 



On Sun, Apr 18, 2021 at 4:17 PM Robert Berta <biker123@...> wrote:
I am using USB active extenders. I have run 62' with no issues and running to a USB splitter at the mount to run a imaging camera and guider camera.

Thx for the info.    It turns out the imaging/mount-control computer is collocated with the mount/tripod... access is over remote-desktop / wifi (which is working great).
I just needed the shortest cable possible to the "thru mount" connection.
However, I'll keep in mind the powered extension possibly for the future, or if I find I need to move the computer.

Btw.. not sure I mentioned this here... I also added a Pegasus Ultimate Power Box v2 on top of the OTA to help resolve the USB3 issues.   
I kinda scoffed at getting the UPBv2 for the USB-3 managed hub.... but i'm finding the UPBv2 to be a fantastic addition.
It is very convenient to be able to power-up the camera remotely and track power usage.
Additionally, I've eliminated the robofocus controller wiring (and additional USB/serial adapter) by using the UPBv2 focus controller and a simple RJ45-DB9 cable I soldered up the other evening.
Oh.. and I no longer need the manual DewBuster controller as the UPBv2 also does intelligent dew-strap heating.  Plus the UPBv2 also tracks temperature humidity and dew point over time.

-jeff

These use a small power supply plugged in similar to a cell phone charger to provide the power. As another person mentioned....I also have some UGreen USB cables that are quality. There are a few USB active cables....just make sure you get the ones that can be powered and are USB 3. Mine are all USB 2 currently.


Re: Mach2 thru-mount USB when using USB 3.0 ? (and an M51)

Robert Berta
 

I am using USB active extenders. I have run 62' with no issues and running to a USB splitter at the mount to run a imaging camera and guider camera. These use a small power supply plugged in similar to a cell phone charger to provide the power. As another person mentioned....I also have some UGreen USB cables that are quality. There are a few USB active cables....just make sure you get the ones that can be powered and are USB 3. Mine are all USB 2 currently.


Re: M 81

KHursh
 

Thanks Unc Rolando


Re: Questions.....does wireless now work correctly with latest updates AND does your Sky Safari 6 Pro allow multiple Park positions now.

Robert Berta
 

Yes...that is same for my Android version of Sky Safari 6 Pro. Before we didn't have the options for parking other than one as I recall. Now when disconnecting it has the list of options. That is great as we have been asking for this from Sky Safari for a few years! 

You said wireless works. Mine did before but would loose the connection often and usually you couldn't reconnect without closing SS an restarting which was obviously a royal PITA. To get around that I was using a SKY FI module rather than the AP wife version. The Sky Fi worked very well and at long distances but since I paid for that feature on my AP mount I was hoping it would get resolved. Others had the same issue but after many attempts at fixes it didn't get fixed until this latest release of the firmware update for the CP4.

I wonder if AP finally worked with Sky Safari programmers to solve the issue. In any case I am finally very happy that it seems to work well and the Park options is also fantastic. 

I will do some more testing but looks good thus far. More testers would be welcome.. By the way the port is 23 on mine for wireless. The way you get the IP is described in the owners manual.....or you can use the utility that comes with the firmware full package update.

I love that I can run Maxim DL for all image acquisition with my laptop but control the mount with Sky Safari which I prefer over other alternatives..mainly because it has such a huge database and ease of use. I can also create a Android virtual computer on my Windows 10 PC and load Sky Safari Android version and run both the imaging program and telescope control from one computer if I wish. If I run the Android app on my cell phone or tablet, it is nice to leave the computer alone while does its scripted imaging gathering and I can go somewhere else and use the Android device to plan other targets or investigate various Sky Safari options at my leisure without worrying about messing up my image gathering accidently. When ready for next target just reconnect and I am good to go to next object. 

For visual use for public events, being able to run the CP4 mount from my cell phone and Sky Safari 6 Pro is neat as I can show people more information, what is in the area, photos of the object, etc. on the cell phone or larger tablet. 

Maybe Howard or Roland can weigh in on who came up with the fix for both so we can thank them!


Re: NGC 3347 and NGC 3358

Karen Christen
 

Wow, that’s pretty.  Well done, Geoff.

Karen

AP

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Geoff Smith
Sent: Saturday, April 17, 2021 7:45 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] NGC 3347 and NGC 3358

 

NGC 3347 is an elongated spiral galaxy, while NGC 3358 is a face-on lenticular galaxy There is a barely visible faint tidal stream between NGC 3347 and the smaller round spiral NGC 3354. Both NGC 3347 and NGC 3354 have similar red-shifts, suggesting that this is a genuine association and not merely a line-of-sight coincidence.

Plane Wave 12.5" CDK on AP900 with FLI Proline 16803

Technical details here https://www.astrobin.com/qlym15/

Higher resolution here https://www.astrobin.com/full/qlym15/0/

Geoff


--
Karen Christen
Astro-Physics


Re: M 81

Roland Christen
 

Not bad at all. I always say "If it's up, image it!"

Rolando



-----Original Message-----
From: KHursh via groups.io <khursh@...>
To: main@ap-gto.groups.io
Sent: Sat, Apr 17, 2021 9:54 pm
Subject: [ap-gto] M 81

I know this is an oft-imaged galaxy, but it is one of the first images I am proud of.
Image processing is challenging, but capture is a breeze with the Mach2.
Sky-watcher 120 with ASI294MM,

https://astrob.in/kxm7yk/0/

Kevin

--
Roland Christen
Astro-Physics


Re: Powering Remote Imaging Systems

Luca Marinelli
 

I forgot to paste the link:

Kingdel Fanless Mini Desktop Computer, Mini PC with Intel i7 CPU, 16GB RAM, 512GB SSD, 2xHD Ports, 2xLAN, All Metal Body, Windows 10 Pro https://www.amazon.com/dp/B01AWB2GWG/ref=cm_sw_r_cp_api_glt_fabc_4Q2DM3XKMQV0SWGAFHBF

On Apr 18, 2021, at 12:46 PM, Luca Marinelli via groups.io <photo=lucamarinelli.com@groups.io> wrote:

I have two of these Kingdel fanless Core i7 headless PC running in my observatory and they have been flawless. The oldest one has been in operation for two years with no downtime and has controlled an imaging system and observatory operations down to -15F without missing a beat.

Luca

On Apr 18, 2021, at 11:19 AM, Steve Reilly via groups.io <sreilly24590=centurylink.net@groups.io> wrote:

Thanks for the reply Dale. I probably should replace at least the SRO computer. Any particular brand or vendor you can recommend for getting these? Hopefully they can be well configured which is what I think kept me from using these early on.

-Steve


-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Sunday, April 18, 2021 11:08 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Powering Remote Imaging Systems


I wouldn't worry about computers needing a "rest" unless you have power availability considerations that would necessitate a complete shutdown of everything during idle periods. Computers are pretty resilient things. You can get fanless systems with SSDs and be completely free of any moving parts that could wear out from long periods of running. It's far better to have a fanless system that is designed to be fanless, than one that relies on a fan for cooling and is in trouble if that fan breaks or gets clogged up with the kind of dust and gunk that often floats around inside observatories.

I don't know what your current in-observatory system is, but I would just opt for a low power system instead of trying to come up with some power management/synchronization machination for a single remote PC. Something NUC-ish is suitable for almost any observatory's control and acquisition system. You can find small systems with 15W TDP Intel i3 or i5 CPUs that sip power are completely adequate for the task.

You can have it do stuff during the daytime, too. Run a weather station, monitor inside temperature/humidity sensors, or an all-sky or security cameras, for example.


On Apr 18, 2021, at 08:17, Steve Reilly <sreilly24590@centurylink.net> wrote:
While not directly mount related it does concern powering systems. For a system I run at SRO and one at home I have Web Power switches for the scripting the powering of equipment on/off through ACP Expert which works great but now years after just leaving the computers on 24/7 forever I wonder about the intelligence of that practice. I do have the computer’s BIOS set to restore to previous state should there be a power loss so that it turns back on and in turn opens the programs I have in the Start Menu which is fine for emergencies but I suspect I wouldn’t want to force stop/start it like that on a regular basis if not necessary. I’ve read a bit about Wake On LAN but that requires a computer that is on that network to access the computer you want woken which in this case is doable even with SRO as they have a VPN that sets the remote computer as part of your local network. I can Remote Desktop into that system using the IP address from home when the VPN is connected.

But of course I’m looking for more fool proofing such as not relaying on memory to connect and turn on each system every day as that will most certainly be forgotten from time to time and likely on the very best of nights. So the real question hidden deep in this post is if anyone knows of a mostly foolproof method to have remote computers turn on and off at predetermined times. I would expect you’d want to calculate the earliest time for On in your area considering DST and off by the latest morning time. Say you may want 4PM start for the winter when you could be imaging by 5:30pm in some areas and off at 9am in the morning which would/should allow time for sky flats should you take them both evening and morning. This at least gives the computer a rest of 15+ hours a day and in my case where I use a Starlight Xpress UltraStar guider t to would be powered down as it’s always on when connected to the computer’s USB.

Just think there should be a more reasonable way to run these system that would be easier on the computers as well as being more efficient. Anything obvious I’m missing? Suggestions?













Re: Powering Remote Imaging Systems

Luca Marinelli
 

I have two of these Kingdel fanless Core i7 headless PC running in my observatory and they have been flawless. The oldest one has been in operation for two years with no downtime and has controlled an imaging system and observatory operations down to -15F without missing a beat.

Luca

On Apr 18, 2021, at 11:19 AM, Steve Reilly via groups.io <sreilly24590=centurylink.net@groups.io> wrote:

Thanks for the reply Dale. I probably should replace at least the SRO computer. Any particular brand or vendor you can recommend for getting these? Hopefully they can be well configured which is what I think kept me from using these early on.

-Steve


-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Sunday, April 18, 2021 11:08 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Powering Remote Imaging Systems


I wouldn't worry about computers needing a "rest" unless you have power availability considerations that would necessitate a complete shutdown of everything during idle periods. Computers are pretty resilient things. You can get fanless systems with SSDs and be completely free of any moving parts that could wear out from long periods of running. It's far better to have a fanless system that is designed to be fanless, than one that relies on a fan for cooling and is in trouble if that fan breaks or gets clogged up with the kind of dust and gunk that often floats around inside observatories.

I don't know what your current in-observatory system is, but I would just opt for a low power system instead of trying to come up with some power management/synchronization machination for a single remote PC. Something NUC-ish is suitable for almost any observatory's control and acquisition system. You can find small systems with 15W TDP Intel i3 or i5 CPUs that sip power are completely adequate for the task.

You can have it do stuff during the daytime, too. Run a weather station, monitor inside temperature/humidity sensors, or an all-sky or security cameras, for example.


On Apr 18, 2021, at 08:17, Steve Reilly <sreilly24590@centurylink.net> wrote:

While not directly mount related it does concern powering systems. For a system I run at SRO and one at home I have Web Power switches for the scripting the powering of equipment on/off through ACP Expert which works great but now years after just leaving the computers on 24/7 forever I wonder about the intelligence of that practice. I do have the computer’s BIOS set to restore to previous state should there be a power loss so that it turns back on and in turn opens the programs I have in the Start Menu which is fine for emergencies but I suspect I wouldn’t want to force stop/start it like that on a regular basis if not necessary. I’ve read a bit about Wake On LAN but that requires a computer that is on that network to access the computer you want woken which in this case is doable even with SRO as they have a VPN that sets the remote computer as part of your local network. I can Remote Desktop into that system using the IP address from home when the VPN is connected.

But of course I’m looking for more fool proofing such as not relaying on memory to connect and turn on each system every day as that will most certainly be forgotten from time to time and likely on the very best of nights. So the real question hidden deep in this post is if anyone knows of a mostly foolproof method to have remote computers turn on and off at predetermined times. I would expect you’d want to calculate the earliest time for On in your area considering DST and off by the latest morning time. Say you may want 4PM start for the winter when you could be imaging by 5:30pm in some areas and off at 9am in the morning which would/should allow time for sky flats should you take them both evening and morning. This at least gives the computer a rest of 15+ hours a day and in my case where I use a Starlight Xpress UltraStar guider t to would be powered down as it’s always on when connected to the computer’s USB.

Just think there should be a more reasonable way to run these system that would be easier on the computers as well as being more efficient. Anything obvious I’m missing? Suggestions?










Re: Powering Remote Imaging Systems

Steve Reilly
 

Thanks for the reply Dale. I probably should replace at least the SRO computer. Any particular brand or vendor you can recommend for getting these? Hopefully they can be well configured which is what I think kept me from using these early on.

-Steve

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Sunday, April 18, 2021 11:08 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Powering Remote Imaging Systems


I wouldn't worry about computers needing a "rest" unless you have power availability considerations that would necessitate a complete shutdown of everything during idle periods. Computers are pretty resilient things. You can get fanless systems with SSDs and be completely free of any moving parts that could wear out from long periods of running. It's far better to have a fanless system that is designed to be fanless, than one that relies on a fan for cooling and is in trouble if that fan breaks or gets clogged up with the kind of dust and gunk that often floats around inside observatories.

I don't know what your current in-observatory system is, but I would just opt for a low power system instead of trying to come up with some power management/synchronization machination for a single remote PC. Something NUC-ish is suitable for almost any observatory's control and acquisition system. You can find small systems with 15W TDP Intel i3 or i5 CPUs that sip power are completely adequate for the task.

You can have it do stuff during the daytime, too. Run a weather station, monitor inside temperature/humidity sensors, or an all-sky or security cameras, for example.


On Apr 18, 2021, at 08:17, Steve Reilly <sreilly24590@centurylink.net> wrote:

While not directly mount related it does concern powering systems. For a system I run at SRO and one at home I have Web Power switches for the scripting the powering of equipment on/off through ACP Expert which works great but now years after just leaving the computers on 24/7 forever I wonder about the intelligence of that practice. I do have the computer’s BIOS set to restore to previous state should there be a power loss so that it turns back on and in turn opens the programs I have in the Start Menu which is fine for emergencies but I suspect I wouldn’t want to force stop/start it like that on a regular basis if not necessary. I’ve read a bit about Wake On LAN but that requires a computer that is on that network to access the computer you want woken which in this case is doable even with SRO as they have a VPN that sets the remote computer as part of your local network. I can Remote Desktop into that system using the IP address from home when the VPN is connected.

But of course I’m looking for more fool proofing such as not relaying on memory to connect and turn on each system every day as that will most certainly be forgotten from time to time and likely on the very best of nights. So the real question hidden deep in this post is if anyone knows of a mostly foolproof method to have remote computers turn on and off at predetermined times. I would expect you’d want to calculate the earliest time for On in your area considering DST and off by the latest morning time. Say you may want 4PM start for the winter when you could be imaging by 5:30pm in some areas and off at 9am in the morning which would/should allow time for sky flats should you take them both evening and morning. This at least gives the computer a rest of 15+ hours a day and in my case where I use a Starlight Xpress UltraStar guider t to would be powered down as it’s always on when connected to the computer’s USB.

Just think there should be a more reasonable way to run these system that would be easier on the computers as well as being more efficient. Anything obvious I’m missing? Suggestions?


Re: Powering Remote Imaging Systems

Dale Ghent
 

I wouldn't worry about computers needing a "rest" unless you have power availability considerations that would necessitate a complete shutdown of everything during idle periods. Computers are pretty resilient things. You can get fanless systems with SSDs and be completely free of any moving parts that could wear out from long periods of running. It's far better to have a fanless system that is designed to be fanless, than one that relies on a fan for cooling and is in trouble if that fan breaks or gets clogged up with the kind of dust and gunk that often floats around inside observatories.

I don't know what your current in-observatory system is, but I would just opt for a low power system instead of trying to come up with some power management/synchronization machination for a single remote PC. Something NUC-ish is suitable for almost any observatory's control and acquisition system. You can find small systems with 15W TDP Intel i3 or i5 CPUs that sip power are completely adequate for the task.

You can have it do stuff during the daytime, too. Run a weather station, monitor inside temperature/humidity sensors, or an all-sky or security cameras, for example.

On Apr 18, 2021, at 08:17, Steve Reilly <sreilly24590@centurylink.net> wrote:

While not directly mount related it does concern powering systems. For a system I run at SRO and one at home I have Web Power switches for the scripting the powering of equipment on/off through ACP Expert which works great but now years after just leaving the computers on 24/7 forever I wonder about the intelligence of that practice. I do have the computer’s BIOS set to restore to previous state should there be a power loss so that it turns back on and in turn opens the programs I have in the Start Menu which is fine for emergencies but I suspect I wouldn’t want to force stop/start it like that on a regular basis if not necessary. I’ve read a bit about Wake On LAN but that requires a computer that is on that network to access the computer you want woken which in this case is doable even with SRO as they have a VPN that sets the remote computer as part of your local network. I can Remote Desktop into that system using the IP address from home when the VPN is connected.

But of course I’m looking for more fool proofing such as not relaying on memory to connect and turn on each system every day as that will most certainly be forgotten from time to time and likely on the very best of nights. So the real question hidden deep in this post is if anyone knows of a mostly foolproof method to have remote computers turn on and off at predetermined times. I would expect you’d want to calculate the earliest time for On in your area considering DST and off by the latest morning time. Say you may want 4PM start for the winter when you could be imaging by 5:30pm in some areas and off at 9am in the morning which would/should allow time for sky flats should you take them both evening and morning. This at least gives the computer a rest of 15+ hours a day and in my case where I use a Starlight Xpress UltraStar guider t to would be powered down as it’s always on when connected to the computer’s USB.

Just think there should be a more reasonable way to run these system that would be easier on the computers as well as being more efficient. Anything obvious I’m missing? Suggestions?


Re: APPM Image Scale Question and Suggestions

Ray Gralak
 

Hi Marty,

1. With a color camera the appropriate x-scale and y-scale factors to enter are twice the individual pixel dimensions.
In my case I should enter 0.52 rather than 0.26 for each X and Y scale. Is that correct?
This assumes the information you provided is correct (that 2x2 binning results in 1 arc-sec/pixel image scale using the ASI294MC with a 300mm aperature F15 scope).

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of mjb87 via groups.io
Sent: Sunday, April 18, 2021 4:26 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Image Scale Question and Suggestions

[Edited Message Follows]

Thanks. I appreciate the assistance. Here is what I'm taking away so far

1. With a color camera the appropriate x-scale and y-scale factors to enter are twice the individual pixel dimensions.
In my case I should enter 0.52 rather than 0.26 for each X and Y scale. Is that correct? (Not sure I understand why
it would be.)

2. When you later attempt to redo a platesolve on a saved image, and when it reports its estimated actual image
scale, it is reporting the binned scale. In other words, the reason my reported scale was 1.04 is that the actual
unbinned image scale was 0.52 and I was using 2x2 binning. Is that correct? (If so, it might be helpful to modify that
window to emphasize that the reported scale is binned scale.)

3. I may just be asking too much to get good solutions using an f/15 telescope and a camera with small pixels, given
my Bortle 5 skies and with the moon out. One option is to use a camera with a larger pixel size. As evidence of this,
in using a similar camera on my 130mm GTX I still had to do 2x2 binning to get easy solutions. I use a Lodestar X2
as a guide camera on my other setup. It has 8.2x8.4 pixels. I can try that instead of the ASI1600MC-Cool.

4. Other things to try: more tolerance around image scale, less sigma above mean, longer exposures.

Make sense?


Re: APPM Image Scale Question and Suggestions

Ray Gralak
 

Hi Marcelo,

Ray wrote:
2x2 binning of 0.26 arc-secs/pixel should be 0.52 arc-secs/pixel, not 1.0 arc-secs/pixel.

However, since this is a color camera, if each group of 4-pixels is considered 1 pixel, then you should enter
0.52 arc-secs/pixel in APPM for the X and Y image scale values.
Marcello wrote:
I assume that the same principles apply for the ASI294MM camera, whose default mode is 2x2 binning, right?
What I posted above was just a theory. The ASI294MM, which is monochrome, recently received a firmware upgrade to "unlock" the higher resolution (natively unbinned). So, it may be that in the color camera (ASI294MC), each "logical pixel" consists of four color-filtered native pixels. So, pixel-scale may depend on the camera modes defined by the sensor and implemented by the camera manufacturer.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Marcelo Figueroa via groups.io
Sent: Saturday, April 17, 2021 10:03 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Image Scale Question and Suggestions

On Sat, Apr 17, 2021 at 05:31 PM, Ray Gralak wrote:


2x2 binning of 0.26 arc-secs/pixel should be 0.52 arc-secs/pixel, not 1.0 arc-secs/pixel.

However, since this is a color camera, if each group of 4-pixels is considered 1 pixel, then you should enter
0.52 arc-secs/pixel in APPM for the X and Y image scale values.

I assume that the same principles apply for the ASI294MM camera, whose default mode is 2x2 binning, right?

4401 - 4420 of 82280