JonCarleton

I just looked at my notes from back then. Another issue with that driver is the need for the stepper delay to be set at least at 50 us. Any less and it won't turn.

I'm glad the Astroberry Focus Driver works for you, that's interesting. I use the indi_wmh_focuser with good success on both my scopes. The trick is to download it from github and compile per the instructions there, but the compile puts it in the wrong place on your machine. It installs the executable in /usr/local/bin instead of /usr/bin, where the rest of the indi drivers live. The easy solution is to just put a symbolic link to the compiled program: sudo ln -s /usr/local/bin/indi_wmh_focuser /usr/bin/indi_wmh_focuser If that isn't the issue, get back in touch with me and I can help you sort it out. You can get away with running the Pi from the WaveShare 12V HAT port =if= it is a Pi3. It will boot a Pi4, but you'll get perpetual low-voltage alerts and it can fail on occasion. I run my scopes with Pi4 8G boards, and it just won't work. The USB ports are underpowered to start with and cameras will fail if I don't provide solid 3 amp power to the main power port. I seem to remember when I was sorting the power issues out that I had to turn off the HAT "supply power to Pi" switch as well to get things to stabilize.

Is than an Arduino board and are you using the INDI Arduino driver? I have a similar setup that uses the Waveshare Motor HAT for the Raspberry Pi with the indi_wmh_focuser driver, but I have always wondered how the Arduino driver compared. I have considered moving the focuser off of the Pi, as it runs =everything= on the scope and occasionally has power issues. If I ran the Arduino HAT on a separate Arduino board with power supply, that'd remove that load from the Pi.

Don't even start....we keep getting hurricanes. Cleverly timed so that =if= we get a clear night between storms, it is during the full moon....and there's fog. 😭

@Steve: I am the precise opposite of a Windows fan/user. The =only= application I =ever= run on a Windoze box is iPolar. I will drop it in a heartbeat the moment I get good at polar alignment in KStars, CCDciel or PHD2. For now, PHD2 is too slow, I haven't tried the KStars method yet and CCDciel didn't work well the first time I tried it, though I like CCDciel very well overall and may just get used to their process. When I got my GEM23EC, it came with iPolar. I bought a little NUC -solely- for the purpose of running iPolar....the quick and dirty way to get up and running. I did the initial run on the NUC with a HDMI screen at the scope. I had the full compliment of ASCOM drivers for my setup on the NUC, thinking it might be a reasonable backup. That's when I had my "RTFM" moment as the iPolar setup aborted the configuration run and said it was ready to go. However, even though I was running the Windows version of software I typically already used (CCDciel, SkyChart, PHD2), I wasn't happy with the way things worked when I got back into my comfortable office and ran the Windoze box remotely, so now I only bring the NUC out and connect it to the iPolar scope for polar align and then put the NUC in "safe mode" (unplugged and in a box in the corner of the closet). Question for you, since you are running an iPolar mount: I'm not particularly pleased with the PHD2 performance of my mount. I blame the mount, as I got pretty much the same performance using PHD2 in Linux and the same version PHD2 in Windoze on the NUC. My total RMS error generally hovers around 1.2 with occasional spikes at random intervals from as short as 30 seconds to as long as 5 minutes. Are you having any issues like that? Note that I turn off the EC chip when using PHD2 as recommended.

@Steve: Yep. That's pretty much my procedure. Good that you mentioned check after locking it down. That's my nemesis. I always seem to fudge the alignment tightening things down. That's why I was wondering about the setup. I've seen guys use the iPolar on a non-iOptron mount with the camera sitting up next to the guide scope. Or, using a guide scope camera instead of the stock iPolar camera....which will work sometimes with the right sort of webcam if the program doesn't bark. Alignment is generally the issue in those situations. By the way, the calibration procedure will sometimes automatically abort if the mount is powered on and the program can determine a recognized iOptron mount type. It will then default to the specs for that particular mount type (we hope).

Hmmm. What sort of mount is this? If not an iOptron mount, is the iPolar camera at the center of rotation?

Two things are important with iPolar. 1. The initial setup; and 2. The dark frame. After that, the only thing you can manipulate is the exposure. I have never had any luck with exposures less than 250ms and generally go to 500ms for a proper solve. Your software does a setup and calibration the first time you run the program. It can be waiting for data you need to enter or can find it by internal polling. Sometimes what it finds by itself isn't wonderful and you need to override the settings. I would recommend re-doing the initial configuration, or worst case, uninstall and reinstall and be very careful of what it tells you on the initial program run. If you reinstall, disable Internet connectivity and don't turn on the mount until after a successful polar align. It generally works pretty well and predictably if the settings are right. Light pollution could be an issue. I have only used mine in a Bortel 4 environment.

ALPACA seems a backward project to me. It lets a Linux or MAC connect to a computer running Windows and ASCOM drivers. I can't imagine ever wanting to do that. I suppose it might make sense if you were running a Windows-based NUC box with drivers on the telescope, but then, I'm perfectly happy with Pi's running Linux doing my device control. Linux/UNIX was designed for distributed computing from the outset. Now, running a Windows box for overall operations with remote Linux computers running INDI drivers...that makes since if one is a a Windows user. But, Windows software with that capability, and not just KStars, has been around a while.

When I look at the source code for my Linux INDI driver. I see the tracking sending adjustments to the mount. When guiding is enabled, a correction received from the guiding software is added to or subtracted from each tracking adjustment. The total adjustment (corrected) is then sent to the mount. I have not seen the ASCOM code, but given that my comparison of the PHD2 graphs for ASCOM and INDI are virtually identical, I'd say ASCOM does the same thing. I did a night of Windows software control with ASCOM when I bought my iOptron mount to verify that the Linux INDI driver for the mount gave the same result as the iOptron-provided ASCOM driver. Overall, both drivers were more or less the same, with the exception of how the Meridian Flip was performed. But, I set it up so the mount firmware performed the flip and told the driver software to mind its own business, so differences between INDI and ASCOM didn't apply for the only difference I was able to find.

Your clarification is mostly correct. As the previous message implies, USB 3.0 is a plus. USB2.0 will do for some cameras, but it will be a slight bottleneck. No real processing or graphics processing required for the imaging, but a slow harddrive will be a bottleneck. Once again, if you have USB3.0, a fast SD chip in a USB3.0 plugin works pretty well. That will make it easy to take the data to your MAC for processing. Both StarTools and PixInsight have versions for MAC. I've had good luck with StarTools, once I got to know it.

+1 for 3.0 USB ports. These can also be a solution for slow mechanical harddrives. Some of the new external SSD 3.0 USB drives can keep up pretty well with any image write load, even with a fairly slow imaging computer. Also, running a camera on a 2.0 USB port is just asking for trouble....unless, perhaps it is just a guide scope with a mono camera.

I started out with the SVBONY cameras and still use them for guide cameras. Sometimes I use the SV305 for planetary work. The SV305 is a good camera to have around. The SV205 is also pretty good, but the SV105 is basically just a webcam in an astro box. It is a pretty good little webcam, but very limited. Under Linux, you have to use the generic V4L (Video for Linux) driver, which although stable, has limitations. I've never used the SV105 on a Windows platform, but expect the same with an ASCOM driver. You might give a look at AstroDMx_Capture instead of Sharpcap (Linux or Windows). They did a lot of work on native drivers for the SV305 when it first came out. Any old laptop will do for basic imaging and scope control. However, once you get a wad of images and need to process them, you will find that is where the heavy lifting starts. Something with 8G or more ram and a separate graphics processor (preferably NVIDIA) is a good start. You -can- stack and process with a less, but you will become one with the concept of "infinate slowness." Ideally, a slow, older laptop with a decent display (I use a raspberry pi, actually) for the imaging bit and a real kicker desktop for stacking and processing.

I had a toilet paper cardboard center tube on my guide scope more than a few times. Alas no picture. Once the dew soaks into it, the "device" becomes a one-time use item. Fortunately, I have a ready supply of replacements.

I've noticed something on PHD2 YouTube videos. Apparently, if you set the scale all the way up to 16, it really smooths out the graph!

I've used the SV305 to good advantage, especially for Moon, Jupiter and Saturn images. It also does a reasonable job with bright nebulae such as M42. Alas, I use it primarily as a guide-scope camera now, where it does an exceptional job. I don't know what you plan to use for imaging software, (as I run Linux), but if you get stuck finding a driver, AstroDMx_Capture does a good job running the camera with its native drivers. The windows version of the AstroDMx_Capture works just like the Linux version. Easy to use and uncomplicated. There is, of course, a Windows ASCOM driver for the camera now, so all the doors are open.

Yep, I agree...amp glow. That looks like it. And yes, I take much longer subs with the refractor than I ever did with the reflector. The 250P is an Alt/Az mount, and you can't really do more than 30 seconds without a rotator or you get smiley stars. The refractor is on an Equatorial mount and I am doing longer exposures. That would be the cause and effect managed. I did find, fortunately, that calibration frames mitigate the problem to the greatest extent, as I mentioned in the original post. Alas, too bad it is more of a permanent issue rather than one that can be fixed with equipment....unless I buy a cooled CCD. I take my flats and bias calibration frames at the beginning of each session, and darks at the end. That method has seemed to work best for my "uncool" cameras. Thank you all for the information. I really appreciate it!

...and for those who don't want to download the full image and just want a peek, this is a single sub @60 seconds Radian Raptor with ASI178MC, no filters, no accessories excepting an adjustable backspacing adapter (required for focus), minor autostretch to make the problem visible for this example image.

Yep...should have provided one. This is from the other evening. Hazy conditions with bright moon just above the horizon (hence the lousey sub). However, this is typical for what I generally get with respect to vignette. Calibration subs clear most of it in post. M33_60s_1x1_26.1C_20210818_065040_190.fits

I've been taking some pretty nice images with a new wide-field refractor I recently purchased. However, more often than not, I am getting light areas in the corners. This is the same camera (ASI178MC) I have previously used with a reflector without issue. I suspect backspacing, but focus has been spot on. If it is backspacing, is it caused by too little or too much? And if it isn't...what else might cause the issue? I have a very rural dark site and no real errant light issues. It wouldn't be difficult to do some testing and figure out if it was a back spacing issue =IF= ever we got another clear night. This week was looking pretty good until we got a hurricane....followed by a cold front. They do say it'll clear up in a week or so...when the moon gets nice and full (mumble). I should mention that I'm not using filters. Just a the camera connected to the scope focuser via a small, adjustable spacer set more or less at the manufacturer specs for backspacing...though it could be a small fraction off one way or the other.

@Olly: Thanks. That explanation makes sense. I actually have a large LCD panel that I purchased several months ago but never used. I'll try it. @Alacant: Artistic restraint? I don't seem to have one of those. I will, however, see if I can find one on eBay. Meanwhile, I'll take a look at the tracking/database thingy. I used to be pretty good at extracting nuggets from log files and the like. I have -tried- to rein in the urge to over-control and was warned against straying too far from the defaults in StarTools when I first started using it. I am, at least, gratified that nobody (yet) has mistaken my attempt at astrophotograpy as a still life image of asparagus. By the way...what is "HTH" in your closing?

Thanks! I see you got the larger stars under more control...something I struggle with a lot. I have tried the Shrink Stars section, but haven't been exactly dumbstruck with the results. Likely, I am not operating it properly. It is clear I just need more practice with StarTools. If ever we get another clear night, I may just get an opportunity to do just that. And yes, I agree on naming convention. I favor "Osmandian Protolapse," on the premise that understanding is counter to singularity.

I mostly use GIMP for sizing and transferring to other formats and sometimes minor cropping. Here's another go at the data with less stomping around and gnashing of teeth. I found that some of the problems were related to a couple of tree shots that somehow managed to get into the sequence. Sometimes I can get ahead of Siril doing exclusions and it will skip some for which I know I clicked the exclusion box. Still needs more data, but this looks a bit better. And yes, StarTools bites back if you get heavy-handed. I have attached my M20_stacked.fit for those interested and added a "tree image" because a picture is worth...um..something or other. M20_stacked.fit

Oily, Please do not pull any punches. I am a rookie and make lots of errors. Corrective suggestions are a help. I am still getting used to the Raptor with the ASI187MC. It doesn't act quite the same as the Skywatcher 250P setup and the autofocus seems to require more iterations for a reasonable result. I tried to get too much out of too few Lights with this image and perhaps got in a bit of a hurry to post. I suspect there may be some "vaseline" effect resulting from the synthetic drizzle in Siril and the reversal via BIN in StarTools. Or it could be all coming from StarTools...I am probably being a bit ham-fisted in my StarTools operations. The individual subs look OK for focus, even when zoomed. However, I am getting some guiding/tracking motion on longer exposures. I am going to have to explore the mount PEC training, I think, as the GEM28EC is supposed to be better than that. I did not use flats. My limited understanding of flats is that they were primarily for removing dust motes...a problem I do not yet have.

I actually got two clear nights in a row! The night before last I got a fair Eagle Nebula, so last night I went for the Trifid (M20). The plan was for 100 shots at 60 seconds. The execution, after review during stacking, yielded only 46 good subs. This, due to 1 satellite pas, 1 airpane and a whole bunch of tree-limb-impaired images. I have this really nice, silver maple that is in its full glory at the moment. Alas, the upper branches were just a bit tall. Still, I got 46 @ 60 seconds. Radian Raptor, ZWO ASI178MC, PHD2, CCDciel, INDI drivers on a Pi4 Linux Ubuntu on the scope. Processed on a Linux Ubuntu AMD64 desktop with Siril, StarTools and GIMP.. There seems to be a light area in the right upper corner that I should have addressed in processing. Odd. Can't think where it came from. I am in a Bortel 4 area and the moon was not out yet. No neighbors close buy. A mystery!