DCF ptakovina - videli jste to uz nekdy?

[Vláďa Anděl]

Takže se můžete inspirovat třeba u mě :-))
http://vaelektronik.cz/cteni.htm
http://vaelektronik.cz/dekoder.htm

Jde o to:
1. dobrý přijímač. Jeden krystal ve filtru stačí při dobrém signálu, ale 
když svítí sluníčko, taky uděláte dobrou fotku i s blbým foťákem ...
2. z přijímače málokdy lezou správné délky značek. Přijímače mají obvykle 
telegrafní zkreslení, značky trochu prodlužují nebo zkracují. Při dobrém 
signálu to není problém - ale když je signál zatížený šumem a délky značek 
jsou rozházené, s korekcí telegrafního zkreslení jste ve výhodě.
3. najít přesný začátek vteřiny při blbém signálu - to chce PLL a průměrovat 
spoustu značek. Chytat každou značku zvlášť jde taky, ale rozptyl délek 
vlivem šumu (rušení) je dvojnásobný.
4. Spoléhat při zabezpečení na vysílanou paritu fakt nestačí. V minutě, 
hodině a datumu my mohla být maximálně jedna chyba, na víc chyb parita 
nestačí. Můžete ještě kontrolovat formát dat (jestli jsou čísla dekadická a 
nepřekročí max. hodnotu). Tím vyloučíte polovinu chyb jako paritou. Další 
zapezpečení je možné jen porovnáváním po sobě jdoucích telegramů.
5. Když si koupíte přijímač DCF-S, S1 ... udělá tohle všechno za vás. DCF-SL 
to jen "předžvýká" a na výstupu dává telegram DCF, ale už bez chyb :-) Moje 
přijímače jezdí i na lokomotivách (pod trolejí) a s falešným vyhodnocením 
bordelu není problém.

Anděl


----- Original Message ----- 
From: "Jakub Ladman" <ladmanj@volny.cz>
To: "HW-news" <hw-list@list.hw.cz>
Sent: Saturday, February 16, 2008 9:09 PM
Subject: Re: DCF ptakovina - videli jste to uz nekdy?


No v létě když jsem to postavil a ze základu naprogramoval (nejdřív jsem
upravoval cizí algoritmy a pak je zavrhl a napsal si to znovu posvým), to
jelo taky co telegram to synchronizace, ale už v průběhu září se signál 
začal
zhoršovat a teď je to tak jak o tom hovoří ten logovací soubor, občas 
platnej
telegram v haldě bordelu.
Ale je to asi tím že ten přijímač co používám evidentně stojí za hovno 
(najít
na parapetu okna místo, kde to občas syncne je porod, CRT TV ani monitor u
toho není).
Datum potřebuju, neb mám na každý den jiné budíky a taky se zobrazuje.
Algoritmus počítá s přestupnou sekundou, ale nijak na ni nereaguje, prostě 
by
se mělo zobrazit 60 na pozici vteřin, ale nikdy jsem to neviděl. Změna l/z
času taky není ošetřená s tím že se to srovná při nejbližší synchronizaci -
ovšem to jsem ještě nepočítal s tím, že budu muset srovnávat po sobě jdoucí
synchronizace.

Jakub Ladman

Dne Saturday 16 February 2008 20:15:37 Aleš Novák napsal(a):
> 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
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list


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