wimvb

Now, that's a depressing bed time story. Sorry it didn't work out for you. I hope you have better luck tonight. Monday night is supposed to be a clear night out here, according to the Clear Outside app. Probably the same gap in the clouds that's passing your neck of the woods this weekend. But at the same time it predicts 7% chance of rain on a cloudless night, as oppsed to 0% chance on a 100% clouded night. I wonder who programned that app.

Great write up. Glad I have PixInsight; only a few sliders and no layers. Thanks for the script, Mark.

To test this, try the following. Wrap something around the suspected vane and image a star. Repeat with each vane until you find the culprit. Focus on a bright star (like Deneb in Cygnus), and gradually defocus. Eventually you will see the shadows of the vanes. At that point you can hold a finger near each vane at a time and identify them in the view. Either of these methods should give you the position of the twisted vane. Then loosen the screw on the outside of the tube, twist the vane until the diffraction spike looks good, and tighten the screw again. If you tighten as before, this shouldn't throw collimation off. But check collimation of the secondary mirror afterwards anyway. Easiest way to check collimation is to focus on a bright star, then rock focus in and out. The defocused star should be symmetrical and look the same on inside and outside of focus.

Dion from astronomyshed has a youtube video showing how to align a sw focuser. Also, the standard focuser has three pairs of collimation screws on its baseplate. They (should) work the same as those for collimating the primary.

That's a great start. The vignetting is best taken care of by using flats, even if gradient removal tools also can do their share. I think that from here, the next logical step would be to add bias and flat frames. Dark frames with a dslr are debateable. Dithering (= moving the fov slightly between exposures) is more effective.

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.