Jednokierunkowa bezstratna cyfrowa transmisja sygnału analogowego 10Hz-175kHz?

Tue Oct 03, 2006 9:37 pm   

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
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Tue Oct 03, 2006 10:51 pm   

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

Tue Oct 03, 2006 11:43 pm   

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

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?


--
| Bartlomiej Kuzniewski
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173

Wed Oct 04, 2006 6:25 am   

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

Wed Oct 04, 2006 8:33 am   

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

STV0191