kodowanie/kompresja danych, transmisja...

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...

Reply to
BartekK
Loading thread data ...

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
Reply to
Greg(G.Kasprowicz

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...

Reply to
BartekK
Reply to
Bogdan Gutknecht

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.