As for guide log analysis:  phdlogview perfectly reads and analyzes the log files from EKOS as they are (in ~/.local/share/kstars/guidelogs/).
 

FWIW, I have looked extensively through the guider code, but to this point haven't changed any of the code related to correcting DEC error.  The 133 value multiplies the DEC error in arc-seconds to arrive at the DEC pulse in milliseconds (ignoring things like minimum and maximum pulses, etc). Thus if the error measured is 1 arc-second in DEC, the guider would send the mount's DEC motor a pulse of 133ms in the direction opposite to the error.  It would be true that using that 133 value was equivalent to a 50% correction, but only if your system happens to need 266ms of pulsing to move the image 1 arc-second along the DEC direction. I think that turns out to be a reasonable assumption--that is, the internal guider has worked reasonably well, and the control algorithm in the face of seeing noise probably has a wide range of acceptable parameters. In any event, if you're curious how your system's ms-pulse-to-arcsecond response was measured during calibration, just look at the calibrations tab in the internal guider's settings menu (below image taken using the simulator).

 

In the above image, you can see that the simulated DEC system was measured at 196 ms/arc-second, so using 133 would be more like 0.68 aggressiveness.  That calibrated value for DEC is not actually used anywhere (yet) in the internal guider. (If you use GPG RA guiding, then the RA's value is in fact used in the control system.)

Re the backlash question: the internal guider itself doesn't compensate for backlash at this point. I suppose it's possible some mounts or drivers do that behind the scenes, but I'm not familiar with that. 

Hy


 

Is it possible to have a "Best practice" infos and configurations that could be applied to different but common setups?
For example I use a DMK 618mono with @ 1120mm with my RC and OAG, I use a value of 550 and 3 iterations and the only algorithm that seems to complete the calibration is SMART. I do not know why bu more informatin about all the section parameters could be usefully for more users

Alessandro: I think that best-practices idea would be great, but it needs to be crowd sourced. I would love an FAQ with info like that. For now it’s this forum.

Re your smart-only issue, my recommendation is for you to make sure that SEP star-detection works for your guide camera and guide scope combination (and if not, tweak the star detection parameters in guide so that it does). For instance, switch the align tab to that camera and scope and see if you can get it to solve. Truth be told, the issue is not with the solving itself, but with the star detection front end, which SEP-based guiding algorithms depend on.

Clearly Ekos could use some kind of wizard that helps adjust StellarSolver parameters. Rob’s StellarSolver GitHub comes with a StellarSolver_Tester program with a UI that at least makes adjusting the parameters a little easier, that might be easier to use than the align tab approach if you can get his GitHub program to compile.

Good info in this thread - thanks!
I actually never touched the proportional gain values only played with min/max pulse.
It turns out that the proportional gain is maybe even more important.
Will give it a try.

Hi!

I keep adding some issues here, as they surface. First of all, I seem to have the internal guider working nicely most of the time, but I still miss the drift alignment in PHD2. 

The issue: at times, like last night, calibration simply fails. Looking at the calibration graph, there is very little (almost no) movement. I have set calibration steps to 1000 ms, using 5 steps or more. So I switch to PHD2, and there calibraion (with similar step size) works flawlessly. 

So far, I have no indications of when this happens, just seems random for now (and summer nights are almost here, so little darkness to play in) - do any of you have suggestions for what to look for, what to check? My feeling was last night that the guider failed to move the mount, as if guide rate was off or far to small steps or guide pulses turned off, like in the guiding assistant in PHD2. Since PHD2 worked 3 minutes later, it could hardly be mechanical issue, can it? But as I wrote, guide steps were at 1000 ms and guide rate the usual 0.5. 

Any ideas?

Magnus

Sorry Magnus, not much to say. 

I assume you're using PHD2 through KStars/Indi, so they're using the same Indi mount drivers.

I will note that as I understand it, the PHD2 folks recommend calibrating once and leaving it, e.g. not recalibrating for months, unless you change the guiding imaging setup (e.g. rotate the guide camera, remove it, or something like that).  I have taken that to heart, and I personally don't calibrate often either. As you probably know, the internal guider has options to keep use the calibration--e.g. do it once where it works nicely, e.g. near the meridian and the equator, and keep that calibration for a long while instead of recalibrating on every slew.

The calibration scheme simply pulses the mount the amount specified, e.g. 1000ms, every step it takes, without regard for the guide rate, until it sees enough movement. Is it possible you have a lot of backlash, and somehow PHD2 compensates for that better than Ekos? I guess you can measure that with the PHD2 guiding assistant.

Do you have these issues in both RA and DEC?

BTW, now that I think of it, it's also possible that the issue is star detection, not mount movement (e.g. the issue could be improved with improved stellarsolver parameters for guiding).  That would be obvious in a log with debugging enabled for guide and fits.

Hy
 

Hi!
Great, thanks! Yes I use PHD2 through Ekos/Indi, so same driver etc. And I use a Losmandy G11 where there is significant DEC backlash - but not RA. It is compensated in PHD2 with compensation around 800 ms, and PHD2 handles it very nicely. This is one thing I was worried about with the internal guider, but it has not yet been a problem. It could play into calibration - however, the scope did not move in RA either... so something else is at play. 

Good thought with star detection! And of course, I did not have logs on... but now I have. To adjust the parameters - what to think of there? Is there a good resources somewhere to look at?

I'll try and experiment a bit with this next time clouds part and I am still awake ...

Magnus

Greetings guys, I want to ask a question about total error. What is the difference between a total error of 1, 2, 5 or 10 and so on for examples? What really happens to the mount and how is the pulse we send being used? The value of the total error is being multiplied with a number x arcseconds? Thank you very much for your time. Sorry for the "google questions" but I cant really understand what is the happening. I hope plain explanation from fellow observers will help me. Thank you a lot again.

Best regards,
George.

Hi!

Unfortunately, George, I have no answer to your question. I have a different problem. 

Tonight, me and the internal guider are not friends. Not at all. 

I can complete calibration tonight. But after calibration, gudiing is just crazy. RA drifts off, far off. So I recalibrate, no help. Some 4 or 5 times. No improvement. So I slew to another area, wait until it is darker and better SNR. No improvement. 

Attached is a guidelog. It looks to me as a Guide Assistant run in PHD2, that is, with no corrections sent to the mount. Kstars log also attached. Anything that makes sense? What did I miss or do wrong?

Directly after this I switched to PHD2. Guiding with RMS 0.54". So it is not a mount issue. And yes, PHD2 runs through Ekos and Indi. 

Any ideas?

Magnus

Magnus,

Very sorry about the issues you're having, and I appreciate you sending in logs and raising the issue.

I did look through the log, and it looks like the guider is doing what it should, e.g. it measures error and sends out the appropriate pulses to counter the error.
Unfortunately, it looks like the computed pulses are having no effect at all on the mount, as if it was not even connected.
Yes, very similar to what you said "as a Guide Assistant run in PHD2, that is, with no corrections sent to the mount".
In fact if you view the phdlogview output to the file you sent me, you can see that.

 

I will ask around, but, sorry, I have no idea what could cause the signals from the internal guider to be "not sent to" or "ignored by" the mount.

Hy

This was on 3.5.1 which should work but it's better if you use 3.5.3 the latest stable release. Your proportional gains are set to 133.33 and your mount guide rate is 0.5x, correct?