INDI, KStars a Ekos

[Howking]

Tak jsem to včera všechno vyzkoušel. Pořídil i nějaká další data SH2-122 i když to v plánu nebylo díky očekávané kondici oblohy, ale chvilkami obloha překvapila a půlka dat určitě bude k něčemu. Zdá se, že je to použitelné. Z počátečního chaosu v tom už vidím i nějaký řád a vlastně to není ani moc složité. Jednou jsem to musel sestřelit, protože to zcela zamrzlo když jsem zobrazil profil pointační hvězdy - krásné 3D zobrazení, co při pokusu to modální okno zavřít vytuhlo všechno. Ale po znova spuštění všechno znova fungovalo i změny nastavení zůstaly. Na to, že je to už 14 let vyvíjený soft je to značně neergonomické. Musel jsem dokonce vytvořit druhý virtuální monitor, který se "připojuje", když spustím RDP a má rozlišení 1920x1080, protože na stávající rozlišení 1366x768 mého notebooku se Ekos prostě nevejde - ovládací prvky sice nezmizí za okrajem, ale naskládají se přes sebe a zabrání tak dosažitelnosti některých. Takže doma přes vzdálenou plochu to bude ok. Jak to bude v eventuálním terénu, to nevím, asi budu muset to ovládat z mobilu. No ale je to funkční, zbavil jsem se posledních Winů. Díky vám vím, že existují ještě i další alternativy - tohle založím Clonezillou a zkusím experimentovat s dalším softem (CCD Ciel, Polaris...)

[peto]

Tak vycitas tomu ze je to 14 rokov vyvijane a stale neergonomicke... a ten tvoj NB s tym 20 rocnym rozlisenim je ergonomicky?

[stmare]

S těmi modálními okny je to tam takové divné, protože mohou být v pozadí, ale v popředí nemůžeš nic dělat a pak ti to může připadat, že se to kouslo.
Doporučuji nastavení: Configure KStars -> Ekos -> Independent Window zaškrtnuté a KStars -> FITS -> Independent Window zaškrtnuté

[Howking]

To nejde. Už se mi potřetí kousl.

[Howking]

Pokus o diagnostiku s umělákem:
KStars 3.8.4.1-1 má GUI zablokované v synchronním QFuture::waitForFinished(). Tento čekací řetězec je volán z kódu, který prochází StellarSolver::extract(). Žádné z ostatních vláken nevykazuje odpovídající aktivní výpočet StellarSolveru; INDI vlákna pouze čekají v select(). Pravděpodobným mechanismem je tedy nedokončená asynchronní úloha/synchronizace uvnitř KStars, nikoli zamrzlé INDI TCP spojení.

A důležitá věc: to, že StellarSolver nebyl vědomě použit, není v rozporu s tímto nálezem. KStars ho může interně použít při některých operacích Ekosu.

[Howking]

Už jsem na to přišel. Dělá to dithering. Opakovaně se to kousne po 10 snímcích, což mám nastaveno v ditheringu.

[Howking]

Nastavoval jsem si volnou délku kabelů na svém dalekohledu tím, že jsem zkoušel krajní pozice - bod na obzoru těsně na východ od meridiánu a pak pak bod na obzoru těsně na západ od meridiánu. Všiml jsem si, že během přejezdu nastává situace, kdy dalekohled kouká mírně pod obzor a kdybych neměl packy na primárním zrcadle, už jsem jej vyklopil do tubusu. Ale ani tak nechci aby se to dělo, protože opakovaným vikláním zrcadla z podložky na packy a zpět dojde k jeho pootočení a ztratím v tuto chvíli perfektní kolimaci, kterou se bojím, že už tak přesně nikdy netrefím. Kombinace N.I.N.A, EQMod, ASCOM to nedělala, nyní na Linuxu kombinace Ekos, EQMod, INDI to dělá. Jde to nějak ošetřit?

Nabízí se alt limit. Ale v dokumentaci je psáno, že když dalekohled překročí limit, vyšle se stop a slew je zastaven. Nastane tedy problém dostat se z jedné korektní pozice do druhé korektní pozice jen proto, že průběh slew po cestě překročí alt limit?

[hades]

Zkusil bych to přes vytvoření a nahrání horizontu do Ekosu