Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoalap|MeresLabor1ZH2k8}} vissza a Mérés 1 tárgyhoz ---- ====ZH 2008==== * {{InLineFileLink|Infoalap|MeresLabor1ZH2k8|meres1_ZH_…”

2012-10-21T20:03:09Z

Új oldal, tartalma: „{{GlobalTemplate|Infoalap|MeresLabor1ZH2k8}} vissza a Mérés 1 tárgyhoz ---- ====ZH 2008==== * {{InLineFileLink|Infoalap|MeresLabor1ZH2k8|meres1_ZH_…”

Új lap

{{GlobalTemplate|Infoalap|MeresLabor1ZH2k8}}

vissza [[MeresLabor1|a Mérés 1 tárgyhoz]]
----

====ZH 2008====
* {{InLineFileLink|Infoalap|MeresLabor1ZH2k8|meres1_ZH_20081211.zip|meres1_ZH_20081211.zip}}: A 2008. 12. 11. Mérés 1. ZH (aka Írásbeli EM) scannelve.

==Megoldások==

'''Ezeket valószínűleg át kellene nézni.'''

===1. feladat===

a) Mivel rendelkezésünkre áll a baudrate engedélyező jel, és tudjuk, hogy a UART TX vonala ennek hatására vált a

következő bit küldésére, ÁLLAPOTANALÍZÍS módot használunk, mert így biztos elkapunk minden állapotot, és nem

pocsékoljuk az állapotmemóriát sem.

b) A mintavételező órajel legyen a baudrate engedélyező jel LEFUTÓ éle, mivel ezután már biztos stabil az adat. (A

felfutásánál léptetjük a shiftregisztert, adjuk ki a következő bitet)

c) A trigger feltétel legyen a TX vonal LEFUTÓ éle, mivel minden frame START bittel kezdődik, ennek értéke pedig 0.

===2. feladat===

t = 70 ns

f = ?

Ha pontos mérést akarunk végezni, akkor fontos minél nagyobb frekit használni. Nagyobb frekvencián kisebb az abszolut

tévedés --> a relativ hiba is.
Viszont csak 256 mintát tudunk tárolni, fontos, hogy a 70ns idő alatt NE teljen be az állapottár.

Ha másodpercenként f mintát tárolunk el, akkor a minta "ideje" 1/f.

Tehát 256 * 1/f > t ==> f < 3,6 Ghz. Mivel ezt teljesíti mindegyik frekvencia, a legnagyobbat, 400 MHz-et

használjuk.

b)

Relativ hiba: abs(1 - mert idő / valós idő).
400 Mhz-en vagy 77.5, vagy 80 ns-ot mérünk, ezekben az esetekben a relativ hiba:

1 - 77.5 / 79 = 1,9 %
80 / 79 - 1 = 1,2 %

===3. feladat===

Egy olyan kombinációt keresünk, ahol X a felelős y kimenetért, és x-nek 1 kellene lenni.
Pl. a = 0, b = 1 (x=1)
c=0 y=1

Itt ha y=0 lesz, tudjuk, hogy az x hibás.

===4. feladat===

mivel a harmadik számlálónak az engedélyező bemenete pont a rcy volt (Elég kár, hogy ezt fejből kellett tudni...

Gyakorlott embernek nyilvánvaló, de nem mindenkinek!), ezért, ha a rcy 0-ba ragad, az soha nem fog felfele számolni,

ergo csak az első két számjegy számol.

===5. feladat===

FIGYELEM! Az uart LSB first módban küldi az adatokat (jobbról balra olvassa a számokat!!!!).

-10 = 0.5 * D - 50 => D = 80 = 8b01010000

Frame format: START | D0 || D1 || D2 || D3 || D4 || D5 || D6 || D7 STOP.

Tehát: 0 | 0 || 0 || 0 || 0 || 1 || 0 || 1 || 0 1.

b)

Valamit kiszamoltam, egyaltalan nem vagyok biztos benne, inkább skippelem.

-- [[KoczkaTamas]] - 2009.12.08.
Én is kiszámoltam valamit, le is írom :)

Kívül -10 fok van, ez a 25 fokhoz képest 35 fok eltérés, így a szenzor a 0.3%/C hőmérsékletfüggése miatt 0.3% * 35 = 10.5%-kal tér el.

Belül 23 fok van, ez a 25 fokhoz képest 2 fok eltérés, így a műszerfalba épített vezérlő a 0.05%/C hőmérsékletfüggése miatt 0.05% * 2 = 0.1%-kal tér el.

Ha a legrosszabb esetet vesszük, akkor ezek egymáshoz való eltérése 10.6% órajelenként.

19200 baud = 19200 bit per sec => Bitidő = 1/19200 = 52us

Így pl a következő időpontokban küldünk biteket (a számítás a start bit lefutó élétől kezdődik):
<pre>1:0-52us; 2:52-104us; 3:104-156us; 4:156us; 5:208-260us; 6:260-312us; 7:312-364us; 8:364-416us</pre>

Ekkor a mintavételezésnek ilyenkor KELLENE történnie (pont a bitidő közepén):
<pre>1:26us; 2:78us; 3:130us; 4:182us; 5:234us; 6:286s; 7:338us; 8:390us</pre>

Ha az órajelek 10.6%-kal eltérnek, akkor a bitidő is 10.6%-kal tér el (?): szóval 57.5us lesz.

Így a mintavételezés ekkor FOG történni:
<pre>1:29us; 2:86us; 3:144us; 4:201us; 5:259us; 6:316us; 7:374us; 8:431us</pre>

Látszik, hogy a 6. bit mintavételezése, ami 316uskor történik az igazából a 7. bit 312-364us-ébe esik bele, tehát a 6. bit helyett már a 7-et mintavételezzük, a 6-os bit teljesen kimarad a számból.

Igazából úgy is kiszámolható, hogy a bitidő 50%ot csúszhat (mert középen mintavételezünk, ezért akkor romlik csak el az eredmény, ha átcsúszunk a következő vagy előző bitbe, ami 50%os csúszást jelent). És akkor 50%/10.6% = 4.7 bitidőnél lesz hibát okozó a késés.

A mintavételezés mindig 0.5ös bitidőnél történik, a következő módon: 1->0.5kor, 2->1.5kor, 3->2.5kor, 4->3.5kor, 5->4.5kor, 6->5.5kor...

Látszik, hogy 4.5 < 4.7, tehát az még pont jó lesz, de a 5.5 > 4.7 már nem...

Szumma: nem tudja értelmezni a műszerfal a szenzor üzenetét.

''ha ez így rossz, akkor valaki, aki tudja igazán leírhatná hogy van ez igazából, mert senki sem tudott a 'bitidő mennyivel késhetes' kérdésekre válaszolni''

===6. feladat===

1 Mhz ==> 1 bit = 1/1000000 = 1 us

I2C kommunikácio: Start feltetel, ADDR + R/W, (N)ACK , BYTE1 , (N)ACK , BYTE2 , (N)ACK , Stop feltetel.
Bitek szama : 1 / 2 , 7 + 1 , 1 , 8 , 1 , 8 , 1 , 1/2
Total: 28 bit == 28 us

Start feltetel: SCK magas allapotában az SDA lefuto ele.
Stop feltetel: SCK magas allapotában az SDA felfuto ele.

===7. feladat===

===="A" változat====

=====Idődiagramm=====

{{InLineImageLink|Infoalap|MeresLabor1ZH2k8|mrspme1_TBW.jpg}}

=====Szintetizált kapcsolás=====

{{InLineImageLink|Infoalap|MeresLabor1ZH2k8|mrspme1_rajz.jpg}}

===="B" változat====

=====Idődiagramm=====

{{InLineImageLink|Infoalap|MeresLabor1ZH2k8|mrspme2_TBW.jpg}}

=====Szintetizált kapcsolás=====

{{InLineImageLink|Infoalap|MeresLabor1ZH2k8|mrspme2_rajz.jpg}}

==Javítói észrevételek==

Szántó Peti nem örült a kihozott, bescannelt ZH-nak. Nem érdemes túl sokat kihozni, mert a ZH-feladatokra a következő kritériumok teljesülnek:

* nem lehet lényegesen könnyebb, mint az előző
* nem lehet ugyanolyan, mint a webről letölthető, mert akkor a tudásotokat nem méri fel (copy&paste)
* azonos szintű feladatokból véges mennyiségű van
* kreatívak vagyunk

Aki tud gondolkodni, az levonhatja a tanulságot.

A javítással kapcsolatos észrevételek (nem megoldások!):

1. Állapotanalízist eltaláltátok, viszont 256 minta miatt nem szabad az 50MHz órajellel, hanem 4800 MHz-es baudrate-tel (2-es mérésen ugyanígy vizsgáltuk a számlálót).

2. A legpontosabb méréshez '''nem''' az számít hogy mi a Shannon-törvény értelmében '''elegendő mintavételi freki''' , a minél pontosabb méréshez '''minél nagyobb felbontás''' kell. A mérés relatív hibája pedig nem 2.5/79.

3.
C=1 -> pont eltakarja a hibát a kimeneten

XOR kapu felismerése általában megy, de az igazságtábla nem: a==b NEM 1 értéket ad, pedig kimenetén az s-a-0 felderítéshez az kell.

4.
NEM áll meg a számláló 99-nél. 
A sorszámozás nem volt egyértelmű, 1. digit általában az alsó helyiérték. 
Szó nem volt hétszegmenses kijelzőről, de ha lett volna, sem aludna ki a felső 2 digit, hanem 0-t mutatna. 
Nincs olyan egy számláló RCY kimenetén, hogy „nem ad ki bitet” – a kimeneten 0 vagy 1 van és slussz.

5.
Bináris <-> decimális átváltás, egyszerű egyenletek rendezése? Általános iskolás és középiskolás alapok erősen hiányoznak a hallgatók 20-30%-ánál. (Helyesírásról nem beszélve.)

6.
Keretformátum ismerete nem árt 
Mértékegységek: ms <-> us <-> ns 
UART vs. I2C gyakran keveritek. 
Start-stop fel/lefutás felcserélve.

8.
Always blokkon belül assign NINCS 
Magát az algoritmust nem ismeritek, pedig használjátok mérésen többször. 
Wire-nak assign-nal, regiszternek always blokkban kell értéket adni.

-- [[SzellAndras|Bandita]] - 2008.12.12.

==Miért nem érdemes ZH-t kihozni?==
{{InLineImageLink|Infoalap|MeresLabor1ZH2k8|zh.png}}

[http://xkcd.com Eredeti: xkcd.com] és a [http://xkcd.com/155 folytatás] :)

[[Category:Infoalap]]

Mérés laboratórium 1, 2008-as ZH - Laptörténet

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoalap|MeresLabor1ZH2k8}} vissza a Mérés 1 tárgyhoz ---- ====ZH 2008==== * {{InLineFileLink|Infoalap|MeresLabor1ZH2k8|meres1_ZH_…”