JonCarleton

Steve, Yes, I am struggling with a new QHY camera and getting the color balance right is challenging. This batch of photos was taken using the auto setting for red and blue. I suspect "Otto" is a bit heavy-handed. I did try to calm it down in post, but apparently was not completely successful.

I finally got around to processing the images I took of Markarian's Chain. I centered on NGC4435 ("the eyes"). This is 200 "acceptable" subs of nearly 400, 60 minute images. Most of the "duds" were due to airplane fly-overs and clouds. I live under (though 60 miles distant) an approach path to Atlanta airport, so sometimes I get some spectacular jet trails. Most of these images were taken during the last half of March this year. The scope is a Radian Raptor on an iOptron GEM29 mount. There is a Raspberry Pi4 on the mount running all the fiddly bits via INDI drivers and controlled over WiFi from inside the house. The software was SkyChart (planetarium), CCDCiel (imager), ASTAP (plate solver), and PHD2 guiding.

I just mated my 10" collapsible newt (formerly a Skywatcher 250P GOTO) with an Skywatcher EQ6R Pro. I call the new creature, "Franken-Newt." It is a bit on the heavy side, but well within the mount's tolerance abilities. It required machining an aluminum losmandy-ish plate to attach to the front of the lower tube and a ring for the rear of the plate lower down the tube. The contraption is a bit of a chore to setup, but I works well. I have been imaging during nebula season with a very light Raptor rig that I can setup and tear down in a couple of minutes. But, it just doesn't have the juice for distant galaxies. After setting Franken-Newt up a few times now, I can see me missing nebula season in the fairly near future. Now I have the bones of an Alt/Az SynScan GOTO mount. I wonder if there is a market for that. It could attach to any 10" OTA if someone wanted Alt/Az performance and really marginal tracking with no real guiding option. Oh...and +1 for the lightweight stuff!

I had horrible guiding results with an iOptron GEM28 that ended up due to a polar alignment problem related to iPolar. Run the Guiding Assistant in PHD2 and see if it agrees with the polar alignment. The problem, in my case, was the initial calibration of the IPolar software was way off, so it reported aligned when it was not at all. I polar aligned using a different method and the problem vanished. Later, I recalibrated iPolar and life is now grand.

I like Siril for stacking, but I don't find it particularly "strict" when it comes to excluding marginal images. I tend to use the grading in ASTAP first and exclude bad images, then stack in Siril. Still, gotta love M101!

Actually, (being allergic to Windoze) I typically run CCDCiel in Linux. It was the guiding routine in CCDCiel (using the main scope) that put me back right. I have also had very little help or useful information from PHD2 Guiding Assistant, but used it as an example (though I did try it). I think the drift alignment tool is probably reasonably OK, if you have all night to run it. Interestingly enough, with a good polar align, PHD2 Guiding Assistant doesn't bark quite as loud as it once did.

My guiding graphs always looked like an earthquake monitor during an volcano eruption. After leveling the base and doing the alignment with the integral polar scope, not only does my alignment match exactly the result in PHD2 drift alignment (using the main scope), my graph now looks like the patient died. In this case, a happy result. While you are correct about a -proper- polar alignment correcting an off-level mount, In my case, the lack of a level mount fouled up the calibration of iPolar, which became the root cause of my perpetual misalignment. After leveling the mount, the re-calibration of iPolar yielded very reliable results. A detail I should have explained in the initial post.

I was once told in passing not to trust the OEM bubble level on equipment. It was a long time ago, and not really related to astronomical equipment. HOWEVER, it apparently applies to just about anything and ESPECIALLY astronomical equipment. Ever since I bought my new mount, I have had issues with guiding and less than spectacular results with plate solving tracking to a target. If I fiddled with it enough, it would work in a "barely acceptable" fashion. I tried everything I could think of (even some really stupid ideas). My only clue was that polar alignment with a polar scope to perfection did not lead to good polar alignment being reported properly elsewhere in the sky. PHD Guiding Assistant, for example, would always report up to 300 arcmin off for polar alignment once I left the pole. Other software that did not use the mount camera also reported similarly bad polar alignment. When I did a polar alignment with software that used the main imaging scope, rather than the polar scope, the result in PHD away from the pole was also bad. Not identical, but still very bad. For a while I considered that my mount was just a dud. The attached picture shows the problem. Prior to actually checking with a level, I had always meticulously leveled the mount with the OEM bubble level. Long story short, once I started leveling the mount with an actual working level, everything began working as advertised. It kills me to think of how many hours and imaging nights I wasted chasing such a simple problem. May this post help prevent duplication of my ineptitude in this matter.

+ 1 for external WiFi Dongle and +1 for adequate power, and a big, flamboyant +1 for testing FIRST with ethernet cables. The Pi uses a "printed on the PC board" antenna for default onboard WiFi. Not ideal. The only time I use the onboard WiFi is with a Compute Module 4 on an I/O board, and then I use an external antenna. That has better range, and since the boxes for most I/O boards for the CM4 are all metal, you -must- use an external antenna. The only thing I have used the stock onboard Pi WiFi for (without external antenna) that worked well was a setup where I used it to do the connection over WiFi to the mount WiFi hotspot. It was able to manage the half-meter distance very reliably, and it reduced my need for USB cables by 1 on that rig. I used an additional WiFi dongle to communicate with my desktop via the home network. As an aside, since I brought it up indirectly, DO NOT try to use a mount's hotspot as a router to connect your Pi and your Laptop/Desktop. It -will- work, but mount hotspots typically have dismal throughput and pushing images through that tiny pipe will not be pleasant. They are designed to manage the minimal traffic involved with operating the mount. Speed or performance is not a requirement nor design consideration.

I have a Skywatcher 250 FlexTube GOTO and have used it to good effect imaging. You have to keep your exposures low ( less than 20 seconds) due to the Alt/Az mount not handling rotation. You will also have to crop out rotation in long sessions. But overall, you can get some REALLY good shots, especially of distant and dim objects. Tracking isn't the best with that rig, and I haven't found guiding software that is much use, but it is still manageable. I tend to plate solve the image, let the SynScan app muddle along with its tracking and re-center via plate solving as necessary. ....and believe me, I have tried every piece of software for every operating system available to try to get consistent, reliable guided tracking, without reliable success for that setup.

Brilliant shots as always, both of you! Alacant: An EQ mount, I suppose, for the reflector? I have a 10" Dob, but the Alt/Az mount is worthless for guiding. Unguided, I can only count on 10 second exposures. Of course, I only shoot 60 second exposures on the wide field EQ rig. I get so many jet trails and satellite trails that long exposures are just begging for a throw-away. Probably due to the current political situation, but the other evening I had one 2 minute image with 13 jet trails in it. one low altitude commercial airliner and the rest probably military. Alas, I live directly under one of the approach paths to Atlanta and there is also a military air route on the charts that goes right over my farm.

I take a different approach, in that I tend to get a large number of bad images, due in part to wind, and in part to being directly under a jet approach to the Atlanta airport (one of the world's busiest). I use ASTAP for its ability to grade images and allow me to eliminate that bad ones without having to view each fits image. My current image size is 39M, and every fits viewer I have ever used is slow with images that large. I do view each one manually that passes the grading process to be sure before post processing, but there is no point going through all the ones with clouds, jets, wind jitter and other issues. ASTAP will allow me to set a grading percent and rename the fails to .bak for easy deletion. I use ASTAP for my plate solving anyway, so it isn't as though I am adding additional software. And, although ASTAP's grading process is pretty good, it does not eliminate photos with satellite or meteor trails. In general, these disappear with a large number of images to stack, so that isn't really a serious problem. ASTAP will stack and does a fair job, but Siril does a better job and has more bells and whistles, so I do the final stack with Siril. I'm still using StarTools for post. I probably should switch to PixInsight, but haven't yet.

I was referring to the PAE in the GA window that updates during the GA run. I know I should have posted logs. I'll put some together when there is clear sky again...looks like next week.

Thanks for your reply. I'm a pilot, and accurate lat/lons are part of my "religion." I will check them again to be sure, but I don't think that is the issue. I would suspect my Plate Solving would get wonky if the location settings were off, and Plate Solving has been excellent. I have several options for polar alignment other than the iPolar regimen. PHD2 has several and there is a pretty good routine in CCDCiel, that I use for imaging. I am beginning to see that I will have to try a few and see what matches and what doesn't. If iPolar is the "odd man out," then at least I'll know, but I'll still wonder why.

I bought a new GEM28 iOptron mount earlier this year. It seems to work pretty well and I don't notice any specific mechanical issues. However, guiding with PHP2 has been less than spectacular. Along with that, sometimes it is pretty good and other times pretty awful. Sometimes a target at one end of the sky works well and another later that same evening just doesn't. The polar alignment is being done with the iPolar "Windoze" program connected to the in-mount iPolar scope. This, by itself is a sore spot, because I had to buy a little Windoze box to run the !@#$ iPolar program. The sole Windoze box in my "collection." I plug it in, do the polar align, then unplug it and put it away in a box in the closet and proceed happily in Linux. I know that the iPolar camera will operate marginally with a V4L2 Linux driver, and I could use a Linux program, but given I believed the problem was alignment, I have been trying to limit the variables. And the Windoze/iPolar solution was "the factory recommendation." But, I digress. A few nights ago, I spent quite a lot of time with PHD2 Guiding Assistant, trying desperately to get a guiding plot that didn't look like a wave of tsunamis. I couldn't help notice that, though iPolar results were rock solid and spot on for polar alignment, PHD2 Guiding Assistant was reporting a very significant polar alignment error (400+/- arc-min). So, I did a Drift Alignment in PHD2. The Azimuth was pretty much on target, but the Altitude was very significantly off. In the end, after the Drift Alignment, I was able to get fair guiding (not wonderful, but fair enough to image). Later I checked alignment with iPolar, which reported, to no great surprise, that the Altitude setting was in need of significant adjustment. I need more testing to be certain, but I am thinking that since I guide with PHD2, I should use its Drift Alignment and chuck the iPolar regimen. The problem is the mystery. I don't care much for mystery. Is it possible that the factory-mounted internal iPolar mount camera could be misaligned? Is that even possible? Or is there something else going on that I haven't considered? The latter is always a reasonable possibility. The setup is a fairly straight-forward all-stock GEM-28 with mount on the stock tripod on a solid foundation with a Radian Raptor and a SVBony 30mm guide scope. Linux Ubuntu 20.04 on a Pi4 8G with INDI server for the mount, cameras and focuser. PHD2 running local on the Linux box that runs the INDI server. Just as a FYI, I did do a guiding session using that little Windoze box with ASCOM drivers and PHD2 Windoze version as a test some weeks ago. The results were similar if not worse, though I admit to some bias in that opinion. Thoughts?

Many cameras go through an initialization during the connection phase. I have seen instances where using the wrong driver or a broken driver can cause a camera to malfunction and continue to malfunction until it somehow receives a "master reset" command...assuming it isn't so confused that it can't accept the reset. Most programs start the connection process with a master reset, then apply the settings the user specified. Other programs take the approach, "It was setup fine last time I used it, let's just configure any changes and move ahead...no real need to waste time with a reset." The latter approach, while efficient, can be subject to issues if the camera "wasn't really setup properly at the end of the previous session." Something as simple as a cable juggle during an initialization or even normal operations can confuse a camera. Usually, this is cured by a restart, expecially if the program using the camera does a master reset on connection. ....or in backyard mechanic terms, it got stuck, and a good kick from another source unstuck it.

AstroDMxCapture isn't as widely used, but the programmer is very dedicated and did a lot of work with SVBONY when their cameras first came out. It is probably because of AstroDMxCapture that the SDC exists for SVBONY cameras. I am a Linux user, so I have never used SharpCap, but I have don't a lot of imaging with AstroDMxCapture, and it works well. It is especially good for planetary imaging in the video mode. The Linux and Windows versions of AstroDMxCapture work exactly the same and use compiled native drivers instead of INDI or ASCOM. If you do happen to have a problem with AstroDMxCapture, they are very good at responding quickly. My guess on your issue is that something got wonked in the camera initial presets. Since AstroDMxCapture uses a specific native driver, it does a grass-roots initialization. This likely "de-wonked" the camera....or at least set it back to factory initialization settings.

I've always had good customer service from SVBONY...and the folks at AstroDMxCapture as well. Good luck with the 205!

I am having a similar problem with a GEM28EC using PHD2. I have the exact same result using Linux/INDI or Windows/ASCOM. Per manufacturer recommendations, my drivers turn off the PEC chip. The result is marginally acceptable guiding with occasional spikes and non-specific intervals. Best guiding is TOTAL RMS error of 1.29" with typical "stable" guiding of 1.5" over long periods separated by random spikes up to 6.0" The spikes occur 1-3 in a batch after which the mount settles down again. All the testing has been done in areas where a meridian flip wasn't going to happen any time soon. Polar alignment was spot on with iPolar (although PHD2 Guiding Assistant reports it as very slightly off). Reducing the AGR and MinMov helps most. I'm currently using 75 RA/50 DEC and about half what Guiding Assistant recommended for MinMov. Guiding Assistant isn't much real help in this instance. I sent PHD2 logs to iOptron at their request, but haven't heard back yet.

Sorry you are having an issue. Contact me if you have questions.

Best way to test stuff like that is to load the driver at the command line: indiserver -vv indi_wmh_focuser then manipulate it via a python program called indigui with which you can fiddle with the parameters and move it back and forth independent of any real client program. It comes as part of CCDciel, but is a stand-alone program.

..and another thing (and yes, someone just needs to tell me to hush).. In EKOS, there is a method for listing "unfound" drivers. It is a bit "twitchy" but basically works . It is called "Custom Drivers" and is the button in EKOS just right of the "-" button for Profiles. It is "twitchy" because you have to add the driver info, then quit Kstars/EKOS, then restart KSTARS and the driver "should" appear in the list. I have had to repeat the process of adding the driver and restarting on occasion to get a Custom Driver to appear (as I said, "twichy"). You -may- be able to add a path in the executable field, but I haven't ever tried this, as the symbolic link always seemed a better idea....more "UNIX-ish."

Gad! Sorry for all the edits. I apparently have lost any typing skills I once had.

There is a thread on INDI Forum where we worked through all this stuff after Kevin wrote the driver. It is a lot to muddle through, but it contains the details: https://indilib.org/forum/focusers-filter-wheels/6038-indi-focuser-driver-for-waveshare-stepper-motor-hat-for-raspberry-pi.html#45918

@Dazzy: I live in NW Georgia. Nights are hot in the summer, and heat kills a Pi4, even with a fan and often is robs power. Then too, I load mine up with tasks and gadgets, but I had issues even with minor loads with the temp warning coming on after about an hour on both scope setups. And yes, just turn off the switch on the HAT board and provide 5v @ 3A to the main board. Two supplies, as you still need 12v to the HAT to power the motor. Also, and you could check the Astroberry Driver to see if it does this....The original WaveShare HAT driver turned the motor on whether it was in use or not. It got really hot (not so good). Later versions turn the motor off on INDI connect and on then off for each move. That keeps things nice and cool.