DCF ptakovina - videli jste to uz nekdy?

Neděle Únor 17 09:47:45 CET 2008

To PLL na zažátky značek fakt pomůže a může být i dost jednoduché.  Od první 
hrany odpočítat vteřinu, zjistit jestli další přijde dřív nebo později a 
podle toho kousíček času přidat nebo ubrat (jednorázově, základní rychlost 
nechat stejnou). Když to dělám v MCU, můžu mu i dolaďovat oscilátor. Tak si 
hrajte :-))
Anděl

----- Original Message ----- 
From: "Jakub Ladman" <ladmanj@volny.cz>
To: "HW-news" <hw-list@list.hw.cz>
Sent: Sunday, February 17, 2008 12:12 AM
Subject: Re: DCF ptakovina - videli jste to uz nekdy?

Omlouvam se udelal jsem co sam nemam rad kdyz mi nekdo udela a sice reagoval
jsem driv, nez jsem to cely precetl.
Ted uz vim, ze jste nemyslel PLL na nosnou, ale na starty znacek.
Jakub Ladman

Dne Saturday 16 February 2008 22:36:28 Vláďa Anděl napsal(a):
> 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
>
> _______________________________________________
> 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