×

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

Bi-monthly release with minor bug fixes and improvements

Internal guider shift when loosing guide start with cloud

  • Posts: 319
  • Thank you received: 25
Thanks @jasem, I think you are right in your theory. Below are my findings that match yours. The question is when we can get this update (when losing guide star go to plate solving and restart guiding)?

 
 
2 years 2 months ago #79168
Attachments:

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

  • Posts: 333
  • Thank you received: 23
Can I also suggest to add a way to change guide star on the fly, without stop the schedule/plan/guide?
2 years 2 months ago #79177

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

  • Posts: 1208
  • Thank you received: 559
@Mohamed: Thanks for that analysis. I believe you are correct that there is a bug here in the guider, your annotations help, and I have a theory about what is happening. Let me look into it a bit more, and I'll get back.
@Alessandro: I think it is changing guide stars on the fly, but I believe the problem is that it is not communicating that well to the guider. 
In any event, it's best that I look more carefully into it without guessing and get back to you.

Hy
2 years 2 months ago #79181

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

  • Posts: 1208
  • Thank you received: 559
I had added a draft merge request that may fix this.
invent.kde.org/education/kstars/-/merge_requests/507
This is pretty raw, and I can't test until skies clear up. Tomorrow night is possible,
but I'm not sure. Weather has been pretty marginal around here for a while. 

@Mohamed (or others who are also capable): if you want to test, that would be great, but you need to be comfortable with git and compiling KStars.
It is not submitted, so you'd need to get it from my forked repo, doing something like this:

In a new directory, if you are good at getting code off of git repos, and want to test this, then
"git clone  invent.kde.org/murveit/kstars.git "
and go to the guider-fix15 branch (git checkout guider-fix15), and setup compilation using cmake and compile that and run the new KStars binary.
This code is at the current KStars HEAD plus my new changes.
You would just run SEP MultiStar guiding the way you've been doing.
The new code probably won't trigger unless the skies are poor, like the ones you've been testing with.

Hy
 
Last edit: 2 years 2 months ago by Hy Murveit.
2 years 2 months ago #79186

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

  • Posts: 1
  • Thank you received: 0
Thanks for the information keep sharing such informative post keep suggesting such post.
2 years 2 months ago #79189

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

  • Posts: 969
  • Thank you received: 94
Hy, everyone

Here is your new code from the git yesterday. I'm not sure how I'd test, it but here's the log anyway:
drive.google.com/file/d/1BAUAv4ItJ-mWO0Y...DT-/view?usp=sharing
All goes well until right at the end where indi closed the session. I had to go back to the stable version to finish it but I don't think it's the guider which caused the shutdown...

Oh, and MANY congratulations to whoever smoothed the guiding plot in the guide tab from those dreadful square waves:)

Cheers and happy new 2022 to all
Last edit: 2 years 2 months ago by alacant.
2 years 2 months ago #79311

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

  • Posts: 211
  • Thank you received: 31
You could test it without clouds by physically covering the guidescope, right?
2 years 2 months ago #79321

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

  • Posts: 1208
  • Thank you received: 559
I recently looked into the original complaint (imaging shifted by the internal guider when clouds rolled in) and in fact found a bug that would cause this shift in some situations. I fixed that issue and it is now in the beta software. See the fix here: invent.kde.org/education/kstars/-/merge_requests/525

I was able to replicate the original issue, and after the fix I imaged with this a couple nights and clouds rolled in a few times, and with the fix the position was maintained. I also put a hat (literally) on the guide-scope for several different intervals, and all was good.

Please let me know if still see issues, and/or if you see improvement with the fix.
Hy
 
The following user(s) said Thank You: Scott Denning
2 years 1 month ago #80292

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

  • Posts: 225
  • Thank you received: 16
Hy,

That's awesome!

When do you think it will be moved to stable?

Ron
2 years 1 month ago #80297

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

  • Posts: 421
  • Thank you received: 102
Fantastic news! I've also noticed the problems reported in this thread. I am looking forward to testing these fixes. Doesn't look like it will be any time soon, though. Nothing but clouds this time of year. :(
2 years 1 month ago #80319

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

  • Posts: 1208
  • Thank you received: 559
@Ron Clanton:   Jasem seems to release a new version about every 2 months. The last one, 3.5.7, was released in mid-January so I'd expect that these changes would come out in 3.5.8 which would likely be released in mid-March.
Hy
2 years 1 month ago #80325

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

  • Posts: 96
  • Thank you received: 25

I'm not sure that it would consume too much time in capture - or perhaps it's time some people would be willing to invest for the sake of properly framed images. To grab some hard numbers, I used StellarSolverTester from stellarsolver-2.2 to test a random capture from last night (Helix Nebua). Using either of "1-Default" or "4-SmallScaleSolving" profiles, stellarsolvertester reported taking 1.678s to solve the image, on my rpi4.

In my view, that's quite acceptable, being not much longer than a frame download (0.73s), and it's less than 1% of my typical exposure duration (240s). I expected that stellarsolver would find a solution quickly since it isn't running blind: it has a very good hint of where the center is expected to be, and probably knows what pixel scale and FoV size are. Additionally, this solving could be asynchronous: optimistically start the next exposure, solve in the background, if the target is appropriately aligned do nothing. If it's obviously wrong, abort the exposure (like a guiding constraint) and realign. If it doesn't solve ... consult a checkbox to decide whether to abort and realign, or ignore it and try again later.
1 year 7 months ago #85847

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

Time to create page: 1.142 seconds