Kivezérlésmérő

Nagyon rég volt már programozásos téma, de most az "Internetet az autóba!" projekt kapcsán volt egy jó kis fejlesztés, amire érdemes pár szót elvesztegetni.
Az alapötlet akkor jött, mikor rendet raktam a fiókban :-), és az elfekvőben levő alkatrészek között találtam néhány MSGEQ7 típusú IC-t. Gőzöm sem volt, mi ez, mikor vettem, hol vettem, miért vettem... aztán egy gyors internetes keresés kiderítette, hogy ez egy 7 csatornás audio spektrumanalizátor. Mivel az internet elérés egyik lehetséges felhasználása a videók nézegetése "a legismertebb videómegosztó oldalon" ;-), és a tablet hangja az autóhifi AV bemenetére megy majd, kézenfekvőnek tűnt az ötlet, hogy ne csak fekete képernyőt kelljen az autórádión nézni, legyen egy jópofa kivezérlésmérő.

Az ötlet aztán elkezdett dagadni... és végül a következő koncepció állt össze: - egy-egy MSGEQ7 IC méri a jobb és a bal csatornát, - egy PIC mikrokontroller végzi a csatornánkénti értékek A/D átalakítását (az MSGEQ7 kimenete analóg), logaritmizálja a mért értékeket, és továbbítja a mért adatokat soros porton, - a beérkezett adatokat egy Raspberry PI számítógép dolgozza fel, és ez állítja elő a PAL képet. Nem kell mondanom, életemben nem programoztam Rapsberryt, de még a kezemben sem volt korábban. :-)

MSGEQ7 IC adatlap Microchip honlap Raspberry PI információk

A részletekről órákon át lehetne beszélni, de most csak két dologra szeretnék fókuszálni:
- az egyes elemek tesztelése,
- speciálisan a VU mérő fizikai modelljének szoftveres megvalósítása.

Tesztelés sok lépcsőben

Egy ilyen léptékű hobbifejlesztésnél már nagyon észnél kell lenni, ha nem akarunk kínkeserves órákat tölteni hibakeresgéléssel. Célszerű az egyes elemek fejlesztési sorrendjét is eszerint megválasztani.
1. Az elektronika megtervezése. Noha az áramkör lényegében csak "egy PIC meg két MSGEQ7", a panelen végül több, mint 30 (!) alkatrész kapott helyet. Ha megtehetjük, inkább tervezzünk hozzá nyomtatott panelt, néhány ezer forintért le lehet gyártatni tokkal-vonóval (forrasztásgátló lakkal, pozícióábrával), és az összehasonlíthatlanul szebb esztétika mellett sokkal kisebb kockázata van, hogy valamit elkötünk, mint egy raszterpanelen.
2. A mikrokontroller forráskód megírása. A legtöbb mikrokontroller gyártó remek fejlesztőeszközöket kínál, nekem egy jó pár éves Microchip IDE van otthon, remekül teszi a dolgát, és ami a legfontosabb: képes lépésenkénti szimulációra. Használjuk ki ezt, és addig ne kísérletezzünk élőben, amíg a szimuláció alapján azt nem gondoljuk, hogy már minden jól működik. Úgyis lesz még probléma elég. :-)
3. A grafikus felület megtervezése/megírása. Mindenképpen úgy írjuk meg a programot, hogy soros kommunikáció nélkül is tudjuk tesztelni, például véletlen adatokkal. Ha már minden remekül megy a képernyőn, akkor tegyük csak bele a soros kommunikációt, mint ki-be kapcsolható opciót.
4. Élesztés első lépés: tápegység. Triviálisnak tűnik, de kezdjük azzal, hogy ellenőrizzük a tápfeszültségeket mindenhol a panelen, mielőtt berakjuk a 3 IC-t.
5. Élesztés második lépés: soros kommunikáció a Raspberryn. Kössük össze a PI adás- és vétel kivezetését (mivel egymás mellett vannak a sorkapcson, egy jumperrel összezárhatjuk, és akkor nem kell forrasztani). Küldjünk ki egy olyan adatsort, amit a PIC-től várunk, és ellenőrizzük, hogy az adatfeldolgozás jól működik-e.
5. Élesztés harmadik lépés: A/D átalakítás működése, és soros kommunikáció a Raspberry és a PIC között. Az MSGEQ7 IC-k még mindig nem kellenek, mivel az olvasási protokolljukban nincsen visszajelzés, tehát akár egy sima potenciométert is beköthetünk a helyükre. Ha a potenciométer tekergetése közben változik a kivezérlésmérőn látott jelszint, akkor lehet, hogy valamit jól csináltunk. :-)
5. Élesztés negyedik lépés: az MSGEQ7 IC-k működése, és ennek tanulságai. :-) Tanulság az mindig van, kettő is: egyrészt az IC-k kimenetén a nulla szint nem 0 Voltnak felel meg (RTFM, ugye ;-)), másrészt a logaritmizálás a nulla közelében nagyon meredek, így minimális zajszint és/vagy kvantálási hiba is szép nagy kilengéseket okoz a kivezérlésmérőn. Ezt sokféleképpen lehet kezelni, mivel jelen esetben a hiteles mérés nem volt cél, ezért nemes egyszerűséggel feltoltam a nulla szintet annyira, hogy a zaj 90-95%-át elnyomja a mérés.
Ha idáig eljutottunk, akkor van egy működő rendszerünk, amit persze konstruktív kritikát előszeretettel gyakorló barátunk azonnal véleményez :-), és nekiállhatunk a szépítésnek, el is jutva a második témánkhoz.

Szoftveres VU mérő

Ahhoz, hogy szépen működjön bárminek a szoftveres modellje, szükséges, hogy legalább közelítőleg le tudjuk írni a működését. Esetünkben - ahogy már fentebb is írtam - a cél a látvány, nem a pontos mérés, ezért a hangsúly azon van, hogy a műszer úgy viselkedjen , mint egy valódi. Ezt fogjuk negvalósítani. A probléma két fő részre bontható:
- van hét darab logaritmikus értékünk, amik csatornánként tartalmazzák a jelszintet, mi viszont egy összesített jelszintet szeretnénk a műszeren megjeleníteni,
- a műszerben van egy rugóval felfüggesztett mutató, aminek van tömege, így nem lehet végtelen a gyorsulása, a sebessége, stb. Így a szimulációhoz nem elég tudnunk az aktuálisan megjelenítendő szintet, hanem tárolnunk és minden pillanatban újra kell számolnunk a mutató mindenkori mozgásállapotát. A dolog szépsége, hogy egy meglehetősen egyszerű modell is meglepően élethű viselkedést mutat.

Az összesített jelszint számítása azért nem triviális, mert logaritmizált értékeket nem lehet simán összeadni. Ehelyett először linearizálni kell, úgy elvégezni az átlagolást, majd az eredményt újra logaritmizálni. A megvalósítást a képen látható kódrészlet végzi. A 100-zal való osztás és szorzás jelentősége annyi, hogy a mért értékeket a PIC a 0..255 tartományra konvertálja, viszont így nem kell szerencsétlen számítógépnek kiszámolni az e255 nagyságrendű számokat. :-) Nekünk pedig azért hasznos, mert könnyebb ellenőrizni a helyes működést.

Nehezebb kérdés a mutató mechanikai modellje... de szerencsére nem sokkal. A következő modellt fogjuk használni: - eltekintünk a VU mérő skálájának nem egyenletes beosztásától, - a mutató "mozgástere" (a skála két végpontja között) 120 fok, - a mutatót rugó húzza vissza a nulla helyzetbe. A rugóerő alapállapotban nem nulla (a mutató le van feszítve), kitért állapotban a rugóerő egyenesen arányos a fokban mért kitéréssel, - a mutató gyorsulását a rugóerőn túl az határozza meg, hogy a jelenlegi pozíciója mennyire van távol attól, ahol a mért érték szerint állnia kellene, - a mutatónak van egy csillapítása, ennek hiányában vég nélkül rezegne a mért érték körül (a modellben ezt úgy valósítjuk meg, hogy a mutató két számítási ciklus között elveszti a sebességének adott százalékát).

Megjegyzés: az egyenes vonalú mozgás és a körmozgás megfeleltethető egymásnak, így a szövegben a gyorsulás a szöggyorsulást, a sebesség a szögsebességet jelenti stb.)
Mivel nem cél az, hogy SI mértékegységrendszerben számoljunk, megengedhetjük magunknak, hogy tetszőleges idő- és kitérés mértékegységet válasszunk. A legegyszerűbb, ha azt mondjuk, hogy az időegység a két képernyőfrissítés (illetve a modell két újraszámítása) közötti idő.

Ha így teszünk, akkor az idő mindenhol kiesik a képletekből, és a kitéréshez simán hozzáadhatjuk a sebességet, a sebességhez pedig a gyorsulást. A képletek ezáltal drasztikusan leegyszerűsödnek. A mutató viselkedését a fő paraméterek (rugóállandó, csillapítás, stb.) határozzák meg. Ha gyors követést szeretnénk, akkor annak az ára az lesz, hogy a mutató rezegni fog; ha az a cél, hogy ne lengjen ide-oda a pontos érték körül, akkor nagy csillapítást kell választani, ez viszont lassabb jelkövetést eredményez. A dolog innentől ízlés kérdése :-), mindenkinek magának kell az igényeinek megfelelő paraméterhalmazt összeraknia.

A működést lemodelleztem Excelben is, a működésről készült videó pedig felkerült youtube-ra.

Mutató szimuláció Excelben Kivezérlésmérő bemutató videó

A cikk utoljára frissítve: 2015.06.

Vissza a lap tetejére | Vissza a nyitóoldalra