<html><body><p>Mam prazdniny takze mam casu dost.</p><p>SR620, servisni manuial pravda nemam. Hledam jsme ho neuspesne na internetu,predpokladam pomerne slozitou analogonou elektorniku se spoustou kompenzaci a ladeni pred tim nez opusti fabriku a ne kondenzator za 2centy. Rad bych videl jak to maji resene.<br></p><p><br> </p><p>>Mne se sumovy oscilator vesel do jedne 555 <img src="skin/default/img/smileys/s06.png" alt=";-)"></p><p>A to bude presne o dve 555 vice nez potrebuji ja. :-) Na dva oscilatory mi staci 4 CLB, do zbytku narvu rizeni a fazovy detektor. <br></p><p>Tusim jsem to uvedl jiz v puvodnim vlaknu, chtel jsem se trochu seznamit s FPGA stavet blikatko nebo klasicke hodiny mi prislo infantilni a takova echt digitalni vec je pro me citac.</p><p>Puvodne jsem uvazoval jen o citaci citajicim jen cele tiky zakladnich hodin 200MHz. To se ukazalo jako pomerne trivialni. Nevim zda to mohu nazvat programovanim, ale napsal jsem si entity pro GATE AND, nejake FF, 32bit citac, delicku pro rizeni Gate a tyto entity pak graficky pospojoval. </p><p><br></p><p>Na domerovani me napadlo to co jsem popsal. Mozna to je hloupost. Chtelo by to zkratka zkusit a promerit oba oscialtory jednak jak se budou lisit a jak jak stabilni tento rozdil bude.</p><p>Bohuzel na to nemam vybaveni, tedy chybi mi neco jako SR620 :-) , nemam ani napad jak neco smysluplne zmerit s beznejsim vybavenim.<br></p><br><p>>Spotreba jakeho zapojeni?</p><p>Myslel jsem to vaseho reseni TTD s 6ps. Nebo obecne zpozdovaci linky v FPGA<br></p><p><br></p><p>Hutta</p><p><br></p><p><br></p><p><br></p><p><br></p><p>---------- Původní zpráva ----------<br>Od: Marek Peca <marek@duch.cz><br>Datum: 6. 8. 2012<br>Předmět: Re: Re: Citac s lepsi nez zemedelskou ns</p><blockquote>> Smyslem je seznamit se s FPGA a pronikdnout do problematiky :-)<br><br>Obavam se, ze malovanim kraslic se vajicka varit nenaucite.<br><br>> Reseni je minimalne o 2x15$ levnejsi nez rozladene veci od cinanu,<br><br>Co si predstavujete pod pojmem "rozladene"? Ze Cinan nastavil pole v <br>C-civce Rb hodin podle GPS, to mu mate za zle?<br><br>> Umoznuje merit i neopakujici se deje, narozdil od padesetileteho C a opet je<br>> o C a ADC levnejsi.<br><br>Nevim, kde interpolace nabijenim kondiku, jak ji dela asi polovina vyrobcu <br>techhle casomeru, selhava pri mereni "neopakujiciho se deje". Sosnete <br>prirucku k SR620 a ukazte mi, jaka funkce vam tam chybi.<br><br>> Cele se to vejde do radove desti CLB.<br><br>Mne se sumovy oscilator vesel do jedne 555 ;-)<br><br>Nechcete se vybodnout na chimery a udelat si prozacatek hezky jednoduse <br>treba desatero fazove rozjetych hodin a primitivne vzorkovat citac? <br>Dosahnete na rozliseni 250ps, realna presnost pri spravne kalibraci bude <br>dana timto rozlisenim, jitter pripadne PLL i D-klopnaku je hluboko pod <br>touhle hranici.<br><br>>> Vestavena PLL v FPGA v nasem pokusu mela single-shot jitter ~35ps RMS,<br>>> tohle bude mit nejspis mnohem vic.<br>><br>> Ja se nehadam neb nevim, jen si rikam, ze 2 x 4 prvky kousek od sebe na<br>> stejnem kremiku budou po dobu 1n, vuci sobe, nejspise mnohem lepsi nez 35ps<br>> RMS nebo taky ne a proto se ptam :-)<br><br>1. Ja se taky nehadam, jenom strasim. Kruh.osc. v FPGA zatim zmerenej <br>nemam a mozna jednoho dne mit budu, ale zatim o nem nevim nic a v cetbe <br>clanku to taky nema prednost (lec to by pro vas mohla byt dobra cesta, <br>ocividne mate casu nazbyt docela dost).<br><br>2. Zda se mi, ze v uvaze smesujete 2 ruzne veci. Sum oscilatoru a drift <br>parametru. Oboji se sice projevi v urcitem pohledu (PSD jitteru, <br>Avar/Mvar/Tdev) jako jedna a tataz velicina, ALE je tu urcity rozdil, jak <br>k temto porucham dochazi:<br>a) osc. se muze rozjizdet tim, ze dochazi teplem/starnutim k pomale zmene <br>parametru;<br>b) osc. je nahodile strhavan vlivy sumu, at uz elektronickeho (tepelny <br>sum), ci jinych vnejsich velicin (mechanika, magnetismus -- to se u <br>kruh.oscu v FPGA neuplatni).<br><br>V (a) mate pravdu, ze oba kruh.oscy budou litat kratkodobe velmi blizce <br>spolu; v (b) ale nikoli a o tom mluvim. Je-li osc jakostni, ma slabou <br>vazbu na okoli a nenecha se tolik strhnout. Kruh.osc. urcite bude na sum <br>hradel citlivej, jak moc, to uz je jina otazka. Ale ze tam nebude prilisna <br>korelace mezi sumem osc#1 a osc#2, to je skoro jiste. Ano, nejaka korelace <br>tam bude, treba vzajemne ruseni spickami na napajeni, ale to by vam leda <br>uskodilo, i kdyby to nahodou melo meritelny vliv.<br><br>> Na digitalni zpozdovaci linku to jiste nema, tuto problematiku hodlam<br>> prostudovat az v dalsi etape :-)<br><br>Tezko posoudim, ale zpozd. linka nam zatim pripada jako spravna cesta pro <br>digi implementaci. Minimalne co do opakovaci frekvence mereni, v ostatnich <br>parametrech si myslim, ze rozjizdejici se oscy muzou bejt dost dobry.<br><br>> Kdyz jste to nakousl, jaka je sporeba zdroju a kde nactu neco o teto<br>> problematice a jeji realizovatelnosti v necem jako Spartan 3?<br>> Tohle jsem vymyslel sam, zpozdovaci linku nevymyslim tu mohu max obkreslit.<br><br>Spotreba jakeho zapojeni?<br><br><br>Zdar,<br>MP</blockquote></body></html>