EQMac Pulse Guiding (via PHD)

[OzDave]

Hi EQMac users,

I've completed work on integrating EQMac with PHD so that it can receive pulse guiding commands. I am presently waiting for a clear night to give it a test before I make a release, although it does seem like it is doing the right thing when I test it on the mount indoors and run a PHD calibration.

The integration works by selecting Equinox 6 as the "scope" in the PHD menus. EQMac pretends to be Equinox 6 and receives the guide pulses from PHD. You can adjust the guide rate for each axis in the EQMac Preferences window.

The only issue that I am a bit worried about is what happens if you also want to run Equinox 6 alongside EQMac and PHD. I don't think it will cause any harm, although obviously you wouldn't be able to use the mount control / pulse guiding aspects of E6.

So standby for an update including pulse guiding as soon as I can get out to test it properly. Tonight is looking like it might be clear *and* the wife is away, so I may get just manage it this weekend!

Regards,

David

[OzDave]

Ok, managed to get out tonight and do some testing. Below is a PHD graph of the guiding session.

I used my 9x50 finder-guider with my Imaging Source guide camera to track Caph using my crappy old (errm, I mean trusty) EQ-3. It's not the best at tracking things, but it's all I have available at present since my NEQ6 is not at home right now.

I configured EQMac with a 30% (of sidereal) guide rate in both RA and DEC. Then I setup PHD and found the guide star (Caph).

PHD calibrated fine, although I had to set the calibration step size to 2500ms to avoid it taking too long. Once calibrated, guiding commenced as usual. EQMac displays the guiding pulses in the status bar at the bottom (a new feature).

After a short while, the PHD history graph settled down and was pretty much flat as the screen capture below shows. This might be due to using such a short focal length guide scope (i.e. a finder), but I think it shows that the pulse guiding is operating properly.

I am now in the process of packaging up a release (0.0.5). Look for it on the EQMac site shortly.

Regards,

David

[OzDave]

Just a quick note to say that v0.0.5 is now available on the EQMac site.

Let me know if you have any issues, or indeed if works fine for you.

David

[OzDave]

Just wondering if anyone has had a play with the pulse guiding yet?

David

[James]

Can't speak for anyone else but I haven't had a night out with my scopes for a little while As soon as it's clear I'll give it a go

James

[perfrej]

Dave!

Downloaded, and it looks good. I have clear skies (somewhat) forecast for wednesday and will give it a spin then with my DSI II as guide camera. Unfortunately, PHD doesn't support Starshoot Autoguider, but the Meade is **** for imaging anyway so it will be downgraded to guiding.

On Lion, all versions of Mount have been unable to terminate properly. Are you using Xcode 4.1 or something of earlier date? Let me know if you want the crash dump from the quit command.

/p

[perfrej]

A quick note for anyone trying the sync feature of Stellarium!

I just tried it and it appears to do the sync on the center of the screen, not the highlighted object. In other words, do not forget to press the space-bar to center your object before you adjust and then sync!

I found this by selecting a star that was in the upper left quadrant of my screen with a click. Then I pressed CMD-1 to slew to it. After the slew the telescope symbol was centered on the star (still in the upper left quadrant). I used the Mount keys to fake an adjustment, which caused the scope symbol to move a bit in relation to the star. Then, the interesting part: press CMD-2, and the scope symbol moves to the center of the screen, not back to the star.

When I repeated this and added the step of centering the selected object by pressing the space-bar before adjustments, everything worked fine.

So, it seems that Stellarium syncs on the center of the screen...

/p

[buzz]

I left a question on the general EQmod thread - I probably should have put it on this one. I have only just got by NEQ6 mount:

If I'm using a ST4 output from PHD via Lodestar directly into the EQ6 mount, is there any advantage to using pulse guiding? When I had an LX200, it was always said that autoguider port commands were better for guiding accuracy over RS232 slew commands. Is Pulse guiding the same thing as issuing small slew commands or is it a unique feature of the EQ mount?

[OzDave]

On Lion, all versions of Mount have been unable to terminate properly. Are you using Xcode 4.1 or something of earlier date? Let me know if you want the crash dump from the quit command.

I have another user with the same problem on Snow Leopard. Strangely, on my Lion dev setup and Snow Leopard test box, I cannot reproduce the crashes on termination.

Working through the problem with the help of the other user, I discovered that the problem happens when I build the software using LLVM v3.0 instead of LLVM-GCC 4.2. I assume since you mention Xcode 4.1 that you will be familiar with this stuff to know what I'm talking about.

Switching back to LLVM-GCC4.2 solved the crash problem for the other user, but as I had not heard crash reports from others I assumed it was an isolated incident. Given that this is second report of crashing, I will look to post a new version to see if that also solves your problem.

Regards,

David

[OzDave]

A quick note for anyone trying the sync feature of Stellarium!

[snip]

So, it seems that Stellarium syncs on the center of the screen...

That's really odd! I have to admit to not having tried the Stellarium stuff for a while, in fact I haven't really been using my kit in anger over the summer - really only to test different things that I've been working on.

I'll have to give that a try and see if it also happens for me.

Good tip though!

David

[OzDave]

I left a question on the general EQmod thread - I probably should have put it on this one. I have only just got by NEQ6 mount:

Yes, EQMOD is a separate project to EQMac. Although EQMac aspires to provide the same kind of features, is it not a port of EQMOD and is unrelated to that project.

However, it is good that you've posted here so I can try to help you.

If I'm using a ST4 output from PHD via Lodestar directly into the EQ6 mount, is there any advantage to using pulse guiding? When I had an LX200, it was always said that autoguider port commands were better for guiding accuracy over RS232 slew commands. Is Pulse guiding the same thing as issuing small slew commands or is it a unique feature of the EQ mount?

Ok, there have been debates on this issue in the past in the EQMOD and ASCOM related threads.

My take on the matter is this:

1. I do not believe that either ST4 or pulse guiding is best. They are different systems to achieve the same thing. With ST4, equipment sends an electrical signal (a bit like pressing one of the hand control slew buttons) for a small amount of time and the mount performs a corrective slew. This is an electrical pulse that produces a guiding correction. With software-based pulse guiding, the pulse is sent as a serial command to the mount. Again it produces a corrective slew.

2. A plus for Pulse guiding is that it does not require a separate ST4 cable for guiding, and depending on your setup, may save your laptop some battery time due to not having to power a USB-based ST4 controller like I used to use.

3. Let's suppose that ST4 and Pulse Guiding have slightly different latency properties. For example, ST4 pulses might be acted on slightly sooner than pulse guiding commands, or it might be the other way around. I do not know of any definitive research on this, but I believe it doesn't really matter because the guide software (e.g. PHD) will do a calibration run before it starts guiding. The whole point of the calibration is to allow the guide software to send known guiding pulses (either via ST4 or pulse guiding) to the mount and to see what effect those pulses have on the guide star. Via calibration, the guiding software will figure out how long a guide pulse it needs to send to move the star a given distance. Once calibrated, the guide software does not care if the pulses are sent via ST4 or pulse guiding. The end result will be the same due to the calibration.

4. If there are any differences in timing between ST4 and pulse guiding, I suspect that they will be on the order of 10s of milliseconds or less, and will therefore not be particularly significant in the grand scheme of things. Thus guide software calibration will easily account for it and produce a good guiding result.

5. For me, the real benefit is not having the extra ST4 cabling to deal with. I get longer laptop battery life as well.

6. Additional pulse guiding benefits would be the ability to vary the guiding slew rate more finely than the mount's handset would allow, and the ability to amplify or attenuate the guide pulses to fine tune the guiding and achieve the flattest graph possible. You might want to google for EQMOD Pulse Guiding and have a read of the documentation that project has on the subject. You'll see that you have a lot more control over things than you would via ST4. Some day I hope to make all those options available in EQMac.

A bit long, but I hope this helps!

Regards,

David

[perfrej]

About the pulse vs ST4 discussion...

I found that Stellarium (don't know about others) doesn't take note of the fact that the corrections are corrections, not slews. The net effect of this was that Stellarium's telescope position symbol moved away from the object as the ST4 guide corrections were applied. I guess the mount just recorded the movements as slews or something. After an hour on one object, the symbol was a good way off, and slewing to another object was close to impossible - it would just be missed by arc minutes...

I switched to pulse guiding via ASCOM, and after that the symbol stays spot on and following slews to other objects are dead on.

Maybe someone has simular experiences to share?

/p

[buzz]

Great answers on pulse vs ST4 - I suspect that the latency thing could be quite interesting. At 9600 baud, with all the other things going on, it could be a while before the mount starts to move. (BTW, I meant to say EQMAC in my question, not EQMOD...I have washed my mouth out now). I guess the best way to find out is to compare results. Something for the weekend....I think the EQ6 system is faster than the LX200 (meaning the response to the handset, start up, etc, an indicator maybe of the processor speed). Certainly on the LX200, ST4 was the way to go, but note the effect on sync with Stellarium.

It is interesting with Stellarium. Not quite sure how that would happen. If the mount is tracking, the scope sends its position back to the planetarium s/w? If it lives in ignorance of its tracking errors, it will remain synced with the theoretical position in Stellarium. If you then issue corrective slews - then you are physically telling the scope to move to a different star position, which would make the scope position in Stellarium move away from the centered star.... the opposite to that reported. ST4 commands, assuming they are not logged by the mount as a physical change in desired star, should be transparent to Stellarium, since the mount will think it is still locked on? I feel a web browse coming on.

[chrisshillito]

If there are any differences in timing between ST4 and pulse guiding, I suspect that they will be on the order of 10s of milliseconds or less, and will therefore not be particularly significant in the grand scheme of things. Thus guide software calibration will easily account for it and produce a good guiding result.

There are two issues to do with timing - speed of system response and pulse accuracy.

When it comes to the response of the system as a whole folks need to appreciate that by far the biggest, and most variable lags are associated with the capture and processing of the guide image. Against this the differences in methods used to command the mount itself are insignificant. If you use a 1 second guide exposure you are introducing at least a 1 second lag into your control system - probably more given centroid averaging algorithms in the guiding software itself. Clearly this kind of lag applies equally to ST-4 and "pulse guiding".

A popular misconception is that by its very nature ST-4 must be a more responsive mechanism for commanding the mount. The fact you can connect your guide cam direct to the mount seems to fool folks into beliving this. In reality of course the image form the camera must be passed to the PC which then calculates a correction and having to communicates back to the camera an instruction to move the mount. This really isn't a whole lot different from telling a driver to move the mount.

Where dedicated ST-4 hardware can win out is in the accuracy of pulse widths.

When it comes to a Synta EQ mount there is one area where pulse guiding has a potentially significant advantage of ST-4. When a Synta mount detects an ST-4 input in put it simply starts moving at the pre selected guiding rate. The mount driver (EQMAC, EQMOD) has really no idea at all that this is happening. By using pulse guiding the mount driver knows exactly what correction needs to be applied to the mount and in this way it can ensure that guiding can work in harmony with any other demands being placed upon the mount such as PEC. In this way a pulse guide command doesn't have to result in th emount being moved at a fixed rate but could rather result in a constant offset to what ever the current rate happens to be.

6. You might want to google for EQMOD Pulse Guiding and have a read of the documentation that project has on the subject. You'll see that you have a lot more control over things than you would via ST4. Some day I hope to make all those options available in EQMac.

To be honest some of the extra bells a whistles that EQMOD has were added just as debug/test beds. I don't believe there is any real application for ignoring the autoguider software and applying fixed pulse widths (Pulse width override) and the minimum pulse width setting might as well be left at 20ms (for windows at least). The "gain" sliders were introduced only to allow the user the to dynamically adjust the "strength" of guiding because at the time PHD didn't allow its own parameters to be altered once guiding had started (I think it does now).

Chris.

[buzz]

Still just on topic of pulse guiding - with the LX200, you can do automatic PEC training with an autoguider. Does anyone know if you can use Pulse guiding with an EQ6 mount to do the same?

[chrisshillito]

Still just on topic of pulse guiding - with the LX200, you can do automatic PEC training with an autoguider. Does anyone know if you can use Pulse guiding with an EQ6 mount to do the same?

If your talking about programming the PEC facility provided by the synscan handcontroller then no you can't do that. The only method to program the handcontrollers PEC table is via pressing its nudge buttons.

With EQMOD we can take an unguided log and use it to build the a PEC curve for use by EQMOD itself (and perhaps EQMAC will eventually be able to do the same). There is little point in using guided logs or guide commands themselves as these are somewhat contaminated by the guider set up - far better easier to track the natural drift of an unguided star and use that as the base data for PEC.

Chris.

[perfrej]

Dave and all!

Tested! Got a full night of the great combination of sleep and light capture.

Working on the Macbook Air (small one) and Nebulosity/PHD/Mount/Stellarium as capture software, there is no support for my Orion Starshoot Autoguide camera. Luckily, I have a Meade DSI II Color laying around that, in my opinion, isn't really good for much due to its low resolution. It proved to be an excellent guide camera.

So, with FLT98 and an Orion Shorttube for guiding, I set all up on the balcony and did a polar align (Dave, it appears the polar alignment function of Mount is 180 deg rotated). I chose IC3111, mostly because it is in the right part of the sky (straight up) and I could get it with a westerly pier position eliminating the need for a meridian flip.

Guiding stayed at OSC 0.13-0.16 and RMS at 0.11-0.13 (don't know what the numbers mean, though ).

Lights were shot at 10 min subs and numbered 12. Same thing for darks that I took after a two hour nap up till 00.15. Lights, 60 of them, were shot at wake up call an hour ago (07.30).

Quick and dirty process with basic dark/flat/debayer in Neb2 and the rest in Pixinsight yielded this result.

Dave, if you want any raw frames or any other data for analysis, let me know.

So far, the pulse guiding appears to work fine. I got slightly better response with 0.5s exposures than with 1.0s. Mount is due for bearing change and belt mod when I get the time (it is not yet a year old).

All the best for now,

Per F

[buzz]

They say a picture is worth a thousand words! Wow, have you counted them yet?

It is good to know that a combination works. I reloaded the FTD driver and finally got my macbook to work with the simple USB-UART cable and Stellarium/Mount. Still unable to get Stellarium to work alone or Equinox Pro to work at all, in any configuration. Well done for EQMAC!

[OzDave]

WOW! That's really really good news and a great image to show for it.

I wouldn't mind seeing one of the lights at full resolution so I can see just how tight the stars really are.

I will have a look into the Polar Alignment thing. I have used it myself and it didn't appear to be rotated as you say, but maybe something has gone amiss. Perhaps I should also document that feature on the site.

David

Dave and all!

Tested! Got a full night of the great combination of sleep and light capture.

Dave, if you want any raw frames or any other data for analysis, let me know.

So far, the pulse guiding appears to work fine. I got slightly better response with 0.5s exposures than with 1.0s. Mount is due for bearing change and belt mod when I get the time (it is not yet a year old).

[perfrej]

Tnaks, Buzz!

And Dave, I will investigate the polar stuff further tonight. You can pickup one light at http://dl.frejvall.se/2011-09-22_IC1311_10m-1_006.fit.zip

Actually, focus was a bit sloppy. It is more difficult to do the Bahtinov thing with the small Air screen...

All the best, time for some Chianti

/p

[perfrej]

Buzz - counted the stars Well, actually I just checked the processing window in Pixinsight:

Registering target image 8 of 12

Loading target file:

/Volumes/Astrofoto/IC1311/2011-09-22/recon_pproc_2011-09-22 IC1311 10m-1_008.fit

Reading FITS: 16-bit integers, 3 channel(s), 3904x2602 pixels: 100%

Structure map: 100%

Detecting stars: 100%

14059 stars found.

Matching stars ...

* Reference image: Limiting to 2000 brightest stars.

* Target image: Limiting to 2000 brightest stars.

1754 putative star pair matches.

Performing RANSAC ...

1561 star pair matches in 70 RANSAC iterations.

Summary of model properties:

Inliers : 0.890

Overlapping : 1.000

Regularity : 0.994

Quality : 0.957

Root mean square error:

ΔRMS : 0.112 px

Average RMS error deviation:

σRMS : 0.048 px

Peak errors:

Δxmax : 0.443 px

Δymax : 0.469 px

Transformation matrix:

+0.9999 +0.0006 +1.5126

-0.0007 +0.9999 +1.3599

-0.0000 -0.0000 +1.0000

scale : 1.000

rotation : -0.04°

dx : +1.51 px

dy : +1.36 px

Generating registered image

Homographic Projection / Bicubic Spline Interpolation, c=0.15: 100%

Registration successful.

Writing output file: /Volumes/Astrofoto/IC1311/2011-09-22/_Rrecon_pproc_2011-09-22 IC1311 10m-1_008.fit

Writing FITS image: 32-bit floating point, 3 channel(s), 3904x2602 pixels: 100%

[perfrej]

Yiiiiiiiihaaaa!

Guiding with EQMAC on M31 as a test with 20 minute subs and getting perfectly round stars - except on the sub where equilibrium on the RA axis was passed... Something that just proves my point of not balancing the mount perfectly

This is good and the NEQ6 is not such a bad mount.

/p

[OzDave]

Yiiiiiiiihaaaa!

Guiding with EQMAC on M31 as a test with 20 minute subs and getting perfectly round stars - except on the sub where equilibrium on the RA axis was passed... Something that just proves my point of not balancing the mount perfectly

This is good and the NEQ6 is not such a bad mount.

/p

More good news! What did you mean by RA axis equilibrium being passed? I know about not balancing the RA axis properly to make the motor work a little bit and thereby help with guiding a bit. But trying to visualise what you meant there.

Dave

[perfrej]

Yes, Dave, that is what I meant

I balance my rig a little top heavy in bot axis so basically the mount has to fight on the east-pointing-west side and hold back on the other. The flake in the guiding happend just as I passed the meridian changing from east to west. It is to be expected, of course.

I do not actually know whether 20 minutes with round stars is normal, good or exceptional, but it does open up possibilities of getting the faint stuff out of the background.

Oh, by the way, when parking the scope from Mount, the tracking status stays "Tracking". You should add code to turn it off in the GUI in all aspects on hitting "Park". Not a big thing, but...

All the best,

P