Jarosław Bułat, Tomasz P. Zieliński Michał Babiuch, Ernest Biela, Szymon Dąbrowski, Piotr Jaglarz, Adrian Karbowiak, Sebastian Leśniak, Rafał Palej, Kacper Patro, Michał Rybczyński, Dawid Rymarczyk, Michał Rzepka, Krzysztof Szczęsny, Wojciech Szmyd, Paweł Szulc, Jan Twardowski, Łukasz Wysogląd, Kacper Zych Akademia Górniczo-Hutnicza, Katedra Telekomunikacji Al. Mickiewicza 30, kwant@agh.edu.pl, tzielin@agh.edu.pl,

„ZRÓB TO SAM”: KOMPUTEROWY ODBIORNIK RTL-SDR RADIA CYFROWEGO DAB+

Streszczenie: Taniejącą technologię radia zdefiniowanego programowo (Software-Defined Radio) można obecnie z powodzeniem wykorzystać do nauczania podstaw teleko-munikacji cyfrowej według scenariusza „zrób to sam”. W artykule opisano algorytm dekodera radia cyfrowego DAB+ (Digital Audio Broadcasting), które jest obecnie wprowadzane w Polsce, oraz przestawiono jego implemen-tację programową w języku C++ (bez użycia biblioteki GNU Radio), działającą na komputerze PC z systemem operacyjnym Linux. Implementacja ta została stworzona przez studentów teleinformatyki w ramach projektu „Ra-dio programowalne w praktyce”. Przetwarzane są dane IQ, pobierane bezpośrednio z przetwornika A/C tunera DVB-T RTL2832U firmy Realtek, pracującego na złączu USB 2.0.

1. WSTĘP

Ponieważ technologia radia zdefiniowanego pro-gramowo SDR (and. Software Defined Radio) ostatnio znacznie potaniała, możliwe staje się jej szerokie wyko-rzystanie, w tym także do nauczania podstaw telekomu-nikacji cyfrowej według scenariusza „zrób to sam”. W artykule opisano algorytm dekodera radia cyfrowego DAB+, które jest obecnie wprowadzane w Polsce, oraz przedstawiono jego implementację programową w języ-ku C++, stworzoną w ramach wieloosobowego projektu studentów kierunku Teleinformatyka AGH, zatytułowa-nego „Radio programowalne w praktyce”. Co ważne, w projekcie tym nie wykorzystywano funkcji z bardzo popularnej biblioteki GNU Radio, zdecydowaną więk-szość kodu napisano samodzielnie (poza funkcjami algo-rytmów: FFT, dekodera Reeda-Salomona oraz dekodera HE-AAC v2 sygnału audio), Program działa w czasie rzeczywistym na komputerze PC z systemem operacyj-nym Linux i przetwarza dane IQ, pobierane bezpośred-nio z przetwornika A/C tunera DVB-T RTL2832U firmy Realtek (koszt około 50 złotych). Jego kod można po-brać ze strony: sdr.kt.agh.edu.pl.

W literaturze polskiej technologia SDR jest omó-wiona w książce [1], ale głównie w aspekcie istniejących drogich platform sprzętowych, umożliwiających jej implementację. W ww. monografii opisano w ujęciu systemowym (technologie, standardy) tzw. radio kogni-tywne, czyli „inteligentne” radio SDR, adaptacyjnie dopasowujące się do zmiennego otoczenia elektroma-gnetycznego (poprzez jego „nasłuch/podsłuch”, analizę sygnałów obecnych w eterze oraz zmianę parametrów własnego nadajnika, np. częstotliwości, modulacji, itp.). Niniejszy artykuł stawia sobie inny cel: przybliżenie technologii SDR pod względem implementacyjnym i

pokazanie możliwości jej szerszego wykorzystania w procesie nauczania podstaw telekomunikacji cyfrowej.

Artykuł ma następującą strukturę: w sekcji 2 opisa-no technologię SDR, w sekcji 3 przedstawiono podstawy standardu DAB+ oraz bloki DSP w nim występujące, a w sekcji 4 zaprezentowano stworzony, programowy odbiornik radia cyfrowego DAB+, napisany w języku C++. Pracę zamyka podsumowanie oraz wykaz literatu-ry.

2. RADIO ZDEFINIOWANE PROGRAMOWO (SDR)

Programowa (ang. software, „miękka”) realizacja

przetwarzania sygnałów w dowolnym miejscu toru transmisji radiowej, oraz dowolnej innej, ma wiele zalet w porównaniu z realizacją sprzętową (ang. hardware, „twardą”). Jedną z podstawowych jest łatwość modyfi-kacji algorytmu przetwarzania, gdyż dającą pełny wgląd do wnętrza poszczególnych bloczków układu transmisji i możliwość ich natychmiastowej zmiany. Dodatkową zaletą jest nieodstrajanie się „układów” (programów) od warunków nominalnych pracy w wyniku zmiany warto-ści elementów pasywnych – ich starzenia się.

Koncepcja transmisji radiowej zdefiniowanej pro-gramowo, czyli starającej się maksymalnie wykorzysty-wać cyfrowe przetwarzanie sygnałów na dedykowanym sprzęcie komputerowym, ma długą historię. Tematyka ta została zapoczątkowana na świecie artykułem [2], po-chodzącym z 1995 roku. Pierwsze syntetyczne opraco-wania książkowe poświęcone tej tematyce pojawiły się na początku XXI wieku, czyli prawie 15 temu (przykła-dem może być podręcznik [3] z 2002 roku). Potem po-wstały książki (np. [4, 5]) łącznie omawiające większość algorytmów cyfrowego przetwarzania sygnałów, nie-zbędnych w urzeczywistnieniu koncepcji SDR (progra-mowe ujęcie: pod-próbkowania i nad-próbkowania sy-gnałów cyfrowych, cyfrowego kształtowania impulsów i cyfrowej filtracji dopasowanej, modulacji i demodulacji cyfrowych, cyfrowej konwersji częstotliwości do góry i do dołu, adaptacyjnych układów synchronizacji czaso-wej (timing recovery) i częstotliwościowej (carier re-covery), adaptacyjnych korektorów częstotliwościowych kanału (FEQ) oraz metod zabezpieczenia nadmiarowego przed błędami i korekcji błędów, które wystąpiły (FEC).

Równolegle powstawały efektywne platformy sprzętowe, dedykowane dla SDR. Do jednej z najpopu-larniejszych i najefektywniejszych należą urządzenia USRP (Universal Software Radio Peripheral) firmy

Ettus Research (ER) [6]. Urządzenia USRP są połączone z komputerem za pomocą szybkich interfejsów USB 3.0 lub Ethernet 1 Gbit. Podczas pracy w trybie nadajnika otrzymane z komputera dane dodatkowo przetwarzają one w paśmie podstawowym (opcjonalne są procesory ARM), a potem nad-próbkowują je do częstotliwości pośredniej (układy FPGA, maksymalnie 16 bitów, do 400 Mpróbek/s), przetwarzają na sygnał analogowy (przetworniki C/A), odpowiednio wzmacniają i przesyła-ją do heterodynowych mieszaczy, konwertujących sy-gnały analogowe do wyższych częstotliwości (zakres 70 MHz – 6 GHz z pasmem sygnału do 56 MHz). Podczas pracy w trybie odbiornika wykorzystywane są 14-bitowe przetworniki A/C, pracujące z częstotliwością 100 Mpróbek/s).

Inną, bardzo ciekawą, znacznie prostszą i tańszą platformą implementacji mniej wymagających układów radiowych w technologii SDR (ale tylko odbiorników!), idealnie sprawdzającą się w zastosowaniach dydaktycz-nych, są tunery DVB-T, pracujące na złączu USB i wy-korzystujące analogowy konwerter częstotliwości E4000 lub nowszy R820 oraz układ RTL2832U firmy Realtek z przetwornikiem 8-bitowym [7]. Pokrywają one zakres częstotliwości 52-2200 MHz, oferują pasmo sygnału 0.25 – 3.2 MHz (Mpróbek/s) i mogą pracować z często-tliwościami pośrednimi 0, 4.57 i 36.125 MHz. Nadają się więc do testowego odbioru szeregu usług radiowych takich jak: tradycyjne radio FM (przetwarzane cyfrowo; zakres 87,5-108 MHz, pasmo 250 kHz), radio cyfrowe DAB/DAB+ (zakres 174-230 MHz, pasmo 2.048 MHz), sygnał GPS (około 1600 MHz), itd.

Układy USRP oraz RTL2832U+E4000 posiadają sterowniki w darmowym środowisku „telekomunikacyj-nym” GNU Radio [8], dostępnym w środowisku Linu-x/Windows, dlatego mogą być oprogramowywane z jego wykorzystaniem. GNU Radio umożliwia programowanie SDR metodą graficznego łączenia modułów wymaga-nych algorytmów DSP (ich przykłady zostały wymie-nione pod koniec drugiego akapitu w tej sekcji). Po wy-kupieniu firmy Ettus Research przez firmę National Instruments jej produkty można także (ale drożej) kupić z logo NI [9] i otrzymać dzięki temu wsparcie układów USRP w uniwersalnym środowisku pomiarowo-obliczeniowym LabVIEW. Istnieją także sterowniki (sockets) dla układów USPR i RTL2832U w środowisku Matlab/Simulink [10, 11].

W zamożnych krajach zachodnich układy USRP stały się już standardem w praktycznym nauczaniu pod-staw telekomunikacji cyfrowej [12]. Z racji bardzo ni-skiej ceny układów RTL2832U+E4000, ich dużych możliwości oraz szerokiego wsparcia aplikacyjnego przez społeczność międzynarodową [13], stanowią one naszym zdaniem bardzo dobrą, wielokrotnie tańszą al-ternatywę dla USRP. Przykładowo, istnieje wiele aplika-cji do nagrywania sygnałów IQ z układów firmy Realtek oraz do obserwacji ich widma w czasie rzeczywistym (przykładowo SDR# [14]). Nagrane dane można potem osobiście przetwarzać. Bardziej wymagającym i kształ-cącym zadaniem jest dekodowanie sygnałów w czasie rzeczywistym (w programie SDR# jest w ten sposób dekodowane radio FM).

My postawiliśmy sobie za cel stworzenie dla ukła-du RTL2832U+E4000 programowego odbiornika radia

DAB+, które jest obecnie wprowadzane w Polsce. W Internecie są dostępne przykładowe implementacje radia DAB dla tego układu, ale nie DAB+, np. w języku C++ [15], w języku Python z wywołaniem funkcjami z GNU Radio [16, 17] oraz w języku Matlab [17]. W celach dydaktycznych tak rozszerzyliśmy dostępny program DAB, napisany w języku Matlab [17], aby dekodował on nie tylko radio DAB ale także DAB+, a następnie na tej podstawie stworzyliśmy w języku C++ programowy odbiornik DAB+, działający w czasie rzeczywistym i przetwarzający próbki IQ z układu RTL2832U+E4000.

3. RADIO CYFROWE DAB+

3.1. Krótki rys historyczny Standard DAB [18] powstał w ramach europejskie-

go projektu Eureka 147 [19], zapoczątkowanego w 1986 roku. Jego pierwsza wersja ukazała się w 1995 roku i bazowała na koderze audio MP2 z normy MPEG-1 z 1992 roku (tylko częstotliwość próbkowania 48 kHz). Opis jego odbiorników można znaleźć w [20, 21].

Jednak pierwsze próby wprowadzenia radia DAB nie wszędzie zakończyły się sukcesem (przykładowo w Finlandii, z powodu dużych kosztów budowy odpowied-niej infrastruktury oraz braku zainteresowania odbior-ców (brak zwiększenia jakości sygnału w stosunku do radia FM), poddano się i zakończono transmisję DAB już w 2001 roku.

W odpowiedzi na niezadowolenie rynku, uwzględ-niono postęp technologiczny, który się w międzyczasie dokonał i w 2006 roku zaproponowano rozszerzoną wersję standardu pod nazwą DAB+ [22]. Jako opcję dodano w niej możliwość używania nowoczesnego ko-deka audio HE-AAC w wersji 2 [23] oraz pakietową transmisję danych, umożliwiającą nowe usługi multime-dialne (np. Slide Show).

Pomimo tych zabiegów radio DAB+ rozwija się w Europie z dużymi oporami. Spowodowane to jest male-jącym zainteresowaniem odbiorców tradycyjną usługą radiową, szczególnie wśród osób młodych, na rzecz telewizji (w przeszłości) oraz Internetu (obecnie). W tym drugim przypadku zwiększa się szczególnie strumienio-wanie multimediów - w rozpatrywanym przypadku radia internetowego oraz serwisów plików dźwiękowych, tzn. audycji radiowych (tzw. „podkastów”) lub piosenek (całych płyt). Przykładem takiej usługi jest bardzo popu-larny serwis Spotify. W 2011 roku w Europie aż 15 kra-jów używało starego standardu DAB, a tylko 8 krajów standardu DAB+. Nawet w krajach, w których liczba słuchaczy radia cyfrowego jest największa, procentowo jest ich i tak mniej niż słuchaczy tradycyjnego radia FM (w 2011 roku: 38% w Anglii oraz 20% w Norwegii).

Nie zmienia to jednak faktu, że w Polsce od 2009 trwają prace nad cyfryzacją państwowego radia [24] i w chwili obecnej znajdujemy się już w bardzo zaawanso-wanym etapie tego procesu [25, 26]: do końca 2015 będzie możliwy obiór multipleksu Polskiego Radia Cy-frowego DAB+ w większości miast wojewódzkich, a koniec inwestycji, tzw. „doświetlenie” elektromagne-tyczne, jest planowane na rok 2020.

Ponieważ sygnał DAB+ już jest lub wkrótce będzie dostępny we wszystkich większych ośrodkach akade-mickich (i nie zniknie szybko ze względu na poniesione

koszty), można go z powodzeniem wykorzystać do nauki podstaw cyfrowej transmisji radiowej. Stanowi on bar-dzo dobre uzupełnienie do przetwarzania sygnału analo-gowego radia FM wraz z danymi RDS przy użyciu tech-nologii SDR (np. cyfrowa pętla PLL do odtwarzania pilota i demodulacji sygnału L-R, pętla Costasa do rów-noczesnego odtworzenia nośnej i demodulacji amplitu-dowej sygnału RDS, podpróbkowanie sygnału, demodu-lacja sygnału BPSK, odtworzenie czasu próbkowania danych RDS metodą Early-Late Gate, itp.).

3.2. Podstawy Szczegółową informację dotyczącą obecnej postaci

standardu DAB+ można znaleźć w bezpłatnych nor-mach, dostępnych w Internecie: [27] – przewodnik po rodzinie standardów DAB, [28] – ogólne zasady działania i implementacji, [29] – główna norma standardu DAB+, [30] – szczegóły dotyczące transportu audio AAC, Same metody kompresji sygnału audio są opisane szcze-gółowo w oddzielnych, najczęściej wcześniejszych nor-mach: [31] – koder poziomu 2 (MP2) standardu MPEG-1 (tylko częstotliwość próbkowania 48 kHz), [32] – koder poziomu 2 (MP2) standardu MPEG-2 (do-danie częstotliwości próbkowania 24 kHz), [33] – koder AAC standardu MPEG-2, [34] – koder HE-AAC v2 standardu MPEG-4. W celu odtwarzania dźwięku, przesyłanego w standar-dzie DAB+, należy wydobyć bity HE-AAC v2 z tzw. Super Ramki (SF) (Super Frame) i zapisać je w jednym z dopuszczalnych formatów transportu AAC, np. stan-dardzie ADTS (ang. Audio Data Transport Stream) [35].

W artykule tym nie będzie zajmować się standar-dami kompresji MP2 i AAC sygnałów audio. Szczegó-łowy opis MP2 wraz z kompletnym programem kode-ra/dekodera w języku Matlab można znaleźć w [36], zaś opis AAC wraz z przeglądem literatury – w [37].

3.2. Warstwa fizyczna Dziedzina częstotliwości. Zespolony, czasowy sy-

gnał IQ(n) pojedynczego multipleksu DAB+ w paśmie podstawowym jest próbkowany z częstotliwością 2,048 MHz. Wykorzystywanych jest 1536 nośnych harmo-nicznych (oddalonych od siebie o 1 kHz, czyli jest uży-wane pasmo częstotliwościowe równe około 1,536 MHz), leżących symetrycznie po obu stronach 0 Hz, czyli po 768 z każdej strony (patrz rysunek 1). Pozosta-łych 512 nośnych, po 256 dla ujemnych i dodatnich częstotliwości, nie jest wykorzystywanych i jest wyze-rowanych. Stanowią one odstęp pomiędzy sąsiednimi multipleksami DAB. Bity są przydzielane na nośne uży-wane. Sygnał czasowy otrzymuje się w wyniku 2048-punktowego IFFT (1536+512). Stosowana jest różnico-wa modulacja fazowa DQPSK (Differential Quadrature Phase Shift Keying) każdej z nośnych.

Dziedzina czasu. Sygnał zespolonej ramki DAB, przedstawionej na rysunku 1 (tylko część rzeczywista), zaczyna się od preambuły. Ma ona postać symbolu ze-rowego NULL, liczącego 2656 próbek (1297 μs). Potem występuje 76 czasowych symboli OFDM, z których każdy ma 2552 próbki (1246 μs): jest to wynik IFFT (2048 próbek) z zadanego stanu nośnych, na początek

którego kopiuje się jego ostatnie 504 próbki, czyli doda-je się cykliczny prefiks CP (inaczej zwany przedziałem ochronnym GI (Guard Interval)). Łącznie ramka ma 2656+76*2552= 196608 próbek. Ponieważ stosuje się modulację różnicową DQPSK, to pierwszy przesyłany symbol OFDM pełni rolę odniesienia fazowego (Phase Reference), a bity są kodowane od drugiego symbolu OFDM w skokach fazy (z symbolu na symbol) każdej używanej nośnej (mamy 4 przesunięcia fazowe ±45 i ±135 stopni czyli po 2 bity na nośną).

3.3. Synchronizacja Symbol zerowy NULL służy do znalezienia po-

czątku każdej ramki DAB metodą szukania minimum energii sygnału (śledzenie kształtu jego obwiedni). Zna-jomość początków dwóch kolejnych ramek umożliwia obliczenie liczby jej próbek. Jeśli jest ona różna od 196608, czyli oczekiwanej, należy zmienić (skorygo-wać) częstotliwość próbkowania fA/C pracy przetwornika A/C lub programowo przepróbować sygnał.

Rys. 1. Widmo symbolu OFDM oraz część rzeczywista fragmentu zarejestrowanego sygnału czasowego radia DAB+ (ramka DAB jest pomiędzy dwoma kolejnymi,

widocznymi symbolami NULL)

Z kolei pierwszy symbol OFDM w każdej ramce DAB, noszący nazwę Phase Reference, poza tym, że stanowi odniesienie fazowe dla nośnych ramki następnej (ważne w przypadku modulacji DQPSK), jest także źródłem innych, cennych informacji.

Po pierwsze można go wykorzystać do wyznacze-nia odstrojenia się częstotliwości pośredniej tunera od wartości nominalnej. Jeśli założymy, że odpowiedź im-pulsowa kanału jest stała i krótka, nie występuje szum i wszystkie operacje w odbiorniku są idealnym odwróce-niem operacji w nadajniku, to sygnał odebrany y(t) dla próbek końca cyklicznego prefiksu oraz dla końca sym-bolu Phase Reference powinien być taki sam, ponieważ nadane fragmenty sygnału x(t) były takie same (istota

nadane fragmenty sygnału x(t) były takie same (istota cyklicznego prefiksu). Jeśli jednak częstotliwość kon-wersji sygnału z wyższych częstotliwości do pasma podstawowego fdown w odbiorniku jest różna do często-tliwości fup konwersji sygnału z pasma podstawowego do wyższych częstotliwości w nadajniku, to sygnał odebra-ny jest równy:

2 ( ) 2( ) ( ) ( )up downj f f t j fty t x t e x t eπ π− Δ= = . (1)

Jeśli pomnożymy końcowy fragment symbolu OFDM i sprzężenie zespolone końcowego fragmentu jego prefik-su (czyli ten sam sygnał tylko z opóźnieniem T, równym długości symbolu bez prefiksu), to otrzymamy:

* 2 2 2 ( )( ) ( ) ( ) | ( ) | j ft j f t Tz t y t y t T x t e eπ πΔ − Δ −= − = = (2)

2 ( )2 2 2 2 2| ( ) | | ( ) | | ( ) |int fractj f f Tj fT jx t e x t e x t eππ πεΔ +ΔΔ= = = gdzie przez Δfint oznaczyliśmy całkowitą wielokrotność 1/T, a przez Δffract – „ułamkową” (0<ε<1) wielokrotność 1/T:

, .int fractkf fT T

εΔ = Δ = (3)

Z (2) możemy wyliczyć ε: ( ) .

2z tεπ

= (4)

a potem z (3) Δffract. W [39] wykazano, że dyskretna wersja ML (Maximum Likelihood) równania (4), zmniej-szająca wpływ szumu na wynik estymaty, ma postać (N − długość FFT, M − długość prefiksu, L=M+N , K<M):

*

0

( ) ( ), .

2

L

prn L Kfract

y n y n N ff f

Nε ε ε

π= −

−= Δ = =

∑ (5)

Po wyznaczeniu Δffract przeprowadza się pierwszą korektę odebranego sygnału Phase Reference y(n) po-przez wymnożenie go z sygnałem korygującym exp(−j2π(Δffract/fA/C)n), usuwającym ułamkowe przesu-nięcie częstotliwości. Powoduje to likwidowanie rozmy-cia widma odebranych symboli OFDM, ale dalej może występować kołowe przesunięcie widma symboli o k prążków FFT, wynikające z odstrojenia fup−fdown o czę-stotliwość Δfint (3). Dlatego oblicza się k korelując wid-mo odebranego, już skorygowanego o Δffract sygnału Phase Reference z widmem teoretycznym (spodziewa-nym), określonym w standardzie. Następnie szuka się maksimum funkcji korelacji, występującego dla przesu-nięcia k. W ten sposób znajduje się Δfint z (3):

0 .print

ff kf k

NΔ = = (6)

Korelację przeprowadza się metodą szybką z wykorzy-staniem FFT (tzn. mnoży się w dziedzinie czasu odebra-ny, już raz skorygowany sygnał Phase Reference ze sprzężeniem zespolonym poprawnego sygnału Phase Reference, a następnie oblicza się FFT wyniku i szuka maksimum).

Znając przesunięcia całkowite i ułamkowe sumuje się je, otrzymuje Δf i przeprowadza korektę wszystkich próbek całej ramki DAB, mnożąc je z (−j2π(Δf/fA/C)n).

Po drugie, sygnał Phase Reference po opisanej po-wyżej korekcie Δf, można wykorzystać do potwierdzenia

(poprawy) estymaty położenia początku ramki DAB. W tym celu wycina się fragment sygnału, uważany obecnie za Phase Reference, wyznacza jego N punktowe widmo FFT, mnoży je ze sprzężeniem widma teoretycznego, oblicza IFFT iloczynu i szuka położenia maksimum wartości bezwzględnej wyniku, mówiącym o przesunię-ciu czasowym odebranego sygnału PR. Jak widać jest to szybka metoda korelowania ze sobą sygnałów czaso-wych w dziedzinie częstotliwości, dopasowująca ode-brany sygnał PR do nadanego.

Literatura, dotycząca różnych metod synchronizacji czasowej i częstotliwościowej, możliwych do zastoso-wania w przypadku radia DAB+, jest bardzo bogata, przykładowo [40, 41, 42].

3.4. Warstwa logiczna (bitowa) Demodulator. Po znalezieniu pierwszej próbki

symbolu Phase Reference przesuwamy się o M=504 próbki (długość cyklicznego prefiku) i obliczamy N=2048-punktowe FFT. Operację tę powtarzamy na-stępnie na każdym kolejnym symbolu OFDM. W sumie otrzymujemy 76 widm, wybieramy z nich 1536 używa-nych nośnych i obliczamy skokowe zmiany wartości współczynników widmowych, czyli 75 wartości dla każdej nośnej (k=1…75, n=1… 1536):

*( , ) ( 1, ) ( , )Y k n Y k n Y k nΔ = + (6)

Na podstawie każdej wartości ΔY(k,n) jesteśmy w stanie odtworzyć nadane bity:

Real(ΔY)>0 & Imag(ΔY)>0 „00”, Real(ΔY)>0 & Imag(ΔY)<0 „01”, Real(ΔY)<0 & Imag(ΔY)<0 „10”, Real(ΔY)<0 & Imag(ΔY)>0 „11”,

ale nie robimy tego (pozostawiamy zespolone liczby ΔY), gdyż chcemy w dalszej części zastosować lepszą -„miękką”, a nie „twardą”, wersję algorytmu Viterbiego splotowego dekodera korekcji błędów.

Na rysunku 2 pokazano przykładowe konstelacje wartości przyjmowanych przez ΔY(k=var, n=const) dla wybranej nośnej: po lewej: bez przez przeprowadzenia synchronizacji częstotliwości pośredniej, po prawej: z jej użyciem.

Rys. 2. Przykładowe, przeskalowane konstelacje zmiany stanów pojedynczej, tej samej nośnej bez synchronizacji częstotliwości pośredniej (po lewej) oraz z synchroniza-

cją (po prawej) Usuwanie przeplotu częstotliwości. Następnie dla

każdej wartości k zamieniamy miejscami liczby ΔY(k,n) względem n (w sposób określony w standardzie). Usu-wamy w ten sposób przeplot częstotliwościowy

Rys. 3. Format ramki DAB+. Oznaczenia: FIB (Fast Information Block), , FIG (Fast Information Group), CIF (Com-mon Interleaved Frame), MP2 – poziom 2 kodera MPEG-2 audio, SF – Super Frame AAC. Na końcu każdego bloku

FIB jest 16 bitów CRC.

wykonany w nadajniku, mający nas zabezpieczyć przed zakłóceniami wąskopasmowymi. Do dalszego przetwa-rzania formujemy strumień danych w następujący spo-sób:

Real(ΔY(k,n)) dla k=1, n=1…1536 (lub bity pierwsze) Imag(ΔY(k,n)) dla k=1, n=1…1536 (lub bity drugie) … Real(ΔY(k,n)) dla k=75, n=1…1536 (bity pierwsze) Imag(ΔY(k,n)) dla k=75, n=1…1536 (bity drugie)

Dekodowanie FIC i MSC. Dokładna struktura lo-giczna ramki DAB+ jest pokazana na rysunku 3. Dane pierwszych 3 symboli OFDM z 75 (łącznie 3*1536 no-śnych * 2 Re/Im = 9216 liczb/ bitów) zawierają informa-cję FIC (Fast Information Channel) o przesyłanych usługach. Kolejne 72 symbole zawierają dane MSC (Main Service Channel) serwisów multimedialnych. Dane FIC nie są w nadajniku poddawane przeplotowi czasowemu, w celu umożliwienia odbiornikowi ich szybszego zdekodowana, natomiast dane MSC – są pod-dawane przeplotowi.

Dane FIC są podzielone na 12 bloków, związanych z FIB (Fast Information Block), po 768 liczb/bitów każ-dy. Każde kolejne trzy bloki (łącznie 2304 liczby/bity) z 12 przypadają na jeden z czterech bloków CIF (Common Interleaved Frame), należący do danych multimedial-nych MSC. Dane te znajdują się za danymi FIC. Cały blok MSC składa się z 221184 liczb/bitów (72 symbole * 1536 nośne * 2 liczby), a każdy blok CIF to jedna czwarta MSC, czyli 55296 liczb/bitów.

Dekodowanie FIC. Ponieważ w nadajniku wysyła-ne dane/bity są poddawane nadmiarowemu (4-krotnie) kodowaniu splotowemu (oktalnie zapisane współczynni-ki generatora to: 133, 171, 145, 133), a potem niektóre nadmiarowe bity są usuwane (tzw. „dziurawienie, punc-turing), w odbiorniku wstawia się zera w miejsce usunię-tych wartości (pomiędzy odebrane), jest to tzw. de-puncturing. W wyniku tego każda z 4 części bloku FIC po uzupełnieniu zerami zwiększa się z 2304 do 3096 liczb/bitów. Następnie dla każdej z nich odtwarza się wartości bitów nadanych, z użyciem „miękkiego” (dla wejściowych wartości Real(), Imag()) lub „twardego” (dla wejściowych bitów 0/1) dekodera Viterbiego. Z

powodu wejściowej 4-krotnej redundancji otrzymuje się 3096/4=774 bity, z których usuwa się sześć ostatnich (przejściowych, równych liczbie układów opóźniających w koderze splotowym w nadajniku). W wyniku tej ope-racji otrzymujemy dla FIC 4 bloki po 768 bitów. Na każdym z nich osobno przeprowadza się operacją XOR z sekwencją PRBS (Pseudo Random Binary Sequence), identyczną jak w nadajniku (generowaną za pomocą przesuwnego rejestru ze sprzężeniem zwrotnym i wie-lomianu x9+x5+1). Usuwa się w ten sposób rozproszenie energii (energy de-dispersal, de-scrambling), wprowa-dzone w nadajniku za pomocą dodawania modulo-2 bitów nadawanych i bitów sekwencji PRBS. Następnie z 4 bloków po 768 bitów pobiera się 12 paczek po 256 bitów, czyli 12 bloków FIB (Fast Information Block) Sprawdza się ostatnich 16 bitów każdej paczki, stano-wiących kod CRC (wielomian x16+x12+ x5+1). W przy-padku niewystępowania błędu, przetwarza się dalej pierwszych 240 bitów. Są one podzielone na bloki FIG (Fast Information Group) o zmiennej długości. Pierwsze 3 bity określają typ bloku (od 0 do 7), następne 5 jego długość w bajtach, potem występują właściwe dane. Dla FIG typu „0” w polu danych mamy: 1 bit C/N (Cur-rent/Next configuration 0/1), 1 bit OE (this/Other En-semble 0/1), 1 bit P/D (Programme/Data service 0/1; dla P identyfikator programu jest zapisywany na 16 bitach), 5 bitów określających rodzaj danych (Extension, od 0 do 31), na końcu właściwe pole danych. W szczególności dla Extension=1, w polu danych znajdują się 24 bitowe (short) lub 32 bitowe (long) paczki bitów: 6 bitów nume-ru identyfikującego serwis (SubChId), 10 bitów adresu początku serwisu w MSC (SubChStartAddr, liczba bi-narna bez znaku od 0 do 863, wskazująca na pierwszy blok CU (Capacity Unit)=64 bity audio), 1 bit określają-cy dalszą długość pola (Short/Long 0/1, czyli dalej 7/15 bitów). Jeśli 7 bitów, to DAB i MP2: 1 bit przełączania tablicy w standardzie (0/1 = tablica 6/zarezerwowane), 6 bitów to opcja w tablicy (od 0 do 63: SubChSize w CU, Protection Level, Audio Bitrate). Jeśli 15 bitów, to DAB+ i AAC: 3 bity wybierające Option - opcję opisu kodowania (0 lub 1), 2 bity Protection Level, 10 bitów SubChSize (patrz tablice 7 lub 8 w [29])

NULL Symbol 1 Symbol 2

Faza odniesie-nia Dane Dane Dane

Detekcja początku

RAMKA DAB

FIC (Fast Info Channel) MSC (Main Service Channel)

Symbol 3 Symbol 4 Symbol 5 Symbol 76

FIB 1 CIF 1 FIB 2 FIB 3

Dane

FIB 12 CU = 64 bits (Capacity Unit) FIB = 4 CU = 256 bity CIF = 864 CU = 55296 bitów

CIF 2 CIF 3 CIF 4

FIG FIG FIG FIG FIG FIG FIG FIG

CP

MP2 MP2 MP2 MP2

SF 1 SF 2 SF 3 SF 4

IFFT

CRC CRC CRC

W podobny sposób dekoduje się inne informacje. Zainteresowanych dalszymi szczegółami odsyłamy do standardu [29]. Nas szczególnie interesują wartości pa-rametrów niezbędnych do zdekodowania audycji kon-kretnej stacji radiowej, nadawanej w systemie DAB+: SubChId, SubChStartAddr, SubChSize oraz Protection. Wartości tych parametrów są podane w bloku FIC, zaś próbki audio są umieszczone w bloku MSC, występują-cym za FIC (patrz rysunek 3).

Dekodowanie MSC. Po odczytaniu z danych FIC informacji o dostępnych stacjach radiowych, wybieramy jedną z nich, a następnie odczytujemy jej bity z bloku MSC=4*CIF. Bity te znajdują się w każdym bloku CIF w tym samym miejscu, określonym przez wartości pa-rametrów SubChStartAddr i SubChSize, wyrażonych w jednostkach CU=64 bity. W pierwszym kroku likwidu-jemy przeplot czasowy tych bitów, którego dokonano w nadajniku w celu zabezpieczenia się przed zakłóceniami impulsowymi. W tym celu należy pamiętać aż 19 ostat-nich bloków CIF-ów z 5 ostatnich ramek DAB, co daje opóźnienie prawie 0.5 sekundy. Potem, podobnie jak w bloku FIC, usuwa się „dziurawienie”, wykonane w na-dajniku po 4-krotnie nadmiarowym koderze splotowym, identycznym jak dla FIC. Metoda „dziurawienia” jest inna niż w FIC, dodatkowo różna dla danych DAB (Unequal Error Protection UEP, skokowe zmiany, tabli-ce 30 i 31) oraz DAB+ (Equal Error Protection EEP, płynne zmiany, tablice 33-36). Po wstawieniu zer w miejsce usuniętych wartości, używa się dekodera Viter-biego do optymalnego odtworzenia bitów nadanych, oddzielnie dla wartości pochodzących z 4 bloków CIF. Długość danych wejściowych do dekodera jest inna dla różnych stopni kompresji sygnału audio i różnego po-ziomu zabezpieczenia przed błędami. Następnie, podob-nie jak dla FIC, wykonuje się logiczną operację XOR z bitami sekwencji PRBS (czyli energy de-dispersal, de-scrambling). W przypadku DAB, wynikową sekwencję bitów przekazuje się do algorytmu MP2 dekompresji dźwięku, co kończy przetwarzanie.

Dekodowanie Super Ramki AAC dla DAB+. Dla DAB+ przetwarzanie trwa dalej. Dane odczytane z 5 kolejnych bloków CIF stanowią tzw. Super Ramkę (SF, Super Frame), utworzoną w nadajniku (rys. 3 i 4). W odbiorniku trzeba znaleźć, w którym bloku CIF się ona zaczyna. Na jej początku jest nagłówek, składający się z: - 16 bitów fire-kodu (obliczonego w nadajniku z uży-ciem wielomianu (x11+1)(x5+x3+x2+x+1), który zabez-piecza występujące za nim 9 bajtów), - 8 bitów określających wartości parametrów kodera AAC (m.in. częstotliwość próbkowania, replikację wid-ma, parametryczne stereo, konfigurację trybu surround), - num_aus=2, 3, 4 lub 6 bloków po 12 bitów, definiują-cych adresy starowe au_start[n] bloków próbek audio (ich liczba wynika z parametrów AAC), - ewentualnego uzupełnienia czterema bitami zerowymi (wynikającego z poprzedzających wartości). Występujące potem paczki bitów AAC, zaczynające się od au_start[n], mają na końcu 16 bitów CRC, wylicza-nych przy użyciu tego samego wielomianu co w przy-padku FIC: x16+x12+x5+1. Dlatego można je wykorzystać do wykrycia pierwszego z pięciu bloków CIF Super Ramki.

Rys. 4. Struktura Super Ramki AAC, spakowanych danych AAC z pięciu bloków CIF. Oznaczenia: FireC – Fire Code, AU – Audio Unit, CRC16 – Cyclic Redundancy Check

Procedura synchronizacji SF może wyglądać tak [17]. Zakładamy, że dany CIF jest pierwszy. Koryguje-my jego początek fire-kodem. Dekodujemy wartości au_start[n]. Jeśli NIE narastają one monotonicznie, to przechodzimy do następnego bloku CIF, w przeciwnym przypadku pobieramy pierwszy blok danych audio i sprawdzamy jego CRC. Jeśli jest poprawny, to przetwa-rzany blok CIF jest pierwszym w Super Ramce. W prze-ciwnym przypadku, przechodzimy do następnego bloku CIF. Następnie, znając adresy au_start[n] początków bloków próbek audio, przepakowujemy je do wybranego formatu transportu (pojemnika, kontenera) ACC, obsłu-giwanego przez używaną bibliotekę dekompresującą, np. do standardu ADTS. Przepakowanie jest realizowane w trybie blok do bloku. W blokach Super Ramki spraw-dzamy CRC (ostatnie 16 bitów każdego bloku).

Na końcu Super Ramki w nadajniku są dodane bity wynikające z jej zabezpieczenia koderem Reeda-Solomona (RS) (120,110,t=5), tzn. zabezpieczającego każde wysyłane 110 bajtów SF dodanymi 10 bajtami (110+10= 120). Generator kodera jest postaci:

9

0

( ) ( )i

iG x x α

=

= +∏ (7)

Użyte jest pole Galois GF(28) z α1=2, wykorzystujące wielomian P(x)= x8+x4+x3+x2+1.

Aby skorzystać w odbiorniku z bitów zabezpiecza-jących, należy zapisać wszystkie bajty wysyłane w SR do macierzy posiadającej 120 elementów w każdym wierszu, ale wstawiając je do niej kolumnami od góry do dołu. Potem należy wykonać dekodowanie Reeda-Solomona na wierszach macierzy i odtworzyć naprawio-ną SF (skanując wynikową macierz ponownie kolumna-mi). Jako dekodera RS można użyć programów popular-nych dekoderów RS(255,245,t=10). Do każdego wiersza macierzy trzeba na początku dodać 135 bajty zerowe (135+120=255), potem wywołać dekoder, a potem po-brać ostatnich 110 elementów z każdego wiersza.

3.5. Podsumowanie Do tej pory prowadziliśmy rozważania w myśl sce-

nariusza „od szczegółu do ogółu” (lub bottom−up). W związku z tym naszedł teraz czas na końcowe podsumo-wanie standardu DAB+. Na rysunku 5 pokazano schemat blokowy układu tworzenia danych FIC i MSC w nadaj- niku DAB+, a na rysunku 6 – łączenie ich w ramkę DAB+. Kolejny rysunek 7 przedstawia podsumowujący tę sekcję algorytm programowy odbiornika radia DAB+. W dalszej części artykułu zajmiemy się problemem jego praktycznej implementacji komputerowej.

HeaderFireC AU 1 CRC AU k CRCAAC AAC

SF (Super Frame) = SF1 +SF2 + SF3 + SF4 + SF5

Rys. 5. Tworzenie danych FIC (Fast Information Channel) i MSC (Main Service Channel) w nadajniku radia DAB+

Tab. 1. Charakterystyk standardu DAB w modzie I [18] Parametr Liczba/Długość Czas trwaniaRamka DAB 196608 próbek 96 ms Symbol Null 2656 próbek 1297 μs Symbol OFDM bez GI 2048 próbek 1000 μs FFT 2048 -- Liczba nośnych 1536 -- Separacja nośnych 1 kHz -- Gaurd Interval (GI) 504 próbek 246 μs Symbol OFDM (z GI) 2552 próbek 1246 μs Liczba symboli OFDM - z Phase Reference (PR) - z danymi FIC (info) - z danymi MSC (audio)

76 1 3 72

--

FIC (Fast Info Channel): - FIBs w ramce DAB - FIBs na 24ms

12 3

MSC (Main Service Ch): - CIFs w ramce DAB - CIFs na 24ms

4 1

Bity na symbol OFDM Bity na ramkę DAB

3,072 kbit 230,4 kbit

Prędkość bit. (bez PR): - FIC (łącznie, kod 1/3) - MSC (łącznie) - MSC (max na 1 kanał)

96 kbit/s

2,304 Mbit/s 1,824 Mbit/s

Max opóźnienie echa Max różnica drogi prop. Max prędkość odbiornika - w mieście - na wsi

-- 90 km

260 km/h 390 km/h

300μs (1,2GI)

--

Rys. 6. Tworzenie danych ramki DAB w nadajniku z danych FIC, MSC oraz symbolu fazy odniesienia

Rys. 7. Algorytm programowego odbiornika radia cy-frowego DAB+

Detekcja NULL Detekcja modu DAB

Synchronizacja T/F z Phase Reference

Wstawianie zer DAB/UEP, DAB+/EEP

5 CIFs Buffer

Transkoder DAB+ SuperRamka do ADTS

(decoder Reeda-Solomona)

DAB+ / AAC

Dekoder Viterbiego↓ 4x mniej

XOR(Bity, PRBS)

Pobierz bloki FIB Sprawdź CRC

Pobierz bloki FIG Zdekoduj FIG

Informacja o serwisie

INFO AUDIO

Korekta Start DAB Korekta fIF, fA/C

FFT Usuń przeplot FREQ

Detekcja D-QPSK Cmplx Real, Imag

Pobierz dane INFO z FIC

(Fast Info Channel)

Pobierz dane AUDIO z MSC

(Main Service Channel)

Usuń przeplot TIME (opóźnienie 16 CIF)

Wstawianie zer Const. Error Protect

Dekoder Viterbiego ↓ 4x mniej

XOR(Bity, PRBS) DABMP2

Przeplot częstotliwościowy

Multiplekser

Audio i Dane MSC

Informacja FIC

Referencyjny sygnał fazy

IFFT

Formatowanie ramki DAB

Audio DAB

Kompresja dźwięku

MP2

Koder splotowy FEC 1/4

Zmienne dziurawienie

kodu

Przeplot czasowy 16 CIFs

Rozpraszanieenergii

Tworzenie Super Ram-

ki

Koder splotowy FEC 1/4

Zmienne dziurawienie

kodu

Przeplot czasowy 16 CIFs

Rozpraszanieenergii

Audio DAB+

Kompresja dźwięku

HE-AACv2

DANE Pakowanie obiektów multimed.

Koder splotowy FEC 1/4

Zmienne dziurawienie

kodu

Przeplot czasowy 16 CIFs

Rozpraszanieenergii

Koder splotowy FEC 1/4

Zmienne dziurawie-

niekoduRozpraszanie

energii

Formatowanie informacji o dostępnych serwisach multi-

medialnych

MSC

FICCRC16

W tabeli 1 przedstawiono wartości podstawowych para-metrów tego standardu dla modu 1 w paśmie VHF (170-230 MHz), stosowanym w Polsce. Teraz liczby te po-winny już być dla nas w pełni zrozumiałe.

4. IMPLEMENTACJA SDR RADIA DAB+

Założonym celem opisanej poniżej implementacji radia DAB+ było zaprojektowanie i zbudowanie biblio-teki programowej, realizującej standard DAB+ w zakre-sie dekompresji sygnału audio z próbek IQ, pobieranych z tunera radiowego. Można wyróżnić trzy cele tego pro-jektu: dydaktyczny, implementacyjny oraz użytkowy.

Celem dydaktycznym było przybliżenie studentom (w projekcie uczestniczyło 19 osób) zagadnień i technik pracy zespołowej, w tym narzędzi programistycznych powszechnie wykorzystywanych w tym zakresie. I tak, przed rozpoczęciem projektu, implementacja została podzielona na 42 zadania. Po ich omówieniu, uczestnicy projektu podzielili się na 3-4 osobowe grupy oraz wybra-li zadania do realizacji. Współpraca na poziomie kodu źródłowego została zrealizowana za pomocą rozpro-szonego systemu kontroli wersji GIT. Środowisko dewe-loperskie zostało oparte o system Linux, program Eclip-se oraz powszechnie dostępne biblioteki programistycz-ne. Komunikację poza zajęciami zrealizowano przy pomocy mailingowej listy dyskusyjnej, a rezultaty pro-jektu rozpowszechniono za pomocą strony WWW [38]. Drugim celem (implementacyjnym) była jak najpełniej-sza implementacja standardu DAB+, tak aby kod źró-dłowy biblioteki mógł posłużyć jako referencyjny. Do-datkowo założyliśmy działanie kodu wynikowego w czasie rzeczywistym na architekturach x86 oraz ARM, w tym na systemach jednoukładowych o ograniczonych zasobach takich jak platforma Raspberry PI oraz smart-fony z systemem operacyjnym Android (implementacja na poziomie NDK [43]). Docelowo, program powinien działać na systemach z rodziny Linux jak również, po niewielkich modyfikacjach, na systemach Windows oraz MacOS. Modyfikacje powinny być wymagane wyłącz-nie w ramach obsługi operacji wejścia i wyjścia. W celu zapewnienia jak najszerszej dostępności zaprojektowa-nego oprogramowania wybrano język programowania C/C++ oraz biblioteki udostępnione na licencji LGPL (lub podobnej). Dołożono starań, aby wykorzystywać tylko funkcjonalności dostępne na wszystkich docelo-wych platformach, dla przykładu, wykorzystana biblio-teka pthread, w środowisku NDK Android jest obecnie zaimplementowana tylko w zakresie standardu POSIX, a więc nie występują tam tzw. bariery (ang. barriers). Z tego powodu zadecydowano, aby nie wykorzystywać tego mechanizmu do synchronizacji pomiędzy wątkami. W projekcie radia cyfrowego DAB+ skupiono się na aspektach cyfrowego przetwarzania sygnałów. Mając jednak na uwadze wymaganie pracy odbiornika w czasie rzeczywistym, wykorzystano następujące, dostępne, „szybkie” biblioteki: • libfftw3: implementacja szybkiej transformaty Fo-

uriera, • samplerate [44]: zmiana częstotliwości próbkowa-

nia,

• GStreamer [45]: odtwarzanie sygnału audio oraz dekompresja HE-AAC. Celem użytkowym było osiągnięcie kompletności

rozwiązania, wyrażonej gotowością do wykorzystania programu w aplikacjach firm trzecich, jak również w pracach dydaktycznych lub naukowych. Docelową for-mą implementacji będzie (w trakcie pisania artykułu prace nad programem nadal trwają) biblioteka udostęp-niana na licencji LGPL, pozwalająca na wykorzystanie programu libsdrdab zarówno w kodzie komercyjnym, jak i programach udostępnianych na zasadach (L)GPL. Kod biblioteki, wraz z przykładami oraz pełną dokumen-tacją, zostanie umieszczony na popularnym serwisie hostingowym dla projektów informatycznych GitHub. Chcielibyśmy spopularyzować standard cyfrowego radia przez przekonanie opiekunów popularnych programów odtwarzających multimedia (np. VLC), aby wykorzystali możliwości tej implementacji w swoich projektach. Ostatecznym celem projektu oraz miarą jego jakości byłoby umieszczenie biblioteki libsdrdab w standardo-wych repozytoriach popularnych dystrybucji systemu Linux.

Na osobną uwagę zasługuje dostępność kodu w ję-zyku Matlab (wkrótce będzie publicznie udostępniony wraz z książką jednego z autorów), realizującego de-kompresję usługi DAB+. Wykorzystano go jako funk-cyjny odpowiednik implementacji w języku C/C++, co pozwoliło zbudować testy jednostkowe (ang. unit test) dla poszczególnych modułów. Testy jednostkowe oparto o dane wejściowe i wyjściowe implementacji w języku Matlab z odpowiednią konwersją formatów danych (im-plementacja w tym języku jest zoptymalizowana w kie-runku czytelności i zwartości kodu, a nie oszczędzaniu zasobów). Testy jednostkowe umożliwiły równoległe pisanie i weryfikację obszernych fragmentów kodu zaraz po rozpoczęciu projektu bez konieczności łączenia ich z całym systemem.

4.1. Architektura biblioteki libsdrdab Ze względu na szerokość pasma zajmowanego

przez pojedynczy multipleks usługi DAB+, pracującej w trybie 1 (Mode I), częstotliwość próbkowania sygnału w paśmie podstawowym wynosi 2.048 MHz. Każda próbka składa się z ze składowej I oraz Q, tak więc efektywnie, w czasie rzeczywistym należy przetworzyć 4.096 Mpró-bek/s. Zakładając 8-bitową rozdzielczość przetwornika A/C (popularne tunery USB oparte na chipsecie RTL2832U + R820T2), otrzymujemy strumień danych 4.096 MB/s, który należy przetworzyć w czasie rzeczy-wistym.

Jednym z przyjętych założeń była praca na urzą-dzeniach o ograniczonych zasobach, czyli dysponują-cych relatywnie słabą jednostką CPU oraz pamięcią RAM ograniczoną do 1 GB (wliczając w to system ope-racyjny oraz inne programy działające na platformie). Odbiornik DAB+ jest złożonym systemem opartym o schemat OFDM, który dodatkowo zawiera dekoder splo-towy, dekoder korekcyjny Reeda-Solomona, złożony układ synchronizacji oraz potencjalnie wymaga prze-próbkowania sygnału radiowego w dziedzinie czasu (2 × 2.048 MHz) oraz przepróbkowania wyjściowego sygnału audio (2 × 48 kHz). Na podstawie wcześniejszych analiz

złożoności dekodera DAB+, napisanego w języku Ma-tlab, oszacowano, że najbardziej złożone obliczeniowo algorytmy w tym schemacie to: przepróbkowanie sygna-łu radiowego, dekodowanie Reeda-Solomona, dekoder Viterbiego oraz transformata FFT, wykorzystywana do rekonstrukcji symboli OFDM. W związku z tym, zapro-jektowano program tak, aby mógł działać wielowątko-wo, rozkładając najbardziej złożone obliczeniowo algo-rytmy na różne wątki. Taki schemat dobrze wpisuje się w obecne trendy architektur jednostek CPU, w których ze względów energetycznych preferuje się wielordze-niowe rozwiązania, np.: 2-4 słabsze rdzenie zamiast 1 mocniejszego. Dodatkowo, szybkość taktowania każde-go rdzenia jest ustalana indywidualnie w pełnym zakre-sie (od maksymalnej częstotliwości do całkowitego wy-łączenia), dlatego nawet w przypadku nierównego ob-ciążenia poszczególnych wątków, system powinien być bardzo sprawny energetycznie.

Uwzględniając powyższe założenia oraz ogranicze-nia, podzielono system na 6 głównych części, z których każda to osobna klasa w języku C++. W poniższym opisie, każda nazwa odnosi się do nazwy odpowiedniej klasy.

DataFeeder jest odpowiedzialny za: 1) komuni-kację z tunerem (urządzenie USB z chipsetem kompaty-bilnym z biblioteką rtlsdr [43]) lub odczytywanie da-nych z pliku, 2) wykonywanie korekty częstotliwości pośredniej i częstotliwości próbkowania (w tym prze-próbkowanie sygnału jeżeli jest wymagane), 3) usuwanie składowej stałej oraz 4) implementację algorytmu auto-matycznej regulacji wzmocnienia (AGC).

Synchronizer wyszukuje w strumieniu próbek pozycję symbolu NULL, potrzebną do określenia po-czątku ramki TF (Transmission Frame) oraz do określe-nia korekty częstotliwości próbkowania. Dodatkowo analizuje symbol PR (Phase Reference), na podstawie którego wyznacza korektę częstotliwości pośredniej, która jest przeprowadzana w module DataFeeder.

Demodulator wyznacza pozycje cyklicznego prefiksu wszystkich symboli OFDM, odtwarza dane z symboli za pomocą transformaty Fouriera - wykonywana jest ona dla symboli OFDM z obszaru FIC oraz tylko tych z obszaru MSC, które są niezbędne do dekompresji wybranego strumienia audio. W tej części wykonywany jest również algorytm usuwania przeplotu w dziedzinie częstotliwości (frequency de-interleaving) oraz demodu-lowanie danych z poszczególnych podkanałów często-tliwościowych. Ponieważ bity są zakodowane za pomocą DQPSK, aby odtworzyć dane z n-tego symbolu OFDM, należy wyznaczyć transformatę Fouriera dla n-tego i (n-1)-ego symbolu OFDM, a potem obliczyć różnicę po-między stanami QPSK w tych samych podkanałach częstotliwościowych dwóch kolejnych symboli OFDM.

DataDecoder pod względem funkcyjnym jest najbardziej skomplikowaną częścią systemu. Rezultatem działania tego modułu jest strumień audio w formacie MP2 lub AAC. W tej części są dekodowane dane z blo-ków FIC oraz MSC (patrz rys. 3 i rys. 7). Wykonywane są algorytmy: usuwania przeplotu w dziedzinie czasu (time de-interleaving), usuwania „dziurawienia” stru-mienia bitów po koderze splotowym (de-puncturing), dekoder Viterbiego kodu splotowego, usuwanie rozpro-

szenia energii (energy de-dispersal), dekoder Reeda-Solomona, dekoder CRC16 oraz konwersja strumienia binarnego do kontenera ADTS. W zależności od trybu pracy oraz części dekodowanego strumienia, wykony-wany jest podzbiór wyżej opisanych algorytmów. Dla przykładu dekodowanie FIC nie wymaga usuwania przeplotu w dziedzinie czasu oraz korekcji Reeda-Solomona.

AudioDecoder wykonuje dekompresję sygnału audio oraz, w zależności od konfiguracji, jego zapis do pliku bądź wysłanie do urządzenia odtwarzającego sy-gnał dźwiękowy. Jeżeli zachodzi taka konieczność, wy-konywane jest przepróbkowanie sygnału w dziedzinie czasu.

Scheduler to zarządca całego systemu. Inicjali-zuje on wszystkie części dekodera (tworzy i konfiguruje obiekty wyżej wymienionych klas) oraz przekazuje po-między nimi dane. W zależności od konfiguracji Sche-dulera, system może działać wykorzystując jeden lub więcej wątków.

Uproszczony schemat blokowy programowego de-kodera DAB+ przedstawiono na rysunku 8.

Rys .8. Uproszczony schemat blokowy programowego

dekodera DAB+

W celu zwiększenia czytelności rysunku, pominięto na nim obiekt Synchronizer, który powołuje, konfi-guruje oraz synchronizuje proces przetwarzania danych w obrębie całego systemu. Poszczególne moduły wy-mieniają się danymi poprzez bufory kołowe, wspólne dla dwóch obiektów (bufory zaznaczono kolorem szarym): jeden obiekt wpisuje dane na końcu bufora (czerwona ramka), a następny odczytuje z wcześniejszego miejsca (zielona ramka).

W architekturze systemu położono nacisk na takie zaprojektowanie obiektów przetwarzających dane, aby były one możliwie bezstanowe. I tak, na każdym obiek-cie, po jego utworzeniu oraz skonfigurowaniu, wykony-wana jest metoda Process(), w której przez argumen-ty przekazywane są: wskaźnik do danych wejściowych,

DataFeeder

bufor: sync_feeder_buffer_

Synchronizer

Demodulator

bufor: demod_decod_buffer_

bufor: audio_bits_buffer_

DataDecoder

AudioDecoder

plik (raw)

RTL-SDR

FIC DecoderMSC Decoder

plik (wave/AAC)

karta dźwiękowa

czas

wskaźnik na miejsce w pamięci, gdzie mają zostać zapi-sane dane wyjściowe oraz inne potrzebne parametry. Przykładowa deklaracja metody Porcess() dla obiek-tu Synchronizer została przedstawiona w tabeli 2.

Tab. 2. Deklaracja metody Porcess() w klasie

Synchronizer void Process(const float *data, size_t size, modeParameters *param, syncFe-edback *out);

Jedno wywołanie tej metody przetwarza pojedyn-

czą ramkę DAB+, czyli około 100 ms sygnału w trybie 1. Taka struktura programu jest bardzo elastyczna. Pro-ces może być skonfigurowany do pracy jedno lub wie-lowątkowej wyłącznie poprzez zmianę ,,zarządcy'' czyli obiektu Scheduler. Dodatkowo, poszczególne modu-ły można łatwo testować, ponieważ nie muszą one znać stanu innych modułów ani swojego wcześniejszego stanu. Założono, że poszczególne klasy będą posiadać tylko po jednym obiekcie, dlatego razem z poprzednim założeniem nietrudno jest zapewnić poprawność pracy w trybie wielowątkowym (tzw. thread safe).

Wszystkie obiekty przetwarzające dane zostały wykonane bez implementacji wątków. Obiekt Schedu-ler, jeżeli pracuje w trybie wielowątkowym (wykorzy-stując bibliotekę pthread), opakowuje klasę lub metodę (ang. wrapper function) odpowiednim kodem, wywołu-jąc ją na oddzielnym wątku. W ten sposób, ostatecznie tylko jeden fragment kodu biblioteki libsdrdab (obiekt Scheduler) zajmuje się obsługą wątków, tworzeniem buforów pośredniczących w wymianie danych oraz wie-lowątkową konfiguracją biblioteki.

4.2. Współdziałanie komponentów biblioteki Proces przetwarzania danych w projektowanej bi-

bliotece może zostać rozdzielony pomiędzy 4 wątki lub być wykonany sekwencyjnie na jednym wątku. Wyjątek stanowi akwizycja sygnału z tunera radiowego za pomo-cą biblioteki rtlsdr, która sama w sobie używa wątków. W konfiguracji wielowątkowej, pierwszy wątek zajmuje się akwizycją oraz wstępnym przetwarzaniem danych (obiekt klasy DataFeeder), w drugim wątku odbywa się synchronizacja i demodulacja sygnału (obiekty klasy Synchronizer i Demodulator), następny wątek jest odpowiedzialny za dekodowanie danych do postaci binarnego sygnału audio w formacie MPEG lub AAC (obiekt klasy DataDecoder), ostatni wątek to dekom-presja sygnału audio wraz z odtworzeniem na urządzeniu dźwiękowym lub zapisaniem do pliku (obiekt klasy AudioDecoder). Współdziałanie oraz synchronizację zadań pomiędzy wątkami zapewniana obiekt klasy Scheduler, który rezerwuje odpowiedniej długości bufory i wywołuje metody wyżej opisanych obiektów przekazując im przez argument wskaźniki na dane wej-ściowe i wyjściowe. Założono, że biblioteka będzie działała wielowątkowo, ale w obrębie jednego procesu. W takiej konfiguracji, na docelowych platformach sprzę-towych i programowych, wszystkie wątki w obrębie jednego procesu dzielą tę samą przestrzeń adresową. Dlatego też, nie trzeba używać mechanizmów pamięci dzielonej (ang. shared memory) albo innego (kosztow-

nego) mechanizmu przesyłania danych pomiędzy proce-durami obliczeniowymi. Procesy mogą komunikować się przez fragmenty pamięci (np. tablice w języku C/C++), zarezerwowane w pamięci głównej i dostępne z poziomu wszystkich wątków. Taki mechanizm jest bardzo efek-tywny ze względu na minimalne narzuty mocy oblicze-niowej oraz brak konieczności kopiowania danych, jed-nakże wymaga zapewnienia takiej kolejności czytania i pisania z i do buforów, aby uniknąć kolizji i hazardów.

Zapewnienie spójności przetwarzania danych jest realizowane przez obiekt klasy Scheduler, który wy-konuje te zadania mechanizmami dostarczonymi przez bibliotekę pthread. Zapewnienie spójności przetwarzania danych jest nietrywialnym zadaniem co pokazano na rysunku 9. Prezentuje on przypadek bufora (o nazwie sync_feeder_buffer_), do którego dane wpisuje obiekt DataFeeder, a odczytuje obiekt klasy Syn-chronizer.

Rys. 9. Schemat zależności pomiędzy odczytem i zapisem

w jednym z buforów kołowych Ze względu na implementację obu klas, długość

porcji danych zapisywanych (w0-w5) do bufora jest inna niż odczytywana (r0-r3). Co więcej, długość odczytywa-nej porcji danych nie jest całkowitą wielokrotnością długości zapisywanej porcji danych. Dodatkowo, dane są odczytywane z przesunięciem mniejszym niż długość odczytywanego bufora, czyli ,,na zakładkę''. Na rysunku 9 przedstawiono najbardziej skomplikowany przypadek, w którym do bufora o długości t3 wpisywane są porcje danych wx a odczytywane rx. Scheduler, zarządzający przesyłaniem danych, może wysłać do Synchronize-ra wskaźnik na początek bufora r2 dopiero wtedy, kiedy bufory w3 i w4 zostaną zapełnione, jednocześnie nie może pozwolić na zapis miejsca pamięci zajmowanego przez r2. W tym samym czasie, w5 mógłby być zapisy-wany przez DataFeeder ponieważ mieści się on w buforze, czyli kończy wcześniej niż w t3. Jednakże na-stępna porcja danych do odczytu - r3 skończyła by się w czasie t4, a więc poza całkowitą długością buforu (t3), dlatego w5 nie może być zapisany w miejscu wskazanym na rysunku (założono, że zarówno porcje danych do zapisu i odczytu muszą znajdować się w ciągłym frag-mencie pamięci). Dlatego też, w5 musi zostać zapisany na początku bufora, dodatkowo musi zostać poprzedzo-ny danymi znajdującymi się w zakresie od t1 do t2, które należy skopiować rozpoczynając od t0.

Taki schemat postępowania zapewnia możliwość równoczesnego działania obu fragmentów kodu (Data-Feeder i Synchronizer), minimalizuje liczbę ko-piowanych danych oraz zapewnia rozsądną długość bufora pośredniczącego w przekazywaniu danych. W rzeczywistości długość całego bufora musi być 3-4 razy

DataFeeder

r0

w0

Synchronizer

r1 r2 r3

w1 w2 w3 w4 w5

t0 t1 t2 t3t4

większa od długości bufora rx. W przypadku przetwarza-nia jednowątkowego, czyli takiego, w którym Syn-chronizer podczas przetwarzania danych z bufora rx blokuje działanie DataFeedera wpisującego dane do wx, całkowita długość bufora to rx.

4.3. Złożoność kodu W celu oszacowania złożoności napisanego kodu obliczono parametr LOC (ang. Line Of Code) kodu źródłowego. I tak, wszystkie źródła (pliki C/C++, pliki nagłówkowe oraz make) całego systemu, bez bibliotek i narzędzi pomocniczych zawierają około 7000 niepustych linii kodu w 82 plikach. Dodatkowo testy jednostkowe składają się z 2400 linii kodu w języku C/C++, zawar-tych w 32 plikach, oraz 1200 linii kodu w języku Matlab, zawartych w 24 plikach. Statystykę wykonano przy użyciu programu cloc uruchomionego ze standardowymi parametrami. Analizując te liczby należy mieć mając na uwadze orientacyjny charakter tej metody szacowania złożoności kodu.

Złożoność obliczeniową kodu programu odbiornika radia DAB+ wyznaczono badając czasy wykonania jego kluczowych części. Ze względu na trudności, związane z wykorzystaniem narzędzia gprof w wielowątkowym programie, użyto pomiaru czasu bazującego na odczy-tywaniu zegara systemowego przed i po wykonaniu analizowanego fragmentu programu. Odczyt czasu wy-konano za pomocą funkcji gettimeofday(), która pozwala na uzyskanie dokładności rzędu pojedynczych mikroseknud. W tabeli 3 zestawiono wyniki najważniej-szych metod.

Tab. 3. Czasy wykonania wybranych fragmentów kodu biblioteki libsdrdab, (*) dane z testów jednostkowych, (**) dane estymowane dla najgorszego przypadku (naj-

wyższy bitrate kanału audio) Nazwa metody Czas [ms]

DetectAndDecodeNULL 0.06 DetectPhaseReference 0.06 FFT (FIC+MSC) 0.07+0.20 DeQPSK+FreqencyDeinterleaver (FIC+MSC)

0.02+0.03

TimeDeinterleaver (MSC**) 0.24 DePuncturer (FIC+MSC*) 0.06+0.24 Viterbi (FIC+MSC**) 5.60+22.4 EnergyDispersal (FIC+MSC**) 0.01+0.01 ExtractDataFromFIC (FIC) 0.02 ReedSolomon (MSC) 1.22

Suma 30.24 Wyniki podano dla procesora i7-3520M @

2.90GHz. W związku z tym, że biblioteka w trakcie pisania tego artykułu była w fazie integracji, nie wszyst-kie moduły zostały ,,podpięte'' do Schedulera, dlate-go ich czasy zostały wyznaczone z testów jednostko-wych lub estymowane. Testy jednostkowe wykonano na rzeczywistych danych i z profilem generowania kodu takim jak dla docelowej biblioteki. W tabeli nie za-mieszczono czasu dekodowania strumienia audio z for-matu AAC, ponieważ w programie przerzucono tą ope-rację do biblioteki GStreamer, a w mobilnych zastoso-waniach można liczyć na sprzętowy dekoder tego forma-tu.

Z tabeli jasno wynika, że najbardziej złożone obli-czeniowe fragmenty kodu to dekoder Viterbiego (92,6% czasu) i Reeda-Solomona (4% czasu). Pozostała część kodu zajmuje zaledwie 3,4% czasu dekodowania radia DAB+. Jeżeli algorytm Viterbiego byłby przeszkodą w implementacji odbiornika w czasie rzeczywistym na słabszym CPU, można go zastąpić mniej dokładnym, ale znacznie szybszym dekoderem kodu splotowego.

5. PODSUMOWANIE

W artykule przedstawiono algorytm odbiornika ra-dia cyfrowego DAB+ oraz jego implementację progra-mową, napisaną w języku C++. Implementacja ta, wraz z układem RTL2832U + E4000/R820, daje działający w czasie rzeczywistym odbiornik radiowy. Program prze-twarza na bieżąco próbki IQ sygnału multipleksu radia cyfrowego pochodzące z przetwornika układu RTL. Oprogramowanie powstało w ramach projektu studen-tów kierunku Teleinformatyka w Katedrze Telekomuni-kacji AGH i jest możliwe do pobrania ze strony [38].

W artykule starano się wykazać, że praktyczna re-alizacja w technologii SDR odbiorników wybranych transmisji radiowych, przykładowo DAB, jest bardzo dobrym sposobem nauki podstaw telekomunikacji. Po-dejście to „bawiąc uczy”, równocześnie zapoznaje stu-dentów z zasadami i narzędziami programowymi pracy grupowej.

SPIS LITERATURY [1] H. Bogucka, “Technologie radia kognitywnego”, PWN, Warszawa 2013 [2] Joe Mitola,”Software Radio Architecture”, IEEE Com-munications Magazine, pp. 26-38, May 1995 [3] Jeffrey H. Reed,”Software Radio: A Modern Approach to Radio Engineering”, Prentice Hall, Upper S. River 2002 [4] B. Farhang-Boroujeny, “Signal Processing Techniques for Software Radios”, Lulu Publishing, Salt Lake City 2010 [5] C.R. Johnson, W.A. Sethares, A.G. Klein, “Software Receiver Design: Build Your Own Digital Communication System in Five Easy Steps”, Cambridge Univ. Press, 2011 [6] Ettus Research, Universal Software Radio Peripheral, http://www.ettus.com/ [7] Realtek, RTL2832U DVB-T COFDM Demodulator, http://www.realtek.com.tw/products/ [8] Oprogramowanie GNU Radio, http://gnuradio.org/ [9] National Instruments, http://www.ni.com/sdr/usrp/ [10] MathWorks, http://www.mathworks.com/hardware-support/usrp. html [11] MathWorks, http://www.mathworks.com/hardware-support/rtl-sdr.html [12] Artykuły zaproszone, “Communications Educations and Training: Software Defined Radio”, IEEE Communica-tions Magazine, vol. 52, no. 5, str. 182-209, May 2014. [13] Informacja o alternatywnym oprogramowaniu dla układu RTL2832U: http://www.rtl-sdr.com/, http://sdr. osmocom.org/trac/wiki/rtl-sdr [14] Program SDRSharp, http://www.sdrsharp.com/ [15] Program SDR-J (DAB), www.sdr-j.tk/ [16] A. Muller, „DAB Software Receiver Implementation”, Praca magisterska, Swiss Federal Inst. Tech., Zurych 2008 [17] M. Hoin, “SW-Realisierung lines DAB-Empfangers mit GNU Radio”, Praca magisterska, Zurcher Hochschule fur Angewandte Wissenschaften, Zurych 2011

[18] W. Hoeg, T. Lauterbach (red.), Digital Audio Broad-casting. Principles and Applications of Digital Radio, Wiley, Chichester 2003 [19] C. Gandy, “DAB: an introduction to the Eureka DAB System and a guide to how it works”, BBC R&D White Paper, str. 1-101, June 2003. [20] K. Taura et al., “A Digital Audio Broadcasting (DAB) Receiver”, IEEE Trans. on Consumer Electronics, vol. 42, no. 3, str. 322-327, August 1996 [21] F. van de Laar, N. Philips, J. Huisken, “Towards the next generation of DAB receivers”, EBU Technical Review, str. 46-59, Summer 1997 [22] F. Herrmann, L. A. Erismann, M. Prosch, „The Evolu-tion of DAB”, EBU Technical Review, vol. July, str. 1-18, 2007 [23] S. Meltzer, G. Moser, “MPEG-4 HE-AAC v2 - Audio Coding for Today’s Digital Media World”, EBU Technical Review, vol. January, str. 1-12, 2006 [24] D. Więcek, B. Gołębiowski, D. Niewiadomski, „Cyfry-zacja radiofonii wysokiej jakości”, Raport Z21/21300089/1315/09, Zakład Kompatybilności Elektro-magnetycznej Instytutu Łączności, str. 1-78, Wrocław 2009 [25] Polskie Radio Cyfrowe, http://dab.polskieradio.pl/ [26] EmiTel, http://www.emitel.pl/radio/radiofonia-cyfrowa-dab [27] ETSI TR 101 495, “DAB; Guide to DAB standards; Guidelines and Bibliography”, ver. 1.3.1, str. 1-19, 2006 [28] ETSI TR 101 496-1, 2, 3, “DAB; Guidelines and rules for implementation and operation; Part 1: System outline; Part 2: System features; Part 3: Broadcast network”, ver. 1.1.1, 2000 [29] ETSI EN 300 401, “Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers”, ver. 1.4.1, str. 1-197, 2006 [30] ETSI TS 102 563, “DAB; Transport of Advanced Au-dio Coding (AAC) audio”, 2010 [31] ISO/IEC 11172-3, “Coding of moving pictures and associated audio for digital storage media at up to about 1.5 mbit/s. Part 3: Audio“, 1992 (MPEG-1 MP2 48 kHz).

[32] ISO/IEC 13818-3, “IT - Generic coding of moving pictures and associated audio: Audio”, 1995 (MP2 24 kHz) [33] ISO/IEC 13818-7, “IT - Generic coding of moving pictures and associated audio information. Part 7: Ad-vanced Audio Coding (AAC)”, 1995 (MPEG-2/4 AAC) [34] ISO/IEC 14496-3, “IT - Coding of audio-visual ob-jects. Part 3: Audio”, 1999, 2005 (MPEG-4 HE-AAC v2) [35] “AAC Transport Formats”, Fraunhofer Institute IIS Application Bulletin, 2012 [36] T. P. Zieliński, “Cyfrowe przetwarzanie sygnałów. Od teorii do zastosowań”, WKŁ, Warszawa 2005. [37] M. Bartkowiak, „Kompresja sygnałów fonicznych”, str. 571-624, w „Cyfrowe przetwarzanie sygnałów w tele-komunikacji”, T.P. Zieliński, P. Korohoda, R. Rumian (red.), PWN, Warszawa 2014 [38] Strona projektu ze stworzonym oprogramowaniem: sdr.kt.agh.edu.pl [39] J.-J. van de Beek, M. Sandell, P. O. Borjesson, “ML Estimation of Time and Frequency Offset in OFDM Sys-tems”, IEEE Trans. on Signal Process., vol. 45, no. 7, str. 1800-1805, July 1997 [40] P. H. Moose, “A Technique for Orthogonal Frequency Division Multiplexing Frequency Offset Correction”, IEEE Trans. on Comm., vol. 42, no. 10, str. 2908-2014, 1994. [41] Ch.-R. Sheu, Y.-L. Huang, Ch.-Ch. Huang, “Joint Symbol, Frame, and Carrier Synchronization for Eureka 147 DAB System”, IEEE Int. Conf. on Universal Personal Communications Record, str. 693-697,1997. [42] Y.-L. Huang, Ch.-R. Sheu, Ch.-Ch. Huang, “Joint Synchronization in Eureka 147 DAB System Based on Abrupt Phase Change Detection”, IEEE Journal on Selected Areas in Comm., vol. 17, no. 10, str. 1770-1780, 1999. [43] Android Native Development Kit (Android NDK) https://developer.android.com/ndk/index.html [44] Biblioteka do zmiany częstotliwości próbkowania, http://www.mega-nerd.com/SRC/license.html [45] Serwer aplikacji multimedialnych, http://gstreamer.freedesktop.org/