I experienced a bizarre behavior last night during a sequence. It was mid run, and my gear centered the target as expected. I wasn’t happy with the exact positioning of the target, so I paused the sequence and clicked “Center Here” on the image. The Center Here process ran perfectly, and it put the image right where I wanted it. I then restarted the sequence, and found out after the next subexposure that it had returned to the previous position. The sequence did not run any type of centering action after I restarted it, and I manually restarted PHD2 so that everything was in place.
I tried a couple more times, and the centering action worked perfectly to center the image where I clicked, but again returned to the previous position before restarting. I finally resorted to saving one of the plate solve frames with the image in my desired position, and inputting it as the target coordinates in the sequence. That worked, but the Center Here function did not.
There were never any errors, and it always centered to within 7 pixels of where I wanted. It just magically returned to the original position when I restarted the sequence. I even tried to just take short exposures with the frame and focus function to see if it stayed in place, but it had already returned to the previous position.
I’m using TheSkyX, and the problem started occurring right around 3:21am.
Activate PHD2, connect Lodestar camera and mount (via TheSkyX)
Create new sequence with by centering on a previous Luminance image of IC 342
Autofocus run, calibrate and begin guiding, start sequence with Luminance frames
Use Mosaic wizard to frame up a horsehead nebula shot for the next target. Select to automatically center it on target start. Target begins and runs trouble free.
After not choosing a target to follow the horsehead, I manually selecte M66 in TheSkyX and slew to it. I recalibrate autoguiding and resume the sequence with the new target, Leo Trio
After 1 subexposure, I decide to better frame the target, so I pause autoguiding and abort the sequence.
I choose “Center Here” on the image, it plate solves, syncs and moves, and after a couple of iterations get it looking exactly like I want, with it framed perfectly.
I resume autoguiding, resume the sequence and wait for another 600-second exposure to finish. I’m shocked when the image is identical to the previous, with the target having moved back to the original position. (There was NO centering action, no plate solve, no indication of any movement between my repositioning the target and taking the image.)
I stop guiding, choose “Center Here” again, watch it plate solve and again perfectly move the target to the correct location.
This time, I get smart and attempt to shoot a 20-second exposure with the frame and focus module, and am bewildered to see that it has moved back to the original spot. This is directly after a successful “Center Here” action, and literally nothing else has been touched. I try a couple more times, but the target continuously moves back to the previous spot after successfully centering right where I indicated with the cursor. This happens with and without reactivating PHD2, so it’s not related to the autoguider moving it.
Completely baffled, I finally saved the Plate Solve frame from the last action of Center Here, solved it in the Target Settings, and then entered it and had the target “Center Now”
That finally fixed it, and it proceeded without a hiccup for the rest of the evening.
And just to be clear, the amount of offset from there it kept returning and where I kept pointing it is not insignificant. It wasn’t something that was just coincidental, but instead the mount was clearly returning back to the point of origin after the Center Now action.
I have been through your logs and concur that no mount moving command was issued by SGPro after your centering iterations. Do you, by chance, have TheSkyX set to do anything… I think you can set it, like other planetariums, to center on some RA, DEC… this would fight with your centering actions in its efforts to keep you on some location. I can’t think of any other reason this would happen, but I can make a few suggestions:
Check your settings in TheSkyX and make sure it’s not fighting SGPro
Assuming the SkyX is not doing anything you don’t want it doing:
Repeat the behavior and note the approximate time the scope “magically” returns to its previous position
Check the ASCOM logs for your mount and pinpoint the commands doing this (make sure they are on before attempting this)
Cross ref it with the SGPro logs to see if something sneaky is happening (we can help with that)
If SGPro is not doing anything, there are 2 other applications attached to your mount…
Thanks for the reply. I’m looking to see what logs are offered from TheSkyX, and I think I’ve found the correct way to establish logs for ASCOM as well. Can you, or anyone familiar, confirm that this is how I create logs for my ASCOM Telescope activities:
I opened ASCOM Profile Explorer
I accessed Telescope Drivers->ASCOM.SoftwareBisque.Telescope
I changed the Trace Level value from TRUE to INFO based on this list of commands I found online: Off - No events are logged. Error - Only major errors are logged. This is the default setting. Warning - Major and minor errors and warnings are all logged by the event logger. Info - Most, but not all, events are logged. Basic and repeatedly performed tasks such as retrieval of hub status/configuration information are excluded. Verbose - All events are logged.
That list doesn’t include TRUE, which was the current setting, so I’m unsure if it’s even a valid list of options. I do see that I’m able to use Windows Event Viewer to read the current logs, but there aren’t currently any for typical activity.
Finally, I alluded to looking for TheSkyX logs, and if anyone knows right offhand how to access them, I’d appreciate it.
Cancel that last post, turns out that using Info caused an error where SGP wouldn’t open TSX. I don’t think that’s a valid Trace setting for the ASCOM Telescope diagnostics. Back to the drawing board!
The ASCOM driver setup for the TSX driver has a trace checkbox that, if checked, will enable logging of trace data and a Help button that, when pressed, will open a file called Help that gives detail of how to enable logging and where the file is.
Yet no user ever seems to be able to see these. The Trace on and Help items seem to vanish from user’s systems. I don’t understand it. People can find the most esoteric ways to do things but what seems like an obvious button and checkbox placed next to the OK button seem to be invisible.
Making random changes to the registry - which is what changes to the profile store is doing - is a really really bad idea. I’ve no idea what state your system is in now. If you can’t get it working by putting your registry hack back the way it was your best option will be to fully uninstall the TSX ASCOM driver and reinstall it. If that doesn’t work you may need to uninstall the ASCOM platform as well.
As for your original problem, is that simply a JNow/J2000 confusion? SB say their mounts use JNow and that’s the equatorial system that’s being reported. SGP uses J2000 and handles the conversions but if something is using JNow when it’s assumed to be J2000 or vice versa then a difference of about 10 to 15 arc minutes can be expected.
I truly do appreciate your input, but I could have done without the lecture. I didn’t miss those buttons, and they didn’t “vanish from my system.” I simply didn’t look there first. I looked through the ASCOM Help file for trace and logs, didn’t see exactly what I thought I needed, and went to Google. I found a website and post from Optec about modifying the Trace settings for a piece of equipment, and utilized the list they provided. It’s since been changed back to the original settings, and no damage appears to have been done. If need be, I will certainly uninstall and reinstall ASCOM. It all seems to be working properly. If the ASCOM Profile Explorer is something the end user shouldn’t modify, but must retain access to, perhaps a Warning! box would be useful.
In any case, thanks for pointing that out. It’s currently set with Trace enabled, and I see now where the logs are. I’ll try to look over them and post them if necessary.
As for the original problem and your suggested observation, I hope that’s not it. I have been using plate solves through SGP, including syncing the mount, for quite some time. I believe it has always had to convert from J2000 to JNow, and it’s always worked perfectly. The Center Here feature seems to utilize the exact same system and plate solves to the point I click. It works perfectly, but then between the confirmation plate solve frame and the first test frame I can shoot afterwards, the mount has returned back to the original position.
See this link for the pertinent ASCOM telescope log, and the above link for the SGP log.
Also see this link if you need confirmation that PHD2 was stopped during the Center Here process.
Ok, I’ve found what appears to be a significant event in the ASCOM log file. Here’s what appears (to the untrained eye) to have taken place:
According to the SGP log, at 03:21:09, a Center Here command was initiated
Center Here works without a hitch, and moves the scope to the appropriate location. The J2000 coordinates are converted to JNow of: RA: 11.3457126168278 Dec: 13.143850537784
From )3:21:40,the mount tracks along on those values, and the confirmation frame of Center Now is in the correct location
At 03:21:58, SGP validates and syncs the final Center Here frame at RA: 11.3457126168278 Dec: 13.143850537784
At the same time, 03:21:58.644, ASCOM shows that the mount, which has been tracking along perfectly on the correct coordinates, syncs to the validated coordinates.
Less than a second later, the ASCOM log shows that the Get RA/DEC have already moved to11.3425637812247, Dec 13.1049662205016, even though Slewing was FALSE.
I used the FOV indicator in TSX and confirmed that this disparity in RA/DEC is exactly the difference in my frames. Enough that the edge of one of the Leo Trio galaxies is now off-frame.
I didn’t see any move command, and it appears that all of the J2000 / JNow conversions have caused no problems. PHD2 was stopped, so no conflict there. I’ll look over the logs again, but I’d bet that each successive time I attempted the Center Here action, the same thing happened.
As I demonstrated earlier with the ASCOM Trace settings, I could very easily be missing something obvious here. I’d be more than happy to be the cause of the problems, as long as we can find a solution.
Do you have any idea how frustrating it is to go to a lot of trouble to make help for users easily available only to be ignored?
Did you really see the button marked Help and rather than click on it to see if it did what it said went roaming over the internet looking or help from some totally unrelated source?
Anyway, from a look at the ASCOM Log:
03:21:24.499 m_SkyTele.GetRaDec Ra 11.3440887433469, Dec 13.134894223084
03:21:29.659 m_SkyTele.GetRaDec Ra 11.3440860100148, Dec 13.1349096273181
03:21:34.877 m_SkyTele.GetRaDec Ra 11.3440873191152, Dec 13.1349247946205
That looks like good consistend reporting of position.
Now a sync is done:
03:21:35.862 SyncToCoordinates set - 11.3436490614187, 13.1299536687879
03:21:35.863 SyncToTarget set - 11.3436490614187, 13.1299536687879
03:21:37.736 m_SkyTele.GetRaDec Ra 11.3436457020766, Dec 13.1299421274047
The position has changed to the sync position because the sync has changed it, that’s what sync does, it changes the current position to be the sync position. It is supposed to change, that’s what has been asked for.
Slew to a new position:
03:21:37.874 SlewToCoordinates set - 11.345720753307, 13.1449040118329
03:21:37.875 SlewToTarget set - 11.345720753307, 13.1449040118329
03:21:38.908 Slewing Get - False
03:21:39.980 m_SkyTele.GetRaDec Ra 11.3457162366248, Dec 13.1448769169042
And the position reported is where the slew commanded.
The ASCOM driver and mount seems to be doing exactly what it is asked for. It reports the position. A sync changes the position reported and a slew moves to a new position.
There’s nothing more I can do or suggest. Differences of a few arc minutes are often epoch differences.
I didn’t even open SGP to look for the ASCOM log files, which is why I missed it. I just looked for information in the Start Menu folder for ASCOM. I apologize.
I appreciate your help, but you are referring to a portion of the log that we both agree on. Everything is behaving normally and as I’d expect for the period you referenced in your quotes. The portion that I specifically asked you guys to look at was right around 03:21:58.
03:21:58.642 CanSync Get - True
03:21:58.644 SyncToCoordinates set - 11.3457126168278, 13.143850537784
03:21:58.654 SyncToTarget set - 11.3457126168278, 13.143850537784
Less than two seconds later, the position has changed, and is reported as:
03:22:00.554 m_SkyTele.GetRaDec Ra 11.3425637812247, Dec 13.1049662205016
03:22:00.554 RightAscension Get - 11.3425637812247
03:22:00.554 Declination Get - 13.1049662205016
I can confirm that the scope was perfectly centered and synced in the original position, as evidenced by the plate solve photos, and for some unknown reason moved to the above current position. There don’t appear to be any Slew commands, so that’s bizarre to me. In each case from the log, the same thing is happening with a move mainly in the DEC axis.
The scope had already plate solved, centered, and synced right where I’d asked it to. Why did it move to the above final position afterwards?
I can’t account for that one. All the ASCOM driver does is translate ASCOM commands to TheSky scripting commands. It doesn’t change the data at all.
Looking through the entire log file most syncs are OK, where a subsequent get Ra Dec reports the sync position but there are other ones that are wrong at 03:01:29, 03:05:51, 03:21:58, 03:23:17, 03:39:17, 03:40:26, 03:43:07, 03:45:37, 03:48:23, 03:51:08. The later ones seem to be alternate syncs, one good one, one bad.
You may need to talk with SB about this to find out what could be going on to cause a sync through the scripting interface not to report the correct position on subsequent position requests. The log file may help them.
Thanks again for the help. I’ll move to the SB forums and see if I can get some insight.
Just to be clear though, are we sure it’s a reporting error? The fact that the target has moved in between exposures seems to indicate that it’s reporting just fine, but that the mount has in fact repositioned itself for some reason. Either way, the only culprit left is TSX, I just want to make sure I ask the right question over there.
I’m not looking over your shoulder. I can’t see the mount. All I can see are the numbers in the log. The discrepancy could be a change in the numbers, a mount move or some combination of these.
Austin, as an aside, have you trying the Framing and Mosaic Tool? Center here is a very manual process; the F&MT allows you to just rely on the plate solving to center the coordinates derived from the F&MT.
It works really well for me. You might give that a try while you’re working with SB.
