×

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

Bi-monthly release with minor bug fixes and improvements

New Internal Guider Features

  • Posts: 527
  • Thank you received: 139
I'm pretty sure (95%) I had that unchecked. And stopped using the feature because calibration would trigger after the flip. I use the scheduler, so not sure if it has anything to do with that. I would have to test again to be positive. But I went through several nights of this issue, and gave up on unguided because guiding would turn back on always after the flip. It seems if the scheduler is the master, and guiding is off, it shouldn't "turn on" with a slew.
3 years 8 months ago #56779

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

  • Posts: 1208
  • Thank you received: 559
Andrew,

I have never run the way you describe (guiding off but dithering somehow). How do you set that up?

If you wanted to go totally without guiding, I assume you could by unchecking the "guide" button on the scheduler page, but I have never tested that.
It's certainly possible that there's some post-meridian-flip bug in the system.
If you want, describe what you set up to enable your setup and how to re-create the issue, and send in a log (e.g. start a new thread about that bug).
I'd be happy to look at it, and other developers might as well. It's even better if you can you get the simulator to repeat your issue.

Hy
3 years 8 months ago #56782

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

  • Posts: 554
  • Thank you received: 138

Changing the Ra guide rate in proportion to the Dec. I think the algorithm is RaRate(current dec) = RaRate(dec 0) / cos(dec); This needs checking, I may have misremembered the correction but it is Ra guiding and is a function of declination.

PHD2 does this and it seems to remove the need for calibration after every dec change.

it may be necessary to make a more accurate etermination of the RaRate at the calibration phase.

The adaptive scheme you suggest should help but it may take a while to adapt after a change in dec.

Chris
3 years 8 months ago #56830

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

  • Posts: 969
  • Thank you received: 94
Hi everyone

Big thanks to @hy for his excellent work on this. We now have reusable calibration, multistar guiding and an excellent PPEC-like guiding algorithm called GPG.

Joint test reuse-calibration and the new GPG guide module.

test observations and comments after calibration slightly east of the meridian near the celestial equator:

- one-time reused calibration
- no need to jump through hoops on meridian flips; it's all handled from the one calibration; use the same settings as you have in PHD2.
- sensible star selection within the frame
- change of PPEC parameters; began with the default with a noticeable change when I dialed in my PHD2 values.


Please join in testing with your setup. No need to be brave as hy has a foolproof method to pull his branch and test without interfering with your stable/installed kstars. (@hy, will you post this?)

logs on eq6 and a 60mm f4 guide telescope including meridian flip, differing altitudes, shutdown-restart and an all night long scheduler run:
drive.google.com/file/d/1u6VwF0-kRtK7jFZ...1fZ/view?usp=sharing

All worked fine except between captures 11 and 12 when a visiting cat began playing with the mount cables!

Cheers and clear skies,
Steve
Last edit: 3 years 8 months ago by alacant.
3 years 8 months ago #56832

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

  • Posts: 421
  • Thank you received: 102
hy,

This is FANTASTIC work! Thank you so much! That was the only reason I ever used PHD2, was for the PPEC algorithm. Well that, and for collecting log data for PE analysis.

Would I seem ungrateful if I asked for a couple improvements? :)

1. On the control tab, when GPG is active, the controls are ignored. It would be nice if the RA controls on the control tab were replaced with controls that affect the GPG guiding. Like PHD2 does when you select PPEC, it replaces the controls on the main screen with controls for that algorithm.
2. On the main guide screen, there are checkboxes for enabling/disabling guiding in RA and Dec. When GPG is active, the RA checkbox is ignored. I think the GPG algorithm should pay attention to that checkbox.

That's all I have. Again, thank you for your hard work on this!
3 years 8 months ago #57338

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

  • Posts: 1119
  • Thank you received: 182

I join in the praise! The PEC has markedly improved the guiding accuracy of my iOptron SmartEQPro+.

Thanks, Hy!
3 years 8 months ago #57339

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

  • Posts: 1208
  • Thank you received: 559
Thanks very much for the encouragement. It's really appreciated. Of course, I didn't write the GPG algorithm, and most of the credit is due to it's authors, and particularly to Edgar Klenske who advised me during this process.

@ChrisRowland: Chris, sorry I didn't mention this sooner, but the RA guide rate as a function of DEC is in the 3.4.3 release. See the lines around
invent.kde.org/education/kstars/-/blob/m...calibration.cpp#L407
I used the formula you had, except added cos(DEC_at_calibration) in the numerator, which is what I believe is correct.
It would be what you said if the original calibration was done at the celestial equator (where cos(DEC) = 1.0).
I do believe it can be improved by adaptation, but that's a project for another day.

@kross: Keven, First off, please do make suggestions and send feedback. It's the only way I can debug/improve. Adding your and others' perspectives can only help, and the more testing the better. Steve (@alacant) has been really helpful breaking the system for me ;) and helping me find bugs, and others doing so as well will make the system better.

Re your specific requests:
Suggestion #1, Control Tab: I certainly considered placing the GPG's controls in the little control tab, but honestly, it's a very small space, and the GPG has lots of controls, and we already have this guider options pop-up with other control and calibration options. My real inclination was to remove the control tab altogether and put that functionality in the Guider options pop-up, but I was conservative and didn't. I'm tempted to do that. I think it is confusing to have two places where guider settings are made (3 really counting the controls on the guider main page as well).

Suggestion #2, Enable RA Checkbox: I have a merge request I'm about to send in (hopefully after successful testing tonight) that will have GPG honor the enable/disable RA checkbox as you suggested (thanks), along with several other fixes. However, I didn't honor the RA directional checkboxes. Those are trickier, as I'd need to integrate that into the GPG algorithm--GPG "needs to know what is being done". I could do this, but will probably not and rather just disable those checkboxes if GPG is in use, at some point. I'm guessing that if one is using GPG, one should let it do its thing.

Hy
The following user(s) said Thank You: Alfred
3 years 8 months ago #57349

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

  • Posts: 209
  • Thank you received: 33
Hy, you've done a beautiful job and the guider interface has substantially improved (it was already simple to use).
The calibration plot and the New Detection Algorithm SEP MultiStar are my favorites.
I have a question concerning the calibration plot
Why is the x-axis so short ?
3 years 8 months ago #57386
Attachments:

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

  • Posts: 1208
  • Thank you received: 559
Jean-Claude,

Thanks!

It's possible that you have calibration iterations set to a small number (3 or 4). That parameter is found in the guider's Options menu (lower right corner of the page). Once there, select the "Calibration" section on the top left. You can then see calibration settings. My recommendation would be to set "iterations" to 10, which is the max value. This parameter sets a bound on how many "outward" steps calibration takes in the RA and DEC directions. It actually likely wouldn't go through all 10, probably about 5 in your case, as what it really does is stop once it's traveled 15 pixels. In the case of DEC, that would be 15 after the backlash steps (which is how you wound up moving 25 for DEC--it looks like about 5 for backlash, then after 2 steps it was just under 5+15).

I'm now a fan of calibrating once, carefully, and using the "store and re-use calibration" checkbox. You'd calibrate somewhere on the celestial equator a little east or west of the meridian. If the calibration looks good, then keep it. "Looks good" means that the outward steps (the green and blue dots) make perpendicular lines and the dot pattern is regular, or at least as regular as your mount gets. You can ignore the inward steps, they're not used in calculating the calibration parameters. The advice the PHD2 folks give on calibration applies to KStars as well. BTW, your calibration looks great to me--I wish mine were as nice.

If you do re-use calibrations, you need to figure out the right value for the "reverse DEC on pier-side change..." checkbox. If you're not sure what to use, just experiment and guide for a few minutes on both sides of the meridian/pier with a stored calibration. If it works well for a minute or two on both sides, you have the right settings. If you have the wrong settings, it would be correcting DEC the wrong way on one side (i.e. encouraging the guiding to get worse and worse for DEC) and that "run-away guiding" should be obvious.

Just commenting that, though you say you liked the SEP MultiStar, your screenshot doesn't seem to have it enabled (I don't see those red and green lines coming from the reticle box). I encourage people to use it. At least for me and a few folks who've tested for me, it seems solid. As a bonus, you get the SNR plot overlay, which is a clear indicator of clouds, etc.

Hy
3 years 8 months ago #57397

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

  • Posts: 421
  • Thank you received: 102
Hy,

A few more comments/observations.

Reusing the calibration didn't work so well for me. I calibrated near the equator/meridian, then slewed to M16, and started guiding. Guiding was bad, with a lot of overshooting RA corrections. I re-did the calibration at M16, and guiding was back to normal.

The Ekos UI becomes very sluggish and slow to respond to clicks, sometimes taking up to 5 seconds. This is on my Raspberry Pi 4 with 4GB RAM. "top" doesn't show much CPU usage, and there's plenty of RAM to spare. The rest of the system is perfectly responsive. So my guess is between SEP Multistar and GPG guiding, they are probably both running on the UI thread, where they should be running asynchronously on a worker thread. Turning off multi-star guiding made Ekos more responsive. It's a shame, since it seems to work better than single star guiding.

That's all for now. Keep up the good work! :)
3 years 8 months ago #57413

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

  • Posts: 1208
  • Thank you received: 559
Kevin,

Do you know if the calibration looked good (e.g. perpendicular lines, reasonably spaced steps out)?
If you have the guidelog from the run where you calibrated and then re-used the calibration unsuccessfully, please post it and I'd be happy to look at it.

The MulitStar part of SEP MultiStar should run very quickly, not much to it. I've timed GPG and a single iteration takes 10-20ms on an RPi4
(and if you're guiding every 2s, that's 1% of the CPU). However, SEP itself might run slower.
Of course, you said that top didn't show much CPU/Memory. Personally, I suspect something else in the RPi OS.
I'll try and put something in the log that looks at the SEP elapsed time, so we can see if in fact SEP is to blame next time it happens.
I admit that there are occasions I've seen my RPi4 get un-responsive, but I'm not sure that it's the guiding (though, of course, I'm not sure it's not).
Rob (@rlancaste) is working on a re-implementation for SEP star detection (and plate solving) for EKos for the next release, so if something like you describe were
to happen, I guess it would be in his new implementation. (FWIW, as currently implemented, I noticed that the SEP library is not thread safe).

If you're willing, please try again sometime to see if SEP MultiStar slows you down.
I have the same RPi, and most of the time it runs responsively for me--though it certainly could be dependent on the number of stars detected in an image.
[BTW, also run dmesg and see if you're getting under-voltage messages, and/or usb resets when that happens.]

Thanks for the feedback, happy to look further,
Hy
3 years 8 months ago #57414

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

  • Posts: 421
  • Thank you received: 102
I thought the calibration looked good. I even did it a couple times until I thought it looked good. But I will try to reproduce the problem next clear night and get some logs.

It's certainly possible something else was going on causing slowdowns on the Pi, and I unfairly blamed the wrong thing. I will get more detailed info next time we have a clear night, which might be a few days.
3 years 8 months ago #57419

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

Time to create page: 0.730 seconds