Hi Kevin,

I recently found your project and I decided to go ahead and make my EQ5 into a GoTo mount. It worked fine, thanks to your detailed description.

Nevertheless, I modified the solution slightly. Instead of using pins 2,3,4,5 I used 2,4,6,8. Why? Because it made a much nicer layout on the stripboard with the optocoupler next to the Arduino. If you like, I can post a quick picture of the finished product.

Next is autoguiding - a quick test with PHD2 already showed potential...

Thanks again for the inspiration and writing the driver code.

Stephan

Hi Stephan,

Thanks for your comment!
Indeed, it makes more sense to have only one every 2 pins connected to the optocoupler since it leaves space for the ground.
If I recall, I think I did like you in the version I use with the optocoupler on a PCB.

Regards,
Kevin

Hi Kevin, One of the things I want to do is really remote control.  I now have Arduino powered goto and guiding (coutesy of you), Arduno-powered remote focusing (but not yet full HFW-stle algorithms), Arduino-powered camera release and remote USB camera control.

But I can't turn it all off remotely.  It struck me that if we had some sort of toggle switch, like the optocoupler, that stayed on or off, even if the Arduino rebooted, it could be used to control the power cable to the remote handset.

What sort of electronic component would work like this?  A sort of semi-permanent, toggle relay.

Regards

Steve.

Hi Steve,

It seems like you built quite an impressive setup! I would be very interested in seing some pictures :)

I would love remote control as well, to get rid of all the cables waiting for you to trip over in the dark night.

One year ago I started to experiment with bluetooth connection (HC-05 bluetooth to serial), and I got it working, but I never completed the project, mainly due to a lack of time. I wanted to put all the electronics including the battery into a single box attached to the mount.

Regarding the component you are looking for, as far as I understand, a latching relay would do the job.

Regards,

Kevin

Hi Kevin.

To continue the saga, I now have guiding, focusing and remote exposure all working on the Arduino.  I'm planning to implement fan control in the same way, and maybe even weather.  I was also trying to use it to do limited star-hopping eg Vega to M57, because otherwise I find some of these Deep Sky Objects difficult to locate, however, it always seemed to send me off to the other side of the galaxy and I couldn't work it out until I realised that my meridian flips were reversing all my Dec commands.

Have you come across this, and what have you done about it?

Regards,

Steve.

Hi Steve,

I was preparing a version with meridian flip taken in account in the ASCOM driver for GOTO.

It is unreleased and not well tested due to lack of time, if you want to give it a try, it is here:

https://drive.google.com/open?id=0B04IJvbw0nqmYWh6aVZwcXlNUzQ

Regards,

Kevin

Thank you for this, and for your quick response.  Sadly, I don't use Ascom, I'm Linux.  Do you just reverse the Dec pins?  Is that all there is to it?

Presumably you don't need to reverse the pins for guiding, since the guide camera is also reversed.

Basically yes, the driver inverts the commands it is giving to the mount for DEC.

For guiding, I don't see why you would have to do anything indeed, excepted in cases where you would like to recalibrate drift rates if this is ever useful.

I never tried guiding with meridian flip so I may not be correct ...

Yes, that is what I understand too.  I was testing at the weekend and everything pretty much worked except for the GOTO.  In fixing the GOTO, I don't want to break the guiding.

Well if you want to use both GOTO and autoguiding, there is an option in the unreleased driver to do the meridian flip so that the calculation for GOTO movements takes in account the inversion of DEC axis. There is also an option in PHD to revert the controls (to cancel the driver inversion for guiding).

Did you get a working goto under linux?

Yes, my GOTO works, but only for small distances, since the slew rate is only 16x.  I tend to star-hop within a constellation, or two local constellations, otherwise it's quicker to go outside and move it manually.  I just wrote a python program to send your DEC# and RA# to the serial port and it all works beautifully.

And my calculations are not correct yet, because of the Meridian flip.

I've updated the calculation and next time I get a clear night I'll check it.

I have created two "hubs" to append to the Arduino.  So the Arduino is in one box on a small table under the mount together with the "Mount Hub", a powered USB hub and the drive handset, while the "OTA hub" is on the focuser connected with a VGA cable (15 cores).  That means I only need one cable running up the tripod.  Actually, all my focusing, exposure and dew controllers in the OTA hub are much more successful than the DEC/RA controls on the Mount Hub!  Which is a bit sad. However, I keep on going.

Hi Kevin,

First of all thanks a lot for this nice project. I have followed your project meticulously. I could able to control the eq3-2 mount. I have one silly question. How the system (stellarium) could understand the starting position of the scope to use goto feature. (In my case at starting the scope marker on stellarium starts well below from horizon. I live in Northern hemisphere approx 13 degrre N). Apology in advance if i sound silly.

Hi,

GOTO works like this:

 - You manually point the telescope to a known star

 - You tell stellarium that it is pointed to this star (SYNC operation)

 - Then you select the destination in stellarium and press SLEW

Hi Kevin

I got the project to work with my Skywatcher Star Adventurer mount, but I can only get it to work in track mode speed and not at x12  so it is impractical to use unfortunately.

It maybe possible to override the speed controller to enable higher slew speeds within the mount, but this of course would mean opening the mount invalidating the warranty, perhaps next year maybe!

Hello Mark!

I just looked up your mount on the internet and it seems that the built-in autoguiding is single axis.
Adding an ST-4 port that would work at 12x could be done by soldering an RJ12 port directly on the control buttons, a bit like this:
http://thx8411.over-blog.com/pages/Add_an_ST4_port_on_the_EQ4EQ5_motor_drives-3258969.html

If you ever feel like opening your mount, please post the results here!

Regards,
Kevin

Hi Kevin,

This project is like a supertanker.  It just keeps going.  Here are my latest changes to the Arduino code, to manage my cheap skywatcher focuser and DSLR shutter if anyone is ineterested.  I used optocouplers and wiring mods the same way as you did to short out the buttons on these bits of kit.  I also defined the focuser as a thrid axis on the OTA, so I have RA (+/-), DEC(+/-) and FOCUS(+/-).  Shutters obviously don't go in and out.  See below.  

else if(opcode=="DEC-"){
      declination.minus();
    }
    else if(opcode=="MAIN_FOCUS_OFF"){
      // Reset focus pins.
      mainFocus.reset();
    }
    else if(opcode=="MAIN_FOCUS_IN"){
      // Focus in
      mainFocus.minus();
    }
    else if(opcode=="MAIN_FOCUS_OUT"){
      // Focus out.
      mainFocus.plus();
    }
    else if(opcode=="S1"){
      digitalWrite(shutterPin, HIGH); // sets the camera shutter on
      digitalWrite(pinLED, HIGH); // sets the LED on

    }
    else if(opcode=="S0"){
      digitalWrite(shutterPin, LOW); // sets the camera shutter off
      digitalWrite(pinLED, LOW); // sets the LED off
    
    }

Hi Steve!

Nice to see that you are extending the possibilities of this small project!
Did you make a driver to support your changes?

Regards,
Kevin

Not really because I'm only using it in a custom application written in python.

It would be nice to write some drivers once everything has settled down and is working well.  I was out last night doing goto, really for the first time only do discover everything moved in the wrong direction. I guess I wired the st4 back to front, but it's easy enough to change but changing the pin allocations on the arduino.

So my app started off managing a satellite dish, but now manages my ota with guidescope and dslr (using gphoto2 if you haven't seen it).

Regards

Steve.

Hi Kevin, 

Have you had any thoughts about controlling the other switches on the handset, like the tracking speed (x.5,x2,x16) or type (solar, lunar, stellar).  I guess the same approach could be adopted, but you'd need to introduce a new socket (or sockets) into the handset.  I don't really like wiring up the 6c6p because they are fiddly and cutting a small square hole is also difficult to do neatly.  Maybe a 2-channel (ie 4 cable) 2.5 pin audio jack and socket might be the answer.  You could drill two small holes into the case.  In fact a single ten-pin socket might do the trick or even a vga socket and cable.

I have an old (ie not ST-4 enhanced) eq5 handset, that I might experiment on.  Have you tried this.  Basically, using an optocoupler to short pins on a switch should work with any DC switch, don't you think, even a three way one, assuming it has a common ground?  One coupler for each position.  So a 4-way coupler like the one we used on this project would do the trick for one switch, and a 4-way + 2-way would do the trick for both of them.  The issue is doing it neatly.  I just hate these lovely instruments looking like something out of a an electrical safety infomercial.

Let me know what you think.

Regards

Steve.

Hi Steve,

Your comment reminds me of a thought I had some time ago, about adding a wire to control the overclock of the mount in order to get even more speeds:
http://orlygoingthirty.blogspot.fr/2010/06/telescope-mount-hacking.html
http://www.webastro.net/forum/showthread.php?t=112141

For me, it is possible to do what you propose with some more electonics as you mentioned, and also a modification of the driver to expose the additional tracking speeds and to allow the control of the arduino.

Are you thinking about being able to let software like PHD fine control the guiding speed?

Regards,
Kevin

Hi Kevin,

Yes I'm trying to set up guiding.  I tried PHD2 and lin_guider with little success. So I found this guy's code (written in Python):

http://sy2000.blogspot.co.uk/2014/05/star-autoguide-with-rpi-5-python-code.html

and I'm currently modifying it.  I'm SteveBz in this discussion:

https://stargazerslounge.com/topic/285181-diy-eq2-economy-autoguiding/?page=2#comment-3155929

You can see there are a couple of references to this project and you can see my effort at the Ardiuno.  You can also see two screen dumps of my front-end to Maple's code using a test star.

Two points:

1) I'd love to overclock it. I have 16x, but really the proper goto mounts have 800-1000 times and this is what I'd like.  Even 32x is only a small jump and I've read elsewhere that the standard motors won't take 800x.  You'd need stronger motors.

2) Secondly, It strikes me that the other switches (sun, moon etc + 16x, 2x, .5x), Could both be achieved by setting the handset to max (say 16x) and then using PWM on the Arduino to underclock it.  Fewer drill holes in the handset.

Regards

Steve.

Hi Steve,

i'm replying to your comment below. I also had problems with permissions but it should work if you are in the dialout group. For the other problem, you should check if the ENDPOINT_INT_IN/OUT is correctly set. But this is just a guess... What kind of hardware do you use? 

Greets Sebastian 

Hi Kevin,

If I wanted to try the Ascom driver on Linux, which files do you think would I need to compile?  There are a lot of files on github and some are obviously important while others are documentation or windows specific.

Regards

Steve.

Hmm... OK.  Ascom doesn't fly on Linux. Needs Indi.

The current code in github only supports ASCOM which is windows only.

There are however 2 unofficial indi drivers made by other developers that you could try:

https://github.com/tliff/indi_ardust4

http://www.indilib.org/index.php?option=com_community&view=inbox&task=read&msgid=359&Itemid=1140

Having an official indi driver is on the todo list, although making it support all the functionalities of the ASCOM driver is going to be a lot of work.

I assembled,wired everything.  Serial commands going through and Arduino responds back with ok# for ra-#,ra+# etc. Checked with multimeter and found contacts opening and closing on the output side of optocouplers.So the circuit is working perfectly. But on connecting with rj12 cable jacked to ST4 port on  my EXOS2 GOTO mount, no response from the mount. Tried interchanging wires here and there. But no response from mount. Checked the st4 terminals on mount. It shows 5V between ground and 4 other terminals. The last terminal is free. So any way to make it work with EXOS2 GOTO mount from Bresser? I heard that its same as LXD75. I don't have the pinout for this mount's st4 port. I have written a mail to Bresser. But can u tell me anything?

The important thing is to get the ground connection sorted out. Once you've done that the rest is debugging.

Maybe a multimeter would help. If you think about it, any switch can be shorted with the correct optocoupler, as long as it's the right way round.

Good luck.

Oh sorry, you did use a multi meter.

Are the motors moving when you short some of the ST4 terminals to the ground on your mount? If so, you could deduce the pinout of your mount and modify the connections to the optocoupler accordingly.
I would be interested to know whether it finally works for you or not, and if so what was the pinout.
I am thinking of making pinout configurable in software since it seems that not all mounts have the same connections.

I have assumed that 'GND, PIN2, PIN3, PIN4, PIN5' on your diagram are referring to GND, D2, D3, D4, D5 on the Arduino, otherwise I have found the project fairly straightforward so far.

Apparently, mounts from different manufacturers use different pin assignments, it seems that there is no standard for this.

I guess that even if you don't connect the wires right, you should be safe since the connection between the arduino and the mount is optically isolated. As long as the GND correspond, the only effect should be that the mount does not behave as expected. 

Also, the pins (excepted GND) can be reassigned in software by editing the arduino firmware.

Maybe I should make this an option of the ASCOM driver.

Can someone confirm that I need to swap the connections over on the RJ12 socket as they do not correspond to the socket on the Star Adventurer? I.E pin 6 on the diagram is pin 1 on the SA socket and GND is pin 5 on the SA socket.

Hi there, very interesting.

Not sure how the device is connected to the computer on one hand and to the telescope guiding port on the other. I guess the RJ12 port and the telescope port are connected via ethernet type cable and the arduino is connected to the computer. However,  many cameras such as the Meade DSI have only a printer type cable that would be connected to...? Summarizing, a complete layout of the cabling would be much appreciated. BR/Pablo

Wait. The DSI camera goes to one usb port in the computer and then the computer uses the device on a second usb port to the telescope, right?

Exactly, this device is only there to allow the computer to move the telescope, not to control the camera.

So connection in your case would probably be:

Computer USB -> arduino -> mount rj12

Computer -> camera

Hi Kevin,

Great project.  Just ordered the bits off eBay.  I bought an old satellite dish (also off the Bay) and I've got it mounted on my trusty driven CG5 mount.  I've written a bit of python to collect input from the radio feed and turn it into a sky bitmap, now all I need are a few resistors and stuff to steer the mount to do a Sky scan (eg 30 seconds RA x 30 seconds dec = 15 minutes).

Steve.

Took some time but now it's finished! Goto works great! I move the mount manually as close as possible, then use APT to blind-solve, slew, blind-solve, center target. So no alignment is necessary.

Thank you for doing this!

Glad to hear it worked for you!

Cracking bit of work, working up the bottle to attack my non goto HEQ5 too, as well as another tripod and mount. a massive saving on the £300 upgrade kit. I should buy you a beer if I get it all sorted :)

All parts ordered from ebay! :) So tired of trying to find the DSO's on my non-goto HEQ5... So, if this works i'll be in heaven! :)

I have almost the same mount :) Don't hesitate to contact me if you need some help! With this, finding deep sky objects is very straightforward.

Great project, myself is just starting out with the arduino for controlling a scope.

Thanks Kevin, great project. ¿How would you outline a project to have it working in Android?

I tried your project on a Teensy 2.0 and it worked with only changing two single lines in the code. Tested it on my star adventurer but there I had to reverse the pin orders for the j12 plug. Then it worked in phd 2. So kudos for you! But I wan't to use it with in_guider running on a RPi 2. Lin_guider has native support for GPUSB but the Teensy is not recognised... Can you help me or have you tried lin_guider? 

Hello,

I looked at lin_guider source code and it seems that it is driving telescopes with its own drivers.

So I guess that you won't be able to use this project with this software unless you either:

 - Write a lin_guider driver

 - Modify the arduino code to behave like one of the supported devices

Yeah, I also looked at the code and probably modifying the arduino code to behave like the GPUSB device, then I can modify the GPUSB driver given by lin_guider to accept the teensy. But thanks again for your help & Project!

@sebktm620

This project uses the serial over USB capabilities of the arduino to communicate with the host.

However, looking at the drivers for GPUSB, I think that it is using direct USB communication.

If you try, I would be interested in knowing the result. Good luck!

I managed to get lin_guider talking to the Teensy via the libusb commands. So lin_guider connects and sends commands. The only thing I'm puzzling about is the correct commands. At the moment I'm just parsing the lin_guider commands to the strings your code understands, but I don't understand how lin_guider is timing the lengths of the pulses. 

There is a documentation of the set of commands implemented on the board available here:

https://github.com/kevinferrare/arduino-st4#flashing-the-arduino

The commands allow you to start and stop movement along the RA/DEC axes (this is all the ST-4 port allows you to do).

If you send for example "RA+#", the RA axis will move in upper direction until you send either "RA0#" (stop) or "RA-#" (move in lower direction).

This very simple protocol is sufficient for pulse guiding.

GOTO functionality is using this set of commands.

The timing is calculated in the driver running on the computer, which computes when each axis should start / stop slewing and executes the commands with the correct timing.

I hope this answers your question.

I got it working last night. Tried it with my Star Adventurer on tenerife. This mount only moves in RA so there was still some drift in DEC but as far as I can tell it was guiding properly. 

Nice!

Would you mind sharing the modifications you made to lin_guider? I would be interested.

Here you go:

https://www.dropbox.com/s/4ujh4j4p26bnief/io_gpusb.cpp?dl=0

I only changed the vendor id and product id, in and out endpoints and the parsing of the bits to your string commands. Also the interface i'm talking to is different than for gpusb. There could be some bugs because I had to rewrite everything from scratch last night (11pm...), because the raspberry image I was running lin_guider on was corrupt. For the arduino code I only omitted the OK commands, because lin_guider doesn't listen to them.

Thank you for sharing!

Do you mind if I clean it a bit and upload it to my github? Or maybe you could submit it to lin_guider? It may be useful to other.

One issue to solve may be the variety of USB ids of the arduino ide compatible boards. Using a list of vendor_id / product_id and probing for each element until the device is found should work.

No I wouldn't mind. I was also thinking of sharing it with the hobby astronomy community and lin_guider devs.

@Kevin Ferrare

I could test the guiding with a losmandy g11 on my last day on tenerife and I found a small typo in the parsing code, which only affected DEC guiding. I updated the source in the dropbox.

Hi Seb,  great job on writing the lin_guider driver.  I downloaded it and compiled it in lin_guider but I'm not sure I got it right.  I changed the vendor and product ids, which seems to work.  I got a whole load of permissions errors so I'm running under root (what groups do I need to join?), but my main issue is that after "if( (m_handle = locate_and_open_device( GPUSB_VENDOR_ID, GPUSB_PRODUCT_ID)) == NULL )", which works I get "-1" for "rcode = libusb_bulk_transfer".

Any ideas how to debug this?

hello do your project and it works very well with Cartes du Ciel but with stellarium no way it works for you tell me how to do it because I read and watched videos of how it's done but do not work I thank you for your project works perfectly very grateful for his contribution

Hello, stellarium cannot use ASCOM directly. I use The StellariumScope program which creates a bridge between ASCOM and the stellarium network telescope control interface:

http://www.welshdragoncomputing.ca/index.php?option=com_content&view=category&layout=blog&id=31&Itemid=39F