Hey, this seems like a really cool project, so I wanted to make it for my Skywatcher Star Adventurer (2i). Unfortunately I was unable to find the TLP521-4 optocoupler, so I had to get the pc817 4 (on a green pcb) (the only one I could get in a reasonable amount of time). I didn't  think much about it, but after trying it out it didn't seem to work. Does anyone know if that optocoupler should be usable (or if it's just me doing something wrong). The optocoupler does get the signal from the arduino (LEDs on it blink), and I was able to see a change in resistance when it was enabled, but the Star Adventurer didn't get any signal (the LEDs weren't blinking). Is there a way to test if it might just be the mount's st4 port that is broken (like connecting the wires by hand maybe)? Thanks in advance, Sam

hello and congratulations on your great project
I built as your description, my problem is that at the exit of the TPL521 sending any command eg. RA- output Pin 5 Arduino 4,7 V at the input pin 1-2 TPL521 I have 1,2 V at the output Pin 16-15 0 V ??? this result does not seem normal to me
Thanks again for an answer

This is normal, the TLP is an optocoupler, it acts like a switch so when there is current flowing between pin 1-2, current can pass between 15-16 (closed switch), it's normal to read 0V here :)

Hi @Kevin Ferrare , thanks for this wonderful project, i have a skywatcher star adventurer and was trying to use your trick to use a usb camera. I get the "ok" replies from the serial console but the leds in the mount dont flicker (which means no commands are arriving). Do you think that my problem is that im using PC845 instead of TLP521-4? what would happen if i go directly from the arduino to the rj12? Sorry about my ignorance! thanks for this great project!

I dont think that the PC845 is the issue, specs are similar to the TLP.

Plugging directly the arduino to the RJ12 would not work because ST4 works like button presses which are simulated by the optocoupler.

When you send a command, you can maybe check with an LED connected to the corresponding arduino pin, if it lights up then you can check with a multimeter if there is continuity between the corresponding outputs pins of the optocoupler.

If there is it means that the problem is with whatever you are connecting to. ST4 is not really a standard so pinout can be different depending on the maker.

Did you get it to work in the end?

When PHD2 send RA+# command, RA tracking speed remains adjusted only for 1 arduino clock cycle (and you reset your pins right away), which essentially does nothing noticable and increased pooling rate from PC can't help because your serial interface have default 1000ms timeout (adjust Serial.timeout() ?). Nothing in this project actually helps with autoguiding, it's almost completley unusable. Only thing that helps a bit is catch-22: Switching rate of your TLP521-4 (<100Hz) actually does all of the job, because it keeps "button pressed" for additional 10ms (accidentally?), but you run into async opcode from PHD2... Lot of thing need to be optimized in order to use this effectivelly and method for "pressing buttons" may or may not work, depending on remote controller vendor settings for this button pooling rate.

I am not sure I understand the problem. In the arduino code, the ST4 signal lasts as long as no other command is sent. In ASCOM, it lasts as long as specified by the software, seconds or minutes for GOTO and milliseconds to seconds for pulse guiding.

With Your permission I would like to use your ArduinoST4 ASCOM driver in my Sidereal Sky Tracker project. I assembled platform all by myself, without any proprietary products. Therefore I do not have remote or ST4 port. I implemented ST4 protocol directly via arduino serial interface and abstracted button events with firmware. This way, I am not tied up to 2x, 4x and 8x sidereal speed multiplers from controller, but much like anything, lets say 0.25x-2.00x (0x to 2x for RA, I only have RA axis)... Wish me luck :D

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

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.

Do you mean it works if you send commands directly to the arduino or via some other ASCOM software? If you check the "Debug Log" checkbox in the configuration, it outputs some logs in text files in the ASCOM log folder here: "My Documents\ASCOM"

You could check that the application is correctly initializing ASCOM.

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

Aaron

@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

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.

Questions:

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.

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:

https://github.com/kevinferrare/arduino-st4/blob/master/ASCOMDriver/ArduinoST4Driver/ArduinoST4Driver/AxisController.cs#L169

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

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.

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:

https://github.com/kevinferrare/arduino-st4/releases/download/1.0/ArduinoCode.ino

Thanks sir.

This is very useful for me in my autoguider project.

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

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

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

Thanks for the kind message!

Hello!

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?

Hi Alexander,

Poorly tested next version with meridian flip is here:
https://drive.google.com/file/d/0B04IJvbw0nqmMUJVX25MQ2NJNFU/view

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!

Regards,
Kevin

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?

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.

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

Exactly, for now you need to reconnect.

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?

Bypassing the controller would improve performance a lot indeed, however there is already a project for this: https://www.astroeq.co.uk/

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

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

https://www.astroeq.co.uk/tutorials.php?link=/doku/doku.php?id=buildown

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