Astronomické fórum

Nemá hledáček. Použiji tool v Sharpcapu a vyfotím oblast kolem pólu ve dvou polohách RA. Já plate solving nepoužívám, příjde mi to moc adidas
Když docentrovávám hvězdu, tak to pohyb registruje a po synchronizaci se to nevrátí na vybranou hvězdu (jako OnStep mojí velké montáži) ale ujede to cca 2-3°. Ne montáž, ale ten terčík v planetáriu

Tak problém s tím ujetím nejspíš vyřešil nový firmware, teď už je terčík tam kde má být, ale přišel další trabl a to ohledně letního času. Může mi tu někdo z vás říct, jestli mu montáž najíždí na objekty správně? Mám v tom totální chaos, v nastavení ascom driveru mám správně GPS polohu, UTC Ofsset +1, jako ostatně i dříve a normálně to fungovalo. Neměl jsem potřebu do toho nijak hrabat. Teď je letní čas a ta montáž (nebo já, nebo číňan) je z toho na větvi, protože to prostě najede v RA blbě. Montáž navádím ze Stellaria kde je teď dole v řádku UTC +2, ale to nepovažuji za chybu.

Já tu položku UTC offset +1 v nastavování montáže chápu, jako vztahující se k mé poloze a ne k tomu, jaký je zrovna čas.
Nějaké komentáře na fóru ZWO kde se lidi zmiňují, že se k tomu uživatel má stavět tak, jako by žádný letní čas nebyl a nastavovat tam o hodinu míň, je už fakt na palici.

Remember that DST is just an artifact placed on the UTC Offset when Summer arrives. UTC itself does not change, and your longtitude does not change.

Can you set UTC time, and Longitude through your Hand Controller? If so, do that. And if it needs Local Time, set the local time to Winter Time (Spring forward, Fall back).

That should be completely equivalent to turning DST off.

Ale v ČR je aktuálně UTC+2, takže to máš špatně.
UTC se nemění podle letního/zimního období, odvíjí se od polohy slunce.

No UTC nijak nesouvisí s polohou Slunce, to by tu asi na AF mělo zaznít.
Pásmový čas, pro nás tedy SEČ je definován jako UTC +1h. A letní = +1 h k pásmovému. Tedy SELČ = UTC +2h

Provozoval jsem ji teď o víkendu na MHV. V notebooku jsem měl normálně letní čas, nic jsem nijak speciálně nenastavoval a najíždělo to dobře.

Firmware mám zaktualizovaný asi 3 týdny zpět.

MilAN píše: ↑11. 04. 2024, 16:39 No UTC nijak nesouvisí s polohou Slunce, to by tu asi na AF mělo zaznít.

Jak to ze ne ? UTC ma poledne presne v okamziku pruchodu Slunce nultym polednikem bez ohledu na to, zda je letni ci zimni cas. Lukas to napsal dobre.

peta62 píše: ↑11. 04. 2024, 22:38 UTC ma poledne presne v okamziku pruchodu Slunce nultym polednikem

To taky nebude tak úplně pravda kvůli mírné excentricitě oběžné dráhy Země a nerovnoměrné rychlosti oběhu, ne?

Pánové, s hrůzou zjišťuji, že jsem na astronomickém fóru, kde se objevují tyhle nesmysly o UTC a vazbě na Slunce. Mezi Slunečním časem na O. poledníku a UTC je v průběhu roku rozdíl, daný časovou rovnici a ta vyjadřuje rozdíl, kdy prochází Slunce meridiánem. A ten rozdíl jde do desítek minut.(stačí si v PC planetáriu zobrazit meridián a v průběhu roku se podívat, v kolik hodin prochází Slunce přes meridián)

Často dochází k záměně GMT a UTC.
GMT je definován jako střední sluneční čas = rovnoměrně jdoucí. NEMÁ PŘÍMOU VAZBU NA SKUTEČNÉ SLUNCE =nemůžeme měřit jeho průchod meridiánem (tedy kromě 4 okamžiků v roce a to ještě nepřesně). Vlivem sezónních změn není rotace rovnoměrná a proto byl zaveden čas UTC, který je koordinovaným časem z atomových hodin. A pokud rozdíl mezi rotací a atomovými hodinami přesáhne 1s, vkládá se navíc korekční sekunda.

Celé to je trochu složitější, tímhle chci jen vyvrátit ten nesmysl : UTC-průchod Slunce -poledne. Pravé Slunce prochází 0.meridiánem v poledne, ale to není ve 12 hodin ( viz časová rovnice) - čili to nejde navázat na UTC
Více je v kterékoliv učebnici astronomie.

mike píše: ↑11. 04. 2024, 22:41

peta62 píše: ↑11. 04. 2024, 22:38 UTC ma poledne presne v okamziku pruchodu Slunce nultym polednikem

To taky nebude tak úplně pravda kvůli mírné excentricitě oběžné dráhy Země a nerovnoměrné rychlosti oběhu, ne?

Samozrejme, ale je to deffinicni vztah, na zaklade jehoz ma Lukas pravdu.

Lidi ale na to jsem se vůbec neptal Martin napsal, že tam nic jinak nenastavoval a najížděla dobře. Mě teď napadlo, že sice mám aktuální firmware v montáži ale nemám aktuální ascom driver v notesu tak jsem ho aktualizoval a uvidím po zkoušce. Celé je to jenom o tom, jak programátor u ZWO uvažoval když to kódil a pokud je pro něj obvyklé přepisovat UTC offset na +2 při změně času na letní tak fajn. Na jiných montážích jsem tohle nedělal tak mi to přijde divný

Astrolamo, to my samozřejmě všichni vidíme, ale je dobře, že Milan uvedl (ač zjednodušeně, ale jinak to ani nejde, je to minimálně na několik stran textu) na pravou míru zavádějící tvrzení o vztahu UTC a průchodu Slunce nultým poledníkem. Kdo někdy stavěl sluneční hodiny, tak v tom má jasno. A ano, celé je to s těmi časy relativně složité. Každopádně UTC udávají atomové hodiny, a budou tak činit, i kdyby Slunce zhaslo.

peta62: UTC je čas. A pro něho je poledne, tak, jak to všichni chápeme, ve 12 hodin. A při tom neprochází (kromě těch 4 momentů) Slunce poledníkem. Mluvím u Slunci , o tom, které je konkrétně na té obloze, a to může být v té době více jak 4° vzdálené od meridiánu.
(Nemluvím o středním slunci, což je matematický konstrukt, kterému dáváme rovnoměrný pohyb v průběhu celého roku. To by procházelo ve 12hodin meridiánem, ale zrovna tak, jako paní Colombovou, ho nikdy nikdo neuvidí )

Jasne, ale definicne je UTC svazany s pruchodem Slunce nultym polednikem, coz mel Lukas na mysli.

V tom případě bych prosil tu definici.
O té bychom se mohli dlouze bavit v případě GMT , nikoliv UTC. Z průchodu Slunce ho neodvodíš. Lze ho svázat s rotací Země, ale nikoliv s průchodem Slunce.

A UTC snad neni svazany s GMT ?