Beta 327 Issues

Don’t use Temperature Compensation with this release.
The first temp comp moved my focus position an enormous amount.
The temp comp marker is not being initialized properly.
[10/26/19 19:26:02.643][DEBUG] [Sequence Thread] Temperature compensation: Temperature change is 549.82 degrees (end temp: 49.82 - temp comp marker: -500); Requesting relative adjustment of 2749 steps…
[10/26/19 19:26:02.644][DEBUG] [Sequence Thread] Temperature compensation: temp_comp_min_step_threshold found (3 steps)
[10/26/19 19:26:02.644][DEBUG] [Sequence Thread] Temperature compensation: Requested compensation meets minimum threshold, applying…
[10/26/19 19:26:02.644][DEBUG] [Sequence Thread] Temperature compensation: Adjusting for 549.8 degrees (end: 24242 - 49.8; start: 21493 - 50.0; coefficient: -5) for 2749.1 steps… (340.3 KB)

Other than that, this release worked perfectly for me for my entire 11 hour imaging session.
I did turn off all temperature compensation. I also did not try to test recovery mode for failed centering on new target slews and meridian flips, since the 327 doc did not indicate it included any fixes for these issues.

For me, the removal of the “Slew To” and “Center On” check boxes in the Target Settings dialog box is not a good change. As check boxes, they were immediately visible and obvious when you opened the dialog box. I always thought the defaults should have been to have both checked but at least it was obvious they were unchecked. With those options now in an easily overlooked drop down, I think there will be a lot of problems when the scope fails to slew and center on target start.

I would request the return of the check boxes or at least make the drop down default to “slew to then center on”.



It might help if some capitalization were used:
“SLEW to then CENTER on”

Focussing seems, if not quite broken, then certainly worse (slower) than before. I didn’t change any settings from my standard set up. I started the focus routine from well outside of focus. It tooka number of frames and was just ‘turning the lower corner’ when the routine decided to restart (albeit from a lower initial position). Is there a way of going back to the old system?

Yep… this was a combination of the code that gives the temperature value a sanity check and not being in a place where I could test properly. I have this buttoned up now.

There is still a math issue here that I need to find… SGPro still thinks that the sequence needs to flip when recovery starts.

@gnomus, you picked the one area of the new focus routine that still needs a lot of work. In fact in another thread I mentioned that I had to turn off Smart Focus because the new routine could easily move you way out of focus if you allowed it to by turning on Smart Focus.

If you had started reasonably close to good focus, like I have always had to do for years, because the old routine was poor at this also, you would have found the new routine to be substantially better at everything else. Just turn off Smart Focus, start near focus, and you will love the new routine.

There are two really new characteristics that come with the new routine.

  1. the new Quadratic fit logic that determines what position is best focus after the focus images are taken is far superior to the old routine. It also provides a critical piece of information, the quality of the run that can be used for making the correct decisions.
  2. The new Quadratic focus fit has required a complete rewrite of the higher level logic that determines the overall flow and decision making about what steps to take after the Quadratic routine has done its thing. This part needs a lot of work to make finding good focus from badly out of focus something that works really well.

The developers and the Quadratic team have mapped out exactly what needs to be done to make part 2) work fantastically better than it ever did before. Just have patience, it is coming.

Until the work on 2) is done, you need to start in focus and turn off Smart Focus.

Here is an example from last night on my TV127 refractor where the new routine performed much better than the old one ever could. Here are three successive focus runs. I was focusing every 30 minutes.

At 3:57am, this fine run with Quality = 99%:

30 minutes later, this terrible run with Quality = 18%:

Followed immediately with this run with Quality = 100%:

The old routine had no way of knowing how good or how bad any of the runs were, so when the bad middle run would come along, it would merrily move focus to a very bad position and not even know it.
That is why for several years I have never used Smart Focus to minimize the chance of it ruining my focus and never recovering for the rest of the night.

1 Like

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

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.


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.

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 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.


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)