Hi folks !

I wish to add automatic temperature compensation for my ZWO EAF focuser in the INDI ASI focuser driver.

I already did some work (source files and screenshot joined). Not tested on the sky yet, but it seems to work.
It should be easy to adapt my code to the parent indifocuser class, providing temperature compensation to all focusers able to read temperature and absolute or relative moves.

I have some questions :

- Are you interested in this feature for the ASI EAF ?
- Should I provide this feature in the parent indifocuser class ?
- Is there a way for a driver to know if a capture is on its way, to avoid moves during captures ?

My solution uses 3 settings :

- steps : steps we should move in or out for each celsius degree
- hysteresis : minimal temperature change before moving (to avoid yo-yo effect)
- samples : number of samples to average to get stables temperature readings

I wish to add :

- only move between two captures.

Any better idea ?

Thanks !

Best regards !

Thx8411

Hi Collin, this feature could be awesome if it will be in parent indifocuser class. I can see one potential problem: How do I know how much (steps) the compesation will be for my focuser?
I have tried to plot values from few of *.analyze files and the value could be calculated. But what if I don't have these files or I don't know how to plot the values? Would it be possible also to implement some functionality, that will do the math for me?
Anyway, I like this idea and would be happy to test it once available.

Great work! This would be nice to have for focusers that do not support temperature compensation internally. It can be added to INDI::Focuser. This assumes there is a temperature source internally? It could be made to snoop on camera exposure to know whether it is active or not.

Thanks,

Do you know any focuser driver that already implement temperature compensation natively ?
We must avoid conflicts.

Best regards,

Thx8411

Hello Hades,

Right, it could be added, but perhaps for "Mark II" .

Best regards

Hello Jasem !

Thanks !

<< It can be added to INDI::Focuser. >>

I'm also looking at INDI:FocuserInterface

<< This assumes there is a temperature source internally? >>

In my mind, it should be done that way :

- Add two new capabilities :
* FOCUSER_HAS_TEMPERATURE : focuser can publish temperature reading
* FOCUSER_HAS_TEMP_COMPENSATION : the focuser already has native temperature compensation, to avoid conflicts

- Enable the INDI:Focuser embedded temperature compensation if : (FOCUSER_CAN_ABS_MOVE or FOCUSER_CAN_REL_MOVE) and FOCUSER_HAS_TEMPERATURE and not FOCUSER_HAS_TEMP_COMPENSATION

Adding FOCUSER_HAS_TEMPERATURE involves some refactoring for many of the focuser drivers (add a method in the INDI:FocuserInterface class, override it in each driver, etc.).

I'm actually writing a list of all the focuser drivers to identify the impact of these two new capabilities.

what do you think ?

<< It could be made to snoop on camera exposure to know whether it is active or not. >>

Thanks for the tip. I will have to figure how device snooping works

Best regards !

Collin

This might be better implemented in Ekos sequencer directly so it could do the compensation operation between frames and could also use temperature from selectable device to do the compensation, not just the focuser itself (though the driver could also snoop other devices) and wouldn't need changes to the drivers at all, similar to how filter offsets work, just according to temperature delta.

Hello Jarno,

I have mixed feeling about implementing temp compensation in Ekos :

- the feature won't be available for other INDI clients
- some drivers already provide temp compensation natively
- It's pretty lightweight, so, no issue with RPi devices

Anyway, without even considering temperature compensation, some focuser driver refactoring won't be useless.
I checked all the focuser drivers to write an inventory (joined)

Some use TemperatureN, some not.
Some use UpdateTemperature(), some use ReadTemperature(), some TimerHit(), etc.

Refactoring drivers so that it all use the same INumber and the same method, overriding members of the INDI:Focuser class would be nice.

I'm ok to work on this refactoring.



What do you think Jasem ?

Best regards,

Thx8411

Hello Jarno,

<< could also use temperature from selectable device to do the compensation >>

Focus shift is strongly related to the real OTA temperature.
I'm not sure that using an external temperature reading would be accurate enough.

What selectable device source do you have in mind ?

- Weather station ? -> wouldn't reflect the OTA temperature
- CCD ? -> even worse

Right, there is some telescopes with an embedded temperature sensor, but pretty rare, and don't cover most of the use cases.

Best regards,

Thx8411

Yes, obviously focuser/OTA temperature would be preferable but if not available, there are other options like USB_DewPoint or other dew heaters or any DIY Arduinos with external temperature probes people might have. As the important thing is temperature delta, not absolute temperature itself, even sensor not directly attached to the OTA might be better than nothing at all as they would still move in the same direction as ambient temperature changes (at varying speeds due to thermal inertia, but equalize eventually).

In any case, limiting the temperature input to just the focuser itself would not be necessary even if implemented in the driver as it could snoop other devices too, but that requires the same standardization of the temperature property you noticed. Synchronizing with camera so that the compensation would not be done during exposure might be possible with similar tactic by snooping the camera property.

I still think the program that controls everything anyway would be the logical place, but nothing prevents having it in both to cover all use cases.

Hi !

I think there are still many things to think of before embedding temperature compensation in the INDI::CCD main class.
I'm also working on the new SV405CC support, and my time is sadly pretty limited (just remind me, what are job and family used for ? So time consuming...)
So, my proposal is to provide temperature compensation just for the ASI focuser at this time, as an "experimental" feature. I'm preparing a PR.

I digged a bit the snooping capabilities, but didn't figured out how to catch the main ccd capture state yet.
I will look further.

Best regards !

Thx8411

Hi Collin, there was some prior work done on this topic, but it failed to move forward due to the lack of GUI. Otherwise, it was completely developed and utilized a config file. You might want to look at this post for some details:
indilib.org/forum/ekos/7626-temperature-...us-compensation.html

I've sent you a PM to see if you might like to work together. You should have it.

Some quick feedback on your approach is that logging additions have already been added in Ekos (released) to prep for figuring out the function coefficients for temperature (and altitude residuals). Another function has been written to analyze the focus log and produce the needed coefficients automatically. In most cases, the temperature relation is best thought of as a quadratic and not a simple linear function. Having used my own version of temperature compensation software for well over a year, and having 800 focus runs as the "database" for analysis, I find that the function's zero offset can change over time (not completely sure why, but it might have something to do with my EAF not having a "sure" reference position through power cycles). The slope is very stable (once enough samples are obtained). FYI, I did add the ability to update focus between exposures, and that allows me to keep focus at f/2.2 for hours even in dropping temps (verified by running unnecessary focus runs to compare). I consider doing focus runs by delta T, and/or after N time expiration to be a complete waste of exposing time. Finally, knowing the temperature, the focus algorithm (currently only linear) can be "seeded" with a proper starting guess so outrageous amounts of time aren't spent in "donut" territory.

As I said, if interested, read your PM and send a PM in return. Best wishes,

Doug S.