Egy-egy részlet, ahol van adat, azt lehet vele konvertáltatni, de valóban inkább egy progit kellene rá írni ... !

Na, akkor itt van mellékelten, dekódolva:


Alkalmasint hosszabb időtartamot is rögzítek.
(h. piros v. fekete egy szám, nincs jelentősége)

Két jel között mennyi az időkülönbség? Másodpercenként vagy percenként jön az adat? Abból vissza lehet következtetni, hogy van-e benne időkód.

Úgy 6-8 másodpercenként jönnek peridikusan üzenetek, közben indőnként "véletlenül".
A bitsor fájlból pontosan ki tudod számolni, hisz 200bit/s, egy bit ideje 5msec

Ügyes !

Sziasztok

Ha még emlékszel, véletlenül nem 17:44 körül rögzítetted? Ahogy nézem a TT az idő és dátum:
#
68 0A 0A 68 13 00 00 TT TT TT TT TT TT TT 99 16
Ha legközelebb rögzítesz és dekódolsz légyszives írd meg a rögzítés idejét is, hátha rájövünk a formátumra

oxy

Szia, rögzítek majd még egy ideit, aztán jövőre, időbélyeggel, ki kell derüljön az igazság.
A korábban irt infók alapján, és ahogy írod is, ott kell lenni a pontos időnek.
Van azért, ami nem klappol.

Úgyis kitaláljuk Ha időbélyeggel tudod feltenni ilyen formában az nagy segítség lenne.
Én fordítva néztem az adatfolyamot, nagy valószínűséggel hülyeség, de ezeket találtam ki rá:
68 0A 0A 68 13 00 00 00 B0 2C 11 7E 0C 0F 99 16

16-Stop
99-Checksum
0F-Év (15)
0C-Hónap (12)
7E-Nap (126) vagy valami
11-Óra (17)
2C-Perc (44)
B0-Másodperc (176) vagy valami
00-Valami
...
A többi meg érdektelen a számunkra.

Én az alábbi doksiból dolgoztam:
http://itpiac.hu/smf/index.php/topic,2075.msg6334.html#msg6334
De valahogy nem az igazi...

Sok időformátumban a nap és a hét napja egy byte -ban együtt szerepel.

Ha e két byte -ot egy word -ként dekodoljuk: 0xB000 = 45056
Lehet, hogy a másodperc és tört másodpercet egy 16 bites érték adja meg ms -ben. Ez is igen elterjedt megoldás.

Valós idejű időbélyeget sajna nem tudok egyelőre.
Legyen elég: 2015. dec. 31., csütörtök, 23.05.30 CET környékén indult az alábbi mérés

Sziasztok, BÚÉK!
Egy felvétel '15, '16 fordulójáról.
Látszik az év, hónap változása. 11. 13. sorok.

Szia, BÚÉK!
Most olvastam bele a téma végébe, és felkaptam a fejem, tetszik ez a téma (bár lehet át kéne már nevezni.. ).
Nem merültem bele a dekódolásba, de tetszik a viszonylagos egyszerűsége. Viszont az analóg részben annyira nem vagyok otthon, mennyire nehéz összedobni ehhez egy vevőt?

Nem tudom.
A karácsonyi szünetben analóg vevőt akartam csinálni. Aztán nem volt alkatrészem, meg műszer nélküll rádiót...
Rátaláltam a GNUradio-ra (egy SDR fejlesztői környezet) és láttam, hogy a RTL chipes DVB-T stick-kel megy.
A "front-end" egy KH rádió ferritantennája, forgókondival, áthangolva 135kHz-re. Egy jFET-es impedanciailleszó, és már megy is a jel az RTL direct sampling bemenetére.
Szóval a laptopomban futó SW a rádió.
Ha sikerül pontosan dekódolni az adatokat,akkor lesz érdemes "igazi" rádiót csinálni.
És ha valaki egy órát is leprogramozna mikrokontrolleren, ui. arra biztos nem lesz időm.

Ja az más. Sajnos idővel én is rosszul állok, de egyszer tuti rávenném magam, ha a vevőt egyszerűen össze lehet rakni.
Na ami késik, nem múlik...

BUÉK!

11.sor:



16: zárás
A7: ?
0F: 15 ( év)
0C: 12 (december)
9F: 100 11111B, azaz 100--> 4.nap ( csütörtök) 11111--> 31 ( dátum )
17: 23 (óra)
3B: 59 ( perc)

13.sor:


16: zárás
55: ?
10: 16 (év)
01: 1 ( január)
A1: 101 00001B, azaz 101--> 5.nap (péntek) 00001 --> 1 ( dátum)
00: óra
00: perc
Egyelőre ennyi, jó éjszakát !

A záró karakter (16) előtti kódokban pedig igaza van oxygen kollégának checksum ( a 68 és a 16 keretkódok közötti összeg alsó byte-ja ) !

Ó nagyszerű, köszönöm. Ahogy látom kissi kolléga kitalálta a kódolást. Akkor amire figyelni kell, az az üzenet hossza "0A 0A" mert kétszer küldi a hosszt, illetve a cím "00 00". Ha ezek megvannak akkor a következő 7 bájt időkód, ha más jön be nem kell foglalkozni vele. Összeszedem a gondolataimat és építek valami egyszerű vevőt, meg írok rá valami programot.
És természetesen BÚÉK Mindenkinek

Átfutottam, akár jó is lehet, bár eléggé összefolyt az 56 bit a számológépen

Pista, kösz a megfejtést!
Annyit hozzátennék, hogy vannak olyan felsőbb helyiértékű bitek, amik biztosan nem használtak., pl. a hónap bájtja. Ha valaki fejlesztene, érdemes ezeket kimaszkolni, mert lehet, hogy egyéb információt hordoznak,
pl nyári/téli időszámítás, szökőmásodperc, Bizonyára a másodperc infó is van, ehhez majd pontosabban kell mérni. És egy ötlet a fejlesztéshez: a legjobb az lenne, ha DCF77 vevőt emulálná a feldolgozás,
így a sok meglévő, DCF77 alapú, térerő hiányában botladozó megoldás kaphatna új életet.

Már csak egy rádiós szaki kell, aki összedob egy vevőt.

Sziasztok!
Egy ídőbélyeggel ellátott mérés eredménye található alább.
A másodperc kódolása nincs még megfejtve.
Az időbélyeg a keretet bevezetö 0x68 beérkezése után keletkezik.
Egy bájt: 200bit/s , 11 bit, az 55msec késleltetés. A neten fellelt adatok szerint kb. 10msec az FTDI UART késleltetése. Igy 65 ms-mal korrigáltam a timestamp értékeket. A gépem órája NTP-vel szinkronizált volt.


Majd jelentkezem további méréssel is.

Kis kiértékelés:
Látszik, hogy
- 10s-onként érkeznek a pontos idő értékek. Erre azért nem lehet számítani!
- Ezt a programom egész pontosan, nagyjából század másodperc (!) pontosan képes követni.
- A késleltetés (latency), amit a FTDI + SW behoz, csak nagyjából ismert, de legalább állandó.

Szóval, ugye, az időt tartalmaző 5 bájt - pl | d8 14 03 4c 01 10 5f | -első bájtja tartalmazza a másodpercet. It d8.
Arra jutottam, hogy ez a negyedmásodperc érték. (Ugye egy bájt van a másodperc leírására,
a legnagyobb felbontást 4*60 = 240, ami belefér 1 bájtba. Én sem csinálnám másképp )
De akkor miért korábbiak a timestamp-ek?
Feltételezem, hogy a pontos időt nem a keret eleje (0x68) reprezentálja, hanem valamelyik későbbi bájt - bit valamelyik éle.
Ezt még pontosabb méréssel lehet kitalálni.
De azt hiszem.hogy már ez a pontosság (keret eleje + 0.5 s) is elég pontos egy "emberi fogyasztásra" készülő óra számára.

Úgyhogy nekifogtam egy "igazi" rádió tervezésének. Remélem, hogy belátható időn belül jelentkezem az eredménnyel. És bátorítalak titeket is a kísérletezésre, vevő/óra készítésére!

Eredményért várjuk vissza! Engem legfőképpen a vételi minőség érdekel, mert a DCF nálam csúnyán megbukott.

Nem tudom, hol laksz. Budapesten ezerrel jön. (Illene korrekt térerő infót adnom...)
Viszonyitási alap: nagyobb térérővel jön, mint a solti Kossuht adó.
Azért olyan vevőt tervezek, ami várhatóan egész Magyarország területén vételt biztosít, szoba-ferritantennával.

Ilyesmit csináltak már.

GPS vevőből a uC egyik portja 77.5 KHz frekin továbbítja a DCF kódú idő infót.
Így a kis térerejű DCF vétel esetén a DCF vevő elvan látva lokális DCF jellel.

Itt csak az a kérdés mennyire fogja zavarni a saját fő vevőt 137 KHzen a 77.5KHz 2*felharmonikusa amikor éppen beindul az adása.

Bele kell nézni egy egy ilyen villanyórákban lévő kapcsoló dobozába.
Ha mást nem ,akkor bementi LC kör paramétereit megmérni.
Habár egy 130 KHz környéki rádió bemenőköre nem lehet nagy akadály.
Vietel tollából jelent meg annó RTben DCF vevő. (kb.:85-88 közt)
Volt hozzá kiegészítő cikk aktív antenna leírása.
Ebben 2 J-FET-ből álló differenciál erősítő fogadta a ferrit rudat.

RT 1988/8 407. oldal aktív ferrit antenna

A DCF77 hazai vételénél a kis térerő a probléma. A HGA22 esetében ez nem gond, inkább a demodulálás. A DCF77 amplitúdómodulált, 1bit/s-mal szemben a HGA22 200bit/s, FSK-ra kell készülni.
A kis 77,5 kHz-es adóra nem gondoltam, de mivel kapható ilyen kvarc, az AM egyszerű, nem lehet gond.

Aki esetleg követi a projektet: készítettem rádiót a HGA22 vételére. Alapja egy TCA440 IC: A lokál oszcillátor 133.333kHz-en jár. Így az adó 135.6kHz-es jelét hangfrekvenciára keveri le. Szépen, zajmentesen szól. Az antenna a Conrad-os DCF77 vevő ferritantennája, persze áthangolva. Következik az FSK demodulátor!