PHD -> Arduino -> DIY Mount

[John78]

Afternoon folks,

I have been perusing this morning and find the simplicity of an Az-Alt mount to my liking, to do what I want with it, it would need to be guided. After poking around I found PHD which seems pretty straight forward.

Now the bit I cant seem to find much information on either their website nor ASCOM website of what information the pulseguide() function that PHD uses actually spits out down what port of the PC?

Presumably all I need to do is intercept this output with Arduino and convert it into pulses to steppers or servos to move the mount? As its closed loop I presume it doesn't even need to be a perfect interface?

As its only one function coming from PHD its not like I need to implement the entire ASCOM on Arduino.

Thanks for any input.

[arad85]

Make sure an alt-az mount will do what you want it to. Guiding is only generally needed for long exposure photography and you will need a wedge on an alt-az mount to avoid image rotation (and consequently funny shaped stars). This is both mechanically difficult to achieve with any sturdiness and quite costly... If long exposure photography is what you want to do (which is what I am assuming you want to do if you're thinking of PHD) you would probably be better off with a German Equatorial (which is, after all, an alt/az on an angle)...

[John78]

Good point ref image rotation. Even if I make a GEM and guide it with PHD I still need some interface hardware presuming I DIY rather than OTS it.

[arad85]

True...

As a start, you could download the source code for the EQMOD project - it can pulseguide the EQ6 platform - perhaps that would help you.

Bear in mind that the mount is more than 50% of astroimaging... If you're thinking of guiding, you need to be thinking of something as good as the HEQ5 or better....

[SteveL]

Are you just trying to automate the mount (GOTO), or make an AltAz mount move across the sky in a pseudo EQ sidereal rate, or do you really want to autoguide it (with seperate guiding camera and scope)?

Be aware that the guiding requirements for AltAz will change as the object moves across the sky, so you will need to be constantly recalibrating PHD. As your guiding session progresses, it will become progressivly worse and worse due to this until you recalibrate.

pulse guide via the serial port is basically "move DEC axis +/- for X ms, move RA axis +/- for Y ms)", which is interpreted by the controller board into the correct functions for it to do that. Guiding via ST-4 is just a digital on/off for the RA and DEC Axis, which you would need to convert from RA/DEC to AltAz dependant on where in the sky you are currently pointing.

[John78]

Imaging is the primary use - but I was being a bit naive - clearly I need a GEM (or other equatorial) for image rotation.

Guiding sounds like fun, and (at least appears) to take some of the construction difficulties out as you have closed loop control over what you are looking at.

The GPUSB I presume is basically just a USB->Serial->ST4 adapter, as a lot of their guides detail sticking its outputs onto the switches in the hand controllers.

Now if PHD just writes to the serial port a string like that - grabbing it with Arduino (or infact use its onboard usb-serial), then driving a DIY GEM should be relatively straight forward - I don't see anywhere on PHD to select the COM port though which is why I am currently baffled

[SteveL]

You need to select an ASCOM mount driver by clicking on the telescope button in PHD, and the driver sends the commands to the mount

.... but you wont/dont have an ASCOM driver for your DIY mount.

[John78]

Here is a USB->ST4 via PIC inc software

Autoguider adapter: USB to ST4 output guider

If you can do it with a PIC, you can do it with an AVR....

[John78]

You need to select an ASCOM mount driver by clicking on the telescope button in PHD, and the driver sends the commands to the mount

.... but you wont/dont have an ASCOM driver for your DIY mount.

Well partly - thats the point - I would need to implement the interface via the Arduino - but I guess it has some kind of hand shake that would need to respond to keep the PHD happy?

[SteveL]

If you autoguide via ST-4, then PHD just sends up/down/left/right pulses. If you want to connect via serial, then you will need to write an ASCOM driver so that PHD can select it and use it.

[John78]

I take it that's the 'on camera' option? Does that send those pulses to the serial or parallel though? Parallel is obsolete which means you'll still need a usb-parallel adapter anyway...

The documentation for all these things don't seemed aimed at the DIY'er....

[SteveL]

As I have never used ST-4, I`ll have to take a back seat from here...

[daz]

ST4's are normally sent from the camera direct to the mount to the ST4 auto-guide port, not via the computer.

ASCOM doesn't see (or care) about what the physical port is. All is knows it is a COM port - that can be physical (Serial, Parallel) or Virtual (USB-SERIAL).

You could always email Craig at Stark Labs, sure he'll be able to help with the PHD questions...

[lynol1000]

Start with an ASCOM Telescope driver as your template. Choose Meade or the Simulator.

Have VB6 or VB-NET/VC++ Microsoft compilers available depending on what you template requires.

PHD supports ASCOM driver and will use only the 'Connected', 'IsPulseGuiding', properties and 'Pulseguide' method of the Telescope interface.

You will of course need the ASCOM frmSetup to configure what your driver requires.

I suggest downloading ASCOM and playing with the Camera and Telescope Simulators in PHD. Turn 'Traffic' on in each driver so you can see what PHD is sending.

Download the source also for the drivers, you get an option on install to also load the source.

Please be advised the latest ASCOM has a software license not allowing derivative works without permission. You would need permision of the author and not ASCOM org.

The older ASCOM 4.1 drivers were done by Space.com and do not have this dirivative works license.

You can get ASCOM 4.1 from the ASCOM site. A driver built from those will work just fine on the latest ASCOM platform and also XP/Vista and W7 if you do not do silly things like writing the windows registry directly, use the ASCOM API's and you are good for the future.

Using an Arduino sounds like an excellent learning exercise but may not be quite cost effective if all you are interested in is guiding and don;t forget your optical coupled ST4 outputs to keep away from ground loop problems.

Gene

Astrogene1000 Stuff

[John78]

Start with an ASCOM Telescope driver as your template. Choose Meade or the Simulator.

Have VB6 or VB-NET/VC++ Microsoft compilers available depending on what you template requires.

PHD supports ASCOM driver and will use only the 'Connected', 'IsPulseGuiding', properties and 'Pulseguide' method of the Telescope interface.

You will of course need the ASCOM frmSetup to configure what your driver requires.

I suggest downloading ASCOM and playing with the Camera and Telescope Simulators in PHD. Turn 'Traffic' on in each driver so you can see what PHD is sending.

Download the source also for the drivers, you get an option on install to also load the source.

Please be advised the latest ASCOM has a software license not allowing derivative works without permission. You would need permision of the author and not ASCOM org.

The older ASCOM 4.1 drivers were done by Space.com and do not have this dirivative works license.

You can get ASCOM 4.1 from the ASCOM site. A driver built from those will work just fine on the latest ASCOM platform and also XP/Vista and W7 if you do not do silly things like writing the windows registry directly, use the ASCOM API's and you are good for the future.

Using an Arduino sounds like an excellent learning exercise but may not be quite cost effective if all you are interested in is guiding and don;t forget your optical coupled ST4 outputs to keep away from ground loop problems.

Gene

Astrogene1000 Stuff

Thanks for the help! Are the strings output on the traffic screen literally what comes down the serial link from PC to camera? Is there expected responses from the scope?

PulseGuide: West, 750: (initiated)
IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True IsPulseGuiding: True
(PulseGuide in RA complete)
IsPulseGuiding: False Slewing: False

I presume the first line PulseGuide: West, 750: (initiated) is from the PC to scope, i'll hook up a webcam and read what actually comes down the port with my Arduino and start properly in the new year...

Yes I like to scratch do things most times for fun and more in depth understanding of what's actually going on - generally takes more time and money but you tend to get a higher quality and more adaptable solution

[lynol1000]

The string shown are not what is sent down the wire.

What any program based on ASCOM does is make a call like:

Syntax

Telescope.PulseGuide(Direction, Duration)

The method syntax has these parts:

Part Description Direction (GuideDirections) The direction in which the guide-rate motion is to be made Duration (Long) The duration of the guide-rate motion (milliseconds) Return (Nothing) Does not return a value.

guideNorth 0 North (+ declination/elevation) guideSouth 1 South (- declination/elevation) guideEast 2 East (+ right ascension/azimuth) guideWest 3 West (- right ascension/azimuth)

Now the ASCOM driver you would supply can implement this method and send anything in any form to cause this to happen to the scope. PHD just makes the call above and you turn it into anything you need.

This could be serial bytes down a wire or pins of a parallel port, PHD does not know or care -how- it is done.

Standard Meade commands are

:MgnXXXX#

For pulse guide north for XXXX milliseconds sent over the serial link to the scope

In my driver, the USB-ST4 does not use this exact command but rather:

:Mg0XXXX#

Where the '0' is direct from the ASCOM API versus the Meade 'n' for north.

Pulse-guiding in ASCOM merely means do this for this many milliseconds, how you do it is up to you.

Gene

[callump]

Sorry a bit late.

Field de-rotation in an alt-az is not difficult to handle.

Mel Bartels hw/sw solution includes stepper driver for a derotater.

Can't say i have tried it myself, though.

/callump

[arad85]

Field de-rotation in an alt-az is not difficult to handle.

Yet more expense and another motor system to control/have errors in....

[callump]

Yet more expense and another motor system to control/have errors in....

Well i would disagree on the expense part, i'm not sure it would add much to the total build cost.

Going back to an earlier part of this thread, if you want to build an equatorial mount for imaging, and looking at a permanent installation, there are a lot easier options than a german mount - english yoke, horseshoe, or split ring or fork - and don't require a meridian flip.

/callump

[lynol1000]

It's possible to go crazy designing a mount, here was my old split ring circa mid 80's.

Provided variable guide rate via DC to AC converter, PEC, tangent arm for dec drive, electronic clutches for RA drive, controlled via figForth, 8inch main, 4.25inch guide scope.

Split ring and equatorial mount/ tracking platform for dob

You could whack it with a hammer and vibrations died in less than 2 seconds.

This mount then morphed into the tracking table shown, which is a viable alternative for an Alt/Az mount albeit the short run times of the sector. I used a direct drive versus a screw lead type.

After the tracking table I came to conclusion was all around 'cheaper' to buy a commercial mount and more fun to then tweak it and design/build everything else for it and imaging.

Gene

Astrogene1000 Stuff