WIth my own observatory and therefor a permananent setup I’m able to get some sleep while my setup is running. Using SGP for several months now all the settings are as they should be for an automated sequence from start to finish. I had a little problem a few nights ago with the guiding in PHD. The guiding was very good during at the start until I went to bed, but for some reason at about 2 AM something went wrong and SGP went into recovery mode as it should. Maybe some clouds were covering the guidestar, I don’t know. The same thing happened a few nights later again while I’m sure that during the night no clouds were present. Probably my mount has some issues when it reaches a certain position.
I was thinking how I could resolve this problem and came up with an idea: after creating a sequence I copied the target in the sequence. Adding events to the first sequence that would end around the time my mount will run into the position when guiding gets bad and in the copied sequence I marked the option “recalibrate PHD when target changes”. Problem solved!
If you post your PHD2 Guide log from the session we can take a look and see what caused the problem.
Regarding recalibration, our recommended best practice for PHD2 is to calibrate once at low declination (near the celestial equator). You should do this manually (not as part of a sequence) and confirm that you have a good calibration. Enable the option Auto restore calibration on the Guiding tab of the brain.
The rationale for this approach is that it is only necessary to calibrate once if you have an ASCOM connection to your mount (Mount or Aux Mount). PHD2 adjusts RA guide corrections based on declination. Once you have a good calibration, it is best to keep re-using it. If you re-calibrate during an unattended sequence run, there is a chance that something could go wrong and adversely affect your guiding for the remainder of the session.
Jeroen, I don’t see anything unusual in the log around 2AM (11/3). Here’s a plot from PHD2 Log Viewer. Yellow is star mass, white is SNR, Blue and Read are RA and Dec offsets.
Settling at regular intervals indicates SGP was taking images, no recovery mode. Pause/Resume before 1:50 indicates an auto-focus run.
Is this really the log file for the incident you were concerned about (“The same thing happened a few nights later again while I’m sure that during the night no clouds were present.”)?
Hi Andy, i was a bit confused and indeed posted the wrong log file. I found the right one now. It seems like SGP lost the connection with PHD or PHD crashed for some reason. PHD stopped guiding at around 2 AM. The PHD log file can be found here:
And the corresponding SGP log file can be found here:
Hi Andy, thanks for your research. It’s seems odd that SGP has aborted the sequence because of a failed meridian flip. The object I was photographing that night was The Ghost Nebula which passes the meridian from east to west at around 10 PM local time. I know, because I was watching SGP performing this meridian flip which was fine. After the MF I watched the setup for another hour. At 6 AM in the morning the sequence would end automatically. That’s only 8 hours after the culmination. It would take, starting at 10 PM, 12 hours for this object to pass through the north. I hope Jared or Ken is able to take al look at this. Thanks again for your effort!
This appears to be, yet another EQMOD issue where the mount side spontaneously changes without any prompting or instruction from SGPro:
At 1:10:
[02/11/2015 01:10:50] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[02/11/2015 01:10:50] [DEBUG] [Sequence Thread] Meridian flip not needed, telescope on East side
Sixteen minutes later at 1:26:
[02/11/2015 01:26:05] [DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[02/11/2015 01:26:05] [DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[02/11/2015 01:26:05] [DEBUG] [Sequence Thread] Meridian Flip needed, Hour Angle >= Degrees Past To Flip: 93.5744516914054 >= 1
This seems like this exact issue I have linked below. You will want to talk to the EQMOD community about this… we cannot do anything.
If the pointing state (aka Side of Pier) reported by an ASCOM driver spontaneously changes as a result of tracking then it is broken. It does not comply with the ASCOM standard.
Pointing state can only change as a result of a slew, never as a result of tracking.
Is it possible to say what position the scope was at when these spontaneous changes happened?
I’m in the process of putting a pointing state tester together. This will check how a mount behaves when it tracks past the critical points such as the meridians. There seem to be other points, maybe at hour angles 6 and 18 or possibly when the mounts from pointing south of west to north of west. It looks as if this mount may have got the pointing state wrong around one of those.
Hi Chris, the mount was 3 hours past the meridian flip (around 22.30 I watched it do a successful MF) )when this error occurred, pointing almost upright. I’m using a new SkyWatcher EQ8 with a Synscan (if that is of any influence). When I switch on the mount I don’t care about putting in date, time etc, I just push “enter” several times and then set it to “PC Direct mode” because EQMOD is taking care of things. The mount is perfectly aligned.
The scope was pointing at RA 21H 16M and DEC +68 15 while I’m at 51.58 N and 5.17 E. Hope this helps.
Is that UTC time? I guess UTC+1 because you are in the Netherlands.
Assuming 00:16 UTC and your location and time gives an hour angle of 6 hrs. That’s one of the pathological cases that I test for.
The EQMOD people need to make their driver ASCOM compliant. This could have been seen using the current ASCOM Conform application.
Hi Chris, it was indeed UTC+1. The problem occurred about 3 hours after the meridian flip which was at around 22.30 UTC+1. At 01.30 UTC+1 SGP apparently tried to do another pier flip. I will try this weekend if I’m able to repeat the same situation and see if there’s a way to fix or bypass this. It’s worth the time because I want to let the setup run during the night. I also have to check what version of EQMOD I’m using now, but I guess it’s 1.27i. Maybe upgrading or downgrading will do the trick for me.
From a look at the log there was a meridian flip at 19:15 which is 6 hours before the erroneous flip attempt at about 01:16. I don’t see any flip attempt at 22:30 but the bad flip attempt being 6 hours different is consistent with what I think is happening.
EQMOD is currently on 1.28k. They did some changes to pier side reporting in 1.27p. I’m not sure if it fixed this issue but I haven’t had this problem since I updated. It could be a coincidence, I don’t know. However, I notice everyone who has posted about this problem is on an old version. Latest versions in files area of EQMOD Yahoo group.
The latest version that’s publicly available is on SourceForge, that’s 2.71l
I’ve checked that and none of the pier side options work properly. Physical is least broken in that one of my four tests work, With the other options none of them do.
Chris - If you mean V2.17l it was released in 2013. Its the latest version of EQASCOM on SourceForge. If you go on their Yahoo site they have released 15 versions since. The latest this October. They have made changes to pier side called “Pierside reporting swapped.” I don’t know why they all aren’t on SourceForge - maybe they are betas? Anyway, I was on 1.27l and had this problem. I switched to a later version 1.28g and haven’t had it since. However, I didn’t have the problem regularly so this may be a coincidence as weather has limited my recent imaging.
I’ve just joined their group, waited to be approved, and downloaded and installed the latest version 1.28k. I’m trying the simulator.
That one handles pointing state correctly as long as you select the SideOfPier option V1.24g. If the others are the same as in 1.27l.then they are all wrong.
Setting Physical is correct between hour angles 18 to 24/0 to 6 but fails with the unexpected pier flip at hour angles 6 and 18, this is what Jeroen is seeing.
This doesn’t seem to be something that should be user configured, the user is in an even worse situation than the developers when it comes to deciding which is correct.
Thank you for your input here Chris, I’m watching this thread with interest, even though I haven’t experienced this unexpected pier flip issue.
I use Eqmod with my Avalon Linear FR and have the latest release V128g and currently select ‘physical’. From what you report I guess I have been lucky to date.
Due to some dry weather today I was able to test the latest version of EQMOD and it worked just fine!
First of all I set the “Side of Pier” In EQMOD to “V1.24” instead of “physical”. After that I started up both SGP and Cartes du Ciel and connected them both to EQMOD.
I had to do this test in daylight, so I made some changes to the SGP settings: I disabled autoguiding, dithering, autofocus,
and autocentering. Disabling the platesolve wasn’t possible as SGP needs this if it wants do to a auto meridian flip.
After that I pointed the scope using CDC to a point west of the meridian and slewed to the point at a hour angle of 6 hours until EQMOD changed the “Side of Pier” from “East pointing West” to “West pointing East”. Then I slewed back to the east a bit, so the scope was “East Pointing West” in EQMOD. I then transfered the coordinates displayed bij EQMOD into the target in SGP and clicked “Slew to target”. After that I started the sequence with capturing frames taking 30 seconds. After a few minutes EQMOD switched the pier side, but SGP didn’t initiate a meridian flip (as it should). So far so good.
After that I repeated this at a point just before the meridian (east side), just to make sure that SGP would perform an automated meridian flip. And it did!
Here’s the log file from SGP. The first part is from the scope pointing about 6 hours past the meridian. At around 11.57 the scope was pointing just east of the meridian.
