wimvb

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

Indeed. And if that thread isn't convincing enough, this one should be. (Just not on a eq3)

Better put the '_2' back again, then. 😉 If there are multiple ftdi chips competing in indi, it's usual to do usb port mapping. I wonder if this works here as well. Just a thought.

Not with the 55 mm f/1.8 lens, I hope? This would give you an even coarser pixelscale. The ASI174 has 5.86 um pixels, vs 3.75 um for the ASI120.

Have you checked the gain settings for either camera? It's in the INDI control panel

I'm surprised the indi_asi_ccd_2 entry works, because this is not the name of the driver. Here's my ekos profile: As I wrote, I don't start the servers from command line, the ekos profile takes care of this. But I run Ekos locally on the sbc. You could try if this also works remote, with the drivers on the Pi, and Kstars on a laptop/Mac (set Host IP to your Raspberry Pi IP-address of course). When I ran 2 sbc's, I had the imaging camera on one (called 'camrock'), and the guide camera on the other. I would start the drivers on the camera sbc with indiserver -v indi_asi_ccd indi_asi_wheel then I would start the mount/guider sbc with indiserver - indi_eqmod_mount indi_asi_ccd "ZWO CCD ASI174MM-Cool"@camrock "ZWO EFW"@camrock How to do this is described on the INDI site.

I have a 174mm and 120mm-s on the same sbc (rock64, not raspberry pi). First of all, you need the usb3 version, but you're safe there. Next you need to start up the imaging ccd and guide ccd as indi_asi_ccd (zwo ccd) in your ekos profile. Btw, if you use remote desktop and run ekos on your Pi, you don't need to start indi server first. Ekos will do that for you. Once you've started ekos, you should see both cameras in the indi control psnel in ekos and kstars. In all the modules that use a camera, you will be able to select either. I had problems running 2 zwo cameras from the same sbc before. Hence the use of 2 sbc's. But since I upgraded to ubuntu 18.04 (and now Armbian/ubuntu), I haven't had any problems anymore.

Checking the motor gear only involves opening the cover, and giving the gears a wiggle. That will show if they mesh ok, and reveal any damage. It's the equivalent of looking under the bonnet. I agree with not doing any further dismantling unless absolutely necessary.

Pixelscale 206*3.75/55 = 14"/pixel, roughly. I would say that you are very undersampled. I don't think phd will like that star profile. You could try to cheat phd by giving the guidelens a small defocus. With a minmo of 0.2 in phd, you'll be looking at an rms of 3" at least. The imaging camera @200 mm will have a pixelscale of 3.9"/pixel. About the expected rms. With a slight defocus and a minmo less than 0.2, it just might work. Try it, and share the results here. I'm very interested to see if it works.

https://www.firstlightoptics.com/skywatcher-focusers/skywatcher-auto-focuser.html

You can dither by hand, if you don't guide, but it's a royal pain. You have to sit by the mount all night. Been there, done that, never wanted the t-shirt.

When you get the chance, open your mount to inspect the gears. Just take the cover off on the side of the mount. Make sure the gears mesh without binding. Also slew the mount one full rotation in ra and dec without any load. If it runs smoothly, with no more grinding than usual, you're probably ok as far as the mechanical part is concerned. While you have the mount open, check also for backlash. The image shows both poor focus and tracking issues. The focus lock screw can cause focus shift, so always check focus after you lock it. A motorfocus will "lock" on its stall torque, and you don't need to use the lock screw. Once you have checked both these things, you can expect better results.

Excellent image, Adam. I agree, that was £159 well spent. You certainly made that scope sing. I look forward to what you will produce with the Esprit.

Nice, Gina. Here's a tip for keeping the core of m42 under control: Create a copy of the image, apply stf as permanent stretch. Then apply curves to bring the white point down to 40% (or pixelmath $T*0.4). This will be a mask. To the original unstretched image, apply a series of modest histogram stretches (I put midpoint at 0.25). When you start to lose detail in m42's core, apply the mask and do hdr transformation with nr of layers set to 4. Then remove the mask and continue applying histogram stretch. Repeat this alternating procedure until the background looks good.

I think you're overthinking this. The setup in the image is most likely put together by marketing people. But probably either camera goes.

The advantage of using zwo components all the way is that all spacers are included, either with the camera efw or oag. No need to buy extra.

Thanks. Yes, the 174MM-Cool is one of the noisier ASI models. 😋 But it also has larger pixels and gathers more photons/pixel. As long as the exposure time is long enough to drown the read signal, it really doesn't matter that much. I use the camera at low gain (20) where the dynamic range is largest, and use 120 s exposure time with the L filter (240 s for RGB). This gives me good signal but not too many stars overexposed. My sky darkness is about 20.6 M/arcsecs2, the Milky Way is just visible. There is some glow from Stockholm to the South, but not too bad.