ArduinoAstroControl - Homebrew Autoguider MkII

[samtheeagle]

So at long last I've finished of the second revision of my homebrew autoguider, this time based on the popular Arduino prototyping board. This is to give me room for future additions such as focus control should I get the itch This is based very heavily on my previous project: SimpleGpUsb, and indeed ports over large amounts of the driver code. Funtionally it operates in exactly the same way, it's just based on different hardware, and has the driver implemented differently (as an ASCOM local server), which is again to support future additions more easily.

Example images from the first use of this autoguider can be found in this thread: http://stargazerslounge.com/imaging-deep-sky/104790-i-love-when-plan-comes-together-m13-ngc7000-ic5070.html

As before I release this under the GPL. Binaries, documentation and all of the source code can be downloaded here: http://www.guywebb.co.uk/ArduinoAstroControl/ArduinoAstroControl 1.0.0.zip

[jnp]

The quad opto chip is a nice touch (compared with previous the implementation using a darlington array) as it needs no additional power to switch the appropriate hand controller button low. A nice low risk circult for begineers.

I found this confusing at first, but for the benefit of others, the '2x' Siderial tracking rate of a mount actually corresponds to a guiding rate of 1x on a Synscan or similar. This means that a motor tracking at 1x will actually stop when guiding West and run at 2x when guiding East.

The Arduino gives you loads of potential, even if it is a sledgehammer to crack a nut when only used for guiding. I guess we will have to wait a bit longer for the "GOTO". Might be feasible at 16x using the handset? I don't know how the HEQ5 motors compare with the EQ3-2, but there must be potential to slew at considerably greater rates if you consider using the Arduino to build your own standalone controller. Be interested to know if anyone has done that and if its accurate enough? (This currently down my list of projects to eventualy get around to).

Nice work and a great contribution to the SGL community.

cheers

John

[samtheeagle]

I guess we will have to wait a bit longer for the "GOTO". Might be feasible at 16x using the handset? I don't know how the HEQ5 motors compare with the EQ3-2, but there must be potential to slew at considerably greater rates if you consider using the Arduino to build your own standalone controller.

Well the driver already supports very basic GOTO functions via the SyncToCoordinates and SlewToCoordinates methods. I can point the scope at a known star, update the driver with the SyncToCoordinates method, and then ask it to slew from there.

On the old EQ3-2 mount it was REALLY slow, but the 16X of the HEQ5 will help a bit. I must admit that I was curious about trying to drive the mount's stepper motors directly for higher speeds, but I'm rather worried about breaking something

Thanks for your comments John, it's nice to know that someone has looked at my work

[jnp]

SyncToCoordinates and SlewToCoordinates are called from Stellariumscope, but setting the CanSlewAsync property to True makes it call the asynchronous methods. This allows you to see the target position updated in realtime in Stellarium (or similar).

16x is probably a bit slow but worthwhile. It's still faster than spending 45 mins trying to locate, say m101 manually (yes guilty ). Means you can explore beyond the 'low hanging celestial fruit'.

I don't see any issues driving the stepper motors faster. If you drive them too fast they just stall and miss steps. Some trail and error is required to get optimal speed. Using a low power 12v adapter should be perfectly safe. You'll need a beefier supply if you want to slew RA and DEC at the same time. I found it more accurate done seqentially as the duration is not an issue for me.

I dont know what the actual slew rate is, but It takes my EQ3 DIY goto just under 1 min to slew from Vega to M57 and then apply the RA correction for the slew duration.

[samtheeagle]

SyncToCoordinates and SlewToCoordinates are called from Stellariumscope, but setting the CanSlewAsync property to True makes it call the asynchronous methods. This allows you to see the target position updated in realtime in Stellarium (or similar)

All very well and good if the Async methods are implemented! But I have not done that yet, as it gets into the realm of synchronizing thread data, and that's just hard work! Maybe one day I'll hook that all up, for now CdC just has a little "rest" during slews

[Euan]

Hat's off to you, auto guiding with off the shelve kit can drive me nuts never mind having to do it from scratch

Looks like a great project

[samtheeagle]

Cheers Euan

Well a lack of funds pushed me down the DIY route initially, but I like to think that getting into the guts of it all has helped me to understand autoguiding a bit better. I'm no expert, and there's still plenty I don't know, but I don't have the fear of it like some seem to. I guess making it all means it's less of a black box (although it is actually a little black box! ) so if something goes wrong I have an idea as to what it is and how it might be solved...

[ncjunk]

Looks interesting,

I will have a look at your code as i am finishing off a focus driver with the arduino at the moment. Got it working last week but i now need to make a comms server if i want to add more stuff to the arduino. (only a stand alone focuser at the moment).

I will be doing 2 focus controls, dew control and cloud sensor.

I have no idea how the ascom hub thing works so your code should come in usefull!

Neil c

[samtheeagle]

Hope it helps Neil. The local server driver setup is a bit of a Frankenstein's monster tbh, but after the initial project setup it's ok. There's just a fair amount of manual adjustment required when adding a new sub driver project, follow the instructions in the readme file created by the visual studio project template and you'll be fine.

[Dante]

This is based very heavily on my previous project: SimpleGpUsb, and indeed ports over large amounts of the driver code. Funtionally it operates in exactly the same way, it's just based on different hardware, and has the driver implemented differently (as an ASCOM local server), which is again to support future additions more easily.

Hello Guy

I read this thread with much interest. I am about to start my first mod and will be following your SimpleGpUsb. I wonder if you could give me any pointers. The mod will be to my HEQ5 control unit.

You mention in the .pdf file that I downloaded that programmes were attached to the download - I didn't get anything other than the SimpleGpUsb file. Any chance of pointing me in the right direction there also?

Thanks

Danny

[samtheeagle]

Danny, if memory serves, the post that I put up for the SimpleGpUsb had two download links, one for the pdf document, and one for the source code and driver install.

[Dante]

Danny, if memory serves, the post that I put up for the SimpleGpUsb had two download links, one for the pdf document, and one for the source code and driver install.

Thanks for that. I have been reading about your latest using the Arduino Duemilnove board & an ILQ74 (replacement for the Dalington Array) Hmm - should I go straight to that mod rather than SimpleGpUsb? Your Maplin store is far better than my local one. They never seem to have the particular bits. I'm having to go all over the place, Farnells, Cool Components etc.

Back to my ? should I go straight to that mod rather than SimpleGpUsb? I'm really interested in mirroring your project, if that's acceptable to you?

Danny

[samtheeagle]

Well I've made all of my code available under the GPL, so you can do modify it as you like within the limits of the GPL. I guess which design you go for depends on whether you want to go off in your own direction, or completely copy what I've done? As I've moved on to the Arduino, that's the platform I'm going to be updating as time goes by. SimpleGpUsb has been replaced by the new design, but that's not to say it doesn't still work ok

Either one will give you a guiding interface, but the newer Arduino based one is the one I'm moving forward with now...

[Dante]

Well I've made all of my code available under the GPL, so you can do modify it as you like within the limits of the GPL. I guess which design you go for depends on whether you want to go off in your own direction, or completely copy what I've done? As I've moved on to the Arduino, that's the platform I'm going to be updating as time goes by. SimpleGpUsb has been replaced by the new design, but that's not to say it doesn't still work ok

Either one will give you a guiding interface, but the newer Arduino based one is the one I'm moving forward with now...

Hi Guy

Thanks for the response.

I have decided to do the SimpleGpUsb first, to get the experience. Never done any electronic soldering so I should start simple (?). If I do a professional job of the mod then I will move on to using the Arduino and follow you (like a slave) on the further changes you make. I also intend to mod my SPC900NC web cam, so a steep learning curve coming up:icon_eek:

Regards

Danny

[l_bird]

So at long last I've finished of the second revision of my homebrew autoguider, this time based on the popular Arduino prototyping board. This is to give me room for future additions such as focus control should I get the itch This is based very heavily on my previous project: SimpleGpUsb, and indeed ports over large amounts of the driver code. Funtionally it operates in exactly the same way, it's just based on different hardware, and has the driver implemented differently (as an ASCOM local server), which is again to support future additions more easily.

Example images from the first use of this autoguider can be found in this thread: http://stargazerslounge.com/imaging-deep-sky/104790-i-love-when-plan-comes-together-m13-ngc7000-ic5070.html

As before I release this under the GPL. Binaries, documentation and all of the source code can be downloaded here: http://www.guywebb.co.uk/ArduinoAstroControl/ArduinoAstroControl 1.0.0.zip

Hi Guy,

first, let my thank you for being so kind to share your project which I think is the perfect answer for many astronewbies in a budget like me who wouldn’t be able to achieve autoguiding otherwise.

I was ready to implement your SimpleGpUsb project but then I found your ArduinoAstroControl so I decided to go with the last one which looks to have even more future potential.

I've followed the instructions but after installing all the software and trying to do the first test using your TelescopeDriver Test.jp, it failed to load the driver, same happens with PHD too. It shows this message:

Failed to load driver: An exception occurred in the target destination

I’ve tried everything from uninstalling the older SimpleGpUsb drivers, the ASCOM platform, FTDI’s drivers and reinstalling the ASCOM platform then ArduinoAstroControl, to upgrading the ASCOM Platform to version 5.5 and back to version 5, and some other combinations but never go it to work. I’m guessing the problem may be in some kind of conflict with the SimpleGpUsb driver not been totally removed or maybe is just that it can’t work as an ASCOM local server in my XP laptop for some reason. I’m stuck at this point, so I’ll be infinitely grateful If you could help me here.

Thank you

Luis

[samtheeagle]

Hi Luis, can you post a screenshot of the error? I'm happy to look into things for you...

[Dante]

As I've moved on to the Arduino, that's the platform I'm going to be updating as time goes by. SimpleGpUsb has been replaced by the new design, but that's not to say it doesn't still work ok

Either one will give you a guiding interface, but the newer Arduino based one is the one I'm moving forward with now...

Was shopping around for the Arduino board that you used - now superceded by the Uno, so I've opted to go down that route.

I printed out your page ArduinoAstroControl (I've done the handset mod, that's another story (heaven help me). The picture is not very clear. I cannot see what the dark area is with all the cable entering it. Is this a USB Input socket?

Any chance you can help me out here?

Thanks Danny

Dante

[samtheeagle]

Hi Danny, sorry but I'm not following what picture it is that's not very clear? From the PDF documentation? Let me know and I'll try to explain

[Dante]

Hi Danny, sorry but I'm not following what picture it is that's not very clear? From the PDF documentation? Let me know and I'll try to explain

Hi Guy

Thanks for the quick response. Yr doc is dtd 24/05/10 and it's fig 4

I'm being a bit slavish here. I have bought a box specific for Arduino which has a cutout that would take a comms plug 6P6C and my cable is Flat 6 core.

Perhaps you could let me know where the connections should go. I'm a complete duffer in this respect:

Thanks Danny

[Dante]

Tried to attach photo of Uno but don't see it. I'll try again

[samtheeagle]

So, figure 4 is the internal layout right? That pick shows the RJ-12 socket at the front, and at the other end just behind the bit of circuit board with the opto-isolator is the usb socket. So cables at the front go to the RJ-12 socket, and then go to the opto-isolator, and then go to the Arduino

Hope that helps.

[Dante]

So, figure 4 is the internal layout right? That pick shows the RJ-12 socket at the front, and at the other end just behind the bit of circuit board with the opto-isolator is the usb socket. So cables at the front go to the RJ-12 socket, and then go to the opto-isolator, and then go to the Arduino

Hope that helps.

Hi Guy

It does help.

Sorry , last one

The headers 13 - 8. I can see that cable are there. Looks like Red and Green but could be more. Are there others and what nos did you use in the header?

Danny

[samtheeagle]

I've used Red, Green, Blue and Yellow wires. They are connected to the following pins as defined in the Arduino code:

const int pinEast = 2;      // RA+   (red)
const int pinNorth = 3;     // DEC+  (green)
const int pinSouth = 4;     // DEC-  (yellow)
const int pinWest = 5;      // RA-   (blue)

[Dante]

I've used Red, Green, Blue and Yellow wires. They are connected to the following pins as defined in the Arduino code:

const int pinEast = 2;      // RA+   (red)
const int pinNorth = 3;     // DEC+  (green)
const int pinSouth = 4;     // DEC-  (yellow)
const int pinWest = 5;      // RA-   (blue)

Hi Guy

Thanks for that. Just as well really as I had Red in 8, Blue in 9, Green in 10 and Yellow in 11.

I haven't managed to get the Arduino software yet it is downloading at 15KB a second and the file as you know is huge 85.5 MB.

One more question - sorry

The RJ12 Socket - how did you attach the wires? I've seen little box section connectors in computers but can't find a supplier.

Thanks again, be a bit lost without you.

[samtheeagle]

Hmmm yeah, I had a real job finding them until I knew they were called RJ-12 A.K.A. 6P6C. An example retailer: MH CONNECTORS|MHRJJ66NFV|SOCKET, RJ12, 6P6C | Farnell United Kingdom

But just google for "RJ-12 socket" or "6P6C socket" for more options