Hicks

@abhoriel: I was much the same way. Used Linux but always switched back to windows for astrophotography. For the last couple of years though I've used KStars/Ekos with Indi and have had no need to use Windows at all now. I was still a little unsure for image processing though until I found out about PixInsight and whilst I generally prefer open source apps, this was an exception worth making. For anyone using Linux, this thread lists a ton of applications, many you've probably already heard of but it's a big enough list there'll likely be some you haven't

If the flat frames are short enough in duration then I think the warning is normal. The scaled dark frame would be so short that it's possible it would add more noise than it removes. In this case I think PI just subtracts the bias from the flat and skips the dark. That said, double check that you either already subtracted your master bias from your master dark or that when you do integration on the flats you have calibrate ticked for the master dark so that bias can be subtracted.

These are my two current best from the back end of 2016. Both taken with an LX90 8", f6.3 reducer, sxvr-h9 and lodestar guidecam. Sometime in 2017 I'm hoping to add colour filters and maybe narrow band but given how much cloud we've had of late it'll take me a while to be happy enough with my mono images to up the complexity. M1 Crab Nebula - Link to Original thread M27 Dumbbell Nebula - Link to original thread

Hi Gina. Just checked the chip you mention, that would likely avoid the issues I was on about. I didn't realise you were using that, I thought you were just using a basic driver chip rather than a controller. The Arduino I imagine is likely similar to the setup I was considering with a Pi -> Pic -> driver -> Motor. I may have to give a bit more thought to my project. Although I will likely still make a custom Pi hat as I want to do a little more than just control the focuser I likely don't need the Pic if I choose a suitable controller chip instead and drive that from the gpio. Just need to find one I can manage to solder

How accurate is controlling a stepper motor directly from the Pi? I've been toying with the idea of getting a moonlite focuser and using the Pi for remote control of it (currently I use a olimex A20 to control CCD, Guider, Scope mount and filterwheel remotely via ekos). However, when I was thinking about using gpio from the Pi + a driver chip I wasn't sure if the Pi would be accurate enough to send the motor on pulse for just the right duration without potential delays due to non real-time OS. I was thinking instead about using a PIC chip and implementing the moonlite protocol on that so that the Pi could use serial to communicate with the Pic, random delays/jitter wouldn't matter there and then the Pic would be able to do very accurate driving of the motor via a driver chip. That said, you've both now got me curious about how accurately the Pi 3 can drive its gpio pins. Do either of you have an oscilloscope and a way to capture a trace of the motor pulses to see how well the Pi does? My main concern was that with it not being a real-time OS, there's a chance it could start the motor then be pre-empted and other processes run a little before it can turn off the motor, causing the stepper to move more than intended. Is that a valid concern? If the Pi is capable of decent enough accuracy I may have to revise my original plans.