Időmérés - Mennyi is az idő?
A legtöbb esetben kétféle problémakörrel szembesülünk:
- a nullpont kijelölése,
- a nullpont óta eltelt időszelet "finomsága".
Nem minden esetben van szükség azonos megoldásokra, sőt nem is minden esetben elvárás mindkét feladat megvalósítása...
Dali: Az elfolyó idő
Nullpont
"A másodperc hivatalos (SI) meghatározása a következő:
A másodperc a cézium 133 atom alapállapotában a két hiperfinom szint közötti átmenetnek megfelelő sugárzás 9 192 631 770 periódusa.
Az 1967 előtti meghatározás a következő volt:
A másodperc a tropikus év 1900 január 0 földi idő szerinti 12 órakor mért 1/31 556 925,9747-ad része." (Wikipedia)
Az időmérések esetén két féle feladattal találkozhatunk:
- szükséges az abszolút nulla időpont meghatározása (illetve az azóta eltelt idő),
- startpontra van csak szükség és viszonyítási pontként tekinthetünk rá.
A második eset egyszerű: a bekapcsolás és a rendszerprogram indulását kinevezhetjük egy önkényes viszonyítási alapnak.
Az első esetben is egy önkényes ponthoz viszonyítunk - ez európai mértékrend esetén Jézus születése.
DCF77
A nullpont meghatározása/megadása valamely abszolút(nak tekintett) viszonyítási alaphoz képest lehetséges. A feladat határozza meg, hogy mennyire szükséges megközelíteni az abszolút időpontot. Saját atomóra - melyet tekinthetünk etalonnak - nem rentábilis, pláne berendezésenként. Azonban számos atomóra jele, ideje kívülről, földi halandó számára is elérhető!
A legegyszerű(bbnek) tűnik a Frankfurt melletti rádióhullámon sugárzó időjelző. Ez ún. DCF77 vevővel fogható és a protokollját ismerve a pontos idő meghatározható. Egyetlen hátránya a távolság, így csak jó vételi viszonyok közt lehet jelet fogadni.
DCF77 vételkörzet
A telepítési helyünket és a jel forrását ismerve - a pontos időt korrigálnunk kell a terjedési sebességgel és (precíz mérés esetén) a jelfeldolgozás sebességével. Így, ha van vett jelünk, akkor pontos időnk is van. Ám ha nincsen....
Network Time
A internetnek, mint kommunikációs hálózatnak köszönhetően az atomórák könnyen elérhetővé váltak. A protokoll az NTP névre hallgat és a Network Time Protokol rövidítése. Az adatátvitel a legkisebb késleltetésű UDP csomagokat használja. Természetesen a küldés pillanatának idejét kapjuk meg, melyet a megtételhez szükséges úttal korrigálni kell még.
Ez a megoldás - természetesen - csak internetre kikötött, ethernetes alkalmazás esetén jöhet szóba... Ám ha ez sincsen...
GSM
Már számos mobilkommunikációs alkalmazás érhető el. Az eszközökben az elengedhetetlen GSM modem a szolgáltató által biztosított időadatokat elérhetővé tette - így egy közelítő pontosságú idő elérhető a rendszerünkben. Itt is fennáll a problémakör, hogy csak a pontos idő miatt kissé drága a GSM illesztés...
GPS
Ha helymeghatározó eszközünk van, akkor ennek illesztése is gyerekjáték a mikrokontrolleres környezetbe. A rendszer a működéséből fakadóan, szintén pontos időt ad. A GPS vétele nem biztosítható épületen belül, föld alatt, árnyékolt környezetben... Ám ez sem ad mindig megbízható működést...
Eddigi lehetőségeink:
| Jelforrás | Korlát | Ár |
|---|---|---|
| Cézium atomóra | Nehezen elérhető | magas |
| DCF77 |
Frankfurttól való távolság |
relatív olcsó |
| Network Time (NTP) | Internetkapcsolat | közepes |
| GSM | Mobilhálózat lefedettség | közepes |
| GPS | Rálátás a műholdra | közepes |
Kézimódszer / RTC
Az eddigi megoldások valahol mindig elvéreztek:
- külső szolgáltatótól függ az adat elérhetősége,
- drága eszközök kellenek a megvalósításhoz,
- nem érhető el az adat folyamatosan.
Így valamilyen eszköz, ami belül megoldja a folyamatosan rendelkezésre álló pontos időt, számunkra az az ideális. Ezek az ún. Valós Idejű Órachipek (Real Time Clock - RTC, újabban Real Time Clock/Calendar - RTCC). Segítségükkel a pontos idő rendelkezésre áll, mivel helyben keletkezik. (Az AVR-ek szoftveresen kialakított belső órája nem jó számunkra, mivel minden bekapcsolás után be kell állítani a pontos időt rajta.)
Az RTC-k alapelve igen egyszerű: ha van egy stabil frekvenciájú órajelforrásunk, akkor annak jelsorozatát számoljuk meg. Gyakorlatilag egy feltupírozott számlálóIC:). Így csak a rezgés/négyszögjelforrás pontossága adja meg az óra megbízhatóságát. Nyers esetben, amikor semmiféle beállítást, finomhangolást nem végzünk, akkor a rezgésforrásnak használt kvarcok 10..100 ppm pontosságúak. Ezzel napi szinten 2-5 mp eltérést okozhatunk a pontos világidőhöz képest - a legrosszabb csillagegyüttállást feltételezve. Ennek kiküszöbölésére időnként az abszolút időt adó eszközökhöz fordulhatunk szinkronizálásra. Utánállítva az órát, már használható kronoszkópunk keletkezett...
Finomság, felbontás
Az órák pontossága mellett a visszakapott idő finomsága is fontos kérdés. A gyakorlatban másodperceket tudjuk az előzőekben ismertetett módszerekkel megkapni, ennél finomabb időalapot csak járulékos mérőeszközökkel állíthatunk elő (pl. msec vagy usec). Az RTC chipekből a kínálat végtelenségig tart - természetesen a beszerezhetőség és az ár dominál a legtöbb esetben... Az ár itthon legtöbbet nyomja a latban*... (*Lat, Latinum : Ferengi nagyértékű fizetőeszköz.)
Az órachipeknek a processzorral is kommunikálniuk kell. Erre a standard kommunikációs módok alkalmasak: mint az 1-wire busz, az IIC és az SPI. A tapasztalat szerint az IIC chipek használata a legegyszerűbb.
A sok gyártó létezik a piacon - azonban chipjeik még véletlenül sem csereszabatosak sem a belső felépítését tekintve, sem a tokozásukat. A chipváltáskor mindenképpen a processzorban futó kódot frissíteni és átírni kell - így a tervezésnél érdemes már megnézni a lehetőségeket. A külső kialakításban a DIP8 tok, SOIC-8 tok a gyakori. Esetenként még az MLF, TSSOP tokozás is előfordul - ezek azonban nehezen kezelhetőek. Kivételes esetben a fő kivezetések egyezése esetén a chipek azonban fizikailag cserélhetőek (maximum a funkcionalitás miatt kell a szoftvert frissíteni a központi processzorban).
Kiegészító funkciók
Az óraIC-k a pontos idő mérésen kívül még számos szolgáltatással rendelkeznek - ezek közül néhány (felsorolásszerűen):
- pontos időalap (1 sec),
- ébresztés,
- külső elem illetve akkumulátor lehetősége,
- belső töltőáramkör,
- külső illetve belső kalibrálhatóság,
- 32000 és/vagy 32768 Hz kvarc támogatása,
- téli/nyári óraátállítás
- stb.
A táblázatban néhány gyakoribb chip (IIC):
| Típus | Gyártó | Tokozás |
|---|---|---|
| MCP79410 | Microchip | SOIC8/DIP8 |
| PCF85x3T | Philips | SOIC8 / DIP8 / TSSOP8 |
| DS1307 | Maxim-Dallas | SOIC8 / DIP8 |
| DS3231 | Maxim-Dallas | SOIC16 |
| RS5C372 | Ricoh | TSSOP8 |
| M41T62 | STmicroelectronics | LCC8 / QFN16 |
Az órachipek csereszabatossága számos esetben felmerült már. A táblázatban a SOIC8/DIP8 tokozású RTC-k átfedése a jelentős. Az áramköri megvalósítás során csak nehézkesen biztosítható a csereszabatosság (így inkább nem érdemes erre építeni). A címzés, az áramköri felépítés és a kezelés is problémákat vet fel. Az órachipek kezelésének mintaprogramjai a kapcsolódó fórumban található, mivel újabb és újabb chipek és funkciók jelennek meg - melyek mintái így naprakészen elérhetőek.
Precíziós időmérő
A precíz időmérők pontossága jobb, mint a RTC chipeké. Ez alapesetben 1 sec-nél pontosabb időt jelent. De, hogy hol van erre szükség? Az esetek jelentős részében csak a relatív idő az, ami fontos számunkra. Vagy röviden: két esemény közti idő. Például egy futóverseny, rajt-cél ideje.
Ha valamely rejtélyes okból abszolút időben van szükségünk másodpercnél pontosabb időre, akkor erre a GPS a legalkalmasabb eszköz. Itt a műholdak egyedi sugárzott jelsorozatát, az ebbe kódolt időt kell megismernünk. A SIRFStar III chipek esetén ehhez a SIRFBinary kommunikációs protokollt használva juthatunk el...
De nem mindenütt van GPS jel és nem is kell mindenütt az abszolút idő.
Erre a feladatra (is) a mikrokontrollerek alkalmazása célszerű. Itt minden rendelkezésre áll a precíz megvalósításhoz:
- nagysebességű számláló,
- precíz órajelforrás.
A kvarcok hangolás nélkül átlagosan 30 ppm pontosak - 10 perc mérésekor néhány századmásodperc az eltérés már. A precíz mérés azonban az órák helyett immár a mikrokontrollerek sajátja - így a Timer kerül legközelebb a billentyűzetbe...
Téli-nyári/nyári-téli óraállítás (Daylight Saving Time-DST)
A nyári időszámítás széles körben elfogadott rendszer, melyben a helyi időt 1 órával előre állítják az adott időzóna idejéhez képest. Az elnevezés onnan ered, hogy ez az időszámítás nagyrészt a nyári időszakra esik. Jelölése: általában az addig használt időzóna utáni „ST” betűkkel történik, például Európában a téli CET helyett nyáron CEST van érvényben (az „ST” eredete: „summer time”, vagyis „nyári idő”).
Téli-Nyári óraállítások (Kék: jelenleg van, Narancs: volt, megszűnt, Piros: nem is volt)
A mesterséges világítás helyettesítésére (és ezzel az üzemanyag háborús célokra való megtakarítására) elsőként Németország alkalmazta a nyári időszámítást, amit 1916. április 30-án 23:00-kor vezettek be. Ezt akkor, az első világháború alatt gyorsan átvette Nagy-Britannia, az Egyesült Államok (az USA hivatalosan csak 1918-ban vezette be) és sok más ország, de a háború végével az országok visszaálltak a normál időszámításra. A második világháború kitöréséig nem is merült fel a használata. Akkor ismét a háborús erőforrásokkal való spórolás miatt vezették be.
A második világháború alatt az órákat néhány ország folyamatosan 1 órával előre állította (például az USA-ban 1942. február 9. és 1945. szeptember 30. között, ezt „War Time”-nak nevezték). Nagy-Britannia „dupla nyári időszámítás”-t használt, nyáron 2 órával előre állítva az órákat, télen pedig 1 órával. Nagy-Britanniában ekkor ismerték fel a nyári időszámítás üzemanyag-megtakarításra vonatkozó hatását.
Magyarországon 1954-57-ben még a munkanapok esti csúcsterhelésekor jelentkező kapacitási nehézségek enyhítésének reményében alkalmazták. 1958 és 1979 között a nyári időszámítás használata szünetelt, 1980-ban újra bevezették villamosenergia-megtakarítási céllal.
2011-ben Oroszország megszüntette az óraátállítást. Az új moszkvai idő az addigi nyári idő (UTC+3) lett. Fehéroroszország és Ukrajna ugyanígy járt el.
Gyakorlat
Az órák használatára a gyakorlatban számos lehetőségünk kínálkozik: leprogramozhatjuk natívan/utasításonként, vagy használhatunk kész függvény/eljáráskönyvtárat.
De mi s a célunk, mit kell tudnia egy órafunkciónak a programunkban? A válasz nem is olyan egyszerű:
- Kezelje a beállítását, fix időpont vagy valamihez szinkronizált legyen,
- A belső óra a külsőórával szinkronizáljon,
- Legyen külön ismert az óra-perc-másodperc mellett az UNIX idő, vagy relatív idő,
- Kezelje a pontosság kérdését és a szinkronizálás periódikusan megtörténjen,
- Legyen ébresztő mely napi/órás beállítást ismerjen és tudja a szundi módot,
- Kezelje a speciális funkciókat: INT, négyszögjel, belső hőmérő,
- Hibatűrő és kis erőforrás igényű legyen,
- Ismerje a téli-nyári átállást
- Ha az egyik órafunkió nem érhető el, az alternatív is működjön (pl. RTC vs. GSM).
Ezen követelményeket leprogramozni nem is olyan egyszerű. Szerencsére részben vagy egészben ezt már mások megtették:
- Belső óra: datetime eljáráskönyvtár,
- Óra adatforrások kezelése: RTCLib, RTCLib2 könyvtárak,
- Ébresztő funkció: TimeAlarm könyvtár,
- Téli/nyári óraállítás: TimeZone eljárás.
- Bascom-AVR alatt a chipkezelés és az órarutin a rendszer része.
A minták, alkalmazások a letöltések közt már elérhetők!
Felhasznált források:
- http://hu.wikipedia.org/wiki/Id%C5%91
- http://hu.wikipedia.org/wiki/Ferengik
- http://hu.wikipedia.org/wiki/Nyári_időszámítás
Kapcsolódó oldalak:
Fórum:
TavIR-Facebook