I’m a happy SGP user since several years, but I always felt that it lacked a autofocus (AF) history feature. Particularly I would like the ability to view the AF info stored in log files after a nights session, such as AF focus position, best HFR, temperature, etc. throughout the night. Just like I review the nights PhD guiding with its log viewer.
So I went about and programmed a simple application that can read a SGP logfile and extract the AF data. The main output is simply a textbox filled with the relevant SGP AF messages (in raw format, unformatted by my application). The type of messages that are displayed are somewhat subjectively choosen by me! Then the application also shows a summary of all the complete AF runs found in a file. Here is a screenshot:
I suppose this could also be useful to others, so I have decided to attempt to “release” it. However, I AM NOT A DEVELOPER, so there is a real risk that this application wont install and/or work properly on some Win systems. I have tested it on all computers available to me, and I have also tested it using 10-15 logfiles that I have downloaded on this forum, and it all checked out. Also please bear in mind that I will not have time to provide a lot of support or make large changes to the application. The idea is to keep it as simple as possible.
since extracting the SGP logfile “by foot” is a very time-consuming task, your effort is very interesting for me. I would like to evaluate some of my logfiles and will use your application.
I understand that you have not much time for further development. Are you interested in feedback at all?
Hi Mikael, will it be able to show if there is possible signs of slippage when focusing typically for crayfords at angles when gravity may have greater effect?
Hi tlooi,
I don’t have any experience with slippage issues, so I don’t really know how this would show up in the AF runs? Note that this software only summarizes complete AF runs (manually trigggered or triggered by a running sequence). I doesn’t track HFR of captured images as part of a sequence. For that there is already an excellent history function in SGP.
Mikael
the filtering of messages relating to AF generating the “scan details” works just fine.
Just as Brian, I intend to use your application for the evaluation of the temperature dependence of the focus position. I would like to have date + time (formatted as in the SGP logfile) as first data column. In my view the evaluation of the temperature coefficient is better done in a spreadsheet software because that approach offers greater flexibility. In order to facilitate the data import into spreadsheet software, it would be convenient to have tab instead of blanks as delimiter, like Brian already suggested.
In the meantime I had a look at several old SGP logfiles, and I want to describe my experience with your AF LogViewer.
The AF Graphs are well suited for the quick judgement of the quality of the seeing and its stability over a capturing session. I saw striking differences in this regard, here are two extremes (Auto focus frequency was set to 0.5 degrees in both cases):
The first screen section (see AFGraph_01) shows 7 AF Graphs of 12th May 2018 from 21:55 till 06:00. Initially the seeing was bad, but it improved and after midnight stabilized. The change is easily recognizable by plotting the HFR value of the validation frames vs. time (see HFR).
T 13.5 -> 10.4 °C,
HFR 4.9 -> 1.8 -> 2.1.
The second screen section (see AFGraph_02) shows 9 AF Graphs of 5th June 2018 from 22:25 till 01:55. Steady seeing conditions prevailed throughout the whole capturing session.
T 15.5 -> 13.0 -> 15.0 °C,
HFR 2.0 -> 1.7 -> 2.1.
In a previous version I had a column of temp coeff data (steps/C). But then when I tested my software on lots of the logfiles posted by different users on this forum I realized that in most cases that gave nonsense data, often bevause either there was no temp data (temp = 0), or the temp difference between AF runs was so small that the temp coefficient diverged to crazy values. I tend to agree with the posts here below that using these data in a spreadsheet and look at focus shifts over large temperature changes (like seasonal ones) probably makes more sense to most users. But I am open to this and could try to include this directly in the application, with some conditions on the temp difference (if too small, then give NA).
Nice results! In fact, my main motiviation for writing this application is exactly what you show. In my system (plate scale 0.9"/pixel), there is a really strong correlation between sky conditions and the shape of the AF curve. Nice deep V curves going down to 0.9-1.0 HFR, and I know the night will be excellent. Shaky, shallow and ragged curves with a lowest HFR well above 1, then I can close the obsy. But then again, as you show the AF runs will sometimes improve vastly over the night. So looking at the log with the AF viewer tells me quickly how good a night was in terms of seeing.
And your HFR graphs over time could be something to include directly in the AF viewer. But it would have to be sorted in terms of filters, as some users focus with filters. I think that is doable without too much additional programming.
I also agree that using this in a spreadsheet could help evaluating the temperature coefficient. I can easliy include the date and time as you suggested, but I would like to keep “AF Run” as first column. Ok if I put date and time as second column?
I can also try to use TAB as delimiter, although it is not yet clear to me how to do that with my current way of programming… I’ll have a look.
Hi Mark,
Thanks! I have not experience with slippage. I’m no expert on focusing, and I have only own one setup.
Could you please describe what you will be looking at using the AF logviewer? Difference of AF best focus position as a function of altitude ?
This is a really great application!
I’d love to see the inclusion of calculation of temperature coefficient.
To make this easier i think you should add importing several logfiles at the same time, this would help a lot for people with absolute positioning on their focusers as they could use data from several nights.
Also add the possibility to enable/disable calculations from user chosen V curves.
Here’s my curves from last night, they improved a lot after enabling backlash comp and raising step size.
I have now raised it again from 2500 to 2800 that i will test tonight.
Something else that could be added is calculation of focus offset, to do this i have used spreadsheets.
To gather lots of data enable autofocus after every image and make a rotating sequence with all the filters you want to gather data from, length can be 0s and use bin4 to save download time.
Thanks for the feedback and glad you found it useful!
These are all interesting ideas and I will consider it. I will think about what could be done without too much changes to the code (eg. adding a temp coeff calculation), while other things would have to wait for a more major revision (and when I find the time to do that! :).
In the mean time the use of the summary output and a spreadsheet can achieve a lot of the things discussed here.
Hi Mikael, give me a moment to explain.
My setup includes a Starlight Instruments 2" Crayford Style Feather Touch manual focuser. I’ve had it for many years, long before SGPro came on the scene.
As a manual focuser its a great device. I’ve since added to it the Starizona MicroTouch controller for absolute positioning to accomodate SGPro. And as an autofocuser the setup is still very good.
But the Feather Touch is a crayford design which uses friction to move the drawtube. As a result there is always a slight amount of slippage between the driver and driven friction surfaces.
Now, I have seen little, if any, problem for the setup achieving accurate focus for a given autofocus run. However over multiple AF runs (i.e. a night’s session), the reported drawtube position is always further “in” than its actual position. This kind of feels right since the stepper motor has to move the drawtube against gravity and make up for losses.
So bottom line is that I cannot rely on the reported stepper position to match the actual drawtube position.
Your utility will allow me to better investigate the behavior of the focuser’s mechanics and possibly make some improvements to its operation.
