SGP and FocusLock Connection

Sequence Generator Feature Requests
1

Greetings!

FocusLock (FL) has been discussed in other topics on this forum. It is mainly intended to be used with the Innovations Foresight On Axis Guiding (ONAG) system. FL is available from Optec. It will monitor the shape of the guide star and adjust the focus continuously without bothering the imaging camera. It has the capability of storing filter offsets for the focuser.

To use with SGP, both FL and SGP need to connect to the filter wheel (FW). FL will adjust its focuser offset depending on the filter being used. However, FL and SGP are unable to connect to my QSI camera + integrated FW at the same time. This is due to the QSI driver needing to be connected twice, which is presently impossible. QSI has informed me that they do not know a solution to this issue. SGP can, of course, connect to both the QSI camera and FW, but FL can not connect to the FW at the same time.

I have attempted to use the Optec ASCOM Server to create a FW hub that will allow multiple clients to connect to the FW at the same time, but here again the integrated driver of the camera and FW gets in the way and makes this impossible as is.

It seems to me therefore that a better solution path is to have SGP and FL communicate with one another directly.

I am aware that this issue affects several other camera systems, such as reported in this topic from last year: In this topic it was discussed that there were plans to integrate better with FL allowing SGP to control it. I certainly applaud this effort.

What is the status of this develop, and when can we expect it to be implemented? I would be happy to help test this capability and make suggestions on features to include.

Thank you very much!

Best Regards,
Ben

2

I have just now posted a thread on this topic and only now realized it should have gone here. Sorry about that. Rather than to repeat my lengthy post, please allow me to provide this link instead.

Thank you very much, and I hope you will be able to implement this soon as it has been discussed in the past and likely affects a growing number of users.

Best Regards,
Ben

3

I merged these posts together and moved the initial request into Feature Requests. (which probably makes the second post make very little sense here but hopefully this is explanation therein).

I was just talking with Jeff from Optec about this earlier this week. It sounds like they’re adding in some functionality into their application that just needs to know the FilterWheel position from SGP to make things happen. We may look into further integration later as well.

Thanks,
Jared

4

Thanks for the update, Jared. This is good news. I look forward to the functionality coming online so that I can use the FocusLock software.

Best Regards,
Ben

5

I have been considering the ONAG as well so would be interested in this.

Questions for anyone using the system since the IF “forum” is not really a forum:

  1. I assume the astigmatism inducing element is built in? No real detail on this that I can find.
    I also note an “astigmatism corrector” accessory. Why/when would one need that?

  2. I would use either my QSI 6120 or STT 8300 as the imager and my STi as a guider. How
    much issue finding guide stars if I do not move the stage (I will be operating remotely)?
    (or to paraphrase Roy Scheider, am I “gonna need a bigger guider”)

  3. If I do need a bigger guider, any choices with larger chips and good QE at > 750 nm?

  4. Any good place you know of where I could get answers to the above?

6

CCDMan:

  1. The astigmatism comes from the dichroic mirror. It is tilted 45 deg from the scope’s optical axis. The front part of the mirror reflects light below about 750 nm. The imaging camera is therefore mounted 90 deg off the optical axis. This image is not distorted as it has reflected off the front surface of a flat mirror. IR light above 750 nm is transmitted through the dichroic mirror (it’s also a beam splitter in this sense). This passes through the front and back surfaces, thus imposing astigmatism. The stars, when focused, have a diamond shape.

  2. Being able to move the stage is an advantage, of course, in finding guide stars, but since the guide image will be in the near IR only, the ability resolve the stars may be improved. I encourage you to contact Gaston at IF about this.

  3. I have recently purchased the SX Ultrastar, which has 2x the FOV of the SX Lodestar X2 for this very reason. It has a good QE in the near IR.

  4. I would e-mail Gaston with these questions. He was very responsive to me and all my questions, and he provided good detail on the science and technology, suitable cameras, etc. In addition to that there is a growing number of experienced users on Astrobin, Cloudy Nights, etc.

Best Regards,
Ben

7

[quote=“BenKolt, post:6, topic:5107”]

  1. The astigmatism comes from the dichroic mirror. It is tilted 45 deg from the scope’s optical axis. The front part of the mirror reflects light below about 750 nm. The imaging camera is therefore mounted 90 deg off the optical axis. This image is not distorted as it has reflected off the front surface of a flat mirror. IR light above 750 nm is transmitted through the dichroic mirror (it’s also a beam splitter in this sense). This passes through the front and back surfaces, thus imposing astigmatism. The stars, when focused, have a diamond shape.[/quote]

OK, that makes sense. Reflected is not astigmatic, transmitted is.

I looked at that, looks pretty good. I also looked at the ZWO ASI 1600MM-Cool. 2X as expensive but MUCH larger and very good IR QE as well. Have to guide via ASCOM but I do that anyway and it is also useable as an imaging camera (of course not when mounted as a guider).

https://astronomy-imaging-camera.com/products/usb-3-0/asi1600mm-cool/

Thanks for the information!

8

As a workaround, until the IFI SharpLock technology is integrated, I watch the ONAG focus pattern in PHD2 and manually adjust the focuser control in SGP to correct for drift. Works amazingly well.

Just a reminder, FocusLock is the software application sold by Optec that incorporates IFI’s SharpLock technology. Personally, I would prefer to have SGP directly integrate SharpLock (even as a priced add-on) to avoid having to add another software package. When I first got my ONAG I looked at FocusLock but, at the time, it did not have native SBIG drivers which precluded my being able to test it with more than one filter. I don’t know if that has changed or not.

BobT

9

That’s an interesting workaround Bob. Can you adjust focus during data acquisition? I’ve never done this before, but I see no reason why you couldn’t. Unfortunately, that can’t be done for an automated session, so you’re right that I can presently only automate on one filter at a time, and that’s not practical.

I have received feedback from Jeff Dickerman at Optec, and he has informed me that they are indeed working on having FocusLock get the filter position directly from SGP. Focus offsets would then be applied accordingly.

I look forward to using this.

Ben

10

No problem adjusting during data acquisition, just open Focus Control in SGP and adjust the star pattern back to the best cross pattern you can get. It usually only takes a few steps on my Moonlight stepper type.

More remote control than automation in my case so this works fine in the interim.

BobT

11

Good to hear. I’ll look into that. In my situation it’s remote control until I go to bed, after which it’s automation …

Ben

12

Here are few links explaining the fundamental concept of SharpLock (SL) with an ONAG:

https://www.innovationsforesight.com/education/real-time-autofocus/

At first this real time patented focusing technology, known as SharpLock (SL), was available only for Maxim DL and PRiSM.

However we have discontinued both since the launch of FocusLock (FL) which is a cross platform solution for SL sold and supported by OPTEC. FL integrates the SL technology under IF licensing agreement.

We are in the process to release a new full frame solution which will allow guiding and focusing using the all guider field of view (FOV) at once, which with an ONAG is up to 28mm diagonal (APS-C size).

Here is a link to two CN pots I recurrently wrote on this topic:

I have a lecture with a live demonstration at the incoming NEAIC 2017 as well as a booth at NEAF 2017 to introduce this patented pending new approach for guiding and focusing which does not require specifically any guide star.

We should release a full frame guiding/focusing software hopefully for the AIC 2017

I hope this helps.

13

Thanks for the information. I do think I will wait until we see some form of integration with SGP so that no workarounds are needed. Clearly there needs to be a solution that not only focuses and (maybe) guides but is able to get filter information from SGP for offsets and is able to stop and start guiding and focussing when SGP is doing something that requires that (slews and such).

I would be very reluctant to start using any hardware or software that does not allow full and complete use of all SGP features (well, except for SGP focus, since it replaces that). I have used pretty much all of the other software out there, including all of the “Big Names”, some of them for many years, and would simply never go back to any of them after using SGP!

My Site

1 Like
14

Thank you for your feedback.

We are working with third party software to insure full compatibility between FL (and future developments such as full frame guiding/focusing) with other applications as much as possible.

FL was developed with the idea of being a cross platform solution such as many as possible people can use it across many different applications. For this goal FL supports ASCOM compliant devices.

I am certainly open to discuss the integration (native stand alone) of our technologies in some popular software, however having an independent application (supporting ASCOM) provides more flexibility to deliver improvements and consistent user interface and efficient maintenance across platforms.

On this matter FL + ONAG is similar to a camera,a rotator, or a focuser, it interfaces with third party software in a native mode through an interface such as a COM server.
FL acts as a driver would do, abstract the hardware and functionality from the application layer.

SL technology is a new concept and it takes some time to update current software to support/provide the proper communication protocol to full support it.

FL works with most auto-guiding software and any ASCOM compliant focuser.

Focuser corrections from FL are issued only if there are incoming new guide star frames, which happens when there is active auto-guiding.
When a third party software, such as SGP, is slewing the mount for instance auto-guiding should be put in hold and as a consequence FL automatically too.
On that matter FL is fully synchronized with the auto-guiding software.

The guide star reference roundness used by FL for auto-focus can be related to a given filter, if filters are not parfocal. This functionality requires that FL can access to the current filter selection from the imaging program or the FW driver.

In order to be as universal as possible FL is able to communicate with an ASCOM compliant FW.
The FW ASCOM driver would first connect with the OPTEC ASCOM sever which will share the ASCOM driver compliant device (such a filter FW) between several applications, for instance FL and an imaging software.
If the FW ASCOM driver provides filter information (as it should) this will be available to FL and any other third party software (such as SGP) connected to the OPTEC ASCOM sever.

I am strong support, when feasible, of using a standardized approach to communicate between all devices and software for astronomical applications, in my opinion this is the best way for many products and companies to provide a robust and unified way to interconnect.
It is useful since there is not one company providing all the parts anyway. This is the goal and the idea behind the ASCOM initiative and I think we should promote and support such an approach whenever possible. Some new ASCOM functionalities may need to be added with new technologies.

However not all software/hardware support ASCOM, but more and more do, for instance SBIG are working for providing ASCOM drivers for most of the camera eventually.

Since there are still many equipment using native drivers, and legacy to deal with, we have also implemented native (non ASCOM) connections to some of the most popular software (and we are still expending the list) .
However since there is no standard anymore here the task is harder, not only FL should know how to interface with each and every third party software, the software should also provide the necessary tools and information for a fully integrated solution.

OPTEC and us are working to improve the situation, which in turns may require some modifications to third party software, outside of our direct control.

This is why we have fully supported ASCOM compliant devices (FW, focuser) for providing an unified way too.

15

I have just checked the latest status of SGP related to FL.

I am please to report that SGP latest API now exposes the filter position (thanks Ben) such FL can select the right focus offset roundness values for a given filter.

The next version of FL, coming soon, will implement this feature such FL fully supports SGP, including no parfocal filter management for any filter wheel controlled by SGP.

16

This is good news, Gaston. Thanks for checking. And thank you for all the information on the technology and the science behind it.

And thanks, SGP developers for this update on exposing the filter wheel information!

I fully appreciate that it would be better if everybody utilized the same standard (ASCOM) in a fully compliant manner so that all codes and drivers would then be compatible, but of course this is not always the case, and such compliance and agreement can take time. Working through SGP is a welcome alternative under the circumstances.

Best Regards,
Ben

17

Hi Gaston
Unfortunatley the onag has to much of a backfocus to be used by me ( and many others I suggest )
But the Lacerta for Lodestar FOAG looks interesting to me
So If I read this right I could use this and your software and intergrate its use with SGP
I.e both can control the focuser and filterwheel , even though as I image with newts filter offset is irrelivent to me
Of course a all intergrated sgp package would be great.
If cost were a problem in doing this ( lack of licence sales etc ) I would imagine most of us would be willing to pay for this add on in sgp
Regards
Harry

18

Hello Harry,

FL works with Lacerta FOAG (lodestar) and therefore with SGP too, same concept than with the ONAG.

However the FL auto-focus performance is function of the guide star shape, off axis aberrations, such as coma, may impact the accuracy of the system. This may become more an issue with large imaging camera chips, or scopes without good off axis corrections.

Also, by nature, OAG have a limited FOV (at once) therefore rotation would be required for finding a guide star since the use of a large guider (APS-C size) is not likely to be an option.

The new coming full frame guiding/focusing approach will work with any guider FOV and with one star, as today, too. Yet, since OAG have a limited FOV, its benefice in term of SNR and seeing reduction will be limited.

The ONAG SC backfocus is 66mm, and for the XM it is 68mm.
New scope designs provides usually more back focus, also rotators are not necessary for guiding anymore when using an ONAG.

However there are still setups for which backfocus may remain a limitation, for instance the Celestron Edge HD series (146mm for the C11 and C14).
Although the C11 and C14 Edge HD usually have enough back focus, if this become a concern OPTEC offers their FastFocus system which uses the secondary mirror for focusing:

OPTEC also, on demand, offers a similar solution for Meade SCTs.

This technique does not add any back focus and works very well with FL, including the new full frame system.

19

Hi Gaston
Thanks for your reply
I think your Idea is great and If I had enough back focus I would look at the ONAG system
But a lot of systems only have 55-56mm ( after the corrector )which is a challang to get filter wheels in etc, this drives me potty as well
My tak 180 ed only has 56mm so the only option for me is the loadstar version
currentley I have never had to hunt for guide stars there are always multiple stars available Off axis and the stars are a nice
round shape ( I do understand your comment on this ).
The Lacerta does seem to reduce the optical entrance though ??? and may inpact on star availability+
Anybody else considering this
Harry
BTW slightley sorry if this off SGP a bit

20

Hello Harry,

Lacerta kit for Lodestar has a minimum impact on the Lodestar FOV, there maybe a marginal vignetting depending of the f/# but I do not think this should impact your ability to find a suitable guide star.

I always recommend to aggressively bin the guider as much as possible, say 2x2 or even 4x4 (for the Lodestar you can do so with its ASCOM driver. I do not know whether SGP offers binning for guider, beside native binning from the driver).

Auto-guiding software can easily delivers sub-pixel (1/10th) accuracy without compromising guidance.
Binning will improve SNR, roughly binning 2x2 double the SNR, 3x3 triple the SNR, …
Also the guide star is tighter, for some auto-guiding centroid based algorithms it make work better, larger guide stars maybe challenging.
The astigmatism created by the Lacerta device spreads a bit the starlight, binning will help.