Hard to tell, here are a few generic things:
- make sure your mount is balanced and the mount doesn't feel too loose when you try to move it by hand in the RA and DEC directions.
- it should "sound reasonable" when you slew both motors
- no large cable drags,
- calibrate a bit more aggressively, that is, use something like 10 iterations and 1000ms pulses (it will stop at about a 20 pixel deflection, and thus not likely use all 10 iterations)
- use the SEP MultiStar guiding algorithm
- Guiding doesn't work well very close to the pole. Are you very close to it?
- Have a look at the little calibration summary page (see image below) in the guider options menu--are RA and DEC pretty close to orthogonal? What values are you getting for pulse ms/arcsec?
- I personally calibrate once carefully, make sure it's good, and re-use it for months (using the recommendations of the PHD2 folks, e.g. calibrate near the meridian and equator). However, clearly you should first get things working well with calibration before trying that.
- report back with a log.
Also, if these don't help, you might also try using PHD2 and running their diagnostics.
Hope this helps,
If you use GPG, then the RA section in the lower right isn't used for RA (except perhaps maximum pulse), but rather RA is controlled by the GPG settings in the Guider Settings menu. I guess that should be improved...
As you correctly point out, the DEC settings there are used.
GPG only affects RA. DEC guiding remains as it was, so it is controlled by the settings in that little tab in the lower-right called "Control"
I agree with Jo that, in general, that plot looks OK. That said, I'd use more iterations, e.g. use the max (10) and then the limit of ~20 pixel travel should kick in. Calibrating with under 10 pixels of travel is probably not that reliable.
Also, make sure your scope is close to balanced.
Though the dec-swap option will affect you if you store and re-use calibrations, it should not affect the calibration routine itself, as it just walks one way then walks the other way. It also shouldn't affect you if you re-calibrate everytime, as the calibration routine will determine the correct setting for that checkmark for the current position.
Replying to @dokeeffe from his comments on
Thanks again for trying out Analyze. I agree that an SQR-type measure is something that should be in Analyze.
SQM itself is possible, but there are complications . For example, I believe the right way to do it is to subtract a dark from the signal,
get the median pixel value, multiply by the inverse of the bandwidth of the optical system, (e.g. if you're using a Blue fliter, or more extreme Ha,
fewer photons reach the sensor than if you're using an L, or a 1-shot camera) then do a little math--have it written down somewhere
This is complicated by the need of the dark and the need to know the filter bandwidth, but certainly possible.
I did provide "Sky Background", the checkbox furthest to the right on the 2nd line, which is the background sky value SEP (Sextractor)
computes when extracting stars, but I see yours isn't populated. I think you need to be using SEP MultiStar guiding to get that value.
I can improve requirements like this after 3.5 when SEP improvements being done by @rlancaste are scheduled for release
You might SEP MultiStar guiding and look at the sky background feature if possible.
Another straight-forward thing I could do is simple add the median pixel value, which is "pretty much the same" as the SQM, except of course
it's linear, not log, has an offset, is affected by filter bandwidth, ... I have gone through the exercise of computing SQM from median pixel values.
Obviously SQM would be more ideal, though.
Adding new features (now that I've filled up the 2 rows) would required a little UI redesign, but I don't think it's too bad. I had planned on organizing
these features into "guiding", "image" and "mount" sections, and SQM and ellipticity would fit in the image section nicely.
What do you think? Would the basic median work for you? Does sky-background look OK as is?
PS I see you're afflicted with the same "after focus guiding correction" that afflicts me.
I'll definitely look into this further someday, if someone doesn't beat me to it.
I'm the "team". I'm eager to get feedback: suggestions for improvements, address bugs, ...
To that end, when Analyze released, I started this thread:
and would like to try and keep such requests there (for a while, pre-release I guess).
I'll shortly respond to your suggestion at the current end of that (with an @dokeeffe).
Analyze should officially come out in release 3.5 which I'd guess is in the next month or
two--haven't discussed the timing with Jasem.
Thanks for trying it, and looking forward to hearing more.
I considered the FFT idea, certainly could be a future. If you want to see that now, you may not know that you can take the guidelog that is saved (see the guidelogs directory that's parallel to the logs directory). That log is compatible with phdlogview, even if you were using the internal guider. So load a log into phdlogview, and use their frequency analysis tool.
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?
There's a log line (if you have fits verbose logging set) that looks like this
[2020-04-27T03:21:10.600 PDT DEBG ][ org.kde.kstars.fits] - FITS HFR: 2.35749
I guess you're right that sky background normalizes by the max value.
Quick HFR shouldn't make a difference in seeing the values (let me know if it does). What it does is just compute HFR on the center 25% of the image. That speeds up the computation considerably, as in some cases the hfr can take quite a while to compute on a raspberry pi. If you have auto compute hfr on, but yet hfr is not being computed, please send me a log with debugging turned on for at least the EKOS sections: Indi, FITS and Capture, and Verbose & File checked at the top of the logging dialog.
BTW, the value might read 0 if you have the cursor set to somewhere outside of a capture interval. Click on a capture in the timeline (one that's after you turned on auto-compute HFR, of course) and check the value displayed as well the value printed in the "Details" box in the lower left, and let me know if it's still 0.
I think all those are already covered.
However, if you notice your filters not being color-coded in Analyze, please let me know.
re skyBg, for now I believe that getting values for that requires using SEP MultiStar for guiding (which is where the skyBG gets computed).
This may change when the stellar solver happens. For now, Analyze just "takes what it can get" as opposed to computing these things somehow.
It should say this on the mouse-over help, but, I know that's not a totally reliable way of informing users.
As I recall, you were having issues with the SEP Multistar and your ONAG, so perhaps you moved away from that.
Let me know if you're not getting it with SEP MultiStar.
@schwim: HFR won't have values unless it's computed, and to do that, the option to compute needs to be set.
To do that, you need to check an option in FITS settings--see the attached image, look for "Auto Compute HFR".