Just starting to get some clear weather after the winter and one of the same problems as last year with the STT camera self guider seems to still exist.
Using SGP and PdD 2.X guiding still fails after a meridian flip. It simply guides away into nowhere in Dec.
I will post the question to the PhD forum as well but it looks to me like the issue is the extra angle introduced by
the odd pickoff mirror plus reducer lens setup that only the STT self-guide has. There is no option to flip dec.
Not sure what could be causing this. As far as I know there isn’t a “STT Self Guide Flip issue”.
I routinely guide through an OAG and meridian flip without issue using PHD 2. So SGP is definitely capable of doing this. The guide camera shouldn’t make a difference.
Some questions:
How are you guiding? (ST-4 or ASCOM)
How are you invoking the flip? (SGP in sequence, SGP Manually, Manually through the mount)
Yes, the guide camera will make a difference because the STT self guide is not optically the same as a regular OAG.
For those with the STT self guiding version (meaning the self-guiding filter wheel is attached) there is not just a pickoff mirror but a reducer lens as well in the optical train of the guider. This results in a extra flip (in both axes) of the guide image as compared to a regular OAG. As I mentioned last fall, this STT specific issue has been seen before with flips in ACP. There was fortunately a way to deal with it in settings within ACP although it took a bit of experimentation to get the right combination of settings.
I would like to hear from other SGP STT self-guide users. There may be something I am doing or setting wrong. If so, I do not know what it is so would appreciate some tips.
I am guiding using the “ST4” direct cable, the flip is being done by SGP in sequence. Guiding is just fine before the flip. FYI, “flip calibration data” in PhD does not help (if it were a normal OAG situation it seems like it should). Only a restart of PhD and recalibration after the flip works (and kinda defeats the purpose of automation).
On a related (but not your problem) issue, is there a way to force PhD 2 to do a recalibration w/o closing and restarting it? If so, I can’t find that.
Sounds like you may need to enable/disable the option in PHD about flipping the dec axis (I’m not on a machine that has PHD installed at the moment). I can’t recall what this setting is, but it’s there in the brain.
Yes, you just have to open up the brain and click the “Force Calibration” option and then click the PHD button which will then recalibrate. The option might be there in the menus as well but I can’t recall.
OK, found that option to reverse dec. Since it was going wild in dec this may fix the issue. I will try it toward week’s
end when it is supposed to clear again.
Thanks
Hmm, I did have “Force Calibration” checked already but it did not seem to be recalibrating. Maybe it has to be unchecked and rechecked. It is a question for the PhD forum in any case.
On another issue I was having trouble getting a plate solve in the Rho Ophiuchi area last night. Will post that to another
new topic.
Odd, all you should need to do is check it. Then click the “PHD” button and it should recalibrate. Maybe you a bug. I guess for the time being you could always close it and reopen…which might be faster than going to the brain, checking that option and clicking the PHD button anyways. You’d want to disable the option to load your previous calibration data…
A couple of the PHD2 developers linger here as well (and we’re fine with them addressing questions like this here)…but, like you mentioned, the PHD group is probably a better place.
Hmm, looks like my response got lost. Let me try again…
The option to reverse dec output after meridian flip is: Brain => Mount => Reverse Dec output after meridian flip.
Regarding forcing recalibration: there are two ways to force calibration:
Brain => Mount => Force calibration
Hold down the Shift key and click the PHD button. You will get a popup message prompting whether you want to force calibration.
While we are on the subject of calibration and meridian flips, you may want to consider using an ASCOM connection to your mount rather than the ST4 connection. If you use ASCOM, PHD2 will automatically adjust calibration based on the declination of the target and the side of pier, avoiding the need for calibration in almost all cases (you would only need to recalibrate if you change the guider configuration, e.g., if you rotate the guide camera or if change guide scope etc.)
It is not necessary to uncheck/recheck the setting. Just make sure it is checked before you start guiding (by clicking the PHD button.) It can be a bit confusing because each time you click PHD it gets automatically un-checked so it only forces calibration once.
Hmm, just tried many of the ASCOM connections but I am using a Paramount ME and “TheSky Controlled Telescope” and get a message that “Pulse Guide is not supported” when I select ASCOM.
This could be because you are running SGPro as admin and phd and the sky as
non admin. All your apps need to run with the same privilege level… You
cannot mix and match. The other possibility is that pulse methods are
simply not implemented in the sky’s ascom driver.
I checked and neither program was being run as admin.
Even worse, I just tested the flip and it again failed to guide after the flip, this time with “flip dec” checked. It WAS now guiding in dec properly (it was not before I checked that box) but guided away from the guidestar in RA. I then tried selecting “flip calibration data” and that caused the system to guide away from the star in dec.
What DID work was to manually change the sign of (only) the RA calibration using “enter calibration data” after the flip had occurred with the “flip dec” box checked.
It tracked nicely after manually changing the RA sign but that kinda defeats the purpose of automation…
Is there anyone else with a self guiding STT that can comment on how (or if) they fixed this? Theory is nice and more suggestions would be helpful, but someone who has actually used SGP/PhD with this equipment would be better.
I will add that I have two imager friends that also have STT-8300 cameras with the self-guide filter wheel who would like to dump MaxIm in favor of SGP but both are waiting to see if I can get this to work before they make the switch.
From what you’ve described this sounds more like an issue with how your mount is interpreting the guide signals than your guider. I bet if you used a guide scope and a different guide cam you’d have similar issues to what you’re seeing.
It’s probably best that they give the trial a shot as well as there setup is likely different than yours. We always recommend folks use the trial first (like you’re doing) to verify things work with their gear and that the application works as they expect before paying for it.
I know we have a couple of other users that are using the STT with the filter wheel guider…but I can’t recall who they are.
No rotator and the guide chip (and of course the main chip) were within a couple tenths of a degree to being aligned to the mount axes.
When I was using the Sti I was not using the API guider as I did not need to and the Sti was connected to the mount separately and directly and just selected in PhD (I think it was version 1.X at that time, but do not recall).
FYI, the Sti cannot be connected to the STT. SBIG does make an “external guide camera” for the STT that looks just like the Sti but the connection is different. The external guide camera uses an HDMI style plug to connect to the STT whereas the Sti is just a simple USB powered separate guide camera like any other.
That’s what I thought…I’m wondering if maybe something is incorrect in the API guider, although it works just fine with my STL and the internal chip (both through ASCOM and the ST-4). I’ll look into that this evening, but I can’t really think of what could be wrong here. It’s pretty simple from the API Guider side. PHD tells us which way to move and for how long and we send those values back through the main cam and into the mount. If you’re using ASCOM it’s even easier as none of the guide commands go back through the API Guider.
It might be worth while to setup your current guider going through a guide scope and to use the API guider to see if you can duplicate the issue…Although I’m sure that’s a pain to change your config.
Kind of stumped on what this could be at the moment…
If so, it would seem to me that the extra mirror/prism would give it different behavior. I used to have one as well but that was before SGP and I sold it because the STT has better cooling and the STL did not play well (connection drop issues) with MaxIm that I was using at the time.
I may be able to set up the Sti on the back of my third scope pretty easily so can try that. It would not guide very accurately because of flexure but it does not have to for a test. I would just put it on the back of the Raptor where you see the DSLR in the photo.
I also have to wonder if I could get it to work via ASCOM instead of cable if that might fix the issue as it would be a bit “smarter”?
If so, that might also account for the lack of other reports about this issue as maybe other STT self-guide users were
using ASCOM by default and thus have not seen the problem. That’s where hearing from one of those folks would be really helpful.
It would be nice to get it to use ASCOM for other reasons as well, of course. The question is what settings to use to
get it to work via ASCOM on my Paramount ME. I am running TheSkyX but I have to assume that I would not need
to do so? I always have used some version of TheSky so have never given not using it any thought.