wimvb

The photometric colour calibration tool in PI reports stars that are not in their correct position. I wonder if this feature could be put to good use? Not just fir supernovas, but also for detecting minor planets/planetoids

Whenever I see artefacts like those in your image, I slightly increase the bright deringing setting in deconvolution. This usually helps. Only because I know what to look for. It wasn't anything obvious.

That turned out very nice, Göran. Did you use deconvolution? Some of the stars and details in the galaxy indicate that you did.

Nice image. I like the variation in star colour, and the blended dark and red of the nebula. As far as the black point or "neutral background" is concerned, you can take whatever section of the image that you like, as a reference. Sometimes I look at someone else's image of the same target to find a suitable reference point.

Yeah, brittle power cables that mess up guiding if you're into AP. Or light pollution aka Aurora. Välkommen, @Rocket Stars.

Every pixel has a small offset (bias) in the electric signal when it's read. Moreover, this offset can vary between pixels, creating a so called read pattern. The signal coming from every pixel in a sensor consists of photons + dark current + offset. The first two of these are time dependent, offset isn't. For short exposures, such as flats, the second (dark current) is much lower than offset, and can often be ignored. But if you don't subtract the offset from your flats, your images won't get calibrated properly. This usually shows itself as a circular pattern similar to vignetting. For completeness; if you let the stacking software scale dark frames (eg taken at a different exposure time than the lights), these will also need to be bias subtracted. Otherwise the scaling won't work properly. In a perfect calibration work flow, you would provide lights, darks, flats, dark flats, and bias frames. Shortcuts are: leaving out dark flats if the flat exposure time is short, or leaving out bias frames if you don't scale darks. In my workflow with a cmos camera that has amp glow, I use lights, darks, flats, and dark flats, but no bias, as I don't scale my darks.

For dslrs, flats may be the most important of the calibration frames. You will also need bias frames to calibrate the lights and flats. There is no general recipe here that always works. You will have to experiment.

I agree with @HunterHarling on this one: both images could use more data. More data is always the best noise reduction you can apply. As is, the galaxy is still very faint in your stacked Andromeda image, as is the reflection nebula in your M45 image. If you're shooting from a light polluted site, you also need a longer total exposure time to reduce the sky noise.

That's a very nice ngc185. To show its extent, and define the dust lanes, it could use more data. What method of colour calibration did you use in Pixinsight?

A rule of thumb is to dither 12 - 15 pixels when using a cmos camera. Since your camera isn't cooled, you'll need a lot of exposures to reduce any noise. Especially if you're imaging from a light polluted site. Colour mottle can be reduced in post processing, but at the cost of colour loss in the faint nebulosity. More data is always the best recipy for noise reduction.

100x5 mins, 8+ hrs, that seems mildly optimistic. How long is your astro darkness each night, Gina? We only have about 2 - 3 hrs, but I'm still building my obsy, so no AP yet. Otherwise, nice to see you imaging again, Gina. That can become a cracking cygnus wide field, even with less than 8 hrs per filter.

As I wrote a few minutes ago in another thread; the ASI174MM-Cool has been discontinued. But afaIk, the qhy cooled version is still available. The Altair Astro 174M only has fan cooling.

The 174MM-Cool has been discontinued. What does that tell you? 😉

Mine is the cooled version. I wasn't aware the uncooled version has this short exposure time limit.

0, I believe. In that case, 300 s exposure as you wrote in another thread, is about the longest practical. I've more or less settled on 120 s at gain 20 for L, and 240 s for rgb.

Excellent. The 174 is a nice little camera, isn't it? With its large pixels, it works best at longer fl. It's still above 1"pp at 1000 mm. What gain did you use?

Disregard my previous post. I've been doing a little more thinking on this. The problem with ST4 is that it's not a well defined standard. The ST4 port on a mount has 4 pins plus ground. As far as I understand it, a pin (RA+, RA-, DEC+, DEC-) is activated when it gets connected to ground ("short circuited"). This will in turn activate the RA/DEC motors. A few years ago I designed a ditherbox that connected to my EQ3 mount in the same way as in @kman42's circuit a few posts back. The transistors in the output of the optocoupler close the circuit for each ST4 pin. A camera can have the same configuration internally. Again, as I understand it, it is the mount that provides the voltage/current on its ST4 port. Therefore, the ST4 port in a camera will most likely also have an internal optocoupler, where the transistor is the output pin. If so, you can just connect the camera directly to the Arduino, which has its pins defined as INPUT with the pull up resistors activated. This link may be relevant: https://www.cloudynights.com/topic/445303-anyone-ever-make-an-st-4-port/ If this is correct, the diagram that @Dr_Ju_ju posted shouldn't work. The ST4 port of the camera has no voltage on its output to drive the LED in the safety optocoupler, and the transistor in the optocoupler will always be in its off state. Personally, I would just test it with the Arduino. Ie, I would connect one camera ST4 port pin to an arduino input. Activate the internal pull up resistor and blink the built in led whenever a guide pulse is received. DISCLAIMER: There is a small risk involved of course, which you may not be willing to take. Worst case: the ST4 port of your camera may die. 2nd worst case: an arduino input may die. Best case: it will just work. So, proceed at your own risk.

The circuit you have is indeed for sending data ('move' signals) to the mount from an arduino. AfaIk, historically ST4 consisted of relays, just on/off switches. I think that you should connect a voltmeter to your cameras ST4 port and read the voltages for signal /no signal. Eg connect the camera to phd2 and use manual guiding. Then issue guide commands of at least 1 s while measuring the ST4 output. If the voltage is only 5v, you can safely connect the cameras ST4 port to arduino inputs. Otherwise you can use opto couplers. Basically as in your current circuit but with the optocouplers pointing in the opposite direction.

They can't. In your circuit, the arduino and optocouplers are used correctly as outputs. The rj11 would go to the mount. You need to have separate inputs on other arduino pins.

Yes. Power comes through the pull up resistor, either internally ( @pete_l's response) or externally connected to 5 v.

If the output of the optocoupler is connected to an arduino input, you also need a pullup resistor cpnnected to 5 v.

Uk is in a different time zone, Göran. 1 hr + 20 minutes now 😉

For a pier you want something sturdy. Since you're probably not going to carry it around, choose the stiffer and heavier material. Can you afford this? https://www.metals4u.co.uk/mild-steel/c6/tube/c2239/tube/c56/152.4mm-x-3.2mm-(6-x-10-swg)/p2356 Or maybe not relevant in your situation

Oag with a hyperstar? That seems an awfully large obstruction. Btw, @gorann had trouble finding a guidestar with the asi120 + zwo oag on a Meade 14" at native f-number. He's switching to a lodestar. This may be relevant for you.