DCF ptakovina - videli jste to uz nekdy?

Jakub Ladman ladmanj@volny.cz
Sobota Únor 16 19:24:23 CET 2008


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

Jak jste to dělali vy?

Jakub Ladman

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





Další informace o konferenci Hw-list