DCF ptakovina - videli jste to uz nekdy?

Aleš Novák ales.novak@t-email.cz
Sobota Únor 16 20:15:37 CET 2008


Stavěl jsem jen hodiny bez kalendáře asi tak před osmi lety. Jsou
prakticky stále na očích a ještě jsem nezaznamenal špatnou
synchronizaci. Paritu testuju taky, i když by to ani nebylo nutné.
Hlavně testuju, jestli dekódovaná informace odpovídá tomu co očekávám.
Tři po sobě následující dekódované informace se musí lišit právě vždy
o jednu minutu po předchozí. To už dává vysokou pravděpodobnost
správného čtení. Pokud ještě hodiny neběží, spokojím se jen se
správnou paritou a hodiny nastartuju.
Přechod mezi SEČ a SELČ neřeším, i když DCF tuto informaci taky nese.
Myslím, že i o přestupné sekundě se ví dopředu. Prostě se hodiny
zasynchronizují o pár minut později. Kdo na ně taky hledí ve tři
v noci, že.
Četnost synchronizace sice neznám ale podle blikání ledky se zdá
signál docela kvalitní a po zapnutí hodin se "chytí" většinou na první
čtení od zachycení minutové značky.
==============================
S pozdravem,
  Novalex

JL> Tak jsem si u těch chybných telegramů přepočítal ty parity a bohužel všechny
JL> opravdu sedí, tj. testovací algoritmy jsou správné, ale data natolik protivná
JL> že kontrolou projdou (no ta ochrana těmi paritami už na první pohled nevypadá
JL> nijak bombenfest, holt je to poplatný době vzniku).
JL> Napadá mě že nejsnažší (nejmenší počet kroků) bude testovat, zda datum
JL> odpovídá dnu v týdnu, ostatně funkci co den v týdnu z data počítá už v
JL> hodinách mám.
JL> Hodiny a minuty pak spolehlivě jedině porovnáváním po sobě jdoucích telegramů
JL> a jejich časového odstupu.

JL> Jak jste to dělali vy?

JL> Jakub Ladman

JL> Dne Saturday 16 February 2008 17:32:04 Jakub Ladman napsal(a):
>> Ahoj
>> V priloze je log soubor ktery jsem zachytil ze seriaku svych DCF hodin,
>> snazim se zbavit falesnych synchronizaci casu, ale stale se nedari na 100%.
>> Vcera jsem se po pul roce dokopal k pripsani toho logovani na seriovku a
>> podle toho co jsem videl jsem se pokousel opravit chyby v dekodovani.
>> Dopsal jsem omezeni maximalniho poctu prijatych bitu v telegramu na 61,
>> driv by to bylo ochotno citat furt pryc, kdyby neprisla minutova znacka.
>> Dale jsem doplnil kontrolu hodnoty nulteho bitu (== 0) a startbitu (== 1),
>> drive to kontrolovalo jen ty tri parity.
>> K memu prekvapeni se to ale stale synchronizuje na kokotiny.
>> Toto pisu driv nez zacnu data sam rozebirat, zajima mne jestli panove,
>> kteri tu maji s prijmem dcf zkusenosti taky neco takoveho zaznamenavaji.
>> Jdu prepocitat ty parity v prijatych datech u tech falesnych synchronizaci
>> a jestli sedi budu muset holt vyrobit nejakou logickou kontrolu - jako
>> jestli cas mezi jednotlivymi synchronizacemi odpovida rozdilu v prijatych
>> telegramech, jestli se datum nezmensilo, jestli tam neni nejaky dalsi
>> nesmysl, jako treba den v tydnu > 6, den == 0, mesic == 0.
>> Ale uprimne receno se mi do toho moc nechce :-)
>>
>> Diky za postrehy
>> S pozdravem
>> Jakub Ladman


JL> _______________________________________________
JL> HW-list mailing list  -  sponsored by www.HW.cz
JL> Hw-list@list.hw.cz
JL> http://list.hw.cz/mailman/listinfo/hw-list




Další informace o konferenci Hw-list