I have an A7S and use it from time to time with Ekos. It works well enough for me. Can you clarify what problem you're having?
The fits viewer does give numbers that are a bit different and seem more correct. I'm happy to debug.
hy wrote: Obviously, it looks suspicious that all the HFR values are 0.940.
It would be good to know if the system is computing them wrong, or if they are being recorded wrong.
Did you say that they were being displayed correctly on the fitsviewer?
It will be hard for me to debug -- so the more info you can provide (and of course the more debugging you can do, if you're comfortable with that)
BTW, what kind of camera, etc?
I don't have fits debugging turned on. Will give it a shot again tonight. At the very least the focus HFRs are not matching. The analyze data looks like this:
CaptureComplete,6910.911,300.000,L,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/L/Light_L_300_secs_2020-09-23T23-06-30_001.fits CaptureComplete,7830.227,600.000,L,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/L/Light_L_600_secs_2020-09-23T23-20-35_001.fits CaptureComplete,8458.568,600.000,L,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/L/Light_L_600_secs_2020-09-23T23-35-01_002.fits CaptureComplete,9530.181,900.000,L,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/L/Light_L_900_secs_2020-09-23T23-52-53_001.fits CaptureComplete,11028.627,1200.000,L,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/L/Light_L_1200_secs_2020-09-24T00-15-44_001.fits CaptureComplete,13210.166,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T00-54-13_015.fits CaptureComplete,15094.138,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T01-25-37_016.fits CaptureComplete,17134.684,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T01-59-37_017.fits CaptureComplete,19174.548,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T02-33-37_018.fits CaptureComplete,21212.947,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T03-07-35_019.fits CaptureComplete,23264.680,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T03-41-47_020.fits CaptureComplete,25316.347,1800.000,Ha,0.940,/home/schwim/Dropbox (7e7)/Astrophotography/working/fsq106/ngc7000/Light/Ha/Light_Ha_1800_secs_2020-09-24T04-15-59_021.fits
OK, whatever I poked at yesterday now provides an HFR number in the Analyze tab. However, the number never changes from sub to sub, and the HFR calculated in the fits viewer is significantly different than the number presented on the graph (e.g. 1.34 in viewer, 0.94 in Analyze). Focus HFR is also different. I tried changing the Quick HFR viewer setting but that did not change things.
Try setting "via" to Paramount.
That would be a fail on my part! Alas, it's not cursor placement. If I go outside of a sub it will show blank in many cases but not all. If I click a sub, it shows 0.00. I opened the .analyze file and see the HFR as 0.00 in all CaptureComplete lines, and if I manually put a number in there it does reflect in the graph, so the graphing appears to be working correctly.
I'll do some more debugging this evening and let you know what I find.
I did notice the value was -1 previously so I found and turned on Auto Compute HFR in the settings. From that point it now reads as zero. I see you also have Quick HFR enabled. I don't. I'll give that a shot.
I just disabled auto compute hfr and checked the graph checkbox and I did get the popup. I don't recall seeing it previously.
Perhaps what you can do in cases where it is not computed is put 'off' in the field.
Re: skyBg, the tool tip popup is clear as to where the data comes from. I'm using SEP Multistar so I am getting values. The values are present if I scan the timeline, just the graph is flat. I figured out why. Turns out my guider was still imaging as the sky brightened, and the tail of it has backgrounds that rapidly increase. If you look at the tail of the graph (way after the last sub so I didn't see it) it does climb rapidly, which shoves the useful stuff down into the floor of the graph. If I delete those lines from the .analyze file the graph is now presenting useful data.
I'm loving the analyze tab! A few observations based on a build from source that was pulled 9.23.2020:
- The HFR value is always 0. If I open one of the fits files I do see the measurement is there.
- skyBg has a value but its presentation on the graph appears to be just a flat line at the bottom so you can't any detail on minor changes sub to sub. No way to zoom in to see fluctuation over time.
Yep, I'm on source builds so I see the Analyze tab. I hadn't had an opportunity to dig into it until just now, and it looks pretty useful. I like that it can show prior sessions, and open subs for inspection. Good stuff.
I'm standing by on StellarSolver. Can/will test it out when it's ready.
I had my first nights using SEP Multistar this week on two different rigs. Fantastic work on this and the guide logs.
One one scope, SEP Multistar seems to "just work". The other not so much out the gate, though I will spend more time with it in the next days. Mainly, the system would not find a guide star. I posted another topic about this here:
If Jasem is correct in the star shape being critical, this will make SEP Mulitstar difficult to use for ONAG implementations that have astigmatism as a feature.
You asked "what's next" and I have a few ideas:
- Auto-tuning of the PI controller
- Represent min/max values in arcsecs of movement based on discovered pulse dimensions that are seen in the options dialog for calibration.
- Auto-scaling of the min/max setting in cases where the calibrated values of ms/arcsec change. I've seen them change enough to think this might be a good idea. Maybe they shouldn't change and I need to chase a problem?
- Have proportional gain be a percentage of the ideal for a given mount's rate. For example, a mount that uses a rate of 0.5 == prop gain 133.3, so setting 100% uses that rate, 50% cuts it in half, 150% does the expected, etc.
Also, one thing that I've wished I've had way too many times is the actual guide log relative to a given exposure embedded in the fits header of subs for easy analysis. Eventually we could have a tool that allows you to open a sub and look at what happened with the guiding while it was exposing.
Thanks again for your hard work on this!
Hmm. I had not thought of SEP having problems with the star shapes. Interesting. I'll need to test standard SEP with it.
Not familiar with StellarSolver. Where can I find details?
First time trying this out tonight. I have auto star selected. The green box moves to a location that sometimes has a star, sometimes doesn't, then calibration starts. After the first move I get the following error:
2020-09-17T20:28:36 Lost track of the guide star. Try increasing the square size or reducing pulse duration.
This may be a problem with building on Xenial systems. I upgraded the system to 19.3 (Bionic) and I am now able to build kstars successfully.
Any idea what might have changed in the code that requires Bionic and up?
I have a Linux Mint system that was on Xenial. I'd been building kstars/Ekos on it for a few years up until maybe 6 months ago. Since then, I could not get kstars to compile. As my other (newer) systems worked fine I decided to upgrade to Bionic 18.3. Unfortunately this did not help, and I am getting the same error which is below. I forced a re-install of all dependencies and this did not help. I also re-downloaded the git repository and started fresh with no success.
Any ideas what is causing this and how to fix it?
[ 85%] Building CXX object kstars/CMakeFiles/KStarsLib.dir/fitsviewer/fitssepdetector.cpp.o In file included from /home/schwim/src/kstars/kstars/fitsviewer/fitssepdetector.cpp:22:0: /home/schwim/src/kstars/kstars/fitsviewer/sep/sep.h:233:31: error: variable or field ‘sep_set_extract_pixstack’ declared void void sep_set_extract_pixstack(size_t val); ^ /home/schwim/src/kstars/kstars/fitsviewer/sep/sep.h:233:31: error: ‘size_t’ was not declared in this scope /home/schwim/src/kstars/kstars/fitsviewer/sep/sep.h:234:1: error: ‘size_t’ does not name a type size_t sep_get_extract_pixstack(void);