Arduino ST4 telescope control

Telescope GOTO and autoguiding through ST-4 with an arduino

Similar projects worth following
The purpose of this project is to connect a telescope to a computer through the mount guide port (ST-4 port) using an arduino in order to cheaply add GOTO and autoguiding capabilities.

The ST-4 Port is easy to add to "low cost" motorized mounts like the EQ4 or EQ5, and the operation requires minimal modification to your shiny mount.

Hardest part is the code (Arduino sketch ~120 lines and ASCOM driver ~2600 lines), but I already wrote it for you :-)

Basically, you need to build the USB-ST4 interface described in the github project page and modify your control pad like explained here if it doesn't have an ST4 port.

Modifying the control pad means soldering and wiring an RJ12 socket to the pad buttons.

Once the hardware is done, you will need to install the ASCOM platform and the driver.

After this you can use a software like the open source stellarium to play with your telescope or PHD for astrophotography.

More details are available on the github project page.

Sample video of the telescope moving:

  • 1 × Arduino For interfacing with USB
  • 1 × TLP521-4 optocoupler In order to isolate the arduino from the autoguide port
  • 2 × RJ12 socket 1 if your mount already has an ST4 port
  • 1 × RJ12 straight cable To connect the adapter and the mount
  • 1 × A case for the adapter Excepted if you prefer to see the bare electronics :-)

View all 6 components

View project log

Enjoy this project?



Serhii Solohub wrote 3 days ago point

Thnx, your schema helped me to figure out the troubles with ST-4 port for my controller :-) .

  Are you sure? yes | no

elfirmamento.astronomia wrote 09/04/2020 at 19:09 point

Hello my name is Walter, I am from Argentina. I have a 150x750eq3 with dual axis motorization.

I have built the layout that appears in this website and I am having the following problem:
Using the software both Cart du Ciel and Stellarium do not send a signal to the motors, but they do if I use ASCOM sending the commands. Thanks for your time.

  Are you sure? yes | no

aaron.ruhs wrote 05/09/2020 at 16:43 point

@Kevin Ferrare Hey, great project. I'm think about equipping my Star Adventurer with declination guiding (can only RA out of the box, no dec. motor avail.).

Where can I get information on the signal on the two dec. lines from the guider. Simple pulses on one or the other line for left or right ?

Varying pulse lengths? Or only varying pulse count ?

I would be so grateful if you tell me how it works or where I can find the specs.

Thank you in advance : )


  Are you sure? yes | no

Kyle h wrote 08/09/2019 at 17:55 point

@Kevin Ferrare Question, were you able to get ride of your control box for the EQ motors? Or did you jsut add this into it so that it controls your EQ from computer

  Are you sure? yes | no

Conrad12n wrote 12/15/2018 at 20:53 point

I am trying to implement this on a Losmondy G11 mount. Single axis drive on either axis works fine, however when I try to get RA and Dec simultaneously the mount does strange things, basically one or both axis stop working. At first I thought I was input power limited but I boosted the available current and keep getting same result.

My implementation has LED's on the input to the opto-isolator (very helpful for diagnostics) so I know the signal is getting thru the Arduino. Also I see the resistance on the output side of the coupler dropping when I command the axis ( single or dual axis)

I have seen some comments suggesting the G11 mount (non Gemini, 492 DDS, quite old pre 2000) only works with a single axis driven at a time.


1) has anyone seen similar results?

2) Is there any modification that drives the axis serially, completing one move before starting the other?

In measuring the rpm of the axis motors I find they are turning 10-15 % slower than they should (AT 16 X speed) This may be compensated by adjusting the stated rates in the input.

  Are you sure? yes | no

Kevin Ferrare wrote 01/07/2019 at 22:33 point

Hi @Conrad12n 

I had the issue with almost dead batteries, but it seems that in your case this is a limitation of the mount rather than an easily fixable issue.

If you feel like it, modifying the code so that both axis are not active at the same time is actually quite simple:

Remove the if (async) and only keep what is inside the else. This way, each axis command will wait until completion.

I would add this as an option in the next version of the driver which is pending proper testing before release ...

Regarding the speed rates, you can adjust them in the dialog to match the actual measured speeds

  Are you sure? yes | no

stevemcclure wrote 08/30/2018 at 16:30 point

This looks like an amazing project and right up my street, so pleased to find something like this and credit to you for sharing this.

I have ordered all the electrical components plus a breakout board and hope to put everything in a small project box.

Regarding the arduino code, when verifying it I get an error of “resetpins was not declared in this scope” I imagine this is me not doing something right, but any help would be greatly appreciated.

  Are you sure? yes | no

Kevin Ferrare wrote 09/01/2018 at 23:21 point

Thanks for reporting the issue, apparently the ino file needed an update to compile with arduino 1.8 (it was initially developed with 1.6 and I never installed newer versions on my computer).

I fixed it and pushed it:

  Are you sure? yes | no

h.movahedi.m wrote 08/16/2018 at 13:24 point

Thanks sir.

This is very useful for me in my autoguider project.

  Are you sure? yes | no wrote 03/19/2018 at 19:16 point

Any idea if this would work with a Bushnell Northstar to track low earth orbit sats?

  Are you sure? yes | no

Kevin Ferrare wrote 07/31/2018 at 16:32 point

I don't think so, the objects will probably move too fast for the mount.

  Are you sure? yes | no

licvinka59 wrote 02/01/2018 at 17:46 point

Thank you for the ST4 driver, Kevin. Found this thing almost two years ago. Everything worked out. There are PHD and GOTO. Could not resist not thanking. )

  Are you sure? yes | no

Kevin Ferrare wrote 02/05/2018 at 16:12 point

Thanks for the kind message!

  Are you sure? yes | no

Alexander Axglimt wrote 10/10/2017 at 13:35 point


I have been using your arduino telescope control hack with success for a year! Mainly used the GoTo function. Even though it it way off when slewing, since i'm using plate solving it does not matter, just slew again and platesolv until the target is centered, and luckily APT does this automatically, so it is still much faster than trying to find invisible dso's manually :D

However, the issue that DEC is reversed after meridian flip and that the goto's are way off, is a little frustrating... Now i read in the comments that you have release a beta version that takes care of meridian flip! :D , so i will download that and test...

Regarding slewing... since mount has 16x i guess i will have to play with the Axis sideral rates in the driver? Would it work to tweak these numbers until the slews are better?

  Are you sure? yes | no

Kevin Ferrare wrote 10/10/2017 at 14:08 point

Hi Alexander,

Poorly tested next version with meridian flip is here:

I wish I had time to take my telescope outside to properly test it and release it. Last time I could do this, the battery was dying and slews were not accurate at all so I couldn't validate the build and release it.

If you use 16x, you need to properly configure it in the driver, else it will be way off indeed :-)
With the new version, the +1/-1 you need to apply on right ascension is automatically done by default

Please tell me if you make it work as intended or if the result is not as expected!


  Are you sure? yes | no

Alexander Axglimt wrote 10/11/2017 at 05:42 point

Sure! Unfortunately i've had bad weather here for a long time... i hope it will clear up soon so i can test.

One question, how does the driver know that you are on the other side of the meridian? Is there position feed-back from the software (APT) to the driver?

  Are you sure? yes | no

Kevin Ferrare wrote 10/11/2017 at 07:24 point

The beta version of the driver has a checkbox to tell whether it is meridian flipped or not. This is a parameter that is setup at connection time though.

  Are you sure? yes | no

Alexander Axglimt wrote 10/11/2017 at 08:36 point

Ok, so it should work to disconnect the scope in APT, tick the checkbox  and re-connect it in APT?

  Are you sure? yes | no

Kevin Ferrare wrote 10/11/2017 at 08:42 point

Exactly, for now you need to reconnect.

  Are you sure? yes | no

Alexander Axglimt wrote 10/11/2017 at 08:47 point

Sweet! Now i don't have to manually throw a switch on the hand controller anymore!

Have you any plans to bypass the hand controller altogether and drive the motors directly? That would allow for higher slew speeds, different tracking speeds, etc.. right?

  Are you sure? yes | no

Kevin Ferrare wrote 10/11/2017 at 08:56 point

Bypassing the controller would improve performance a lot indeed, however there is already a project for this:

  Are you sure? yes | no

Alexander Axglimt wrote 10/11/2017 at 10:39 point

Hmm, yeah but that one requires programmed pic's... I think you could do it better and simpler! I have faith in you! :D

  Are you sure? yes | no

Kevin Ferrare wrote 10/11/2017 at 11:42 point

Thanks ! However there is already an arduino version of it for those feeling lazy :D

  Are you sure? yes | no

stephan_bock wrote 10/07/2017 at 06:52 point

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.


  Are you sure? yes | no

Kevin Ferrare wrote 10/10/2017 at 13:56 point

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.


  Are you sure? yes | no

subscriptions wrote 08/14/2017 at 16:19 point

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.



  Are you sure? yes | no

Kevin Ferrare wrote 08/15/2017 at 11:45 point

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.



  Are you sure? yes | no

subscriptions wrote 07/11/2017 at 15:50 point

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?



  Are you sure? yes | no

Kevin Ferrare wrote 07/11/2017 at 16:27 point

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:



  Are you sure? yes | no

subscriptions wrote 07/11/2017 at 16:41 point

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.

  Are you sure? yes | no

Kevin Ferrare wrote 07/11/2017 at 18:28 point

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 ...

  Are you sure? yes | no

subscriptions wrote 07/12/2017 at 05:54 point

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.

  Are you sure? yes | no

Kevin Ferrare wrote 07/12/2017 at 07:06 point

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?

  Are you sure? yes | no

subscriptions wrote 07/12/2017 at 07:33 point

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.

  Are you sure? yes | no

sudhangshughose wrote 07/08/2017 at 14:14 point

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.

  Are you sure? yes | no

Kevin Ferrare wrote 07/11/2017 at 16:23 point


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

  Are you sure? yes | no

Mark Bowles wrote 04/14/2017 at 17:13 point

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!

  Are you sure? yes | no

Kevin Ferrare wrote 04/18/2017 at 12:14 point

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:

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


  Are you sure? yes | no

subscriptions wrote 03/15/2017 at 10:58 point

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-"){
    else if(opcode=="MAIN_FOCUS_OFF"){
      // Reset focus pins.
    else if(opcode=="MAIN_FOCUS_IN"){
      // Focus in
    else if(opcode=="MAIN_FOCUS_OUT"){
      // Focus out.;
    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

  Are you sure? yes | no

Kevin Ferrare wrote 03/16/2017 at 11:14 point

Hi Steve!

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


  Are you sure? yes | no

subscriptions wrote 03/16/2017 at 17:04 point

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).



  Are you sure? yes | no

subscriptions wrote 02/19/2017 at 11:27 point

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.



  Are you sure? yes | no

Kevin Ferrare wrote 02/23/2017 at 10:57 point

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:

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?


  Are you sure? yes | no

subscriptions wrote 02/27/2017 at 06:55 point

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):

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

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.



  Are you sure? yes | no

sebktm620 wrote 02/28/2017 at 12:13 point

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 

  Are you sure? yes | no

subscriptions wrote 02/17/2017 at 14:18 point

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.



  Are you sure? yes | no

subscriptions wrote 02/17/2017 at 15:39 point

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

  Are you sure? yes | no

Kevin Ferrare wrote 02/17/2017 at 21:50 point

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:

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.

  Are you sure? yes | no

reynoldsunnyfrancis wrote 02/12/2017 at 12:52 point

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?

  Are you sure? yes | no

subscriptions wrote 02/17/2017 at 14:23 point

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.

  Are you sure? yes | no

subscriptions wrote 02/17/2017 at 14:38 point

Oh sorry, you did use a multi meter.

  Are you sure? yes | no

Kevin Ferrare wrote 02/17/2017 at 21:43 point

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.

  Are you sure? yes | no

Mark Bowles wrote 12/23/2016 at 22:16 point

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.

  Are you sure? yes | no

Kevin Ferrare wrote 01/12/2017 at 21:10 point

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.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates