Recovery not working

Sequence Generator
1

Looks like my Recovery is not working. It is indicating in the bottom right that it is enabled with a green circle. Yet in the logs it’s reporting as false. It is also ticked in the ‘options’ recovery menu… all pointing to the fact that Recovery mode is enabled.

I have just updated to the latest stable version of V2.5.1.15

I have attached the SGP and sequence log.

Dropbox - File Deleted sequence files
Dropbox - File Deleted SGP log

2

I hope someone has some ideas on this as it has happened again last night… cloud came across, it didn’t go into recovery mode and so I have great images of the target in the wrong place!!

Can ANYONE help? Recovery is clearly not working, despite it being activated in software and yet showing false in the logs.

I can provide logs from tonight again if that helps.

3

I had this a while ago but thought it was fixed. I need to go back through my posts.

4

I actually don’t see any failure state in the attached log that would indicate that recovery should have been triggered. It appears that all ran successfully and even ran the end of sequence events around 5:47am.

To trigger Recovery there needs to be some sort of failure. Either guiding, solving, focusing, etc. It’s possible that if you’re imaging through clouds that the guider is still locked onto something.

If you can attach the logs from last night’s run I can take a look.

Thanks,
Jared

5

There was a guiding failure - The guidestar was lost around 01:33

Here’s the PHD log for this session where you can see that the guide star was lost

Recovery SHOULD definitely have been enabled - There was cloud, the guide star was lost and the target was totally out of frame before the guiding took back over again.

If nothing else, can you tell me from the log whether recovery is enabled?

6

Unfortunately I can’t. It seems like something is certainly wrong with the setting that is being used by recovery mode though. So it’s likely not working correctly. Currently looking into that now.

Thanks,
Jared

7

Thanks Jared - It would be good to get recovery working.

8

So after looking at this again I don’t see a reason it should have entered recovery. The issue that I spoke about earlier was a Red Herring and has been around for a while. Essentially when we output all of the settings at the top of the log some of them are the default values as the settings system hasn’t been initialized yet.

So it’s very probable that recovery was on but it didn’t get triggered. You start dithering around 1:33:

[13/06/2016 01:33:52] [DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Guiding
[13/06/2016 01:33:52] [DEBUG] [Sequence Thread] Waiting for Auto Guider distance to fall below 1

And it completes at 1:41:

[13/06/2016 01:41:20] [DEBUG] [Sequence Thread] Distance stayed below 1 for 5 seconds, done settling...
[13/06/2016 01:41:20] [DEBUG] [Sequence Thread] Auto guider has settled...

This is well within the 15 minute timeout for dithering. So recovery was not triggered. PHD did tell us the star was lost which would have triggered a frame restart event, but since you were dithering there was nothing to restart.

Hope that helps,
Jared

9

So in this case a ;dither’ lasted for 8 minutes? In which time my target moved from its centre position and so all subsequent frames were useless… I’ve watched dither and it just does a quite few pixel move for milliseconds then carries on… should it be running for 8 minutes?

Sorry, just trying to get my head around this…

10

Well technically the dither is fast but getting back within your bounds for settling is what is taking time. In your case it toook 8 minutes to settle for 5 seconds with a guide error < 1px. PHD2 reports a distance and SGP waits until that distance is < 1px. We’ll wait for up to 15 minutes before we decide that the settle has failed. If we determine it has failed then we launch recovery mode.

But we don’t have enough insight to know what is “too long”. But we’re pretty sure that 15 minutes is too long.

I think what would be best in your case, and maybe others, would be something that would check the distance off target prior to starting a frame. Essentially look at the RA/Dec of the scope compared with the target and if it’s over your centering tolerance to recenter the object. Unfortunately we would probably want to do this prior to the dither which would have caused you to lose a frame…but everything after would have been decent.

Thanks,
Jared

11

In this case Jared, when looking at my recorded All Sky frames, the 8 minute dither is because of cloud passing at that particular time… it’s normally settled back in seconds, not minutes!

Are you suggesting that there may be some mileage to add something to SGP for checking the RA/DEC coordinates?

12

I’m saying 2 things:

  1. It’s hard for a machine to know what is a cloud and what is bad guiding. Since we don’t yet completely integrate with weather stations a cloud just looks like bad guiding to us. You’ll notice in your logs that PHD was always locked on to something and reporting a distance. I don’t know what it was locked onto but it was trying to guide on something. We don’t have enough context to know that a cloud is in front of your target, and PHD was getting enough data to think it was still locked onto a star so we waited for it to settle and then continued.
  2. Yes, we may consider adding something that monitors the scope position and the target position and invokes Auto Center if these two are farther apart then your auto center allowance. Not promising anything at the moment, but that seems to be the correct way to solve your problem here.

Thanks,
Jared

13

Would there be any mileage in being able to manually say how long you allow the settle to happen in PHD? For example I know that my mount settles very quickly, so anything more than 30s is absolutely going to be cloud of some description (or guiding on a hot pixel). If I could set a time limit to enforce a recovery then that would solve that, without having to draw the distinction between cloud or bad guiding.

In this instance if your mount requires longer to settle then you could put in a time that would be specific to your mount.

That way, there would not have to be any ‘is it cloud / isn’t it cloud’ decision by the software. It would know that after a stipulated period, if the mount doesn’t settle then out it into recovery.

14

I think the better way to handle this is detecting that your mount goes off target, which is really what the culprit is here. For instance if your settle time is 30 seconds and you’re guiding on close stars you may end up going off target accidentally even if you manage to settle in those 30 seconds. I don’t think adding multiple options on controlling recovery is a great solution as it makes SGP more complex overall and less understandable for new users.

Probably the right way to solve this is to detect if [current position] > [Auto Center allowance] and if so trigger an auto center to get back on target. In addition to solving this issue it also takes care of other issues where scopes may drift. We actually have another request run auto center every X minutes but I think being more deterministic about it is likely the right way to go here.

Thanks,
Jared

15

Thanks Jared for this - I look forward to see what gets implemented in SGP. I think that the idea of an auto centre sounds very useful.