SharpCap Forums

Wratten #12: 20x60s
Red: 14x120s
Green: 8x120s
64 minutes Total Integration Time.

Anyone who follows me knows that I am a glutton for punishment. I have a 50 year old equatorial mount which presents ample opportunities for experimentation. It is non-stop "thrill of victory and agony of defeat." After three years of relying on tracking alone, I decided that it is time to step up to auto-guiding. Actually, it was a lot easier than I thought. It really only required two resistors, an ST-4 cable between my Raspberry Pi and guide camera, six lines of Python code, and of course, PHD2.

It took two nights under the stars to shake out the bugs that always plague my mount. On the first night I had nasty oscillations in declination that had nothing to do with guiding. It was the setup. I had the incorrect amount of torque on a holding bolt. And on the second night I had to skip polar alignment due to the threat of clouds. That unfortunately led to a good amount of declination drift due to the shifting soil under my tripod, thawing in the springtime warmth.

I ran some tests to measure how long I could guide in right ascension. (I forgot to mention that my mount is incapable of auto-guiding in declination, only right ascension.) In the attachment entitled "guide-test-random-star-field" I captured four frames at different exposures: 60, 120, 240, and 480 seconds. The left-right direction is right ascension, and up-down is declination. In all four frames there is no noticeable right ascension error, but declination begins to fail at 240 seconds. Again, that is due to poor polar alignment.

I tried something else on the second night. I tried to auto-guide out the Periodic Error. It actually works! But it only works because my pixel scale is a relatively large 2.3 arc-seconds per pixel. A smaller pixel camera would require Periodic Error Correction (PEC), which I do have as an option in my Raspberry Pi implementation. However, PEC presents all kinds of additional challenges that I prefer to avoid.

Lastly, the clouds held off long enough so that I was able to image M92 in LRGB. M92 contains lots of colorful red and blue stars, but it is rather small at only 14 arc-minutes in diameter.

Brian

Here is a full-frame view of M92. You may like this better. The official diameter of the cluster is nearly double of what you see here. I wanted to double the exposure but was constrained by poor polar alignment (not the fault of SC).

An attractive view of M92 with true-looking colour. You have a very well tuned solution now that must be pushing the limits for what is even possible for a 71 mm achromat!

Could you explain exactly how the PHD2 plus raspberry Pi solution works? It is in fact interesting to get back to basics sometimes and too much of how things actually work in my set up is obscure to me.

So I am guessing that the rasberry Pi is programmed to take numbers from a laptop running PHD2 - which is presumably reading a guide camera via a laptop - and converts them into timed pulses which either speed up or slow down the RA motor via the ST4 port which is otherwise just tracking along at the sidereal rate? Or is everything apart from SC capture running on the raspberry Pi.
thanks
TimH

Hi Tim,

Referring to Figure 1, SharpCap and PHD2 run on the same laptop. SharpCap connects to the Imaging Camera via USB. PHD2 connects to the Guide Camera via USB. The Guide Camera's guide port connects to the Raspberry Pi via ST-4.

PHD2 sends two types of commands to the guide camera. One command is to capture a frame. The other command is to speed up or slow down the RA motor rate.
Referring to Figure 2, the ST-4 cable contains 5 wires, but we only use 3 since we ignore the DEC commands. To understand how the circuit works, place a multimeter on GPIO 22 (RA+ Sense). As the circuit is drawn, the multimeter will read +3.3V. Now if we were to connect Pin 3 and Pin 2 with a jumper, then the multimeter would read 0V. Think of Pin 3 and Pin 2 as points on a Relay. The contacts are either opened or closed depending on logic in the guide camera. When PHD2 commands the mount to speed up for 100ms, the guide camera closes the relay for that amount of time.
Here is my Python code that modifies the step rate to the motor:
The -3 and +1 values ensure +/-0.5x sidereal rate. In a production unit, stepper timing would be handled by dedicated hardware. But this is a DIY project, so software modifications are easier to make than hardware.

Brian

Thanks so much for the clear explanation Brian, that helps a great deal. An elegant and understandable solution.

There is a lot to be said for taking the DIY approach rather than buy ready made solutions. Then you completely understand the system and can diagnose and fix problems. I have been having strange problems with the CEM70 mount and PHD2 guiding wherein with more than a certain number of pulses in a short time the mount just stops communicating via the driver and everything needs to be rebooted from scratch --- which is pretty annoying.
I have possibly now fixed it by updating the firmware and controller software ...but for all I know the changes will disturb something else. It is just a problem of modern life I suppose .

Tim

Tim,

Yuck. There is firmware in the Mount and the Guide Camera. And then there is the electronics in each. Do you have another camera that you could try?

Brian

Hi Brian,

The Ioptron firmware and driver updates did seem to fix the problem OK - two nights without crashing every time PHD2 got busy so all good now

Tim