wimvb

How and when in the process did you mix the short an long exposures?

If you use 10 s exposures with your Canon, I think your subs are underexposed. The lines/bands are a typical read pattern of a dslr sensor. Flats should be as neutral as possible, but PI can handle a colour cast caused by the calibration process. Post processing will take care of this. It will be corrected during backgound neutralization. Personally I would try to avoid doing any processing on calibration frames, other than calibration and integration.

Next you could check your dark master, but this is also a likely candidate: If the problem persists, it's vey likely something in the calibration process, but otherwise atmospheric conditions could be to blame. Are all subs affected equally, or are some subs worse than others?

Yes, I currently use one of those with an ESP32 module. They're easy to use, but you won't have humidity measurements. BME280 are cheap on Amazon, and just as easy to work with. They need two data lines, as opposed to just one for the DHT module.

Great image. I had to look it up, it's an unusual target.

Is there a risk that the fork itself may flex?

Sorry, I assumed the camera without the filter wheel was an OSC camera.

Your master flat is not neutral, which means that it introduces the opposite colour to your light frames. Eg, if the flat frame has RGB values 0.25, 0.5, 0.5 (scale 0 .. 1), the calibration routine will divide: (Light_R - Dark_R)/0.25 (Light_G - Dark_G)/0.5 (Light_B - Dark_B)/0.5 This will give a higher Red signal in the calibrated light frame than Green and Blue. Things to consider Try to create neutral flats. I believe that EL panels can result in non neutral flats Make sure you do the calibration before deBayering (ie, calibraton frames should not be deBayered, only lights just before star alignment) Create proper darks for flat calibration

If you suspect the calibration process of the master flat, try calibrating one flat frame with the master flat, and the master flat dark. This should give a completely flat flat. I guess that this means that the originals are NOT 8 bit, and that lights and calibration frames are all the same bit depth.

The intermediate step between manual focus (even when using the APT metrics) and autofocus, would be a motorized focuser with hand set. I have found that on my SW Newtonian, focus can shift when I lock the manual focuser. But as long as a motorized focuser is powered, the stall torque will keep focus position, so there is no need to lock focus. A motorized focuser also causes less problems with vibrations during focusing.

Here are James' and my solutions to the protection problem:

As far as I know it isn't, but the math behind it isn't straight forward, because the quality of the final image is not only determined by single sub exposure time, gain, and number of subs. At low gain, a CMOS camera has a higher dynamic range than at high gain. When you stack multiple images that have low dynamic range, you increase the dynamic range again. The advantage of high gain is that you can use shorter single sub exposures. During stacking you can then exclude images that have star trails, satellite trails, passing clouds, etc. Also if you use short enough exposures, you may get away with not guiding. Generally the better astrophotographs have long and similar total integration times, regardless of which gain setting and sub exposure time was used. ZWO wrote this in their blog: https://astronomy-imaging-camera.com/tutorials/cooled-asi-camera-setting-in-ascom-driver.html I do most of my imaging at low gain, below unity, and 120 - 240 seconds (the shorter time for L, the longer time for RGB). My camera has a somewhat high read noise (compared to other ZWO cameras), and I like to image at high dynamic range.

The original Mesu design perhaps 😋 : http://www.astro-imaging.com/Equipment.html http://www.sternwarte-hattingen.de/hatt/hatt2010.htm (scroll down to the 10th image) @Gina: if you put the DEC wheel on the side with the colour camera, won't that give you a better weight distribution? Also, which parts will be in metal and which will be 3D printed? I wonder where material stiffness is most critical.

With the Raspberry Pi, you will also need a power adapter and a micro SD card. You then need to install the software on the SD card. I believe that the astroberry site has all the information you need. https://www.astroberry.io/ The StellarMate is sold as a hardware/software bundle or as software only (if you have a Raspberry Pi) https://www.stellarmate.com/ As an alternative, you can install INDI and Ekos/Kstars from scratch on a Raspberry Pi. This is straight forward, but requires some basic knowledge of Linux. Astroberry and StellarMate are easier.

How about the BME280? You will get humidity, temperature and pressure from one device. It uses I2C which is quite straight forward to set up with Arduino

Nr 1 for me too. After all, it's a VEIL, it's supposed to be thin imo.

Those must be cheap in your neck of the woods. Over here a barebones nuc with zero storage costs about the same as an asiair v1. And then you still need to configure that nuc and get all the software. If I didn't have a working Ekos/Kstars solution, I'd definitely go for either this or the StellarMate. The real downside of asiair imo, is that it's locked to only zwo and dslr cameras.

I read on the agena astro site that the 12 v outputs can handle up to 3 A each (10 A max, total), and some are pwm controlled = can be used for dew heaters. That should be enough for the eaf and camera power. I just wonder how much heat will be generated if you run both the sbc and the power outputs at full capacity.

That's not going to happen anytime soon. The next version you'd have to pay for is 2.0. The newest version is 1.8.8, while I bought 1.8.4. Version 2.0 isn't even on the drawing board yet. Pixinsight is cheaper. Otoh, if you do daytime photography, PS clearly is the better choice.

The Liverpool telescope is. And on a high mountain top above the clouds. And with a pixel scale of 0.3"/pixel. So

That argument is one of the reasons why I bought Pixinsight some three years ago. It has so far saved me roughly 200 €. Pay once, cry once. But I agree on the rest.

Nice catch, Rodd. Is this cropped?

Very nice widefield. Keeping better star colours with short exposures makes sense. Once you start to overexpose stars, all 3 channels will be maxed out = white. If the camera has enough dynamic range, it may be better to keep the exposure time short. But you risk losing faint detail.

From what I could find, the Orion has a small sensor with large pixels. With your 200pds you are undersampled at roughly 1.7 arcsecs/pixel. Ok for nebulae, but imo too course for galaxies. At the same time, you probably won't fit nebulae on that small sensor. What ZWO camera are you considering? On my wish list it would be 1. ZWO cooled 2. DSLR (new or second hand) 3. ORION G4 But as @Skipper Billy wrote: use a field of view calculator when evaluating various candidates.

I've now made a MQTT version of the sky quality meter. In this version, the device no longer creates a webpage with the SQM readings, but publishes the timestamp and SQM readings to a MQTT broker. The code is in the github link provided in the original post. Here's what needs to be done: 1. Install a MQTT broker. I installed Mosquitto on a Raspberry Pi I had lying around. Here's a good resource: https://randomnerdtutorials.com/how-to-install-mosquitto-broker-on-raspberry-pi/ 2. Install a MQTT client. For this I use MQTT.fx ( https://mqttfx.jensd.de/ ) on my Windows computer. There are several clients available, including Mosquitto. 3. Get a simple mqtt client for the esp32: https://randomnerdtutorials.com/micropython-mqtt-esp32-esp8266/ This version of the sky quality meter is not (yet?) compatible with INDI, you would need an INDI MQTT driver for this.