Any plans to support FocusMax in the near future?



Any plans to support FocusMax in the near future?

I really like SGP and I’ve used it for a couple of years with good success until I entered the world of fast newtonians. For refractors SGP focusing algorithm always worked fine. However for with my Epsilon 160 f/3.3 and my Generic 12inch f/4 newtonian SGP focusing algorithm was a hit a miss. I thought that my issues were caused by poor focuser mechanics until I tested FM.

While I love the idea of focusing on target, I found FM very reliable and repeatable with any of my telescopes, regardless of the collimation (slightly out of collimation) and seeing.

FM can deal with centering, plate solving etc, so adding basic support should (without knowing anything about your code) not be so difficult to implement. Just leave the control to FM, wait for FM to do its thing, resume were you left prior focusing.

FM is very robust and it looks like most focusing corner cases are already sorted out.

Please give some thought to.




I think this has been brought up here before and the answer was no if I recall correctly.

The reason many of it’s users use SGP is because it requires almost no external software such as MaxIm and FM. Many if not most other sequence software does. Adding any third party software simply has to reduce reliability and increase complexity, there is just no way around that.

I used FM for many years (in fact from the day it was announced and released at the now defunct ITS conference). One of the reasons I went to SGP is that it does not use FM (or MaxIm) and that makes it more reliable. My results have been at least as good and significantly more reliable and repeatable with SGP alone.

IMHO, it would be a step backwards to support FM.



With refractors I’ve no problem focusing with SGP, but that is not the case with fast reflectors. I like how SGP try to achieve focus, no slews,always on target, no training curves etc, however in some cases FM works better.

I am not saying that SGP focusing routine should be replace by FM, I am bring it up that in some cases FM works better and some users will benefit by adding external focusing support. Software Bisque is also developing another routine that focus on target and they claim to be very robust, so opening SGP to external software is a step in the right direction (IMO). Whats wrong with having options?

Regarding external software support, SGP is already using external software very successfully (PHD, Astrometry, PlateSolve2, Pinpoint).

Even if this feature has been brought up in the past, I think is healthy to let the developers know what I need as a customer. I am very pragmatic and the reason I am asking for this feature is because FM works better in some situations.




We owe a lot to the pioneering work of the fellows that designed FM. Like CCMan, however, I found the implementation was, in practice, unreliable. Yes, when it works, it can be very good indeed, but I do not miss the plethora of different screens, temperamental nature and large degree of tweaking parameters to get it to perform each night.


Absolutely agree. I have met and talked with both developers years back when they introduced FM, both great guys, For it’s day, it was truly revolutionary. I just think SGP offers a more robust and (for the vast majority of users), better, solution.

It might seem that making SGP work with FM is trivial but adding something like that is anything but trivial and almost certainly has more downside than upside given the small number of potential FM users.


I agree options tend to be good -

With focusmax, however, and unless it has changed a lot recently, SGP would have to relinquish control of the CCD camera so Maxim (or the other program I don’t remember now) can take control of it - then when back to SGP, connect to the camera again, check cooler and any other thing Maxim/FM may have changed… Same for the telescope, but in this case POTH can help.

So not really very easy - and a potential source of problems as SGP loses control of so many things for a while.

I’d rather devote the effort to improve the current SGP algorithm.



FM hasn´t changed much. In order to make this happen (if ever) FM needs to add support for SGP as well. FM would have to delegate (at least) camera control to SGP in lieu of MaximDL/TheSkyX. IIRC Pempro3 has support for SGP (for camera control) so maybe all plumbing to integrate with FM is already there.





On the FocusMax support forum more people have asked to include SGP support. It looks like Steve Brady (FM developer) is interested and started the talks with SGP developers.

I hope FM will eventually be supported by SGP. There are some (edge?) cases where SGP focus algorithm doesn’t work well no matter how much you tune the routine.




When I used FM with Maxim DL, I did not like the proliferation of windows and for me its reliability with refractors was worse than SGP’s. I was unable to leave it unattended.
It certainly pioneered a way to predict focus positions and has done a lot for amateurs around the world but paying $149 for a program that was freeware goes against the grain.


Hi Buzz,

Having more options is better, I was early adopter of SGP and I was very successful using it however there are edge cases where the built in focusing routine is far from perfect and FocusMax is better alternative. I won’t start listing the pro and cons of both solution, I don’t want beat a dead horse.

By no means we are asking to deprecate the current built-in routine in favor of FM. We want to have another alternative for focusing.




I agree - the principles used by both are the same, it just how it is implemented that are a little different. I certainly prefer the convenience of focus on the imaging frame, rather than move to another star. As I said a little earlier - some alternative modelling to a simple linear regression and correlation functions might sort the wheat from the chaff and allow SGP to work as effectively with less points. If I recall correctly, the slope is predictable too, according to the f/ratio, which helps with the modelling.


I agree with Buzz, even if FM were better at focusing, not a given, having to move to another star to focus is a complete no-starter for me. With a little work on the current focus routine, it is capable of completely solving the current problems.


I think one thing that FocusMax has going for it is the way it characterizes the focus curve ahead of time.
It does so by taking multiple exposures at each focus position to help overcome seeing issues.

Another issue with SGP vs FocusMax is that by using a single bright star FocusMax is able to calculate a better HFR value on a larger star and seeing is less a factor. That is, there are more pixels to do the calculation and seeing is a smaller percentage of the star image. SGP tries to overcome this problem by using multiple stars but the disadvantage remains.

I have not used FocusMax but it sounds like it is much faster getting to focus so the time required to slew and reestablish the target is not so much a factor. On the other hand, SGP is doing the focus at the final scope position so there is no possibility of mirror flop caused by the final slew.

I can imagine SGP having a “Focus Wizard” that you could run to establish step size, backlash, target HFR and the curve slopes - this process could be done with a single bright star like focus max. Once the characteristics are known, SGP would be in a better position to evaluate the curve of a focus run. Knowing the focus curve, SGP would likely not have to do a full focus curve run but rather estimate the final focus and do a narrow focus run around the estimated focus point. One weakness of the current SGP method is that it is easily fooled by one exposure that has especially bad seeing. So if SGP required fewer data points for a focus run then it might be practical to take more than one exposure at each focus position to help reduce seeing issues.


I’m not convinced that multiple stars help a great deal…This opinion is formed from observations while collimating my RCT, using out of focus stars. The process tries to form a perfectly evenly lit donut. I will often slew to a loose cluster and take short exposures and examine the stars. I often have to ignore many frames due to seeing and only once in a while will I get a good one with which I can tweak the mirror adjusters. The thing that I have noticed is that any seeing distortion on the donut is mirrored on every star in the frame, strongly suggesting that the seeing conditions are common over the entire field of view.
[update] - that being said, using multiple stars does address HFD calculations from what I would call ‘image noise issues’.


I guess it depends of the FOV. With a wide FOV, you would expect to see more seeing variation across the field.
It nevertheless points out the challenge of setting focus based on one or more exposures that have poorer seeing. I gather FocusMax ameliorates that issue with multiple exposures.


Could be. The only way of telling is to compare stars HFD across the frame and calculate the variation between successive exposures. It is often a compromise between expediency and accuracy


Hi buzz,

I think I have seen evidence that multiple guide stars can help. When I have captured video of the moon I often see different parts of the video distorted unevenly. I believe this effect is most often caused by tube currents, but it can also be caused by nearby heat sources (e.g. people, roofs, streets, etc.) wafting heat upwards in front of the telescope’s view.

However, once a setup has reached temperature equilibrium and no other heat sources are causing localized atmospheric disturbances then the sum of multiple stars approximately adds up to the equivalent of one brighter star (actually, slightly less because there may be more pixels producing larger accumulated readout and dark noise).

BTW, I believe that multiple stars would be favorable to a single brighter star if the equivalent brighter star would have saturated.



Very true - I guess there are lots of mechanisms going on here, some are very local, some more global.