wimvb

Great image with superb processing. And, as Olly said, unusual in nb. But it clearly works.

The first is my favourite too. You managed to bring out more of the faint Ha background. (Btw, the Ha background causes stars behind it to appear orange.) My first guess was that this is the image with more subs, since more subs = less noise, which means you can stretch more. Otoh, as the moon brightens the sky it also introduces more noise. So, in this case the better image may well be from the smaller stack.

You be the judge to that: I've never had such distinct star spikes before. Considering a 1.6 "/pixel image scale, I'm very satisfied. The geared motor does have a lot of backlash, which my arduino code could compensate for. But the moonlite driver has no backlash compensation. Still, the autofocus routine in Ekos handles this fine.

It works good too. I autofocus with ekos/kstars from my livingroom. No need to go outside to refocus.

Nice to have you back here, Gina.

That's a very well thought out design for your obsy. I like the idea of the main roof sliding over the smaller roof. Foundations are the most important to get right, so take your time for this. Once the floor is in place, you'll find that the next phase will go a lot faster. Good luck with the build.

You folks in the tropics.

Nice! I think that polar alignment should only be out a tiny bit. Too much will mean the guiding will have to work harder. When I used Lin_guider, I let the mount drift for a while until I saw in which direction the DEC would guide. Then I switched on guiding in that direction only. This would quiet down the dec guiding, almost independent of how good PA was. Sometimes I find Lin_guider to be more Push Here Dummy than PHD. (Also note the 'Accumulate frames' settings which let you average corrections over a number of frames before applying.)

Usually it's frost and water level that causes movement in the ground and shift of the block and pier. I would aim for getting the block deeper than frost will get during the winter months, and have the immediate surroundings filled with draining gravel, rather than sand or clay. A local builder should be able to give you advice on the best way to make the block and pier. It's better to over-engineer a pier than to 'under-engineer' it, but over-engineering will most likely also mean over-budget. Good luck with the build

Gradients can have all sorts of causes. Dion from astronomy shed even had gradients caused by ground loops. Don't ask me how that's possible. When he had systematically removed the sources for ground loops, the gradients had disappeared. If you use PixInsight, remove the gradient with dbe and carefull placement of the samples.

Systematic testing for light leaks. If you rotate just the camera, the gradient should rotate in the frame you get. If it still is in the bottom part of the frame it's the camera. If you rotate the camera 90 degrees, and the gradient 'moves' to the short edge, you got a light leak. Next, rotate camera + filter wheel. Etc. If you take a long exposure with the (lens) cap on, this will also reveal light leakage. As said: systematic testing. That's what cloudy nights are for. Good luck

I don't think that rebar into the ground will help much, adthe it's too easy to bend tohelp with anchoring. But definitely use it inside the block & pier. Any diy store that sells concrete will also sell rebar rods in different sizes.

I don't know if PHD2 has this feature, but at least in lin-guider, you can set it to average a number of exposures when sending a guiding command. If you set frames to, say, 3 lin-guider will average over three exposures before sending a command. This 'quiets' the guiding behaviour, as you're no longer chasing the seeing. Maybe PHD2 has a similar feature. Just a thought.

Indi should support celestron nexstar. http://indilib.org/devices/telescopes/celestron.html It seems that qhy support is limited. There are several threads in the indilib forum indicating trouble with qhy cameras. This is the main reason for me not to buy qhy. Zwo has much better support. All their cameras seem to work with indi, and any issues are generally addressed very quickly. I have programmed a fair bit, both in my work and privately. But always just to solve problems, never as a professional programmer. So, I always have to keep a reference manual handy when I start a new project, to get the syntax right. @Gina, I have been following your thread(s) with great interest. I opted for the SW DC focuser mainly because of the hardware and because it required less diy mechanics to get working. (Don't have a 3d printer. ) Steppers are better for focusing, and I have a couple lying around. But I knew the SW would attach to my scope without any issues. I find arduino easier to control hardware, and don't want to mix my efforts of hardware control with vital functionality such as guiding, on the same RPi. I plan to use two RPi's for my setup; one for mount control and guiding, and one for imaging and focusing. RPi's are cheap, and this will give me some redundancy.

Neither do I. INDI is great. With just a Raspberry Pi, an eqdir cable and a camera (I've used my asi 120 guidecam for testing), I can have complete remote control of my setup, excluding polar alignment. That's quite a step up from a dslr with an intervalometer.

It may very well be that the raspberry pi can control a motor directly, but I had a motor controller for the Arduino, and I'm not that familiar with Python and GPIO programming. For me this was the easier solution. Besides, I have INDI running on the Raspberry Pi, and I want to keep this as clean as possible. The Arduino basically emulates the MoonLite focus controller box.

Imaging season is still a few weeks away up here, but I've started dusting of my gear and upgrading some parts. One step closer to automation is a motor focuser, and I opted for a budget solution. I bought a SkyWatcher DC focuser and built a computer control for it. Since I use INDI for my automation, I had to find a way to connect the focuser to indiserver. A first thought was to use the INDIduino code, but after some coding and testing I found out that this code is very limited and not really supported by indi clients. The Ekos/Kstars focus module can't be used for focus control if you use INDIduino, apparently. But then I stumbled upon an Arduino solution that emulates the MoonLite focuser (http://www.indilib.org/forum/general/283-moonlite-focuser-protocol.html). Unfortunately, this protocol is for a focuser with a stepper motor, whereas the SkyWatcher has a geared DC motor. I had already rewritten some code from stepper to (geared) DC motor, so it was easy to adapt this to the MoonLite based code. My solution consists of the following: hardware: - SkyWatcher DC focuser (only the motor is used, the handbox is replaced by the Arduino) - Arduino UNO - Velleman motor controller shield for Arduino - 9 V power adapter to power the shield - Raspberry Pi software: - Arduino sketch with Geared Motor library (see below for link) - INDI server on RPi, and client (Ekos/Kstars) on Windows I've tested this setup on my SkyWatcher Explorer 150PDS and it runs fine. Unfortunately I haven't been able to test the autofocus, due to absence of astrodarkness and clear skies. Since a DC focuser has no knowledge about the position of the actual focuser, the software assumes that position '0' is all the way in. Maximum position is 25000 for my setup. By default, focus is increased by 100 steps, which is supposed to be 100 ms of motor drive. BTW, the code is in my GitHub repository: https://github.com/wberlo/Arduino_Moonlite_Focuser

Me too! My first impression was that you'd clipped the background. But zooming in reveals faint variations. If you can find the time (and the hole in the clouds), more data can reveal the subtle difference between the dust clouds and the true background. It's easier to get to this level of detail if you have really dark skies. Thanks for sharing.

You're right, as long as you don't guide, DEC backlash is of less importance. But it will affect GOTO accuracy as well. That's why you always have to end a GOTO alignment with RA+ and/or DEC+ movement. You just need to approach an alignment star from the same side. Otherwise any backlash will throw the alignment off. If you use guiding, a polar misalignment will help, as recently explained by Olly. (You only need to correct DEC drift in one direction)

I just wish I had read that before I started stripping mine. The aluminium ring on the ra axis (underneath the polarscope ring) is locked by three tiny grub screws. I found out about that the hard way. Nearly stripped the thread clean off this ring. Also had to redo the whole process, because the grease I used the first time was too thin. The thick chinese stuff is needed in this case. The DEC axis is easier, and since DEC backlash usually is the main issue, I would start there. Another problem I had with my mount is the alt adjustment. The bolt that holds the head on the fork, tightens when you increase altitude, making the altitude adjustment difficult. As I live at 60 deg North, this caused the altitude adjustment bolts to bend. I resolved this by loosening up the central bolt, and eventually adding a wedge to the 'lip' that the altitude adjustment bolts push against. (Hope this description makes sense. I will try to find some images that show what I mean.) Found some: the altitude 'hinge' bolt that tightens itself when increasing altitude The aluminium ring in the RA axis behind the polarscope ring. Notice two of the three grub screw holes and the threading coming off. Also a small indentation in the RA axis where a grub screw pushed against the thread (top of the image). The 'lip' of the altitude adjustment mechanism. The adjustment bolt just bent underneath this, so I made a small wedge for the adjustment bolt to push against.

You probably also have a fair amount of periodic error in this mount. I would advise to first take care of backlash in ra and dec, before stripping the mount. As I wrote before, this mount is tricky, since it doesn't have bearings in the axes. Smooth running under load is entirely dependent on the right amount of lubrication and tension in the bolts. But if you go for it, there is a write up.

This image shows a cloud above Europe, and when I looked outside my window (in Europe) earlier today, there was. Therefore the image is accurate. And so the earth must be flat. QED (And as for the size of the bottle relative to the cat: have you guys never been on an aeroplane. They always serve wine from small bottles.)

As @alacant already noted, your image is the true measure of quality, and that is great, even at 3 subs. If you can add more frames, this will dramatically improve the image.

Eq2 is more of a challenge anyway. And, yes, they certainly are.

Isn't this the eq3 challenge? (Done that, been there.) I understand the frustration