Rigol 1052E - prevodniky

[balu@home]

tiez si dovolim nesuhlasit, vzorkovanie musi fungovatpresne aj keby boli 
na periodu len dve vzorky.
Ono to co sme namerali ma velmi velky pocet prispevkov, spomeniem len par:
- jitter hodin osciloskopu
- sum obvodov osciloskopu
- jitter hodin generatora
- sum a necistoty v spektre generatora

toto vsetko sa napocita dokopy. Nemyslim si ze fazovy sum osciloskopu je 
jediny a dominantny prispevok, lebo ked som porovnaval smernicu toho 
ziskaneho grafu so smernicou funkcie ENOB vs. jitter tak mame zhruba 
polovicnu hodnotu, t.j. nedegraduje to tak rychlo ako by malo keby bol 
jitter jediny prispevok.
Myslim, ze velky prispevok tam ma sum, tie vstupne zosilnovace zdaleka 
nie su idealne.
b.



On Dec/30/2010 9:51 PM, Ing. Peter Adamec wrote:
> "Proste pokud mi vyjde na jednu periodu 100MHz signalu treba 8 mereni
> (coz je dane samplovaci rychlosti bez ohledu na to jak kvalitni pristroj
> to meri) tak proste efektivne merim s vyrazne nizsim rozlisenim. To
> proste jinak dle meho vyjit nemuze. "
> Vyslovujem nesuhlas, rozlisenie prevodnika ma teoreticky zostat vzdy
> rovnake, ma to spocivat v tom ze ten sinus sa z toho zrekonstruuje tak
> ze mam danych 8 bodov v ktorych poznam presne hodnotu sinusu a poznam
> ako daleko su body od seba tak viem PRESNE kde mam ten sinus prelozit
> aby vyslo meranie s rozlisenim 8 bit.
>
> Problem pri tomto rigole je ten ze aj keby prevodniky merali celych 8
> bit tak cas v ktorom sa robia merania nie je presne definovany, vzhladom
> na to ze ten fazovy posun merani robi FPGA. Fazovy posun spustania track
> and hold +konverzie od jednotlivych prevodnikov nie je konstantny a tym
> padom NEVIEM jednoznacne povedat kde mam tu sinusovku prelozit.
> Efektivny pocet bitov si treba predstavit ako prelozenie sinusom o
> rozliseni ENOB tak aby to najlepsie opisalo namerane body.
>
> Odpoved na otazku preco sa ENOB pohybuje aj pri nizssich frekvenciach na
> cca 6 bit :
> jednoduche mily watsone, hodinovy signal je generovany FPGA, pre 8bit
> 100MSPS (co je zakladna frekvencia toho prevodnika) je potrebny jitter
> hodin tusim niekde na urovni 3ps (tak nejak sa mi zda ratal som to uz
> davnejsie).
> V kazdom pripade je to daleko daleko menej ako dokaze dat PLL v FPGA
> (byva radovo horsia). Pre 3ps je potrebne ZASADNE cistejsi zdroj
> hodinoveho signalu aby bolo PRESNE definovane kde ten prevodnik tu
> sinusovku sampluje.
>
> PA
>
>
>
> On 30. 12. 2010 8:37, RV wrote:
>> Ahoj, dik za obrazky...
>>
>> Kdyz na to ale koukam, tak s prominutim dochazim na to, ze to tak musi
>> vicemene dopadnout z principu veci.
>>
>> Proste pokud mi vyjde na jednu periodu 100MHz signalu treba 8 mereni
>> (coz je dane samplovaci rychlosti bez ohledu na to jak kvalitni
>> pristroj to meri) tak proste efektivne merim s vyrazne nizsim
>> rozlisenim. To proste jinak dle meho vyjit nemuze.
>>
>> Otazkou tedy zustava proc se pohybuje efektivni rozliseni kolem 6b i
>> pri nizsich frekvencich - kolem 6b se to pohybuje az do cca 20Mhz.
>> Duvodem muze byt sum, nekvalitni signal z DDS a nebo treba impedancni
>> neprizpusobeni (DDS byla propojena s rigolem koaxem bez sondy (1Mohm)
>> - bohuzel rigol nejde jednoduse prepnout/prekalibrovat na 50ohmu).
>>
>> Takze podle me zadne prekvapeni...zatim. Zkusim dneska sehnat jeste
>> ten BNC terminator a odmerit sum.
>>
>> Radek Vicek
>>
>> Dne 30.12.2010 0:41, balu na home napsal(a):
>>> Vysledky vyzeraju realisticky, ale zavery z tejto analyzy robit nebudem
>>> lebo neviem nezavisle overit ci su vysledky spravne.
>>> b.
>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>