-
Data: 2017-05-26 12:52:55
Temat: Re: Źródła czasu -- kolejność padania
Od: "HF5BS" <h...@...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]
Użytkownik "Piotr Wyderski" <p...@n...mil> napisał w wiadomości
news:og4sje$nmn$1@node2.news.atman.pl...
> HF5BS wrote:
>
>> To może własny zegar atomowy/cezowy/rubidowy?
>
> To nie wychodzi wcale tak drogo, za kilkaset dolców można mieć
> wzorzec rubidowy. Cezowy to inna półka, nie do zastosowań domowych.
No... zdaję sobie sprawę, że nic wiecznego nic wiecznego nie ma. Choćby i
zmęczenie materiału, czy jego płynięcie.
>
> Tylko one mają dwie wady: potrzebują sporo energii i się szybko
To płachta jakaś z fotoogniw, najwyżej pójdzie się do kiosku po nową
baterię, jak się stara zużyje, dla pewności przynajmniej dwie-trzy, aby w
razie padu jednej, pozostałe chociaż przez chwilę to utrzymały.
> zużywają (patrząc na to w skali kilkudziesięciu lat). Kwarc przy
Ano... to też zdywersyfikować i jechać na przynajmniej dwa zegary. Jak jeden
powie, że za chwilę umrze... albo i nie powie, tylko padnie, to drugi
powinien to jakiś czas podtrzymać, zanim wróci ten drugi, lub zostanie czymś
zastąpiony.
> braku drgań jest przewidywalny, rezonator widełkowy będzie działał
> i za 100 lat.
Cóż... albo tanio, albo dobrze, coś kosztem czegoś...
>
>>i/lub zrobić to tak, że czasu nie podawać
>> bezpośrednio, tylko zrobić coś, co będzie jakby interfejsem, co
>> pozwoliło by, w razie przepadku jednego źródła, móc przekształcić
>> protokół nowego do postaci strawnej dla starego, dzięki czemu żródeł
>> można by sobie narobić i pierdylion, wystarczyło by wtedy
>> "przetłumaczyć" ich dane, na postać dotychczas stosowaną; ze źródła,
>> które lepsze, bądź wygodniejsze.
>
> To jest unikanie problemu, choć w praktyce może się okazać nadzwyczaj
> skuteczne. :-)
Nie... nie chcę tu unikać problemu, tylko wyjść na przeciw sytuacji, że nowe
źródła mogą się okazać znacznie lepsze I TRWALSZE, wiążąc na sztywno stare
źródło z urządzeniem, czynimy sobie trudność, gdzie musielibyśmy bujać się z
czymś, co stare, najprawdopodobniej już nie produkowane, kosztowne w
utrzymaniu i niepewne. A tak, mając interfejs, zachowujemy integralność
systemu na ruski miesiąc (w samym systemie, jeśli się da, to oczywiście, też
jakieś źródełko, ale nie jako jedyne), może to sobie stać choćby w samym
piekle w pieczarze Diabła Naczelnego, a my sobie na spokojnie, "nie wiedząc"
o piekle, zmieniamy peryferia, nie ruszając samego systemu. Przekładanie
danych różnych źródeł na jednolity format ma właśnie temu służyć, żeby nie
trzeba było w samym systemie już nic robić, a w razie zmiany formatu źródła
nie być tym ograniczonym, w razie nowe źródło - siadamy do kompilatora,
tłuczemy te parę linijek programu do interfejsu i po bólu, wszystko nadal
bangla.
Ja sobie pomyślałem o jeszcze jednym źródle - o Księżycu, ale nie w sensie
zaćmiony, w której fazie, etc. tylko o jego obecności, lub nie, na
horyzoncie.
Zgodnie z prawem powszechnego ciążenia, Ziemia i Księżyc oddziałują na
siebie, a jako, że to są wektory, wystarczyło by mierzyć ich wypadkową,
okres obiegu księżyca wokół ziemi jest dokładnie znany, w związku z czym,
nawet, jakby zaliczyć potężną zgubę w odmierzaniu czasu, wystarczyło by
określić, ile razy Łysy w tym czasie okrążył Ziemię, z wartości wektora, w
powiązaniu z położeniem na firmamencie wyliczyć DOKŁADNY czas. Maszyny są
mocne, wystarczy azymut i elewacja, nasz wektor, podstawiamy do odpowiednich
wzorów i wydaje mi się, że mamy wystarczająco dokładny czas, którym możemy
zsynchronizować system. Pozostaje tylko problem w miarę dokładnego
zmierzenia wektora ciążenia, ale to chyba nie takie bolesne do zrobienia?
Może i nie tanie, ale połączenie pomiaru wektora, z wyznaczeniem dokładnego
położenia, mogło by być ciekawe i całkiem przyzwoite.
Przecież już starożytni potrafili pewne rzeczy obliczyć całkiem dokładnie,
czemu by nie wykorzystać tu matematyki, a fizyką jedynie się wesprzeć?
--
"Jeśli przyjmiesz do siebie zabiedzonego psa i sprawisz,
że zacznie mu się dobrze powodzić - nie ugryzie cię.
Na tym polega zasadnicza różnica między psem a człowiekiem"
(C) Mark Twain
Następne wpisy z tego wątku
- 26.05.17 13:08 HF5BS
- 26.05.17 13:08 Piotr Gałka
- 26.05.17 13:18 HF5BS
- 26.05.17 13:32 Jarosław Sokołowski
- 26.05.17 13:32 Jarosław Sokołowski
- 26.05.17 13:34 Jarosław Sokołowski
- 26.05.17 14:15 robot
- 26.05.17 14:51 Marek
- 26.05.17 16:50 Paweł Pawłowicz
- 26.05.17 17:26 Jarosław Sokołowski
- 26.05.17 20:38 Zenek Kapelinder
- 26.05.17 21:09 badworm
- 26.05.17 21:37 Sebastian Biały
- 26.05.17 22:02 Zenek Kapelinder
- 27.05.17 07:08 slawek
Najnowsze wątki z tej grupy
- termostat do lodowki
- SEP 1 kV E
- Aku LiPo źródło dostaw - ktoś poleci ?
- starość nie radość
- Ataki hakerskie
- Akumulatorki Ni-MH AA i AAA Green Cell
- Dławik CM
- JDG i utylizacja sprzetu
- Identyfikacja układ SO8 w sterowniku migających światełek choinkowych
- DS1813-10 się psuje
- Taki tam szkolny problem...
- LIR2032 a ML2032
- SmartWatch Multimetr bezprzewodowy
- olej psuje?
- Internet w lesie - Starlink
Najnowsze wątki
- 2024-12-14 światła znów wlączyli
- 2024-12-14 nie lekceważ termostatu
- 2024-12-14 numer 112
- 2024-12-14 Pendrive, ale dysk
- 2024-12-12 Autocom CAN CDP+ wysokie kody błędów
- 2024-12-13 termostat do lodowki
- 2024-12-13 Gdańsk => Inżynier bezpieczeństwa aplikacji <=
- 2024-12-13 Warszawa => Head of International Freight Forwarding Department <=
- 2024-12-13 Poznań => Employer Branding Specialist <=
- 2024-12-13 Kraków => Business Development Manager - Dział Sieci i Bezpieczeńst
- 2024-12-13 Kraków => Business Development Manager - Network and Network Security
- 2024-12-13 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-12-13 Gdańsk => Programista Full Stack .Net <=
- 2024-12-13 Warszawa => Analityk Biznesowo-Systemowy <=
- 2024-12-13 Białystok => Architekt rozwiązań (doświadczenie w obszarze Java, A