wimvb

After my main target for the night had set behind my observatory wall, and before the clouds moved in, I was able to capture 36 minutes of data on M43 and M42. I kept the single exposures short (30 s) at low gain, in order to preserve the Trapezium area in M42. Processed in PixInsight. To avoid ovestretching the central area, I combined three different stretches of the image with PixelMath. Then I boosted local contrast and colour saturation with MMT. As always: SW Explorer 190MN on a SW AZ-EQ6 mount ZWO ASI294MM-PRO with Optolong 31 mm RGB filters Red: 14 x 30s (7 mins), Green: 20 x 30 s (10 mins), Blue: 38 x 30 s (19 mins) With a little more drama:

Why not say 21 decimeters? It is a fairly round number without any decimals. And it sounds/looks huge. (Do I need to add an emoticon here?) Edit: Of course I do. Here goes.

A few extra clear nights allowed me to capture luminance for this target, some 40+ subs. Slowly the ifn is emerging. As chance would have it, after midnight tonight the skies cleared again. So with the moon out of the way and guiding between 0.65" and 0.7", I'm collecting luminance data. Guiding could be better, earlier this evening during a gap in the clouds, I measured 0.5", but the target is lower in the sky now.

Drawer tracks are mainly for indoor use. In a humid environment or one with a lot of dust, this can lead to problems in the long run. Gate tracks are designed for outdoor use. A friend of mine is also contemplating the use of drawer tracks for his micro-observatory. But he has ready access to them, so it won't be much of an investment for him.

Oh, guys. Stop complaining. (I better insert one here: 😉) At least we've settled on a standard foot. When the Swedish, 18th century shipwright Fredrik af Chapman wrote (and drew) his Architectura Navalis Mercatoria, he had to deal with three measures: Swedish, English, and French feet. The Swedish battleship Wasa (which sank on its maiden voyage less than a mile from where it was built) was found to be quite lopsided. In its wreckage, measuring sticks of at least two different units were found. Dutch and English carpenters had worked on the ship, and it is very likely that they kept to their own system of units ... Btw, the Swedish mile is the only non-standard unit conforming to the decimal system; it's a distance of 10 kilometers.

The recommendation for dithering with a DSLR is 12 pixels. When I dithered manually I went for 15 pixels, this way: Determine your pixel scale (arcsecs/pixel = 206 * pixel size (um) / focal length (mm) ) Set the hand controller to 1 x sidereal speed After the first exposure push the RA+ button for as many seconds as your pixel scale is. After the second exposure press DEC+ for as many seconds After the 3rd exposure: RA- for the same time After the 4th exposure RA- again Then in order: DEC-, DEC-, RA+, RA+, RA+, DEC+, DEC+, DEC+, RA-, RA-, RA-, RA-, DEC-, DEC-, DEC-, DEC-, etc This will give you a spiral pattern which will break the walking noise. To keep track of the movements, jot them down on a piece of paper. I did, and I believe I still have that piece of paper somewhere. This is what the registered sub frames will look like: https://wimvberlo.blogspot.com/search/label/dithering

Imo, if a galaxy has Ha regions, then adding them to an image will increase the quality of that image. The only thing you need to take care of is that Ha doesn't skew the colour balance towards the red. As a starting point, try the NBRGB script in PI to blend the Ha with red. You can also use PixelMath to add Ha to red. Kayron Mercieca (LightVortexAstronomy) has a tutorial on the how to blend. This is a more complex method (I think that the NBRGB script is based on it): https://pixinsight.com/tutorials/narrowband/index.html

With a CMOS camera, like the one in your signature, there is no need to take 20 minutes exposures. This is something from the CCD past. For RGB imaging up to 4 - 5 minutes at low gain should be enough, and for NB imaging you simply increase the camera gain and keep the exposures short (5 - 6 minutes). CMOS cameras work best with many, short exposures. So no, in my opinion you don't need a mount that will give you 20 minutes exposures.

Plastic lens caps can be almost completely transparent to IR light. I take darks with the window side covered with 2 layers of aluminium foil. This works for my ASI294MM

You might want to do more homework before deciding on this camera. I've seen discussions where people have had problems with image calibration. Especially flats in combination with NB filters seem tricky for this camera. Even I have had problems with flats and the ASI294MM, although that may have been due to edge reflections from my 31 mm RGB filters. Nevertheless, I find my stacked images never as clean as they were when I used the ASI174MM, and that is not just because the ASI174MM has a smaller sensor. The images are good and I can go deep, but the ASI174MM produced cleaner images, imo.

To clarify: you will get a list of devices that are connected to the Pi, as well as the usb ports in the internal hub. There should be one entry for the t7c camera. If that says ”120”, the firmware should be identical to the asi120.

Thanks Göran. The stars are already reduced in this image. We’ve had a lot of moisture in the air lately and most of the subs were quite soft with fat stars. I’m hoping for a longer period with colder air so I can gather more luminance. That should also increase the amount of details in the galaxies.

There certainly is a learning curve with Linux, but once you passed that, it works at least as good as more expensive Windows based systems. Only you can decide if the learning curve is worth it. For me it was, and I like the integration that INDI/Ekos or StellarMate offers. Does it work flawlessly every time? No. But neither does the more expensive Windows based SGPro package that a friend of mine uses.

Have you tried an RPi wired connection? Ie, using ethernet rather than wifi?

That's why I suggested biting the proverbial bullet and get a camera from a main stream manufacturer. I advise against updating the linux software during an imaging season. The situation and stability of software has improved tremendously since I started usin INDI, but new updates can still break things, or, as in your case, at least upset a functioning workflow. There are just too few clear nights to have to struggle with software issues that weren't there before an update. This is not just a Linux issue. Windows systems are just as prone to fail after an update. Because single board computers are so cheap, I always have a backup system ready. If I update software on one, and it doesn't work as expected, I can just plug in another computer and continue imaging. You can also just have a duplicate sd card handy, but having a second computer is a good insurance against hardware failures.

Galaxy group Mahtessian 266 in the constellation Pegasus. This interacting group of three galaxies consists of ngc 7769, ngc 7770, and ngc 7771. The gravitational pull between these galaxies have created shell structures and tidal tails. Also just barely visible in this image is IFN. Acquisition details: telescope/camera: Skywatcher MN190 with ZWO ASI294MM and Optolong LRGB filters Exposures: L: 48 x 2 minutes (I had collected 88 subs, but had to throw away 40 because of high clouds. I plan to collect more Luminance when the weather starts playing nice again) R: 54 x 4 minutes G: 63 x 4 minutes B: 52 x 4 minutes Total integration time so far: almost 13 hours Because of the low number of luminance subs, I combined all subs and created a synthetic luminance.

Very likely your best option. I've googled around and found very little usefull data on this camera. As you wrote, it's a zwo copy, but that doesn't necessarily mean that zwo drivers are compatible. I found one quick guide that refers to zwo drivers and sharpcap, but there's no guarantee that it will work with anything else. Here's info on how to update the zwo driver on a Stellarmate device. This is done from a command line interface. https://www.indilib.org/ccds/zwo-optics-asi-cameras.html

This lack of transparency bugged me when I used DSS a long time ago. If you have it set to accept x%, then on a bad night you get x% of garbage, and on an excellent night you get x% of gems, while 100% would still have given you an excellent image with better noise characteristics. My guess would be that signal to noise ratio or amount of noise is also one of the criteria.

Did you post your question on the INDI forum? Ekos/Kstars has a debugging tool that can be downloaded and installed. I haven't used it myself yet, but it's supposed to gather information in case of a crash. When you post your question and the debug log on the INDI forum, you should get good help there. As far as plate solving is concerned, I've found that it works best if you have installed the necessary as well as the recommended index files. I can't help you more than that, I'm afraid. But I'll keep following this thread with interest.

The middle one is ok. Personally, I would like to have it slightly more to the left, halving the gap between the diagram edge and the left side of the histogram, but that's a minor adjustment. If you do colour correction in the stacked image and in essence subtract the red glow, you subtract an equal amount from burnt out stars. They then end up with cyan star cores, irrespective of their natural colour. This is one of the problems with light pollution. You need to have an exposure time that burries the read noise (read pattern). If you can see horizontal or vertical lines in your subs, that is read noise. But otherwise you can keep the exposure time short to avoid burnt out stars. With low read noise cooled cameras, you can have shorter exposure times and keep better star colour, just because of this.

Back in 2016 I dithered manually, because I couldn't connect my dslr camera to a computer. One reason for the large dithering with non-cooled dslr cameras is that the images suffer from 'colour mottle' if not dithered enough. 'Colour mottle' is a term that Tony Hallas uses to describe large scale chominance noise. Cooled cmos cameras suffer less from this than dslr cameras, so there is no reason to use large dither steps. Now that I have a computer controlled cooled zwo camera, I set the dithering ta a larger than default value. It is not 15 pixels, but it works anyway, because my colour masters are clean and flat. Btw, if you set the dither scale in phd, it's the guide camera's image scale that is used. The dithering in the captured subs can be quite different.

Those subs look good, with the histogram to the left, but a small gap so you don't black clip any data. The subs from my cooled camera look like yours, with only the brightest stars visible.

This was with a Raspberry Pi and INDI & Ekos. I wanted to test a RPi 4 against a Rock64. The Rock sbc's have always peformed quite well, even though the Linux system isn't as mature as for the RPi. One thing I found out is that with a RPi, I don't need to use a usb3 hub. With a Rock64 I do.

If you got the funds, go for the eq6-R. It works great and can carry a lot.

Ok, that just happened to me half an hour ago. When I checked the rig, I saw that the telescope was trying to plate solve the obsy floor. For some reason, the dec clutch had come loose (probably a cable in combination with being too loose in the first place). Lucky enough, my remote rig is in my back yard. A friend of mine has his setup in the same obsy. I get regular evening exercise checking his rig. Remote operation seldom is.