kodowanie/kompresja danych, transmisja...

Oct 03, 2006 4 Replies

Walcze od pewnego czasu ze zrobieniem jednokierunkowej bezstratnej transmisji sygnalu analogowego w postaci cyfrowej. Teoretycznie proste? Sygnal analogowy ma parametry pasmo 10Hz - 150kHz (a najlepiej z 175kHz conajmniej), dynamika ~70dB. Po stronie analogowej robie preemfaze - zeby nie bylo problemow z malymi sygnalami o wysokiej F. Tor przesylu jest w zasadzie "gruba rura" - bo 10Mbit puscic to nie problem. Pracuje w zakresach 10-12GHz, i to jest zrobione i powiedzmy ze nie ma tu problemow z czescia radiowa. Narazie kombinuje (bycmoze pod gore):



- przetwornik A/D 12bit (wystarcza przy tej dynamice), z tego co przetwornik wygeneruje (12bit) obliczam CRC (narazie na procku, ale przy pelnej predkosci ciezko bedzie...), wszystko razem trafia do rejestru przesuwajacego rownoleglo-szeregowego, skad jest wysylane szeregowo (przez koderek manchesteru). Przesylanie odbywa sie paczkami - sa 2 rejestry przesuwajace, raz z jednego przesuwam i wysylam, a w tym czasie przetwarzam A/D, laduje do drugiego wynik przetwarzania i crc licze, a za chwile odwrotnie. Wysylanie "ramki" danych + crc odbywa sie cyklicznie, pomiedzy wyslaniami jest przerwa okolo ~ 4-5 bitow (wtedy "nosna" manchesteru nie leci!). Pierwszy bit ktory jest wyslany to zawsze 0 - dzieki temu zawsze manchester zaczyna sie od tego samego zbocza.



- z drugiej strony jest odbiornik: a) detektor nosnej - jesli nie ma nosnej W.cz. to wogole wszystko jest zablokowane b) dekoder manchesteru - najwieksza moja zmora i jego synchronizowanie - gdy znika clk z sygnalu (brakuje 3 lub wiecej clk, czasowka...), licznik "numeru bitu" jest zerowany. Pierwsze zbocze opadajace oznacza odebrane zero i startuje generator taktujacy licznik "bitow" ktory odtwarza sygnal manchester na postac szeregowa, co trafia do rejestru szeregowo-rownoleglego. Jak licznik bitow doliczy do konca - to liczone jest CRC - jesli sie zgadza, to zawartosc rejestru trafia do przetwornika D/A (+deemfaza i wyjscie analogowe). Jesli CRC sie nie zgadza - to nic nie trafia do D/A i D/A trzyma nadal wynik poprzedniej transmisji.



No i tutaj wychodzi lista problemow... Zaklucenia sie zdarzaja - i dosc czesto trafiaja sie pakiety uszkodzone. Czesto licznik bitow zeruje mi sie z niewiadomych przyczyn (zaklucenie zjada pare CLK i juz zgubiony caly pakiet) albo startuje mi za wczesnie (jesli w trakcie "ciszy" miedzy paczkami trafi sie jakies zaklucenie przyjete jako pierwszy bit)



Transmisja nadmiarowa jest mozliwa, ale i tak przy probkowaniu np



200Khz*(12bit + crc + bit startu + przerwa miedzy paczkami)- wychodzi pasmo prawie 8-10MHz...

Moze to wszystko zle robie? Moze trzeba by wymyslec lepsze kodowanie danych, by dalo sie odzyskiwac nawet z uszkodzonych paczek cos? (tylko jak przy takim bitrate wysokim?) Bardzo by mi zalezalo by dalo sie np zrobic transmisje odporna na zaklucenia - by przy wzroscie gubionych paczek spadala tylko jakosc sygnalu, lub jego pasmo zostawalo obciete (awaryjnie przez 1-2sekundy to nawet pasmo do 5kHz mi wystarczy) a nie powstawala przerwa w calej transmisji...


a mzoe zrobic cos z oparciu o standardowy sprzet? puscic TCP/IP po tym, uzyc scalakow do ethernetu optycznego? wbrew pozorom nie ejst to secjalnie skompliowane, sa gotowe bloki funkcjonalne

2 ARMy maja chyba wystarczajaca moc obliczeniowa by to tanio zrobic. Moznaby nawet kompresowac w locie

Greg(G.Kasprowicz) napisał(a):

Niestety radio to jest koniecznosc (odleglosci kilka-kilkanascie km w gestej zabudowie, ale jest widocznosc optyczna). TCP/IP odpada bo transmisja jest jednokierunkowa, a wysylanie "w slepo" po udp niczego mi nie poprawi. Chyba ze sie nie rozumiemy do konca?

Tak tez chce wlasnie zrobic, akurat czekam na LPC2148 i zobaczymy...

Zamiast crc dla ka¿dych 12 bitów zastosowa³bym jaki¶ inny kod daj±cy mniejszy narzut i umo¿liwiaj±cy naprawê b³êdów, mo¿e Hamming? Mo¿e nawet proste powtórzenie?

Dlaczego a¿ trzy? Po up³ywie 1,5 bita je¶li jest przerwa to wiadomo, ¿e nie pozostaje nic innego jak odrzuciæ dotychczasowy wynik. Zbyt d³ugi czas reakcji powoduje zamaskowanie dobrej transmisji prze krótkie zak³ócenia przed jej pocz±tkiem.

To po 1,5 bita zak³ócenie siê koñczy. Poza tym mo¿e jaki¶ filterek przed dekoderem Manchestera?

Przez CRC zafundowa³e¶ sobie taki nadmiar informacji, z której niewiele wynika, ¿e nie narzekaj na brak pasma.

Generalnie podej¶cie do problemu zale¿y od tego ile b³êdów transmisji siê trafia - inaczej wyglada sprawa w niepewnych kana³ach, a inaczej w ma³o zak³óconych. Je¶li chcesz przesy³aæ d¼wiêk to zastosuj jak±¶ prost± kompresjê stratn± d¼wiêku, dodaj kodowanie korekcyjne i mo¿e powtarzanie informacji. Dla w miarê niezawodnego kana³u powinno wystarczyæ.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required