wimvb

No, unfortunately not, but information about how to make one are in the thread. The code is on github. https://github.com/wberlo/AutoDither Using the dither bix oresumes that you have a mount with a st4 port and a snap port (camera port). Most skywatcher mounts have these nowadays.

It doesn't have to be random. Before I started using guiding, I dithered manually. Worked absolutely fine. @Pankaj: here's my recipe. set the slewrate to 1x sidereal. After image 1, press the dec+ button for about as many seconds as your pixelscale (minimum of 1 second). This will give you a dither distance of 15 pixels. Let's call this one dither step. Take image 2. Then press ra+ for one dither step. Take image 3. After that press dec- for one dither step Repeat the same after image 4 (dec-) Take image 5. Press ra- for one dither step. Repeat efter image 6 (ra-) After images 7, 8, 9 each, dither in dec+ After images 10, 11, 12 each, dither ra+ After images 13, 14, 15, 16 each, dither one step in dec- After 17, 28, 19, 20 each, one step in ra- Etc. This will give you an outward spiraling dither pattern. Been there, done that, used a cheat sheet, and was never bothered by walking noise again. This will even work if you have a (moderate) backlash in dec. If you get tired of doing this manually, and you're not afraid of some diy, here's the automated version

Very smooth. I like it.

Yes. There's so much marketing hype in filters that it's best to (learn to) read the spectral curves before buying.

AfaIk, moon filters (neutral density filters) are used to image/look at the moon. As Olly wrote, they dim the light to a manageable level, so it doesn't blind you. The only filters that work in moonlight are deep red filters when used at 90 degrees to the moon. As with sunlight, moonlight is scattered in the atmosphere, and the sky will be blue at 90 degrees to the moon. A red filter will block this blue scattered light and create more contrast. This is the same as using deep red filters in b/w daytime photography, and the reason why Ha imaging works during a full moon. The filter that you have, blocks light between 550 and 600nm (if it's similar to Baaders https://www.baader-planetarium.com/en/baader-neodymium-(moon-and-skyglow)-filter.html) and is basically a light pollution filter that blocks the light from sodium and mercury lamps.

Is this really necessary? Indi is distributed, ie N x M solution with any number of servers and any number of clients. I haven't tested this, but I wouldn't be surprised if only one rpi is needed. Also, check this link https://indilib.org/develop/developer-manual/100-3rd-party-drivers.html

Ok. Pixinsight can do platesolving of course, but not autofocus. It seems that development of the INDI modules in PI has stalled.

... and that's where it performs best. I never liked that pcgcontrol-through-hand set solution of skywatcher. Glad it all worked out well.

Strange. Could it be thrown off by the overall brightness? How does it perform when it's darker?

Do you run ekos on the Pi, or on a laptop/pc? Whatever you use, you can control the other camera from pixinsight. Just connect to the remote pi, and use the ccd process. It's fairly straightforward.

Recently, Göran @gorann and I had a private discussion about this galaxy and faint structures surrounding it, and he reminded me of this thread. Having nothing better to do atm, I decided to reprocess the data, using a few new methods and tricks I picked up in PixInsight. So here's my latest, and maybe even final, attempt As before, I created a synthetic luminance from the RGB frames, since the original luminance has calibration artefacts (shifted dust bunnies). I processed the RGB data for maximum colour punch, and the L data for maximum detail, and trying to preserve the objects in the background. I also managed to pull out a few Ha regions in the galaxy. The data can take a fair amount of deconvolution, as well as stretching. I hope I didin't overcook it too much. Also, note the very faint smudge at the bottom of the image, towards the left. This is a small galaxy that goes by the name SDSS J124324.90+322854.2, poor thing. It is about at the same distance as ngc 4631 (some 40 Mly according to SED), but I haven't been able to find any data relating them to each other. There is however, supposed to be a faint tidal stream going between ngc 4636 (the Whale) and ngc 4656 (the Hockey stick). Unfortunately, this image doesn't show that level of detail. https://www.researchgate.net/figure/Final-ROSA-L-image-of-the-NGC-4631-environs-The-image-is-approximately-81-81-in-sky_fig2_267338882 Edit: This composite image shows the size of the tidal structure surrounding ngc 4631. There is a lot going on in the background, but the data doesn't show any sign of the extension between ngc 4631 and ngc 4656

Vcc of the sensors is connected to 3.3V on the esp board, Gnd can of course be connected to any one of the ground pins, easiest is the pin directly next to 3.3V I2C pins are: SCL is pin D5 and SDA is pin D4. Both these pins are on the same side of the board as 3.3V Since distances are short, these pins can be directly connected to the corresponding pins on the BME board and the MLX board. These pins are marked with SCL, SDA, Vcc and Gnd. There's no need for extra resistors or capacitors as the distance to the esp board is only a few inches. I connected the MLX board with short leads, because this device needs to be glued in a hole in the enclosure. The BME board can be soldered onto the V-board (strip board). The layout was very much like the picture I posted in my original post, with the BME just above the esp, and the MLX connected with leads. I sealed the enclosure with silicone, otherwise I could have opened it and taken a picture. But maybe this helps.

Thanks, but there's no need to go through that trouble for me. What fl do you intend to use?

Very nice, and it does look rather faint, indeed. If luminance gives you larger stars, maybe your subs are slightly overexposed. I use 120 s subs for L, but 240 s for rgb. That is with a cmos camera. Just a thought.

You can always resample the image to get any nr of pixels you like, but it won't get you any more detail. The only resampling that can get you slightly more detail is drizzle integration. You'll need a fairly large number of subs that are (somewhat) undersampled. It comes at a cost of reduced signal to noise ratio. (There ain't no such thing as a free lunch. Certainly not in astrophotography.)

The easiest way to get rid of those magenta stars: Invert the image (process - intensity transformations - invert) Apply scnr (process - noise reduction - scnr) Invert

I had left the cloud monitor outside in the rain last night. Some time during the night, Ekos had lost contact, and I also couldn't see it in the web browser. But it did show up in the connected devices list of my router. The esp I used is a cheap Chinese knock off unbranded model (2 for the price of one). The original Espressif that I use in my sqm seems much more stable. More stability testing needed.

A thought; can you mount everything at 90 degrees to the plate? This will allow both imaging camera and guide camera to be on the plate. It would allow for better balance as well.

With the guide camera hanging the way it does, you'll get differential flexure. The question is how much you can tolerate with your pixelscale. The 135 mm may be the best option. Can you add a support to that?

Probably. The sensors are simple i2c types, not at all difficult to set up. The ESP32 is an intruiging little device. Much smaller, cheaper, more powerful than an Arduino (not smaller than a Nano). It has built in Wifi AND bluetooth. I like my hardware controllers to be separated from software controlling the imaging rig. If anything goes wrong with the hardware, at least I know that it won't jeopardise an imaging session. The ESP32 also has 3 native UART ports/channels of which only one is used for USB. I plan to connect my just-received wind speed meter to that. This device uses RS485 and modbus. Always more to learn ...

This should be easy for you, Gina. You can print your own enclosure. If I had that possibility, I'd probably shield off the esp from the sensors, to prevent heat transfer, have ventilation for the esp, and improve air flow around the bme. But nothing too fancy, this is supposed to be simple. Probably more holes, but not larger. You don't want to make it a spider hotel. It's possible to put the esp in sleep mode to keep it cool, but that will turn off wifi, and disrupt communication with Ekos.

I figured out that if it's only temperature and clouds you want to monitor, just having the mlx sensor will do. The mlx also senses ambient temperature. No need for the bme. But if you want dew control, you'll need it.

I have ordered electronics from Amazon (uk), and in my experience, most of these devices come from chinese vendors. Quality can vary, so you have to make sure whom you buy from. Handling and shipping is usually very cheap, but expect to pay duties. Tracking, even if you get a tracking reference, is virtually non-existent. Otoh, everything I have ordered so far, has arrived on time and in good order. The only delays I have had were caused by the Swedish postal service who were quite slow to deliver after I paid duties.

I recently posted my design for a weather station in this section. https://stargazerslounge.com/topic/345153-indi-weather-station/ As I had bought several pressure/humidity sensors, as well as ir temperature sensors and ESP32 development boards, I wondered how small a weather monitor could get. The sensors are quite small, and so is the micro controller. Such a weather monitor wouldn't incorporate wind speed measurement nor a rain detector, since these take up more space. But otoh, there is seldom rain without clouds, so if you detect clouds, you should be safe. Here it is, a miniature (9.8 x 5.9 x 2.7 cm) weather monitor. The device has built in wifi, is powered from a micro usb contact and is compatible with the INDI Weather Watcher driver. The parts: (the mat underneath has a 1 inch grid pattern) BOM: plastic box 9.8 x 5.8 x 2.7 cm a piece of V-board, in my case with copper islands rather than strips ESP32 development board with male headers MLX90614 ir temperature sensor with I2C interface BME280 environmental sensor with I2C interface micro usb cable and power adapter, or a powerbank for wireless operation Assembly is really easy and involves drilling a hole in the box, soldering the components in place and wiring to the ESP. The finished monitor in place. As this is a box with a click lid, I used silicone to seal it. The holes on the sides and bottom are drilled at an angle to keep rain out. As I built it, the electronics will heat the BME slightly, and because it is mounted inside the casing, it will be slow to reach ambient temperature should this change abruptly. Adding more holes near the ESP would take the inside temperature down. Otoh, temperature readings don't have to be that accurate, and you could use the MLX ambient reading for more accuracy. Here's the INDI control panel for the weather monitor (Wind and rain are simulated, because I was testing the driver when I took the screen shot) Here is how it looks in Ekos scheduler. The red marker indicates that weather conditions are bad. In this case clouds = 100 %. If the tickbox next to "Weather" is checked, Ekos will allow weather conditions to control an imaging sequence. And in the ROR driver (I know it says Dome, but the ROR driver is derived from the dome driver, and it's still under development. Besides, this is the simulator driver.) The code for the esp is on my github page: https://github.com/wberlo/indi_meteostation You need the files: bme280.py mlx90614.py boot.py (replace the ssid and password with your own, or comment/uncomment lines to create an access point) main_mini.py (which you will have to rename to main.py before uploading to the esp board)

This then: https://www.amazon.co.uk/UMISKY-Indicator-Damp-Proof-Automotive-Independent/dp/B07GYTZF35/ref=pd_aw_sbs_263_3/262-9023612-6204953?_encoding=UTF8&pd_rd_i=B07GYTZF35&pd_rd_r=024b8ff0-84ee-4de0-b1a0-4f2ea32f2381&pd_rd_w=4i725&pd_rd_wg=h2Bno&pf_rd_p=0208d703-a674-4413-8899-c3889837d212&pf_rd_r=NGD51G5JGNJ3CDHQ4ZHQ&psc=1&refRID=NGD51G5JGNJ3CDHQ4ZHQ