wimvb

I had a go at your original data with PixInsight. The process I used enhanced reflection halos which I haven't corrected. They can be reduced with an appropriate star mask.

In principle, super pixel deBayering could be done in the camera, it just need a processer to do so. If the calibration frames are treated the same way, then it would still be possible to calibrate and stack as normal. (This is equivalent to processing (lossless) jpeg images from a dslr.) But in reality, the sensitivity in the colour channels is different, and the monochrome image you get from binning RGGB data will be weighted by the transmission characteristics of the dye that is used in the Bayer matrix, as well as the QE of the pixels. If 3x3 binning is used in an OSC camera, these colour differences may actually make it into the final monochrome image, since some binned pixels will have more green, while others will have more red or more blue, depending on the position on the sensor. I would want to see the result before I'd be convinced that this actually works, as this kind of binning could very well lead to Moiré patterns. But maybe we're digressing from the original post. I probably should have clarified that, rather than just imply it.

You can use this image as L in an LRGB process. Just stretch the original image using arcsinh stretch and boost colour. Then blur (mlt - 2 layers, or convolution) and apply LRGB combination.

Actually... You can't bin a colour camera in hardware due to the Bayer matrix. But you can do it in software during the calibration process. This is called superpixel deBayering, and the colour information of one 2x2 pixel group (RGGB) is used to cleate one colour pixel without interpolation. The only advantage that I know of this technique is to lower the resolution of an otherwise oversampled image, giving a more realistic pixel scale and smaller files to work with.

The cc to sensor distance should be 55 mm and is achieved by the t-ring that attaches it to the dslr. For most dslrs, the sensor to flange distance is 45 mm, and the thickness of the t-ring is 10 mm, giving the correct distance. This distance is not as critical as eg a field flattener's. Unless you have more rings/filters in your imaging train, you should be fine. The colour cast may be due to light pollution, exaggerated by the image conversion software. My favourite raw conversion software is Rawtherapee, which is free and available for windows, mac and linux. On sw telescopes with the standard focuser, locking focus can lead to focus shift. One way around this is to use a motorised focuser, where the holding torque of the motor will keep the draw tube in place. Hope this helps.

That's getting along very nicely. Will you add another 12 hrs, or continue on your Sadr mosaic? Add colour to that perhaps?

Generally, the DS are the imaging versions of the skywatcher newtonians. DS stands for dual speed and refers to the focuser. I have used the 150 P-DS on an eq3 goto with aluminium tripod, and in my opinion it's undermounted. The eq3 has a load limit of 5 kg, which is taken up by the scope only. You have no margin for camera, guidescope, etc. That being said, with some tlc, attention to balancing, and beefing up of the tripod, it's still a nice setup for a beginner. When you outgrow it, you can use the mount for a light weight grab & go setup with a photo lens and camera. The 130 P-DS has a shorter fl and is somewhat lighter than the 150 P-DS, so probably easier to guide. I believe that the DS models are also slightly shorter, so it's easier to reach focus with a camera. Not sure about this, though.

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.

When I did the benchmark test, I got swap times twice the cpu time. Clearly, for me it makes more sense to look over my swap directory and RAM configuration before investing in more CPU power. All I'm saying is that if PI is slow, a faster computer is the obvious solution. But by that I mean both faster hardware and an optimised configuration of that hardware. Sometimes, optimising an existing configuration can be enough. Ymmv

The easiest way to test a configuration (swap drives, ssd vs hdd, etc) is to run a benchmark test. It's under Scripts > Benchmarks. I just did a benchmark test on my laptop (Acer AMD A8, 8 GB RAM) and the bottleneck for me is the swap time. My guess is that this is the most common bottleneck, not CPU speed. Btw, to free disk space, have a look at orphaned swap files. They are in C:/Users/NNN/AppData/local/Temp, unless another location was specified in Global preferences.

Have you optimized the settings in General Preferences (under Edit menu)? Here you can set the number of processers that PI uses, and the swap directories.

Ekos/Kstars. Anything from simple planetarium to full robotic observatory automation. Free. This demo video is a few years old now. A lot has happened since then Kstars is available on Windows, Mac and Linux (pc or single board computer, such as Raspberry Pi).

If you decide to re-engineer your station, you might want to print the enclosure in UV resistant material, if you haven't already. I don't think that the plasic vent covers that I use will last long outside. My experience is that it will hold together as long as it's not disturbed, but the plastic will crack when force is applied (as in unscrewing the lid). Connecting to INDI was easy, and using a standard driver has the advantage that I don't have to compile or install own software or reinstall software after an INDI upgrade. I could have connected the hardware directly to a Raspberry Pi /Rock64 GPIO bus, but I like to keep my hardware layer separate from the INDI server layer. That way, if a home brewn device or its firmware fails, it won't cripple my INDI server or crash an imaging session.

Thanks, Steve. Yes, I plan to add a rain sensor. I just haven't ordered one yet. In the firmware, I will probably replace the irradiance (light) sensor with a rain sensor. The light sensor only reports day/night, which is pretty obvious. Sounding an alarm when it starts to rain is more important.

Hooking up to INDI was easy. First I looked at several protocols from commercial weather stations, but none seemed to fit. Fortunately, there is already the Arduino Meteostation (indiduino). I just had to replace a few header files (the original meteostation uses Adafruit components, I use SparkFun), and I also simplified some of the code (sky temperature correction, dew point calculation). Uploaded the firmware and connected the Arduino to my Rock64 sbc. Then started up INDI with the Arduino Meteostation driver and telescope/ccd simulators. That's it. Here's the first result. Now I just need to reexamine the firmware code to see if I missed anything, but so far, so good.

Astro darkness is still about half a month away, and I wanted to build a cloud warning system. With the addition of an environmental sensor, this became a simple weather station. It is based on an infrared thermometer and a Bosch environmental sensor: MLX90614-BAA https://www.sparkfun.com/products/9570 BME280 https://www.sparkfun.com/products/13676 Arduino UNO a small piece of perf board, two resistors (4k7) and a capaciter (100 nF) The cloud warning system measures the sky temperature and the ambient temperature. If the sky is clear, these two temperatures differ (sky cooler than ambient). If they are about the same, the sky is probably clouded. Nothing original with this probably, other than a creative use of home ventilation parts. Housing projects of this kind is always somewhat of a challenge. The enclosure must protect the sensors from bugs and dust, but at the same time not shield them too much. I came up with the idea to use home ventilation covers and an aluminium strip to build a well ventilated box. The inside is lined with a course filter. The IR sensor is hot glued to the top of the enclosure. Both sensors use I2C communication, so they are easy to hook up to an Arduino. (The IR sensor is the green part, and the environmental sensor is the red part. Note the two resistors that pull SCL and SDA high.) I also added a 100 nF capaciter across the power wires. The sensors are connected to a piece of perf board that holds the resistors and capacitor. I just modified the example code from SparkFun for each sensor. At the moment the weather station reports sky temperature, ambient temperature, relative humidity, and air pressure every 10 seconds. (The values marked with red are after blowing into the enclosure for a few seconds. I am aware that the IR sensor and environmental sensor report different ambient temperatures, but the difference is too small to bother me.) Next step is to make the station talk to INDI. I will probably use an open source protocol for this, so I don't have to write my own INDI driver software.

How would you manage without a 3D printer? 😀

A quick way to do this in PI is to create a preview of the desired area. Then drag its tab out of the image window unto the workspace. This creates a new image of the preview. Save as jpeg.

You only need the smaller fov for plate solving. When you start a sequence, you can set the roi to full size again. Re star alignment. Try increasing the noise settings, noise scales and noise reduction. Usually this helps. Hope you're feeling better.

If you have internet access from the computer that runs kstars, you could try the online solver.

I don't think they do. Temperature affects dark current in semiconductor devices. As such it will affect amp glow. But bias frames are so short, that dark current is not an issue. In stead only artefacts caused by the read out circuits and unevenness in gain will affect bias frames. But better safe than sorry and don't vary temperature. Flats are a different issue. They correct only optical issues. As such they must be independent of temperature. I don't think Warren had cooled cmos in mind when he wrote that. Amp glow is probably not that much of a problem with short exposures. But theoretically any exposure except the very shortest ones, must have some dark current (read, possible amp glow). It just may be so little that you can't see it. But when you start stretching the image, and there is some residual dark signal left, it may show itself.

I found out the hard way that plastic lenscaps can be remarkably transparent. I never trust them. One way to avoid light getting in is to wrap the lens (with lenscap on) in two layers of aluminium foil.