A/D prevodnik a komprimator

Ing. Vladimír Anděl vaelektronik
Středa Březen 17 11:50:22 CET 2004


To ja bych navrhoval daleko jednodussi reseni. Ta telefonni ustredna se mi
moc libi, jen ji to chce zautomatizovat. Co tedy tim datovym pojitkem ridit
provoz dadiostanic (napr. na 4 kanalech na CB, ale pasem s generalnim
povolenim je vic) a rikat jim na ktery kanal se maji prepnout a kdy ma ktera
vysilat. Urcite by to vyslo levneji, nez delat ten strasny vyvoj.

Andel

Nechci vam kazit radost, ale na takovouto kompresi je potreba DSP.
Nejake hotove obvody se delaji, ale myslim, ze pro uvedene pouziti nevyhovi
z hlediska ceny a dostupnosti.
napr. http://www.audiocodes.com/
         http://www.dspg.com/prodtech/ct/main.htm
         http://www.dvsinc.com/


>nerikam, ze to co tady uvedu by mohlo nejak pomoci k reseni, ale snad aspon
>neco... to zavisi od vypocetni slozitosti - zadny integrac, ktery tohle
dela
>neznam,ale pri trose namahy se da pouzit stejny algoritmus jako v gsm, tedy
>vypocet LPC koeficientu z nejakeho kratkeho casoveho useku. Funguje to tak,
ze
>se vezme casovy interval - rekneme 20ms, vypocitaji se z nej LPC (linear
>prediction coeffs... nebo tak nejak) koeficienty - pocet tech koeficientu
>ovlivnuje kvalitu reci a delku prenasenych dat, pak se prenesou ty LPC a
cast
>recoveho signalu a na zaklade znalosti techto dvou prenesenych udaju se da
s
>jakousi pravdepodobnosti vypocitat puvodni recovy signal. komprese je to
>samozrejme ztratova - jestli se ji vubec da rikat komprese. ale v nejakem
>rozsahu se to vyuziva v GSM. ta data by se mohla zpracovavat nejakym
>jednocipem, myslim, ze aduc812 od analog by se dal - navic ma integrovane
ad/da
>prevodniky....

>d.


>"Zíka Aleš, Ing."@regina.gin.cz wrote:

>         Zdravim vsechny,
>
>         potreboval bych nejaky obvod, ktery dokaze zkomprimovat hlas tak
aby
> se dal protlacit seriovou linkou rychlosti max. 19200 kbps, lepe 9600 nebo
> 4800, nejlepe s integrovanym A/D prevodnikem, a pak opacny obvod, ktery by
> to dokazal na druhe strane zase rozbalit a prehrat, proste neco jako je v
> mobilech. Na kvalite prilis nezalezi, bude to jen pro hlas, klidne staci
> tzv. "telefonni kvalita".
>
>         Mozna ale nekdo prijde na uplne jine reseni nez my, tak to radeji
> popisu kompletne, omlouvam se za delsi mail:
>         Vyhodnocujeme zavody ve vodnim slalomu - kanoe, kajak - podel
trati,
> delka tak 200 az 500 m je rozmisteno zpravidla 8 az 12 stanovist
brankovych
> rozhodcich, kteri zavodnikum pocitaji trestne body za minuti nebo dotyk
> branky. S temito rozhodcimi my mame hlasove spojeni do centra, kde obsluha
> zadava body programu, ktery zaroven bere udaje o case z casomiry a pocita
> vysledky. Provoz pak vypada tak, ze u terminalu sedi zadavac bodu, vybere
si
> jednu jedouci lod a postupne se pripojuje na 1. az posledni stanoviste
> rozhodcich a pta se jich na tresne body na jednotlivych brankach a zadava
je
> do pocitace, az skonci, vezme si dalsi lod a jede znova, porad dokola.
> Vetsinou jsou tito zadavaci dva pricemz se muzou nezavisle na sobe
> pripojovat na jednotliva stanviste, pak se to stiha v realnem case. Mame
na
> to zarizeni vlastni konstrukce, takovou jako telefonni ustrednu, ktere je
> chopne obslouzit az 14 stanovist rozhodcich a 4 operatory, teda spojit
ctyri
> nezavisle hovory, je to mirne predimenzovane, v praxi jsme ho naplno nikdy
> nevyuzili (i kdyz obcas se hodí, kdyz jsou nejake nejasnosti, ze se zapoji
> treti operator, resi s rozhodcimi problem, a zbyli dva mohou dal zadavat a
> nezpozduji se za lodema).
>         Pak je tam jsete hlasove spojeni casomeric se startovním a cilovym
> rozhodcim, impulsy z fotobunek do casomiry a datova spojeni s vysledkovou
> tabuli, televizi pro titulky a terminalem, ktery prubezne zobrazuje
vysledky
> pro komentaora, ale to uz je na uplne nezavislem zarizeni.
>
>         No a problem je v tom, ze kvuli tomuhle vsemu musime vzdycky pred
> zavodem roztahat podel trati nekolik set metru kabelu, coz nam trva pul
dne,
> a po jeho skonceni to zase minimalne tri hodiny balime (trati je totiz po
> republice asi deset, my tam vzdycky prijedem, rozbalime to, odmerime,
> sbalime a zase odjedem). To nas celkem stve, nehlede na to, ze nam cas od
> casu nejaky divak rozkopne spojku nebo prerve kabel, takze bysme radi
presli
> na bezdratove spojeni.
>         Docela nas navnadil DECT modul MD32 od SIEMENSe. Je to modul,
ktery
> muze pracovat v nekolika rezimech - GAP, pak se chova jako sluchatko u
> bezdratoveho telefonu; FP (fixed part), PP (portable part), kdy je mozně
> vytvorit point-to-point spojeni mezi FP a PP, ktere se tvari jako seriova
> linka, maximalni rychlost 19200 kbps; a konecne FP-server, kdy je mozne se
> pripojit az k 16 PP, pricemz muze soucasne probihat komunikace az se 4 z
> nich (19200 kbps se pak samozrejme deli mezi ne), na strane FPserveru - PC
> je pouzit jakysi jednoduchy protokol, ktery dava packetum hlavicky, aby FP
> vedel na kterou PP to patri. Jenze podle poslednich zprav od SIEMNSE se
jim
> ta kombinace data + GAP nejak vymkla, takze to zatim umi jen data, ne
hlas,
> pro ten bude vyvinutej nejakej novej modul, a navic asi bude potebovat
> zakladnu z Gigasetu (ta nam nestaci, ptotoze umi pripojit jen 6 PP).
>
>         Takze nas napadlo pouzit datovy DECT v rezimu FP server s tim, ze
> prevod hlas -> data a naopak si musime udelat kompletne sami. Aby se pres
> FP-server daly protlacit dva hovory soucasne, potrebovali bysme to stlacit
> na nejvys 9600 kbps. Vlastne jeste o neco min, protoze je nutny dolepit k
> packetum ty adresovaci hlavicky, takze by se sikla nejaka komprese s
> promennym datovym tokem, nejvyse vsak 9600 kbps. Stejne si to zatim
nedokazu
> moc predstavit, budeme tam muset ubastlit nejakej jednocip, kterej bude
> sbirat dve linky 9600 a michat to do jedny 19200...
>         Takze shanime neco, co by nam ten hlas co nejlevneji prevedlo na
> seriovou linku.
>
>         Pokud nekoho napada uplne jine reseni, sem s nim! Jeste jednou to
> shrnu: Máme nejvyse 12 stanovist rozmistenych na (zhruba prime) trati max.
> 500 m dlouhe (typicky tak 200 az 300 m) a ridici pracoviste, ktere taky
lezi
> pobliz trati, a z tohoto ridiciho pracoviste potrebujeme vest minimalne
dve
> hlasova spojeni soucasne s libovolnym z tech 12 stanovist (kdyz budou
mozna
> tri spojeni, tim lepe). Nepotrebujeme spojeni mezi temi stanovisti
vzajemne
> (neni to uplna telefonni ustredna), zadne velke naroky na kvalitu. Hodil
by
> se broadcast - spojeni se vsemi stanovisti soucasne (napr. rict vsem
> rozhodcim najednou, ze je po protestnim case a muzou to sbalit), ale neni
> nutny.
>
>         Diky za kazdy napad!
>
>                         Ales Zika
>                         Pelhrimov
>
>                         e-mail: Ales.Zika@pel.cb.ds.mfcr.cz
>                                   Ales.Zika@seznam.cz
>                         SMS:    Ales.Zika@sms.underground.cz










Další informace o konferenci Hw-list