×

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

Bi-monthly release with minor bug fixes and improvements

Plate solving issue in EKOS

  • Posts: 1119
  • Thank you received: 182
"Yes, you have the "I paused KStars and forgot to unpause it" syndrome :D I've seen it happening a lot of times that Ekos actually forcibly unpauses the clock when it starts."

I will gladly work with you to bring this debilitating syndrome to the attention of the medical community at large. In fact, we should write a paper about it and Nature seems to be the appropriate forum for this.
But I am concerned that the reviewers will ask us to be more specific on the methodology of the therapeutic approach.
So, where is this pause/unpause button???
I am prepared to sacrifice myself and be the guinea pig.
Just point me in the right direction.
Last edit: 5 years 11 months ago by Jose Corazon.
5 years 11 months ago #25285

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

It's a big pause icon in the main toolbar...
5 years 11 months ago #25286

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

  • Posts: 1119
  • Thank you received: 182
Sorry, I just don't get it. Here are the two screenshots from my Pi3 and from my Zotac mini-PC, both shut down this morning at the same time, both started back up tonight at the same time, both showing Kstars. The Pi3 shows the time from this morning,



the Zotac this evening's.



In neither case is the Pause button in the main menu activated.

Where is that Pause button you are referring to?
Last edit: 5 years 11 months ago by Jose Corazon.
5 years 11 months ago #25294
Attachments:

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Plate solving issue in EKOS

(in any case I have a commit in the pipe to warn the user when the Ekos Scheduler starts with a non-current time clock, but it might be helpful to emphasize on this more generally in the UI)

-Eric
5 years 11 months ago #25300

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

  • Posts: 321
  • Thank you received: 19

Checked yesterday the time and found out, that there indeed was a wrong time displayed in the main window on the left upper side. Changed that time then to the right. But in the indi drivers page where i set up the time, it still remains utc 3. it was not a problem yesterday but is it right? I always get confused, when its about time in such environments.

Cheers Niki



Gesendet von iPhone mit Tapatalk
Skywatcher EQ6-R | Lacerta 10" Carbon-Newton | Lacerta MFoc Motorfocus | Moravian G2 8300 Color | Canon EOS 5DMarkIIIa | Lodestar X2 guiding cam | KSTARS 3.4.3. on my outdoor-Laptop with KDE-Neon/Plasma | KSTARS 3.4.3. on Remote-IMac with Catalina | KSTARS 3.4.3 on Remote-Macbook Air with Catalina
5 years 11 months ago #25302

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


Oh that's not a pause problem then. Is RPI3 connected to the net? RPI does not an onboard clock, so it needs to sync with out an outside time source (e.g. NTP server).
5 years 11 months ago #25303

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

  • Posts: 18
  • Thank you received: 2

Replied by pask on topic Re:Plate solving issue in EKOS

Hello everybody,

My turn to jump to this thread as well, let me expose my "little" issue which is a problem in plate solving also :
Well, i spent two nights trying to solve this plate unsolving but in vain :'( ... i stayed at 1hr from my home in the middle of a field from 6PM to 6AM this morning (a bit hard for me to have my eyes open now loool) ...very frustrating to spend all nights trying to get the first step done ...but welll this is also why we like astronomy ;)

Issue :
- doing a capture & solve will never solve the capture.
- starting even a polar algnment is the same, not solving
BUT
- doing a capture ( in the module of capture, in a sequence or a preview that i saved) and then use "load & slew" will work in about 5sec !! (with the exact sky portion captured on both way)

-> from both test it is the exact same position and same exposure etc....

my setup is this one :
- skywatcher 254/1200 (+skywatcher coma corrector) with only canon EOS 5D3, no guiding.

one curious fact about the canon is, you can find 2 data for its resolution :
- 5760x3840 for a 36x24mm sensor giving 6,25microns
- 5796x3870 / 36x24mm then 6,22microns
Calculatin FOV gives : (103' x 68') - for both characteristics

I noted one weird thing :
- when i do a load&slew : it shows in the status zone that it starts the solver with that options : -H 108.966 -L 65.8275
- when i do capt&solv : options are mostly the same ...except H & L : -H 113.446 - L61.8794
Seems that from capture&solve it allows a bigger window...why ?
-> i tried to modify the options line in the "solver option" part of the aligment module, but it gets erased each time i start a capture&solve (i did not find from where it erase it)
-> I tried in the astronometry option (from the "option" button in the bottom right part of the aligment module) : i tried to uncheck "auto-update FOV" and modify the value of the FOV there but i did no see any change, each time the option line ("-o ....") is erased ... just like it was computing the FOV tolerance directly from the fresh capture
-> Is there a tolerence in the code that is different from "capture&solve" to "load&slew" ? Reversing the data gives me a +/- 5% for "capture&solve" and +/- 10% for "load&solve" !

-> so I try directly the solve-field command on the terminal ... from the same picture and just changing the H or L options ... the issue is on the H size ... the bigger one allow the picture to be directly solved in 5sec ... the initial H value does not solve at all (i increased the timeout to 5 and 10min..)

-> Then i noted the astrometry version was 0.67 ... i went to the website and in the middle of the night downloaded the latest sources (0.74) i did all the procedure from the website to install it : the short version failed at some points (i suppose some dependencies for compiling were missing) but the long version worked fine... i restarted kstars/ekos etc.. and ... well the version displayed in the status bar at launch of the alignment module is still 0.67 !! :'( :'( :'( i can't understand ... anyway no more time for that... :

As the sun was rising :'( ... i was short in options ... so idid trick the latest thing i could => i reversed the FOV formula to modify my telescope Focal length to match a option H of 113 !!
The focal was then 1146mm (instead of 1200mm) ... it solves !! but i have a warning saying "the calculed Focal length is 1082,x please change for better accuracy), i change the length, i redo the solving, then it ask me to change a little more the focal length, but still around 1082-1084mm ..(and 1082 is the exact value that gives directly a FOV of 113 .. strange)

Well ... that"s all my investigatio ... i ended up doing a polar alignment with the sunrise.. it was beautiful .. and i got my vector to adjust my alignment ! (well i missed it coz i was really too exhausting ... so i packed up everything and drove back home to sleep a few hours !!

Well ... thank you for reading me (long email, i tried to make it the most detailed and explain all i did .
@Niki and others : did you check the H & L options the solver gets to solve your picture ? (maybe it's same thing ?)

Any help will be more than welcome ... we have a big astro event tomorrow with all association of my region ... i would very love to be able to participate and most of all i would love to show the great bundle kstar/ekos/indi which is for me just a pure diamond of open developpment !!!

Pask,
The following user(s) said Thank You: the.cakemaker
5 years 11 months ago #25304

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

  • Posts: 1119
  • Thank you received: 182

Jasem, that cannot be entirely correct. When you are looking at the screenshot I had provided, you can see that the system clock of the Pi3 (upper right corner) was displaying the correct local time, i.e. 1835 h or 6.35 PM, whereas Kstars was showing 8.56 AM, which was the time the system had been shut down in the morning. So Kstars did not synchronize with the system time on the Pi3.

HOWEVER!

You put your finger on the problem: For whatever reasons I no longer remember, I had set Date and Time on that Pi3 to Manual. In fact, the Pi3 kept the actual time remarkably well, it must have a very precise onboard clock, because I never noticed any deviation from actual time, although no NTP server connections were activated. When I set Date and Time to interrogate the NTP servers and then restarted Kstars, now the correct time (minus ~30 seconds) was being displayed by Kstars!

IMO that means that Kstars upon startup is not synchronizing with system time, but with NTP servers specified in the Date and Time Module. If that is, however, set to Manual, it falls back to its previous shutdown time. However, when I now go to Time > Set Time to Now, Kstars will synchronize with System Time. Note, that the Pi3 WAS connected to the internet the entire time, so Kstars will not independently call up the NTP servers, it apparently tries to do that through the Date and Time Module and if that is set to Manual....

Interestingly, Kstars fails to set the correct time ONLY after a reboot, not if I quit Kstars and the restart it after some period while the Pi3 is still running.

I would not have thought of those contingencies in a million years. Is it straightforward to change that in Kstars so upon startup Kstars synchronizes to system time, not internet time?

Another quirk I noticed and mentioned above is that the Kstars time always lags behind system time by about 30" after it starts up.



Thus, there is a lag introduced by the time the time is first determined, the time span required for the software load, and when it begins to display the initially determined time via the Kstars internal clock. To get rid of that lag, one has to manually go to Time > Set Time to Now, which then cuts the lag down to ~ 1-2 seconds.
The following user(s) said Thank You: Jasem Mutlaq, Eric
5 years 11 months ago #25312
Attachments:

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

Thanks for the detailed report! It's fixed now in GIT and should be in KStars 2.9.5 release :-)
The following user(s) said Thank You: Jose Corazon, pask
5 years 11 months ago #25317

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

  • Posts: 321
  • Thank you received: 19
Hi!

I recognized, that there were somehow, somewhere 2 different resolutions given for my canon 5dIII. I had some Canon_ccd_blablabla errors on sturtup of indidriver, but the cam still works. Today and yesterday, this error did NOT occur anymore. I think that lies on my new laptop, and Jasem, who did a great supporting Job via Teamviewer on my new laptop. I must admit that i am a total noob on Linux...
What works for me in case of solving problems, and a mount, that drives down the floor is, like Jasem and Eric mentioned, to clear all the mount model data and start from scratch. The galaxys residing right in the zenith atm, force me to sometimes get the mount hit the tripod, even with my tripod extension. Thats the main reason, that goto/solving does not work anymore. But since i clear the data, in case of need, it works like a charm :-)

cheers
Niki
Skywatcher EQ6-R | Lacerta 10" Carbon-Newton | Lacerta MFoc Motorfocus | Moravian G2 8300 Color | Canon EOS 5DMarkIIIa | Lodestar X2 guiding cam | KSTARS 3.4.3. on my outdoor-Laptop with KDE-Neon/Plasma | KSTARS 3.4.3. on Remote-IMac with Catalina | KSTARS 3.4.3 on Remote-Macbook Air with Catalina
5 years 11 months ago #25329

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

Time to create page: 0.520 seconds