Beta 327 Issues

Two Bugs in my beta 327:

  1. the user profile associated with my sequencing is lost on startup, and reverts to “none”. i can reselect and it works fine, but it’s not working as it should

  2. Starlight Xpress filter wheel problem -
    Blue filter is chosen, works fine for the first 10 or so exposures
    Blue filter continues to look fine (interface says Blue, the fits header shows Blue, the file name shows “B” for my filter type) but it goes to the next filter Ha instead.

this is a starlight xpress 5 position filter wheel
L
R
G
B
Ha

happened on multiple targets

Thanks Jerry for the detailed reply.

I must say that I did not find the previous focussing routine to be bad. For example, if for any reason I ran successive focus routines (like when calculating filter offsets) the focus point seemed consistent enough from one run to the next.

I note that your graphs look a little different to mine. I usually get an in-focus HFR of less than 1.0 (sometimes as low as 0.6). A typical focus run would go from around 3-4, through (say) 0.8 and back out to 3 or 4 again. I usually get a nice ‘V’ curve. I would only ever get a run looking like your second graph if the sky had clouded over to the point where I probably shouldn’t be imaging. Once I got going last night, the ‘numbers’ I was getting seemed about the same as I got before. I’m not going to pretend that I fully understand ‘quadratic fit’, but I do agree that it does sound rather spiffing.

I’m a little uncertain how to start ‘near focus’ without doing it manually. What I have been doing over the last couple of years (without issue) is as follows: I start from the assumption that I finish an imaging run at or near good focus (since I check all my subs every morning, this is a reasonable assumption for me to make). Of course, temperatures tend to be at their lowest at the end of a run. So, if I were to start the next night’s focus routine from there, this would be a poor starting position, since the focusser would be racked too far inwards. As a result, I will usually rack the focusser out a little at the start of the next run (around 200 points with my Optec/FT generally does it). Because temperatures can vary wildly from one imaging night to the next, this does mean, of course, that sometimes I rack the focusser out a little further than necessary (although sometimes that initial 200 ‘OUT’ is not enough, so it’s clearly not too excessive). I’ve taken the view (up until now) that it’s better to be a little too far out than in. In any event, up until now, the focusser would just keep racking inwards, through the nadir of the curve. It might take 7 or 8 steps to get to the lowest point of the ‘V’, but it would always get there, and continue through a further 3 or so steps so that it could calculate a focus position. Last night, it had just ‘turned the corner’ when it decided to reset (a little nearer to focus that it had started). Had it kept going it would have been able to calculate focus with just 2 or 3 more steps, but the reset meant I had to sit through another 9. That does not strike me as being especially logical.

As I said above, I don’t think my initial ‘rack out’ is so extreme as to lead me to be all that far from focus (I’d typically be getting initial HFR numbers of around the 5 or 6 mark). So I’m not sure how I achieve ‘near focus’ without going through a tedious semi-manual method.

I’m also not clear what I would lose by disabling smart focus.

In any event, focus had been working without issue for me, until last night using the new beta.

In any event, could not the logic be tweaked so that the routine ‘keeps going’, so long as the HFR number keeps decreasing?

This has generally been true for most of the SGP users over the past couple of years. There is a distinct divide between two different user camps. Those who find focus works great for them, and those who don’t. Simplifying things somewhat, this is usually directly related to the resolution your equipment is producing. Those with resolution < 1.0 arcsec/pixel and going to have the most trouble with focusing. Those with resolution > 2.0 are going to find it works great for them. Why? At resolutions > 2.0 the star finding routine in SGP finds many more stars and maintains good star and HFR counts over a much wider range of focus positions, so naturally all the focus processes are going the tend to work really well.

This is most likely because you are getting these numbers on your Takahashi FSQ 106 running at 2.092 arcsec/pixel. My rigs run at .70 or .75 arcsec/pixel so my HFR values range from 2.5-3.5 up to the 8-10 range. The HFR values will usually be inversely related to your resolution. Mine is 3 times yours, so your low HFR is 1/3 that of mine. The low HFR varies over a fair range based on the particular target and its mix of stars.

This is basically how we all have had to do this. That is because the limitations of the current star detection routine directly limit the out of focus range that the SGP focus routine is going to be able to effectively recover from bad focus. And again, the larger your resolution number, the wider this range is and therefore the more successful the focus routine is going to be.

Exactly the kind of fix we will be putting in.

But after you finally achieved initial good focus, how did it work for you? You only mentioned that it took a long time to find this initial focus.

Thanks for the detailed reply, Jerry. It’s much appreciated.

In fact, I have a number of permanent set ups from the Tak 106 you already mentioned, down to 0.75” from my TEC140 and QSI 690 combination. I usually get an HFR of just under 1.0 on the 0.75” rig, although sometimes it will be nearer the 1.2 mark.

Last night I was using my Esprit 120 and Moravian G2-8300, which is around 1.32”. Having achieved focus, everything seemed to work OK. But once it’s all up and running I tend to let SGP do its thing, so I wasn’t watching every run.

If the logic could be fixed as you say, then that would be great.

Steve

PS: Apologies for the double instance of ‘In any event…’ Quite ghastly.

This is exactly how myself, and probably most other folks have had to do this.
However, there is an enhancement that has been suggested many times on this forum, but never implemented by the developers.

This enhancement would be easy to implement, and would solve this problem perfectly for most users. An added major benefit would be the fact that it would prevent the routine from ever moving the focuser much out of good focus range, regardless of bad weather or hardware issues.

That enhancement is to add the two parameters that define the temperature behavior of your equipment. It is:
Position = TIntercept + (TSlope * Temperature)
So the two parameters that the user would input are: TIntercept and TSlope.
A third parameter would be helpful but could be hardwired in the program.
Tolerance: this would be the maximum distance that the program would ever move the focuser away from this best fit temperature regression line. Tolerance would be given in steps.

Example:
The temperature dependence equation for my TV127 refractor is: P = 20977 - 5.42 * F
where F is the temperature in degrees Fahrenheit. So I would input to the program: 20977, -5.42, and 50. Where 50 would be 50 steps, the most deviation from my line that the focus routine is allowed to move my focuser. The program already is collecting the -5.42, so only 2 additional parameters need to be input from the user.

The really good news on this — the SGP Log Viewer program developed by @mikaelA at SGP AutoFocus LogViewer - Auto Focus - Main Sequence Software will calculate this equation for you. Just run the program and open one of your logs that contains a lot of focus runs. Or combine logs from many runs to get a much more accurate set of values.

Here is an example (the different filters are displayed in different colors):

Another issue - that has now happened two nights in a row. I start capturing sequence involving the capture of a number of a 1200s Narrowband subs. On the second sub of the night, the lower info window reads ‘Integrating (Target) … 1200s (1198)’ and it ‘sticks’ on 1198. I let it sit in this state for over 20 minutes thinking that it was just a ‘reporting problem’. But no - it just kept sitting at 1198.

I had to Pause and then Resume the sequence to get things moving again.

As I said, this has happened two nights in a row. Tonight it stuck on the second sub. I think it stuck on the second frame last night too (certainly it was one of the early subs).

We’d need logs to see why (hopefully there is something logged)

It has just stuck again on 1198 at the beginning of the third sub. There was a small window that popped up saying something about an event warning and 1.5 pixels but it disappeared before I could get a screen shot of it or even register properly what it was saying. Once again I had to pause and then resume the sequence to get it started again.

Right. I totally believe you. If you could post logs, we’ll take a look.

I think this is the current one - and, if so, its happened twice in it:

sg_logfile_20191028195008.txt (441.4 KB)

It may be doing this after the new focus routine.

Three times now in 4 subs. Each time after a focus run. I did have one focus run without a ‘hang up’. I’m going to re-install the non-Beta version - this one seems way too flaky. Hope the log helps in fixing it.

@gnomus

I’m not seeing any relation to auto focus… maybe coincidental. What it seems is happening is that the guider issues a frame restart command when no frame is in progress and this borks the next event.

I am curious if this happened every time. If you have a spare moment, checking the log file with the 3 of 4 instances would be helpful.

Note on going back to non-beta any changes to sequences or profiles in 3.1 will not move back to 3.0.
You will need to navigate to your profiles directory and restore the backup copies (same name, just with .bak extension… delete all sgp and sgu files and then remove .bak extensions)

Possibly not. I’m not sure what the guider is doing from what you say. I’ve had no problem with my guider here at home, until this recent beta version. And no issues in Spain either (using the same set up on two rigs - where we don’t use the beta).

I tried re-installing the non-beta only to discover that all my Equipment profiles were no longer there. So I’ve had to go back to beta for now (I’ll try sorting everything out in the morning). Bit of a disappointing release this one (as suggested by the frequent new versions). But it is ‘beta’ I suppose. And I do have to admit that the parabola is much prettier than the ‘V’.

Log with 3 out of 4 attached (I think - I’ve had to do a number of restarts).

sg_logfile_20191028195008.txt (638.4 KB)

If they were present in 3.0, they are there in some form. See my comment above.

If it’s of any consolation, this issue is in 3.0 also… going back would not have helped.

I did find the issue and will have a fix shortly.

Glad to hear you’ve found the issue. But if, as you say, it’s in the non-beta version too, then I’m very surprised that we haven’t run into it before. (I use ‘We’ because I’m part of an imaging partnership … and because I’m pretentious, of course.) We’re pretty heavy users of SGP - perhaps 2 x 200 nights a year in Spain and 2 x 30 or so nights a year in the UK.

Can you tell us what the issue is?

The gist of it this:

A sequence image starts and occupies the camera. The guider issues a restart message due to guider error. The frame does restart, but in this case, the frame restart triggers auto focus (didn’t look at the trigger). This requires use of the camera, but restart did not properly end the failed exposure. Now we have a deadlock… The sequence is waiting for auto focus to finish and auto focus is waiting for the image to finish before it can start.

I did not validate that the issue is in 3.0 also, this is an assumption based on the fact that auto focus triggers and frame restart have not changed.

Thanks Ken. So if I disable the ‘Restart current frame when guider distance > …’, would that provide a temporary workaround?

I did not test this, but I am almost certain that disabling the function will prevent this issue from happening.