Gabriel,?
Just a note on how the ST4 guide port works as implemented in the ServoCAT.?
First off both the AZ and the ALT tracking rates are changing continuously on an ALT/AZ mount. They will go from zero as, for example, AZ crosses over directly south in which case the ALT will go from UP through 0 speed and then back to down... it will of course be decrementing (on the east side of the meridian) and slowly incrementing on the west side. I believe the equivalent location in the sky for the same action only in the AZ axis is at a position of 90 - LAT in both AZ and ALT. So if you are at 40¡ã LAT it would be at a position of AZ=50, ALT = 50. Just below that in ALT and the AZ will be slowing down, just above that it will be speeding up.?
Second of course if you reverse direction you will due to the nature of mechanics in gearing, introduce backlash and have to unwind the gears going in the opposite direction.?
The way ST4 applies guiding is to add a fixed amount (programmed in GUIDE 2 speed value and used only when the HC is in GUIDE and the command is coming from/through the ST4 port). It does not replace the actual track rate. It simply modifies it. So if at a particular location in the sky the AZ track rate is 12.52123 arcsecs/second and the ST4 AZ GUIDE 2 speed is 10 then an ST4 command to go west (in the direction of sidereal movement) the track speed will increase to 22.52123. If the east command came in it would go to 2.52123. So it speeds up - or it slows down. NOTE however that if the ST4 rate were, for example, 15, then in one direction it would go to 25.52123 and in the other direction it would go negative to -3.47877 AND in the process lash will be introduced.?
Hindsight says I should have designed it not to go below 0 speed... but it is what it is currently (and there are more than likely additional complications if it were done that way).?
So you can see that ideally the GUIDE speed (ST4) values should, as well, be fluid as the AZ changes drastically going through infinity as one approaches dead-center to the zenith and passes through it. In 0 time it has to go from pointing directly east to directly west. Because of this for any and all factors related to tracking with a dob - avoid the pole! It works extremely well visually even as high as say 86¡ã Alt... but you're getting in to some very high numbers and rapid changes so from an imaging standpoint I'd stay a good distance from the pole - probably a good 10 - 15 degrees away.?
If I were to do it again, now having actually used it and experimented with it... it would be different than what it is. But when i did it very few were using it (I had a handful of people that would talk about it over nearly 20 years or so). But now that CMOS cameras have made very short exposures possible (down to sub 1 second on very large apertures) it becomes something that ideally would be optimized.?
I don't say this as any pressure on Bill.... he is doing fantastic work both in keeping up production as well as working on new and exciting products... but maybe a "what could I have done... " statement on my own part and accordingly: an explanation of what I did probably way way back in about 2004 or so.?
Gary Myers
------ Original Message ------
Date 2/14/2025 9:47:26 AM
Subject Re: [ServoCAT] Promising Autoguiding results in PHD2
[Edited Message Follows]
I would also like to take the opportunity to correct myself. I have now read the PHD2 documentation (mostly the troubleshooting section) and according to what is written there, if you get large/abrupt guidestar deflections like i was getting, wildly changing the settings in PHD2 is not likley to solve the problem, at least not in the long run, it is almost always due to hardware issues which should always be adressed first.?
?
This is what the PHD2 documentation states about the symptoms i had:
?
Large/Abrupt Guide Star Deflections
Most users eventually encounter situations where the guide star appears to make a large, abrupt excursion away from the lock-point. ?The great majority of these problems?arise from neither the mount nor?PHD2's guide commands. ?Instead, they usually come from?unwanted mechanical movement in the gear that is riding on top of the mount, especially the guide camera/guide scope assembly. ?This is especially true if the large deflections occur in declination because the Dec motor is normally idle except for executing the very short, relatively infrequent guide commands it receives. ?The unwanted mechanical movement usually comes from several sources:
- Tiny movements of the various components in the guiding assembly as a result of the changing gravitational forces while the mount tracks the target object
- Dragging, binding, or snagging of cables, especially those that are connected to the guide camera
- Wind gusts or less commonly, effects from camera filter changes, auto-focusing, or mirror movement
- Use of mount features for backlash compensation - these should not be used with PHD2 guiding
Before rejecting these things as likely sources of? problems, think again about the tiny measurement scales and tolerances described in the previous section. ?With many guiding set-ups, a movement of only 5 microns can create an apparent tracking error (guide star deflection) of over 6 arc-sec, the equivalent of many star diameters. Every mechanical interface, every set-screw, every movable element has the potential to shift or move on its own by these tiny amounts. ?Even when cables have been routed in a purposeful way, they may bind or pull in certain sky positions or after a meridian flip. ?Cable ties or ribbed plastic cable guides hare small protrusions that can briefly catch on stationary parts of the mount. ?For large Dec deflections, it's easy to determine if these things are coming into play. ?Just use the PHDLogViewer tool to zoom in on the time of interest and see if the deflection was immediately preceded by a correspondingly large guide command in the direction of movement. ?In most cases, you will find this didn't happen. ?It can sometimes happen at the beginning of a guide session if you're using PHD2 Dec backlash compensation, but those events should disappear quickly. ?If the abrupt deflections occur in RA, the analysis is less straightforward because the RA motor runs continuously. ?But even then, unusually large, randomly space deflections are more likely to arise from the sorts of mechanical problems described here than from errors in the RA drive system.
?
?
So i took a closer look at how my guidescope is mounted and it could be a problem, i have tightened the screws and we will se if it makes a difference.
?
Guidespeed was probably also the problem in the beginning and just to see what will happen next time i will try 10 arc seconds /per second in ServoCat Sky, which is actually what the link with the Panther mount recommends and also the defualt value in the Meade Generic driver.
?
I also read in the documentation that you should not change the guidespeed in PHD2 "manually" you should reset and create a new profile where that is entered in the first steps, i noticed that if i enter 10 arc seconds per second in the Meade Driver and in the beginning in PHD2 when creating the profile, PHD2 does not change it to 1.01 arc seconds like i wrote earlier so now both the Meade driver, PHD2 and ServoCAT sky has 10 arc seconds /per second, i hope it clears up tonight so that i can give it a try! (i have also set backlash comp to 0 on both axis in ServoCat Sky this time)
?
In the first calibration, If the measured guidespeed in PHD2 turnes out to be say 5 arc seconds per second instead of 10, then i will re-do the profile and enter the new speed (0.33 x Sidereal in that case) so that the correct guide-pulse length is calculated for calibration and guiding.
?
Here is the PHD2 user guide: https://openphdguiding.org/PHD2_User_Guide.pdf
?
/Gabriel
?
?
