Ez is a vevőállomás függvénye. Persze egy ilyen snurcli vevőantennával sokra nem lehet számítani, de egy tisztességes antennával, érzékeny vevővel azért a föld túlsó oldalán is vehető.

Egyetlen nagyon nagy előnye van a dcf-nek, a fogyasztása, és van, amikor az súlyosat nyom.

A DCF -nek nincs fogyasztása. A DCF vevőnek van. A német piacra szánt vevőben egy egyszerű pár tranzisztoros egyenes vevő van, egy kisméretű ferrit antennával. Ennek valóban kicsi a fogyasztása. Viszont az érzékenysége nem túl nagy. Ez Németországban megfelelő használhatóságot biztosít, nálunk már nem annyira, főleg nem minden körülmények között.
Az adótól kisebb távolságban egy detektoros vevő is elég lenne, és annak semmi külső energia fogyasztása nem lenne.
Tehát a DCF vevő fogyasztása jelentős részben függ az adó távolságától (azért a GPS vevőknek sincs nagy fogyasztása) illetve, hogy a vevő, és a feldolgozó áramkörökben milyen, lehetőleg kisfogyasztású áramköröket használsz.

Érdekelne, miket találtatok a HGA22 -ről. Ahogy időm engedi, készítek vevőt. Ám az költői túlzás, hogy "hasonoló" a kódolás. Egyrészt FSK, Nem AM, mint a DCF77. A gyári DCF vevőkben egy(két)77,5kHz-es kvarc biztosítja a szelektivitást. 135.6 kHz-es kvarcot beszerezni lehetetlen. Szóval, egyenes vevő tkp. kilőve.
Persze, az adó közelsége, térereje sok mindent megengedhet, de azért korrekt vevőt kellene készíteni.
Szóval, jöjjenek az ötletek, tervek! Ha itt kevés lesz, indítsunk külön topikot, szerintem lesz érdeklődés.

Ezek a DCF-es rádiós ébresztőórák kompatibilisek a magyar időjellel is?

Vagy pl a Németországból származó dcf óra a német adóhoz fog szinkronizálni?

Nekem van ilyen órám, csak az emeleten veszi a DCF jelet, pedig van hozzá egy vastag külső antenna is.
Pont egy ilyenem van:
Bővebben: Link

Na ha a kérdező megveszi 990 Ft-ért akkor erről már tud időjelet venni. Meghosszabbítja az antennája kábelét amit így magasra ki tud tenni és már csak a tápot kell megoldani. Óra, perc, napot is tudja, automatik vált téli/nyári időszámításra. A kijelzőn azt is jelzi hogyha elmegy a DCF jel, sőt áramkimaradás esetén elemről üzemel tovább.
De másnem ez jó lenne a kérdezőnek tesztelni a DCF megbízhatóságát. De beltéren sok helyen nincs vétel, a tetőtéri szobákban jó nekem is.

De azt nem értem hogy honnan tudja hogy melyik időzónában vagyok? Mert bedugom és pár perc aztán már írja is a pontos időt, napot is szinkronizálva a DCF-hez.
Sőt téli, nyári időszításnál automatik át is állítja magát.

Abban az időzónában vagy, amelyben az adóállomás, tehát a szinkronizálás nem nagy kunszt.

Ki a "kérdező"

Nincs külön "Magyar" időjel. Magyarország, és Németország ugyanaz az időzóna, ugyanakkor van a téli-nyári átállás is. Ezért (sem) tudunk megszabadulni az átállási rendszerból, egész európában egyszerre kellene.
A svájci mérésügyi hivatalban van egy atomóra, mint elsődleges etalon, (10^-12 pontos) ehhez szinkronizálják a DCF adó vivőfrekvenciáját. Ezért hívják másodrendű etalonnak (10^-11 pontos. Az időkódot már az adóban "rakják rá" a vivőre, és ezt sugározzák ki. Természetesen az időkód alapja is a vivőhullám.Egy közönséges kvarcoszcillátor 10^-3 - 10^-5 pontos, egy termosztátos hőkompenzált is 10^-8 - 10^-9 pontos.
Bárhonnan származik a DCF vevő, (akár építhetsz magadnak is, csak egyenes vevő legyen) az ezt az adót veszi, ennek a jelét fogja feldolgozni.

Tényleg nincs "külön magyar idő".
Ettől még szolgáltatunk saját (ámbár szigorúan "fentről" szinkronizált) időinformációt speciális célokra (lásd pl. MÁV órahálózat).
Vagy a korábban is emlegetett Lakihegy:

Lehet ezt mindjárt meg is fülelem

Ez egy speciális probléma, nemcsak a MÁV -nál. A nagykiterjedésű órahálózatoknál már számolni kell az információ átvitel késleltetési idejével. Különleges probléma pl. MVM esetében az egymástól távol levő állomások egyidejű szinkron kapcsolása, vagy egy szövevényes digitális hálózat (PCM) szinkronozása.

Ehhez kepest a NTP nehanyszor tíz milliszekundum pontossaggal szinkronizalja a szamitogeped orajat (az enyemeket legalabbis), pedig ott az atviteli csatornak kesleltetese (Internet) teljesen valtozo.

Az NTP a késleltetést a körbefordulási idő kiszámolásásával kompenzálja. Kétségtelen, hogy hibák keletkeznek azáltal, hogy a késleltetési idő oda és vissza különbözik, és változik. Ezért érdemes "közeli", nem toródott átvitelű NTP szervert választani időforrásként.
Ezt a problémát -és mást is- oldja meg a IEEE1588 protokoll, amivel ns nagyságrend pontosságú időszinkronizáció lehetséges, IP hálózaton is.

Mellesleg már régen nem az eredeti kérdésről szól a dolog

A topic a kérdést megoldotta, a felvetődött problémákra pedig workaround felírások vannak. Aki erre jár hasonló problémával, bőségesen el lesz látva a szükséges információkkal. Szerintem nem nagy baj az.

Ha indul egy hga22 topic, egy linket hagyjon itt valaki.

Ha kellene doksi alap itt a #19 és #24-et olvasd el.

Nos, készítettem HGA22 vevőt. A protokoll dekódolása még várat magára, tehát hogy a pontos időt küldi-e, és hogyan. Aki esetleg ráérne evvel bíbelődni, mellékeltem a egy felvételt a bitfolyamról. Örülnék neki, ha valaki hasznos adatokat nyerne ki belőle. Tehát a soros kimenetről a bitek (start, stopbit, paritási is van) bájtokba pakolva. Mivel így egy bájt hasznos adat 11 bitet foglal, nem báj-határon vannak a karakterek!

Mivel lehet ezt a fájlt megnyitni?

Hát, valami hexeditorral. Linux alatt én hexdump-pal, ill xxd-vel nézem.

Találtam egy ilyet, lásd melléklet. Nekem sehogy nem jönnek ki a bájtok (lehet, hogy nem jó módszert követtem). Elsősorban a doksiban leírt 68h és 16h bájtokat kerestem.

Arra időközben rájöttem, hogy little-endian vannak a bitek a bájtokban.
Tehát van pl egy FC20D94 szekvencia, az binárisan
111111000010110110010100
Az aláhúzott 10 az a stop és köv startbit, vastagon a 8 bit, amt visszafelé olvasva
0x68 utána a paritás dőlttel, majd a köv. stop,start.
Hurrá, a doksival egyezik, 0x68-cal kezdődik az üzenet.

Kíváncsi vagyok, mire jutsz vele. A Start és Stop bájtokat megtaláltam, de hogy közötte lenne pontos idő, a fene tudja.

Szia!

Hol találtad ezt a szekvenciát a csatolt fájlban ?

Szia Pista, nem alszol ?
A korábbi fájl hexdump-pal (pontosabban xxd-vel) kiírt változata mellékelten.
Ebben megtalálod.

Á, bagoly üzemmód !

Keresem !

A raw-os meg ez teljesen más !

ASCII-ben küldi a 2.fájl tanúsága szerint az adatokat és azt kell bitekké visszaírni ?!
szerk.: én a képeknek megfelelően látom, jó így a beállításom ?!

Igen vissza kell/lehet soros bitfolyammá alakítani. Aztán dekódolni kellene. Valamiféle SW UART -ot kellene csinálni. Nekiestem megírni, de egyelőre feladtam.

Excellel szerintem megy !

Nem láttam FC02D94-et csak FC2D94-et!

Csak példának szántad vagy szerinted benne van ( akkor kellene a címe, a dekódolásodat értem !) ?!

Igazad van, rosszul írtam, de a bitsor már helyes, tehát
FC2D94 = 111111000010110110010100
Ez a sorozat többször is benne van fájlban.

Így meg lett volna az előbb is !