[csidc:2004] - MUSIC & Minimum variance algoritmi by "Dusan Grujic" <grujic@europe.com>

Cao.

Ispravio sam gresku na Plonu. Inace, imam problema pri koriscenju Plona. Ne znam da li je u pitanju bag ili ne, ali kada udjem u neki direktorijum nema opcija za brisanje ili modifikaciju fajlova. Drugo, kao se uopste fajlu daje status published?

Sto se tice sastanka u sredu, necu moci da dodjem, jer u to vreme imam laboratorijske vezbe (12-17h). Postoje 3 mogucnosti: da ne dodjem na sastanak, da odlozimo za posle 17h ili pre 12h. Pricao sam sa Caslavom i njemu bi odgovaralo pre 12h. Bilo bi lepo da se svi izjasnite po ovom pitanju.

Napravio sam novi m fajl koji ne koristi funkciju hilbert, vec samo fft. Nova funkcija se zove music2.m, i odredjuje ugao po music i minimum variance algoritmima. Funkcija prepoznaje 2 signala, ciji su dolazni uglovi u promenljivama th i th2. Uglovi th i th2 su u radijanima, odnosno 23*pi/180 (23 je ugao u stepenima). Pretpostavlja se da su th i th2 u intervalu od -pi/2 do pi/2 tj. -90*pi/180 do 90*pi/180. Veci uglo vi nemaju fizickog smisla, pa se dobijaju besmisleni rezultati. Ne znam zbog cega se dobijaju 2 maksimuma za jedan signal, ali to ne bi trebalo tako da bude. Probaj novu verziju. Ako menjas broj signala, promeni i broj sopstvenih vrednosti koje se uzimaju za racunanje u poslednjoj petlji (k=1:2 za 2 signala, k=1:3 za 1 signal - ovo bi inace trebalo da se radi u samom algoritmu, tj. da on procenjuje broj prisutnih signala, ali to ce biti uradjeno u sledecoj iteraciji).

Zbog prisustva suma (awgn) izlaz pri uzastopnim pozivanjem music2.m ce biti razliciti, sto je i ocekivano usled slucajne prirode Gausovog suma. Zbog toga uglovi bliski -90 i 90 stepeni mogu biti pogresno prepoznati za 180 stepeni (tj. -90 stepeni kao 90 i obrnuto). Medjutim, i mnogo ozbiljniji sonari pate od ovog nedostatka (na primer SIMRAD E3000 koji ima 80 mikrofona!). Mozda se ovaj efekat moze umanjiti ako se d/lambda smanji ispod 0.5, mada je to tesko izvodljivo jer je i pri d/l=0.5 rastojanje d izmedju mikrofona oko 3mm.

Da bi se koristila ova funkcija mora postojati i funkcija sfbsmooth koja radi forward-backward smoothing. Odradio sam i funkciju sfsmooth koja radi samo forward smooth, a obe funkcije su postavljene na Plone. Iako se trenutno koristi sfbsmooth, mozda bi bilo bolje da se koristi sfsmooth, jer ona umanjuje red matrice R za 1. Posto imamo 4 mikrofona, nijedna funkcija ne moze da odvoji vise od 2 signala, pa se sa sfsmooth dobija nizi red matrice za koju je potrebno izracunati sopstvene vrednosti, odnosno inverziju za minimum variance algoritam.

Broj kanala se moze vestacki povecati. Mozemo svaki kanal da podelimo na n opsega i da izlaz mikrofona ogranicimo da za maksimalnu vrednost upada u jedan opseg. Ako se pojedinim izlazima doda odgovarajuci ofset (vrlo jednostavno uz pomoc operacionog pojacavaca), moze se dobiti da jedan kanal meri n mikrofona odjednom, cime je uvecan broj mikrofona. Ovo ima smisla samo ako ADC ima veliku rezoluciju, tako da se efektivno umanjuje rezolucija ADC, ali se povecava broj kanala.

Dosta sam razmisljao o undersampling-u. Trebalo bi ozbiljno razmotriti i ovu opciju, jer se njom moze znacajno smanjiti broj racunskih operacija, tako sto se izabere perioda odabiranja da se za vreme trajanja jednog pinga dobiju odbirci (>4 odbirka po periodi) iz 2 periode, tako da se u jednom bloku sigurno dobiju odbirci iz cele periode.

Sta treba uraditi:
1. Prilagoditi postojeci music i minimum variance algoritam za blokovsku obradu primljenih podataka, tj. da se matrica dolaznih podataka obradjuje u manjim blokovima. Matrica m u trenutnom algoritmu je primer jednog bloka.
2. Odraditi funkciju koja ce generisati podatke koji bi se dobili sa senzora.

Pozdrav,
Gruja

--

___________________________________________________________
Sign-up for Ads Free at Mail.com
http://www.mail.com/?sr=signup