SDR pro QRP - 4.díl: Úskalí, která ještě musíme vyřešit.

Abychom se už konečně mohli začít zabývat konkrétní realizací SDR softwaru, tzn. otázkami typu: na jakém procesoru to má běžet, jakým jazykem budeme software psát, či v jakém vývojovém prostředí bude tento projekt vyvíjen, je potřeba ještě zodpovědět jednu "kardinální" a několik méně podstatných otázek. Musíme si uvědomit, že veškeré operace (a budou to operace pouze matematické), které budeme se signály "I" a "Q" provádět, zaberou nějaký reálný čas. Naším úkolem bude tedy zajistit, aby přijímač reálně fungoval tak, že tuto latenci (zpoždění mezi vstupem signálu do QSD a výstupem signálu do sluchátek) nebudeme vnímat, lépe řečeno, latence neovlivní schopnost TRX dělat reálné QSO. Přiznám se, že mi to trvalo poměrně dlouho, než jsem to pochopil, jak se to udělá, ale toto považuji pro sebe za naprosto zásadní "objev", který mi v podstatě umožnil vůbec pokračovat.

Na tomto místě trošku předběhnu "dějovou" linku mého seriálu. Real Time Audio Processing - zpracování audio signálu v reálném čase, to je to, co musíme vyřešit. Uspokojivé řešení bylo možné použít až s příchodem a dostupností procesorů ARM M4. Tento 32 bitový procesor vyrábí více firem, já budu používat ten od firmy STMicroelectronics - STM32F4, což je procesor s jádrem ARM M4. Jeho rychlost a velikost paměti RAM jsou ty základní vlastnosti, které nám umožní zpracovat audio signál v reálném čase. Ale jak se to konkrétně udělá? Je možno najít mnoho prezentací a teoretických prací o tom, že to lze udělat, ale nalézt něco praktického, bylo pro mě obtížné a musel jsem toho mnoho zhlédnout a přečíst, abych se konečně dostal k "jádru pudla". Jedná se o toto dvoudílné video:

Part 1 of 2: ADC to DAC via DMA
Part 2 of 2: ADC to DAC via DMA

Tahle 2 videa doporučuji zhlédnout a třeba i opakovaně. Pro pochopení nášeho dalšího snažení je to naprosto klíčové. Obrázek, který jsem "vystřihnul" z videa, se nyní pokusím popsat.

Obrázek ukazuje, jak budou data procesorem zpracovávána. Pracuje se zde jen s jedním ADC kanálem (signálem), my budeme pracovat v reálu se dvěma, ale pro názornost to postačí, možná je to i lepší pro pochopení. Signál vstupuje do ADC. To již známe, je to náš analogově-digitální převodník, který nám převede analogový signál (m.j. spojitý signál) do digitální podoby, tedy do podoby diskrétních hodnot napětí. Kolik se jich za jednotku času vytvoří je dáno rychlostí vzorkování. Tu má na starosti Timer (časovač). Tato vnitřní komponenta procesoru, na základě konfigurace, kterou mu dáte, bude v nekonečné smyčce opakovaně dávat ADC příkaz, aby udělal další převod a výsledek uložil do paměti procesoru.

O ukládání naměřených hodnot do paměti se stará další komponenta procesoru: Direct Memory Access - modul pro přímý přístup do paměti. Přímý proto, že data jsou ukládána do paměti bez nutnosti je nejprve načíst do nějaké proměnné a o všechno se starají vnitřní řídící struktury procesoru, nemusíte se o přesun dat starat vy ve vašem programu. Inicializací a spuštěním DMA na začátku vše běží automaticky bez vašeho zásahu a takto ušetřený čas můžete trávit prací s naměřenými hodnotami. DMA ukládá naměřené hodnoty na adresu v paměti označené na obrázku jako ADC buffer. Vidíte, že je rozdělen na poloviny Upper a Lower (horní a dolní). Mechanismus ukládání používá tzv. Circular buffer. Základní vlastnost takového "rotujícího" bufferu je to, že pokud je vyčerpáno místo v bufferu, které jsme mu přidělili při jeho inicializaci, začne zapisovat znovu od začátku a dříve uložené hodnoty jsou tak přepsány. To ale nemůžeme potřebovat. My chceme zpracovat všechny hodnoty, které jsme naměřili.

O to se postará další vlastnost modulu DMA. Ta vyvolá přerušení (pokud si to budeme přát), pokud dojde ukazatel zápisu do poloviny kapacity bufferu (Half Transfer Complete) a znovu, když dojde na konec (Full Transfer Complete). Přerušení vyvolaná DMA jsou skutečná přerušení běhu programu, všechno se zastaví a program skočí na adresu danou tzv. vektorem přerušení, kde vykoná tam uložené příkazy. Musíme zajistit, aby těch příkazů bylo co nejméně, aby se program zastavil jen na co nejkratší dobu. Provede se to tak, že v obslužném podprogramu pro obsluhu tohoto přerušení nastavíme jen nějakou proměnnou, která bude našemu uživatelskému programu signalizovat, že data jsou připravena pro zpracování. To bude trvat řádově mikrosekundy, takže to v podstatě nepoznáme. Po vykonání této jediné instrukce se totiž běh programu vrátí zpět do místa, odkud byl přerušen a pokračuje dál.

Uprostřed obrázku je žlutý obdélník nazvaný Process_Data(). Jak správně tušíte, toto je náš SDR software. Ten převezme data z ADC bufferu, zpracuje je a výsledek zpracování uloží do DAC bufferu. Ten je rovněž rozdělen na dvě poloviny a ukazatel zápisu do něj je rovněž řízen modulem DMA. Ale jiným, než byl na vstupu. Pokud měl stream (proud) dat u DMA, který přebíral data z ADC nastaven směr periferie (ADC) -> paměť, tak tento DMA stream má nastaven směr přesně opačný, paměť -> periférie (DAC). Timer u DAC dává příkaz DAC, aby "přehrál" jeden vzorek zpracovaných dat.

Kolik času nám tedy zbývá v žlutém obdélníku na naše zpracování dat? Budeme-li vzorkovat rychlostí 48kHz a použijeme-li buffer o velikosti 256 vzorků, bude jejich načtení do bufferu trvat přibližně 5,3 milisekundy. Během této doby musíme stihnout signál zpracovat, ale také "obsloužit" enkodér, přeladit hlavní VFO, překreslit display případně zareagovat na zmáčknutá tlačítka. Každá tato úloha má jistě jinou prioritu a podle ní musí být software napsán tak, aby latence nebránila plynulému chodu přijímače.

Nyní se dostáváme k těm méně podstatným problémům, které je možné, ale ne nutné vyřešit. Prvním z nich je fakt, že se jedná o přímosměšující přijímač a že tak v podstatě pracujeme se signálem, jehož spektrum je rozprostřeno okolo nuly, tedy okolo signálu s kmitočtem 0Hz. Hlavní problém takového spektra je to, že právě okolo nuly máme různé šumy a brumy, jako např. 50Hz ze sítě apod. My zde chceme přijímat CW se záznějem např. 700Hz. Tím se nacházíme přesně v místě, kde bude těch šumů a brumů nejvíce, protože ty jsou soustředěny právě v oblasti +/- 1kHz okolo nuly. Abychom zabránili pronikání tohoto rušení na výstup, můžeme z přímosměšujícího přijímače udělat superhet s jedním směšováním. Prostě nebudeme demodulovat spektrum z okolí nuly, ale někde níže nebo výše. Zavedeme prostě do přijímače mezifrekvenci na nějakém nízkém kmitočtu větším než 1kHz. To provede buď směšováním "I" a "Q" s kvadraturním signálem z oscilátoru dejme tomu 12kHz (jako u Weaver metody) nebo uvedený posun kmitočtu provedeme matematicky. Existuje totiž popsaný a v praxi odzkoušený trik, kdy bez potřeby násobení (což je směšování) provedeme nad několika vzorky jednoduché sčítací a odečítací operace. Tento trik funguje tehdy, pokud se chceme posunout o 1/4 vzorkovací frekvence nahoru nebo dolů. Takže pokud budeme vzorkovat rychlostí 48kHz, uvedeným jednoduchým trikem se posuneme o plus nebo minus 12kHz.

Druhým problémem nabízející se k řešení je AGC. Přiznám se, že zatím nevím, jak to softwarově udělat. Mám dva zdrojové kódy s vyřešeným AGC, ale zatím jim moc nerozumím. Nicméně si myslím, že QRP CW TRX se bez AGC na začátku jistě obejde. Nemá to být (zatím) rádio do závodů. U "lepších" SDR rádií je blok, který řeší odchylku amplitudy a fáze mezi "I" a "Q" automaticky. Pokud "můj" RX bude trpět nedostatečným potlačením opačného postranního pásma, což je důsledek těchto odchylek, pokusím se takovou auto opravu zařadit do svého softwaru také.

Dnes to bylo trochu delší, ale o to důležitější. Příště se podíváme, jak SDR software stejného typu řeší profíci. Jejich zdrojové kódy jsou to nejcennější, co mám.