In the kstars log, there's a line that looks like this:

Autofocus values: position, 54671 , temperature, -274 , filter, ""

The temperature is not set right. See 3rd post for images of Ekos dome weather tab and INDI showing correct temperature. The kstars autofocus position log entry should show this temperature.

-274C means no temperature sensor is attached.

Edit: Both Ekos and INDI know and report the temperature correctly. It's just the kstars autofocus log message that's incorrect. Here's two (attached) screen shots showing this (dome tab + INDI PPB). So, why isn't the kstars log reflecting what the dome tab already knows? Isn't this just a bug to be fixed in the kstars log? I suggest that whatever the dome tab shows for temperature should show in that focus position, temperature entry.... Do you agree?

The code for this issue is in focus.cpp starting at line 2788. It's looking ONLY for a focuser temperature sensor with INDI property name "TemperatureNP". By default (in case the focuser doesn't have a temp sensor), it pre-assigns a -274 value. Otherwise, it assigns the temperature from the INDI property fetch.

I am not familiar enough with the kstars/INDI development process to change and submit a revision to this code. However, it would seem a solution is a relatively simple addition of an else clause at line 2797 (and a couple of declarations required to access the "WEATHER_TEMPERATURE" INDI property (for weathersensors). The else clause would attempt to fetch the more generic INDI "WEATHER_TEMPERATURE" property, if and only if the focuser temp sensor fetch fails. The added attempt to fetch a weather sensor INDI temperature property would cause no harm if not found; the else clause would simply end and the -274 default value remain. Here's the relevant code snippet:

2788 // CR add auto focus position, temperature and filter to log in CSV format
2789 // this will help with setting up focus offsets and temperature compensation
2790 INDI::Property * np = currentFocuser->getProperty("TemperatureNP");
2791 double temperature = -274; // impossible temperature as a signal that it isn't available
2792 if (np != nullptr)
2793 {
2794 INumberVectorProperty * tnp = np->getNumber();
2795 temperature = tnp->np[0].value;
2796 }
2797 qCInfo(KSTARS_EKOS_FOCUS) << "Autofocus values: position, " << currentPosition << ", temperature, " << temperature <<
2798 ", filter, " << filter();
2799 }

The addition of the else clause would require a reference to an INDI weather sensor, and a variable for the property fetch. I'm still looking for the appropriate indi header file to include. The INDI WEATHER_TEMPERATURE property would be used. Haven't quite figured out the final details, but I'll try and resolve those soon. If someone who knows INDI structure a bit better can throw a bone and help with the INDI include/declaration, it would be appreciated. I hope folks will agree that having a log line with both focuser position and temperature will be very helpful for trying to debug/correlate/improve focus! A bonus might be addition of the last HFR value in that log line too (e.g. as seen in the "FITS received. HFR X @ Y. Delta (Z)" log message), but this would be a dream for another day. First the temperature.... Cheers, Doug

Thank you for the suggestion. I can see how this is useful in case the focus driver cannot report temperature. So INDI::Weather class emits new weather via the signal newWeatherData (like 59 of indiweather.h). However, Focus module has no access to this device. The Observatory module has access to it, but it does not exposure the signal.

In void Observatory::updateSensorData(std::vector<ISD::Weather::WeatherData> weatherData) , it can emit the same data via a signal which can then be connected to the focus module by the connectModule() function in manager. Then Focus can record this and it can be used as a backup temperature in case the primary one is missing.

Thanks for replying Jasem. The approach you suggest is a bit more complicated than I was originally hoping for, but I'll look into it. While investigating the code base last night, it seems that adding HFR to that particular log entry is trivial as the variable is already in scope. So, if this should move forward, I would like to see the log entry have focuser position, temperature, filter, and lastHFR all together. This line would be very helpful when isolated (egrep) for post-processing analysis. It could lead us towards simple temperature based focus compensation as well as other possible improvements for the focus algorithms. I'm motivated to spend some time on this topic due to focus being so critical on the RASA. Cheers, Doug

Hi,

So are you contemplating implementing "temperature based focus compensation"? That would be very interesting.

Well, implement is a bit premature. More like study now, dream of implementation later. We don't yet have access to correlated temperature / focus measurements (at least those of us without focuser temp sensors), and we have a definite liability of entangled seeing within our fine-focus measurements (all current focus algs). I've been looking into ways to mitigate both of these. We've already discussed a backup for temperature via the more generic weather temperature sensor that many of us have in one form or another, and a path to post-processed focus performance monitoring has been discussed in a separate thread. I mentioned in yet a third thread a similar but different approach for wavefront sensing (collimated pupils vs focused spots), where pupils have a sensitivity advantage. The idea of determining focus from measurements well outside of focus to gain advantage over seeing has been implemented at CTIO in Chile by the creator of DIMM (Tokovinin). A good paper for those interested is here:
www.ctio.noao.edu/~atokovin/papers/don2.pdf
While the approach goes beyond focus to other optical aberrations (which could benefit collimation....but I digress), the idea that we could overcome point/spot focus uncertainty is definitely appealing, and would help make measurements for temperature based focus compensation model(s) more accurate. Finally, there's the issue of timing/control, but these seem simple enough to deal with. So, beyond these thoughts, implementing temperature based focus compensation definitely needs time to develop and mature. I will continue to experiment with focus measurements (an F2.2 setup is a perfect if frustrating focus laboratory). For the moment, unfamiliarity with this code base (although learning) is another complicating factor. So, patience and hope are my words of choice for now unless there are others that want to enter the fray and beat me to the punch. I do think there's a path forward to better focus for us all. Cheers, Doug

How about a brute-force poor-man's temperature focus compensation? If Delta T > threshold, run auto focus ?

That could certainly work for long/slow focal ratios, but the shorter/faster the focal ratio, the more important solving these things becomes. I can tell you that right now, on F2.2, none of the focus algs can be trusted via the scheduler to "set/forget" Delta T> refocus level. Iterative and Poly are virtually unusable at F2.2, and Linear solves better, but needs to be watched. The issues involved are not really that difficult; it's just attention to detail. Once solved, everyone should be able to benefit to some extent.

Hello,

I am currently having a look on how this Delta T > threshold focus trigger could be implemented.
Like for you, the learning curve is a bit hard.
My USB Focus V2 does have a temperature probe, but it seems I am still getting the default value -274.

I too am rummaging around the code now (it's a deep pool to dive into) for how to make the temperature more useful.
I have a Pegasus FocusCube V2 which provides temperature to the control panel.

Various PC based software packages apparently do auto-temperature controlled focusing, but I have yet to use a PC for astronomy and I'd like to keep it that way.