I am using a Pegasus Astro Focus Cube 2 on a Takahashi Epsilon 160ED stock focuser. When focusing OUT (focus tube is extending and since the camera is mounted on top of the OTA it is generally moving against gravity - opposite of a refractor) and the backlash parameter is set to my current best estimate (31 steps) the focus motor moves beyond the requested number of steps and then returns to the requested value. This happens for every requested move OUT - not just after reversing direction from moving IN. When focusing IN (focus tube in retracting - assisted by gravity) the focus motor just moves the focus tube directly to the value requested (there is no overshoot and then return to the requested value). This is true for all focus algorithms.
Is this the way the backlash compensation is designed to work?
I have setup a sensitive dial gauge to monitor absolute motion of the camera and focus tube. I am making measurements by manually entering numbers in the “Desired absolute focuser position” box of the Ekos “Focus” window and executing the “Go to absolute focus position” button to the right of the entry box. I watch the reading of the “Current absolute focuser position” window and the corresponding dial indicator reading to monitor the motion of the focuser. I realize this is not necessarily what happens during the execution of an Auto Focus algorithm when doing an actual Auto Focus using a real star.
The problem is if the focuser reverses direction from focusing OUT to focusing IN, backlash is not implemented. And if the focuser continues to move IN, backlash is never implemented. It seems like the overshoot and return to requested position should work every time the direction is reversed -no matter whether it is moving IN or OUT? What am I not understanding about backlash compensation?
Thanks for any guidance and explanation of what I may be doing wrong.
Madhav, thank you for your work on this new Stats tool. I've already found it useful. I would like to see min and max included. Thank you.
Jasem, when there is no Filter info in the Fits header, that field was empty. I discovered this today on my surrogate RPi (duplicated OS) inside (I bring in the telescope when not imaging at night and leave the operational RPi on the mount, so won't be able to test this on the real set up until the next observing session). Here is what I am seeing. When I connect the INDI server via Ekos, it connects immediately to the camera and EFW. The Capture window shows the camera and filter wheel. I normally have a sequence of exposures with different filter wheel selections like LRGB, which I build manually using the filter drop down menu. When the sequence is running, if I watch the ASI6200 tab/Options/Filter in the INDI Control Panel it sometimes just randomly goes blank and stays blank for the rest of the sequence, even if the filter changes. Otherwise the value in that field is "ASI EFW" as normal. So of course if the Snoop value is blank in the Options tab, I get no Fits header keyword for Filter. When this happens the FW drop down menu in the Capture window also goes blank, --. This happens without any operator intervention. I will turn on verbose logging on my next night time run and keep an eye on the Snoop value and the FW drop down menu and try to send a log file. Thanks for your question.
I have this same problem using my RPi as a server at the mount. It saves the Filter keyword on the very first file captured after startup but then none afterwards. Been this way for a while. I am running Stellarmate OS on the RPi and used Software Updater to update the OS yesterday before my run last night. Not having the Filter designation keyword in the Fits Header is inconvenient when using Weighted Batch Preprocessing Script 2 in PixInsight. All the frames (including Flats) have to be added using the Add Custom button which then requires filling out by hand information about the files. Also my Mac version (3.5.5) of KStars/Ekos does not record the Filter keyword in the Fits Header when capturing files - normally use this set up when recording Flats with my indoor panel. I am using the ZWO ASI6200 MM and EFW filter wheel.
Thank you, Hy! I really appreciate all you guys do. Another example of why open source is so great.
Sonny, thanks for submitting this. I also discovered from a friend who sees the same behavior, that HFR is updated automatically with new image downloads if the Statistics panel is displayed. Statistics does not report Eccentricity, however. We just need the HFR and Ecc values reported at the bottom of the displayed image to update properly. Thank you all for your inputs.
Thanks for the info Sonny! I have just discovered that if I uncheck "Single preview tab" in the FITS Look & Feel section of the KStars/FITS Configure window, the newly downloaded images do in fact appear in a new tab and the HFR and Ecc data is reported correctly. Of course, any custom settings for magnification, shadows, midtones, crosshairs, etc are not present. So this seems more and more like a bug of some sort.
Setup is Stellarmate OS running on RPi4 at the telescope as remote server - KStars/Ekos 3.5.5 Stable. Linux desktop running KStars/Ekos v 3.5.5 Stable connected to RPi Stellarmate via ethernet cable. Ekos CCD tab setting for Directory is a NAS on the same local network. Downloads work well - generally two seconds for 122 MB files. Images downloaded from camera exposure sequences are displayed in the FITS viewer on Linux desktop. First downloaded image from camera displays HFR and Ecc values, but next image in sequence does not update HFR and Ecc values for the current image - they remain unchanged from the first image. Snippet from Log file has a Warning: "Non-native QFileDialog supports only local files" Could this be the problem? The Save dialog in the CCD tab says it is being locally saved. The HFR is always reported for new downloaded files in the Graph in the Analyze module.
However, if I use FITS Viewer to load an existing image from the NAS storage device, it opens in a new tab and displays the HFR and Ecc values correctly. Then if I click on the other tab from the last loaded camera image, the HFR and Ecc values update to the correct values. So the images displayed in FITS Viewer directly from the camera download are not updating HFR value but if recalled from a storage device HFR is displayed correctly and then when revisiting the tab from the download the HFR is updated and displayed correctly. Is this a bug or is the way I am downloading and storing images?
Log file snippet attached.
Thanks for any assistance.
More info - Workaround Found
Setup is Stellarmate OS running on RPi4 at the telescope as remote server. KStars/Ekos connected to Stellarmate from Linux Desktop via ethernet. Desktop Linux running Kstars/Ekos v 3.5.2 Stable. From Ekos CCD tab images downloaded from camera exposure sequences are displayed in the FITS viewer on Linux desktop. First downloaded image from camera displays HFR and Ecc values, but next image in sequence does not update HFR and Ecc values for the current image - they remain unchanged from the first image.
However, if I use FITS Viewer to load an existing image from a storage device, it opens in a new tab and displays the HFR and Ecc values correctly. Then if I click on the other tab from the camera image, the HFR and Ecc values update to the correct values. So the images displayed in FITS Viewer directly from the camera download are not updating HFR value but if recalled from a storage device HFR is displayed correctly.
This seems like a bug from how it worked in version 3.5.1.
After upgrading to INDI Library v 1.8.9 from 1.8.8, I no longer can get HFR values to display in the FITS image viewer window. HFR used to appear at the bottom margin of the window on the left side. Now there is an HFR value for the first image displayed on the right side but it does not change when new images are displayed.
The HFR value does show up on the graph in the Analyze tab but not in the viewer.
Can someone tell me what I am doing wrong? Thanks for any help.
Stellarmate OS on RPi4