×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Internal guider questions

  • Posts: 643
  • Thank you received: 62
Hi!

I'm playing with the internal guider, trying to move definitely from using PHD2. And in doing that, I have 2 questions that I so far have not found out about: 
1. Adjusting the DEC aggressiveness: which is the appropriate parameter to change, similar to aggressiveness in PHD2? As the parameters have different names, I become a bit unsure...
2. Is there DEC backlash compensation like in PHD2? THat is, automatically adjusting. My G11 have significant DEC backlash, beautifully handled by PHD2, and I'd be happy if that was aslo possible in the internal guider. 

Magnus
2 years 11 months ago #70448

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
The "aggressiveness" setting in PHD2 is expressed as a percentage. In Ekos internal guider it's called "Proportional Gain." You adjust it in the "Control" tab at the bottom-right of the Guide panel in Ekos.

Most people use a guide rate of 0.5x sidereal. In that case a "Proportional Gain" of 133.3 is equal to 100% aggressiveness in PHD2. If you want the equivalent of 50% aggressiveness you'd use 66.6 instead of 133.3.

See attached screen cap. The left column under the "Control" tab is RA and the right column is DEC, though these aren't labeled. In the attached example I've got RA aggressiveness at 50% and DEC aggressiveness at 100%.
The "aggressiveness" setting in PHD2 is expressed as a percentage. In Ekos internal guider it's called "Proportional Gain." You adjust it in the "Control" tab at the bottom-right of the Guide panel in Ekos.

Most people use a guide rate of 0.5x sidereal. In that case a "Proportional Gain" of 133.3 is equal to 100% aggressiveness in PHD2. If you want the equivalent of 50% aggressiveness you'd use 66.6 instead of 133.3.

See attached screen cap. The left column under the "Control" tab is RA and the right column is DEC, though these aren't labeled. In the attached example I've got RA aggressiveness at 50% and DEC aggressiveness at 100%.
  
2 years 11 months ago #70469
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 643
  • Thank you received: 62
Hi!

Great, thanks! I guessed it was "proportional gain" but could not figure out why it was 133. So what is the logic there, how does 133 relate to 100% in PHD2? Just for fun. 

Another question: can I draw out a log file and view in something like PHDlogviewer, or only in the Analyzer? I mean, I really like the Analyzer, but I'd also like to do frequency analysis on the log. 

Magnus
2 years 11 months ago #70470

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
I've tried to figure this number out myself but I couldn't make the arithmetic work out to 133.3

It's something like milliseconds of motor pulse per arcsecond of sky angle.

Sidereal day is 23 hours 56 minutes 4.09 seconds long = 82805023 milliseconds per revolution
One revolution is 360 degrees = 1296000 arc seconds
So sidereal tracking is 82805023 milliseconds / 1296000 arc seconds = 63.89 milliseconds per arcsecond

At half-sidereal we should need a motor pulse twice this long to move the scope 1 arcsecond:
2 * 63.89 milliseconds per arcsecond = 127.8 milliseconds per arcsecond

Maybe somebody rounded something wrong?

Regarding logs, I am pretty sure there is indeed a way to dump internal guider logs into a text file that you can read in PHD2 logviewer, but I don't know how. Google should know!
Last edit: 2 years 11 months ago by Scott Denning.
2 years 11 months ago #70477

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
Ack! I just figured it out. Whoever set "Proportional Gain" to 133.3 used 24:00:00 hours for the sidereal day instead of 23:56:04.9

It should actually be 127.8 for 100% aggressiveness, but honestly I doubt it makes a significant difference!
2 years 11 months ago #70478

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 57
PS: Hy Murveit plans to redo the GUI for controlling the internal guider, but has recently been up to his proverbial eyeballs doing the lovely new terrain visualization for Kstars.
2 years 11 months ago #70479

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
As for guide log analysis:  phdlogview perfectly reads and analyzes the log files from EKOS as they are (in ~/.local/share/kstars/guidelogs/).
 
The following user(s) said Thank You: Scott Denning
2 years 11 months ago #70485

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
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


 
2 years 11 months ago #70505
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 333
  • Thank you received: 23
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
2 years 11 months ago #70514

Please Log in or Create an account to join the conversation.

  • Posts: 1208
  • Thank you received: 559
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.
2 years 11 months ago #70534

Please Log in or Create an account to join the conversation.

  • Posts: 910
  • Thank you received: 86
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.
-- Max S
ZWO AM5. RST-135. AZ-GTI. HEQ5. iOptron SkyTracker.
TPO RC6. FRA400. Rokinon 135 and other lenses.
ZWO ASI2600MC. D5500 modified with UVIR clip-in filter.
ZWO ASI120MM Mini x 2. ZWO 30F4 guider. Orion 50mm guider.
ZWO EAF x 2.
2 years 11 months ago #70564

Please Log in or Create an account to join the conversation.

  • Posts: 643
  • Thank you received: 62
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
2 years 10 months ago #71252

Please Log in or Create an account to join the conversation.

Time to create page: 0.872 seconds