开云体育

Dear all, I have used servocat+AN to follow ISS. As ISS is moving at high speed you have to have have very good ratio adjustment (and also good pointing to have the maths done at good location => I implemented a TPAS) To improve accuracy of tracking I started to improve ratio using the "track improvment" method described in the Sercocat quick V3 file. To adjust Az ratio, it describes to use a star located at south. I understand because at south it's a pure Az movement, no alt movement. Then for Alt ratio, it describes to use a star located at east. For ex you strack an object for 1/2 hour, the sky moved 7.5° (=360/24/2)and you divide your offset by this 7.5° value to calculate a correction factor of your Alt ratio. What I don't understand is that for a star located at east, it's not a pure Alt movement so I don't understand why you divide your offset by 7.5° For example I live at 45° latitude. In this case the star move only sin(45)*7.5= 5.3 in Alt (and 5.3 in Az). After 1/2h let say I see in AN an offset for the star of 0.1° in Az and 0.2° in alt => I would have divided the alt offset 0.2 by 5.3 to get the correction ratio, not 0.2/7.5 I'm certainly wrong, but could someone explain my mistake ? Regards Rapha?l

Can any one tell me the settings for the servocat on a skyvision D500. Thanks Frank

Hi, We have recently purchased the Nexus DSC Pro and tried it last night while at the Texas Star Party. I have a question about selecting an object. We were in the Catalog Messier, and wanted M31 (or some other object currently up). We typed in the 3 then 1 and pressed OK. It returned some other M object information, not 31. Something similar with the NGC catalog. Request one specific object and a different NGC object is displayed. The first couple of objects we selected during the night were fine, no issue. But after some use, the above issue started happening. Any thoughts on why this is happening? This is a new Nexus right out the box. Thanks Steve Goldberg

About a year ago (Msg #6876), Gary Meyers hinted he was working on, or considering working on, a driver that would connect ServoCat mounts to the ASIair. Has there been any progress in this direction? thanks jim

Dear all, I was not using the local sync function but after reading manual I believe it is quite powerfull to find faint objects. So yesterday at end of observation I tried to activate it on M42 with the idea to find the horse head just after. The Aux switch was up. I'm quite sure I was in guide mode, but not 100% sure. When I pressed for approx 1 s the Local Sync on my (wireless) Handpad, the yellow led didn't turned on. The Yellow LED sync on panel of main unit didn't turned on neither, BUT the Left-most RED marked "AUX" LED turned on. So it seems something happen.... I pressed again the Local Sync on my (wireless) Handpad, the RED "AUX" then turned off. Both yellow led on HC and main panel still off. Any idea what's happening ? I have a version3 (updated from version 2 a few month ago) Thanks for reply Rpha?l

Maybe its old age, but I cant resolve this issue. When I set up (Obsession f5/20) I basically have the scope pointing North and at 90'. Power on the Cat and Argo and it goes through initialing and gives beep synch tone and do a fix alt ref. Now if I go to Mode Encoder I see my AZ is almost always about 90' as if pointing east? Why is it nolonger reporting 0 when pointing north? This deviation makes alignment and/manual targeting a bit more challenging. Did I miss somethin? Suggestions? Thanks

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 ------ From "Gabriel Wiklund via groups.io" <gabriel.wiklundholeshot@...> To [email protected] 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

At last guiding works as intended and without changing the settings wildly or going against PHD2 recommendations. From the last time out I have tightened the screws on my guidescope which caused it to shift slightly, so the main scope is pointing to the lower right corner of the guidescope fov, which is not much of a compromise since i just have to pick the closest guidestar in that corner instead of the center. In ServoCAT Sky i have set backlash comp to 0 on alt and az, lowered the guidespeed in ServoCAT Sky and the Meade Generic driver to 6 arc seconds per second (0.40 x Sidereal). I also created a new profile in PHD2 where it detected the 0.40 x Sidereal guidespeed from the Meade driver. It was windy outside, the type of wind that makes me very skeptical to even give imaging a try but i gave it a shot anyway! PHD2 calibration was completed without any warnings, and after running the guide assistant it recommended min mo of 0.12 in RA/AZ and 0.19 in DEC/ALT. So i followed that. I tried guiding first to the north at 38 degrees altitude, then to the east at 50 degrees altitude, in both cases, despite the windy conditions i got 1.0-1.3 RMS guiding in arc seconds. Similar error in both axis and round stars in the test exposures. The guiding graph looked similar to my 200PDS on the Sky-Watcher EQ mount without any large deflections apart from a windgust here and there, Then the clouds rolled in! Can't wait for the next clear night hopefully without any wind! Moral of the story: Read the PHD2 documentation: From the trouble shooting document: "YouTube videos, unless done by someone close to the PHD2 project, have wildly variable quality, often reflecting misunderstandings and sometimes producing a witches' brew of good and bad advice - so be careful what you watch. One of the most common mistakes is to wildly change the PHD2 guiding parameters in a futile attempt to correct for mechanical problems that exist in your setup. This only makes things worse. The default guiding parameters calculated by PHD2 reflect the parameters you entered in the new-profile-wizard, so they are already adjusted for your setup. You should be able to get reasonable results out-of-the-box if the equipment behaves and if you don't, you are probably dealing with operational mistakes or mechanical problems" Edit: I did however follow the below alt/az PHD2 guide (unchecked multi-star guiding and changed the ALT/DEC guiding algorithm to Hysteresis etc) https://telescopemount.org/guiding-the-panther-alt-az-mount-with-phd2/