DIY Focus Controller Project.

[Hicks]

I'm finally nearing the end of my project to move imaging over from a Olimex A20 running INDI to a raspberry pi (also running INDI) that will be mounted to the side of my LX90 fork arm to really reduce the amount of cables running down the mount.

I'm now down to a single multicore cable from the ground to supply two separate power lines, one for the dew heater and then the second that is split between CCD, LX90 and the Raspberry PI.

The PI itself controls my CCD, Guide cam and filter wheel via USB but in addition I've built a "Hat" (although I shouldn't really call it that as it violates a few parts of the official hat spec). That provides an RS232 connection for the LX90 autostar and a DRV8805 based controller to drive my newly arrived (Early Christmas present to myself arrived just a few days before Christmas) Moonlite focuser.

Below is an image of the final board mounted onto the Raspberry PI

and here's a photo of it hooked up to the Moonlite focuser.

 

The project wasn't without its issues, quite a few of them to be honest. From design flaws with the PCB switch mode power supply (luckily fixable without needing a new PCB) to... well they're all covered on my blog which has several posts covering the project.

On Christmas Eve, it all came together though. With a custom INDI driver for the board driving the focuser perfectly.

Full source for the INDI driver, hardware schematics and PCB gerbers along with a few kicad components are all available at:-
 

• https://bitbucket.org/BWGaryP/mup-astro-cat
• https://bitbucket.org/BWGaryP/mup-kicad-library

If you're wondering about the name (he says hoping someone read this far), it was originally the MUP Astro Hat, but since I didn't end up following the full PI hat spec, I decided to rename it. It was a toss up between CAT (after the SCT it's used with) or CAP, since a Cap is like a Hat but not quite a hat!

For the odd person who did get this far, there's much more detail on my blog in a series of posts including a totally, amazing, action packed video of the focuser erm moving.

http://www.mups.co.uk/post/2016/12/moonlite-focusing/

Bottom of that blog post is a link to all the earlier posts which cover the many mistakes made and bodges to fix them

This is the first PCB I've ever made, so I'm incredibly chuffed with how well it turned out despite some rough edges and the many issues along the way. Can't wait to sort the last couple of bits now (few cables and counterweights to sort) so I can finally give this focuser a proper test under the (hopefully not quite as blurry) stars

[Gina]

Looks brilliant   I'm interested in your INDI driver - was it difficult to write?  I'm thinking of having a go myself.

[Hicks]

Not difficult really, but the documentation on some parts seem to be a little hit and miss. As long as you have a read over some of the existing drivers though you can fill in the blanks.

When you do get around to it, if you run into any issues let me know and I'll see if I can offer any advice.

 

[Gina]

Thank you very much

[Marci]

Looks really slick...! Well executed!

I’m currently getting round the whole writing-of-INDI-drivers (and ASCOM) issue by using socat on raspberrypi to redirect raw traffic between /dev/virtualcom0 & tcp:localhost:4080 (in the case of INDI), and a windows vcp client to forward a com port on my Windows VM (on MacBook) over to tcp:scope.local:4070 (in the case of ASCOM - scope.local being the raspberry pi), then just grabbing that via Node-Red TCP Listener node and knocking up translations / responses for incoming commands over to my own control methods within Node. I basically make all my hardware mimic something else. On that basis, I should probably rename my controller to Cuckoo-Pi!

I spool up an indiserver on the Pi with ALL focuser drivers loaded, configure them all to use /dev/virtualcom0, then I’m going through them one by one sniffing their serial protocol (connect a debug node to the tcp listener) to find the closest command set match to my set up. Documentation/source for individual hardware’s protocols/drivers seem easier to wrap one’s head around than INDI & ASCOM’s minimally useful docs on writing drivers from example templates, and I get to keep everything within an easily maintainable environment (Node-Red).

[Hicks]

Had a clear night last night although only from about 6pm to 9pm but long enough to be worth setting up and testing out the new setup. Just about anything that could go wrong did go wrong

Stars in the main ccd didn't quite look like they were evenly focused and worse I had what appeared to be coma. The guider view was even worse, the stars were not eggy, they were more like sausages

By the end of the night I'd started to think the spacing between the back of scope and focal reducer was a real problem even though the spacing from focal reducer to ccd was close enough to correct and solving that would be tricky. Then I decided to check the reducer was seated correctly inside the focuser and hadn't somehow come loose (not that it could, but straws/clutching..), opened it all up and OMG it's in BACKWARDS!

I'm assuming all the visual defects were down to that although I've not seen any images taken with a reducer installed backwards so can't be certain. Either way it wouldn't have helped Can't believe I did that.

So, fingers crossed the guide stars at the edge of the field will once more be small blobs and not sausages and the edge of field of the main ccd will show no eggy stars (other than those due to polar alignment). More cloud for the week though so it may be a little while before I find out if that is all it was and that having the focal reducer a few inch away from the rear cell of the SCT is going to be ok.

2017 is off to a good start