kodowanie/kompresja danych, transmisja...

BartekK - 03-10-2006 23:45
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...

--
| Bartlomiej Kuzniewski
| http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Greg$G.Kasprowicz$ - 04-10-2006 01:45

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

BartekK - 04-10-2006 01:45

Greg(G.Kasprowicz) napisał(a):
>> 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
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?
> 2 ARMy maja chyba wystarczajaca moc obliczeniowa by to tanio zrobic.
> Moznaby nawet kompresowac w locie
Tak tez chce wlasnie zrobic, akurat czekam na LPC2148 i zobaczymy...

--
| Bartlomiej Kuzniewski
| http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Bogdan Gutknecht - 04-10-2006 08:45

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

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?

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

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.

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

To po 1,5 bita zakłócenie się kończy. Poza tym może jakiś filterek przed
dekoderem Manchestera?

>
> Transmisja nadmiarowa jest mozliwa, ale i tak przy probkowaniu np
> 200Khz*(12bit + crc + bit startu + przerwa miedzy paczkami)- wychodzi
> pasmo prawie 8-10MHz...
>

Przez CRC zafundowałeś sobie taki nadmiar informacji, z której niewiele
wynika, że nie narzekaj na brak pasma.

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

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

PAndy - 04-10-2006 10:45

"BartekK" <sibi@drut.org> wrote in message
news:eful92$7f7$1@nemesis.news.tpi.pl...

STV0191