Re: Which Camera?
Kenneth Tan
I have quite a few zwos . The 6200 is great . I would not get the 2400. The 2600 are ok. Zwo Filter wheel design acceptable and convenient if you intend to use their system with the asi air pro. But not what i would say the best. A little rough around the edges in implementation. OAG best to avoid the zwo Kenneth
|
|
Re: AP1100 coming, least hassle plate solver?
Alex
That sounds exciting! Hoping the beta progresses quickly as well. It is always nice having options.
|
|
Re: [ap-ug] Which Camera?
Robert Chozick <rchozick@...>
I have owned four ZWO cameras and I’ve had very good luck with all four. I have a Mac and ZWO supports Mac operating systems whereas QHY does not. I have only had one experience with a QHY camera and it had a lot of problems. This all could be luck of the draw but my preference is to remain with ZWO cameras.
toggle quoted messageShow quoted text
Robert
On Jul 1, 2021, at 4:21 PM, Dale Ghent <daleg@...> wrote:
|
|
Re: AP1100 coming, least hassle plate solver?
ap@CaptivePhotons.com
Thanks, Alex. I’ve done a lot of plate solving with TSX (in tPoint) and with ASTAP in NINA. So far both with the 4” refractor and C11 I’ve had no real trouble getting solving to work. Maybe it’s the mono camera that helps. If I recall I’m at about 2 sec in tPoint. But both solve very quickly and even at 2800mm rarely have trouble.
My hope is I can get APPM to work as well as quickly as tPoint with NINA. I’m hoping that beta I hear is out there is progressing nicely! Dale’s work has me now thinking it’s just around the corner!
Linwood
|
|
Re: AP1100 coming, least hassle plate solver?
Alex
Hello Linwood,
This is kind of a side note. Initially, I personally had trouble with getting any of the plate solvers to work quickly with my main camera and scope. My setup includes the AP1100, 130GTX, QUADTCC and a ZWO ASI 2600MC camera. What I discovered after hours of tweaking settings to improve performance in TSX, ASTAP, etc. is my viewing site has a lot of light pollution. Now, I use a quad band narrow filter with the main OSC camera with 12 second exposures and all of the plate solvers work very quickly (Usually 2 to 8 seconds) with this combination without endless tweaking. It appears the severe light pollution was negatively impacting the plate solving process. Also, my guided exposures at 330 to 360 second look much better with the quad band narrow filter. Saves a lot of time imaging too. All four narrow bands at the same time. Best, Alex
|
|
Re: [ap-ug] Which Camera?
Dale Ghent
I have the QHY600M (the Pro version, but it's not likely you'll want that), and a bunch of my colleagues have the ZWO ASI6200MM. Both use the IMX455 sensor. I have other ZWO cameras, and have direct experience programming for the software stacks of both companies. We also all sit in a chat together so we always talk about our current camera war stories.
toggle quoted messageShow quoted text
On the whole, QHY and ZWO are equivalent in a broad sense. I prefer some design aspects to the QHY cameras over ZWO's habits, but then I also feel the same about certain ZWO design aspects. QHY have cleaned up their driver situation over the past two years so gripes about that are a bit dated, I feel. This camera functions fine. The QHY600M comes in 3 main flavors. It's likely you would be getting either the Lite (QHY600L-M) or the Photographic (QHY600PH-M) versions. The obvious difference between the L and PH is price. The L uses the "commercial grade" variant of the IMX455, and the PH model uses the "industrial grade" variant of the same. According to QHY, the differences are chip lifetime, with the industrial variant having some higher MTBF. Accordingly, the QHY600M-L is cheaper. The PH itself is available in 2 sub-model: the normal one with a 17.5mm backfocus and a "short backfocus" (SBFL) variant that consumes 12.5mm of backfocus. The attachment of the two variants are different. The normal backfocus version attaches to the rear of the QHY filter wheel via circular dovetail that is secured by 3 screws placed around the circumference of the saddle. This saddle is bolted to the rear of the QHY filter wheel. This saddle consumes 6mm of backfocus. The SBFL variant (12.5mm) of the camera has a different mechanical interface. In addition to the sensor being 5mm closer to the front of the camera, the camera bolts directly onto the rear of the QHY filter wheel. This eliminates the saddle and saves another 6mm of backfocus, bringing the total backfocus savings to 11mm. This SBFL variant is not available on the L model. In most cases, I would suggest going with the QHY600PH SBFL because of the non-trivial amount of back focal length that's conserved, leaving room for whatever paraphernalia you want between the flattener and filter wheel. It's also better for faster optics because it places the sensor closer to the filters. The "normal" version is useful because that circular dovetail makes rotating the camera quick and simple. If you have a rotator or prefer to rotate the imaging rig via the focuser, then it's obviously not any use in that case. Outside the mechanical aspects, the QHY600 has 4 readout modes. QHY uses the readout mode facility in a different way than it has been traditionally utilized for on CCDs. These CMOS sensors can be driven in a myriad of different ways which can yield various combinations of pixel well depth, read noise, and dynamic range. QHY details the 4 modes they implement here: https://www.qhyccd.com/qhy600m-c/#c120 The modes are intended for specific applications, with them being divided more or less along the lines of well depth and noise. The QHY site explains them with graphs. I personally shoot in mode 1 ("High Gain mode") and just inside the High Conversion Gain domain of the sensor. As for the ZWO analog, it consumes 17.5mm, and I think that can be reduced slightly by removing its front push-pull tilt plate. It does have a 2-port USB2 hub built into the rear, but its intent is mainly for running the filter wheel and an OAG camera. It does not have multiple readout modes, and it drives the sensor in a way that is equivalent most to QHY's mode 1. There are a bunch of other differences between the two cameras. QHY puts humidity and air pressure sensors in the sensor chamber so you can know when it's time to attach the desiccant tube. Stuff like that. In the end, you won't go wrong with either choice; the decision comes down to technical specifics, such as needing to conserve backfocus distance or the desire for the different operating modes. If you want, I can throw you some raw frames from my 600.
On Jul 1, 2021, at 16:09, Roland Christen via groups.io <chris1011@...> wrote:
|
|
Re: Which Camera?
Marcelo Figueroa
Since both use the same sensors, the differences are minor.
The more or less generalized opinion is that although the QHY hardware is a little better, its drivers are not the best (just take a look at the CN forums). On the other hand, ZWO has a very good hardware and also very good drivers.
For me the differences are very minor and I would go for the one that is available sooner.
Keep in mind that the new Sony sensors are a bit temperamental and the flats, especially on Ha and Sii, look really weird. But the calibration works perfectly.
|
|
Re: Which Camera?
Having owned both I pretty clearly lean toward ZWO for one big reason and a few minor ones, but both will serve you well I think.
The big reason: From day one with the two QHY cameras and filter wheels I had, the drivers were buggy. I could always get the equipment to work without too much trouble, but I was constantly wondering "will it work this time?" And forget about updating the drivers because every time I did something had to be "worked around" in order to get it to work. Once I had a driver that seemed to work well I just left it for a long time. Contrast that with my two ZWO cameras (6200MM and 2600MC), which worked perfectly from day one. Driver installation and usage is easy and has worked flawlessly ever since, for about 16 months now. I have updated drivers without any issues as well. The minor considerations: I actually found the plethora of QHY options to be a hinderance. The ZWO system seemed a lot less complicated and straight forward, which was fine for my system. The filter wheel has always worked well. Tip: set the driver to only rotate one way in order to assure accurate filter position. I haven't experienced this but some have said that when trying to rotate the wheel either direction the filters weren't placed exactly in the same position. The OAG uses a wide M68 connection thread which is nice. ZWO also just announced a new OAG with a 12mm x 12mm prism (larger than most 8mm prisms) so it can take advantage of larger guide cameras. I will likely upgrade to this new OAG myself so the guide camera (ZWO ASI174-mini) can cover more territory. ZWO also announced recently that they are opening a servicing center somewhere in Indiana. The ZWO cameras have a USB hub for peripherals. I run the filter wheel and guide camera directly through the ASI6200MM without issue. As for QHY having better build quality, that may have been true in the past but I haven't seen any differences myself with the cameras I have owned. Both seem to have pretty much equal build quality IMHO. Some of the early ZWO cameras used a tablet desiccant system which seemed to be pretty weak, but they have done away with that now. While you can tell I definitely lean toward ZWO, that is not to say that QHY doesn't make good equipment. I do think that both work well and that the differences are relatively minor. In my system ZWO just seemed to work better. joel
|
|
Which Camera?
Roland Christen
I've been looking long and hard at full frame mono CMOS cameras as a next purchase for our AP observatory. So the question is - which camera - QHY or ZWO?
Which has the better accessories such as filter wheel, off-axis guider etc...
Any and all thoughts welcome.
Rolando
-----Original Message-----
From: Dale Ghent <daleg@...> To: main@ap-ug.groups.io Sent: Thu, Jul 1, 2021 12:44 pm Subject: Re: [ap-ug] Questoin for Roland: Waited too long to buy 175TCC (discontinued) for my 175EDF....is QUADTCC is as good of a solution. > On Jul 1, 2021, at 01:54, ROBERT WYNNE <robert-wynne@...> wrote: > > Based on what I've read on this and other venues I remain unconvinced in CMOS chip technology's ability to capture an equal amount of photons compared to an CCD, in focus and without tilt at the pixel well level with 0 or near 0 noise in reasonable time frames. I would not underestimate my desire to obtain the largest Sony CCD available if the notion caught my interest nor a CMOS chip if the advancement in CMOS quality presents itself in the next year which could easily exceed a 67 mm circle. Thus my push. With all due respect, but none of this makes any sense. Current CMOS sensors have QE in the high 80's, pushing 90%, and approach 1e- read noise in typical operating modes. 5, and even 3 minute long narrowband exposures at circa f/5 are normal... no more 15-20 minute exposures that can be ruined by a passing cloud or other interference. On top of that, you don't need to endure the comparatively glacial readout speeds that CCDs have, which eats into total integration time when you sum up the 15-20 seconds it takes to pull each frame off a CCD camera. You sentiments would have made more sense perhaps up to 2 years ago. But the current generation of CMOS sensors, namely the IMX533 (1", color), IMX571 (APS-C color+mono), IMX455 (FF, color+mono), and IMX411 (150mp medium format, mono), have performance characteristics that make choosing them over CCD almost a no-brainer. They also have such low dark current that chilling them below -10C is very firmly in the territory of diminishing returns, making these sensors more warm-climate friendly top operate. I will say that there seems to be a lot of sentimental or emotional attachment to CCDs; perhaps more so now that stocks of them are running on fumes. There are *plenty* of compelling reasons to adopt modern tech, however. -- Roland Christen Astro-Physics
|
|
George
Fred,
You’re most welcome. Please take care and enjoy!
Regards,
George
George Whitney Astro-Physics, Inc. Phone: 815-222-6538 (direct line) Phone: 815-282-1513 (office) Email: george@...
From: main@ap-gto.groups.io <main@ap-gto.groups.io>
On Behalf Of contact@...
Sent: Wednesday, June 30, 2021 11:58 AM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Pointing model and Wifi control #APCC #Mach2GTO
Thank you Georges for your answer!
|
|
contact@...
Thank you Georges for your answer!
Actually i was expecting this answer! I think i will drive the laptop thru VNC with an IPAD for the familie’s star parties Clear skies from Corsica Fred
|
|
George
Fred,
No. The pointing model is in the APCC computer software. Sky Safari uses its own proprietary program…no computer contact.
Regards,
George
George Whitney Astro-Physics, Inc. Phone: 815-222-6538 (direct line) Phone: 815-282-1513 (office) Email: george@...
From: main@ap-gto.groups.io <main@ap-gto.groups.io>
On Behalf Of contact@...
Sent: Wednesday, June 30, 2021 5:03 AM To: main@ap-gto.groups.io Subject: [ap-gto] Pointing model and Wifi control #APCC #Mach2GTO
hello everybody,
|
|
contact@...
hello everybody,
As I’m a newbie please forgive me if my question seems weird. I have created a pointing model thru APPM And APPC PRO. My Mach2 mount is connected to my laptop with an ethernet connection. Everything is workin fine, I’m very impressed! But is it possible to connect at the same time an IPhone with skySafari thru wifi and take advantage of the pointing model? Thanks in advance for your kind answers! Fred
|
|
Re: AP1100 coming, least hassle plate solver?
I understand you want to use NINA, tho you also mentioned SGP. Fwiw I use APPM with SGP and ASTAP, and it seems to work fine But we don't. I deleted SGP and don't want to configure it or platesolve2 again. Times change and both of those programs are severely outdated. ASTAP is free and 1/10,000th the time that PLATESOLVE2 requires to solve. NINA vs SGP goes without saying.
On Sat, Jun 26, 2021 at 3:03 PM Jeffc <jeffcrilly@...> wrote: I understand you want to use NINA, tho you also mentioned SGP. --
Ron Kramer
|
|
Re: AP1100 coming, least hassle plate solver?
YAY! thanks RAY! been patiently waiting and watching. I did notice a option in nina to use SGP SDK... excited to try it.
On Sat, Jun 26, 2021 at 2:30 PM Ray Gralak <iogroups@...> wrote: Hi Linwood, --
Ron Kramer
|
|
Re: Mach2/APCC Pro communication and low power errors during imaging run
Luca Marinelli
Thanks Roland, will do.
Luca
On Jun 29, 2021, at 10:32 AM, Roland Christen via groups.io <chris1011@...> wrote:
|
|
Re: Mach2/APCC Pro communication and low power errors during imaging run
Roland Christen
Please call George at AP and talk to him about this. He may have the solution for you.
Rolando
-----Original Message-----
From: Luca Marinelli <photo@...> To: main@ap-gto.groups.io Sent: Tue, Jun 29, 2021 8:10 am Subject: [ap-gto] Mach2/APCC Pro communication and low power errors during imaging run I was imaging unattended last night and this morning I found the mount stopped (not parked) in Park 3 position with many communication and low-power errors in the APCC console, which stopped the imaging run. The SGP log showed errors communicating with the AP ASCOM driver. The 24V power brick works and when I parked, unparked, and slewed the mount from both APCC and the keypad, everything worked. I am stumped as to what might have gone wrong during the night.
Ray, I have zipped the log files and parked them here: https://www.dropbox.com/s/86upw9pw2igmxdx/ApccZip-Luca_Marinelli-2021-06-29-071128.zip?dl=0 I would appreciate if you could take a look and see if anything jumps out at you. thanks! Luca -- Roland Christen Astro-Physics
|
|
Mach2/APCC Pro communication and low power errors during imaging run
Luca Marinelli
I was imaging unattended last night and this morning I found the mount stopped (not parked) in Park 3 position with many communication and low-power errors in the APCC console, which stopped the imaging run. The SGP log showed errors communicating with the AP ASCOM driver. The 24V power brick works and when I parked, unparked, and slewed the mount from both APCC and the keypad, everything worked. I am stumped as to what might have gone wrong during the night.
Ray, I have zipped the log files and parked them here: https://www.dropbox.com/s/86upw9pw2igmxdx/ApccZip-Luca_Marinelli-2021-06-29-071128.zip?dl=0 I would appreciate if you could take a look and see if anything jumps out at you. thanks! Luca
|
|
Re: AP1100 coming, least hassle plate solver?
W Hilmo
Ok, so I have the system up and running again and was able to reproduce the problem.
toggle quoted messageShow quoted text
If I connect to the camera via ASCOM, and set binning to 2, then it fails to take a picture and gives the following error:: ---------- ASCOM CCD Expose Failed(1): NumX set - '6776' is an invalid value. The valid range is 1 to 3388. ---------- If I set binning to 1x1, then it successfully takes the image. It failed to solve, but that's likely related to my plate solver. I'm using TheSkyX (until ASTAP is available as a direct selection in APPM) and I probably need to tweak the image link settings, although TheSkyX solves fine if I'm using MaxIm/DL as the capture program. MaxIm also works fine if I bin 2x2. Note that the valid range mentioned in the error message is the camera's native resolution, binned 1x1. This seems to be very similar to the problem that I was seeing a few years ago with SGP. The difference then is that the obvious symptom was that the image never appeared in SGP, and I had to go to the logs to see the error message. In this case, the error message pops up on the screen. Also, I do have some feedback for using ASCOM as the capture software. The APPM camera image viewer renders the image at 100%, which is far too large for my monitor's resolution (my observatory computer is 1920x1080). I don't see any way to automatically scale the image. Actually, I don't see any way to manually scale the image either. I need to use scroll bars to pan, in order to see it. The viewer also doesn't appear to do an automatic screen stretch. There is a slider to adjust the gamma, but it would be nice if it auto selects a decent stretch. Finally, the timer that displays during capture, download and solving stops just before the exposure is complete, and then nothing happens on screen until the solution is completed (in my case, with an error from TheSkyX, as above). When I use MaxIm as the capture software, the timer runs continuously until it completes. Thanks, -Wade
-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of W Hilmo Sent: Sunday, June 27, 2021 7:02 AM To: main@ap-gto.groups.io Subject: Re: [ap-gto] AP1100 coming, least hassle plate solver? There was an error message. I don't remember it, and was in the field when it occurred and didn't make a note of it at the time. With limited time at that site, I just switched to another piece of camera software, probably Maxim. I remember that the error message referenced pixel coordinates, which is why I think that it might be related to binning the camera 2x2. I was planning on reproducing it at home and digging a bit deeper, and was going to do that before reporting it. I mentioned it here, due to the mention of using the ASCOM driver in APPM, and in case someone else encounters it. And since problems seem to happen in groups (at least for me) the computer that I was using in the field failed and could not be restarted when I got home from that trip. I have a new computer nearly fully provisioned and ready to go, but have been slowed by lots of family things going on. I hope to be going again before the next new moon and will give a much more precise description of the issue then. -----Original Message----- From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak Sent: Saturday, June 26, 2021 12:03 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] AP1100 coming, least hassle plate solver? Hi Wade, Regarding the ASCOM driver, I tried it a few weeks ago with my QSI690What doesn't work? The binned image doesn't get created? Or, the plate solve of the image fails? -Ray
|
|
Re: AP1100 coming, least hassle plate solver?
W Hilmo
This is outstanding! I'm really looking forward to this.
toggle quoted messageShow quoted text
-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent Sent: Monday, June 28, 2021 9:18 AM To: main@ap-gto.groups.io Subject: Re: [ap-gto] AP1100 coming, least hassle plate solver? On Jun 26, 2021, at 14:46, W Hilmo <y.groups@...> wrote: So I have a Plan(TM) to improve the quality of life here. NINA 1.11 has the new Advanced Sequencer and, with it, a new plugin system. The plugin architecture is based on MEF and anyone can write one using the exported NINA frameworks that are on nuget. The plugin system is intended to allow people to create functionality that can be used in Advanced Sequencer as a sequence instruction, trigger, condition, or any other current or future type of thingy that Advanced Sequencer implements. This weekend, I made a plugin that runs APPM from within Advanced Sequencer. It will depend on the upcoming APCC 1.9 release. Here is an annotated screenshot of how this looks: https://i.imgur.com/AZR2cjd.png With APPM talking through NINA to get images, this means you can keep the camera connected in NINA even if it's being driven by a native/direct driver. Since APPM 1.9 will also be able to use ASTAP, it can now also plate solve using a freely-available app. With these two features, we can now have automated and unattended APPM model runs be done as a part of a NINA sequence. For NINA users, this completely obviates the need to run APPM under a different software stack (say, SGPro or TheSkyX) and the manual toil involved in switching things between the that and NINA. There's still some kinks to work out and some testing to be done, but I expect this plugin to be available in the NINA 1.11 plugin repository (which is also a new thing) shortly after APCC 1.9 is released. I'd like to extend a huge thanks to Ray for his patience and help in supporting NINA and ASTAP in APPM and I hope that automation such as this helps people consider using pointing models, or to use them more regularly. /dale
|
|