MLAB wiki

Máte načtenou starší verzi dokumentu! Pokud ji uložíte, vytvoříte tím novou aktuální verzi.

====== Multikonstelační přijímač GNSS ======

Přijímač by měl být určený ke zpracování signálu a navigaci z aktuálně dostupných družicových navigačních systémů.

Cílem studie vtupního dílu multikonstelačního přijímače GNSS je nalézt odpověď na následující technické problémy:

- Způsob směšování signálu (převedení do digitalizovatelného pásma)
  - A/D převod signálu za směšovačem
  - Zpracování digitalizovaného signálu, tj. získání korelační funkce
  - Výstup digitálních dat a dat z korelátoru pro další zpracování

Jde převážně o zpracování v ustáleném režimu sledování je však nutné vzít v úvahu i nutnost
prvního zachycení v prostoru kmitočet/čas.

===== Zpracování RF signálu =====

Přijímač předpokládá připravený RF signál zbavený mimo-pásmového rušení a zesílený na úroveň vhodnou ke zpracování bez extrémních technických nároků na šumové a dynamické parametry (( 8bit ADC, SFDR < 55 dB)).  V řetězci zpracování signálu se dále již ze zadání předpokládá, že každý navigační systém bude obsluhován vlastním procesním řetězcem. Viz následující blokové schéma:

Při průzkumu možných řešení založených na [[http://en.wikipedia.org/wiki/List_of_software-defined_radios|dostupných konstrukcích SDR přijímačů]] bylo zjištěno, že žádný z nich není vhodný pro přímou realizaci multikonstelačního přijímače.  Mezi potenciálně nejvhodnější lze ale  zařadit tyto SDR přijímače:

* bladeRF
  * Bitshark Express RX
  * HackRF
  * XRAD-3200

Ve všech případech je ale problémem jejich vysoká cena pohybující se v řádu tisíců USD a dále také (kromě HackRF) uzavřený design.

==== Směšování ====

Většina navigačních družicových systémů vysílá ve frekvenčním pásmu mezi 1 až 2 GHz, je tedy nutné, aby se směšovací řetězec vypořádal minimálně s tímto frekvenčním rozsahem při zachování vhodných parametrů. Tento problém lze řešit i běžnými klasickými konstrukcemi superhetů. Ovšem vzhledem k tomu, že primárním cílem zpracování RF signálu je získat co nejlepší číslicový popis navigačního signálu, na což tyto konstrukce nebyly primárně vyvíjeny, je žádoucí uvažovat o jiných možnostech směšování do pásma vzorkovatelného dnešními ADC. Navíc zpracování digitalizovaného signálu je vhodné provádět v [[http://www.ni.com/white-paper/4805/en/|komplexní obálce]].

Z tohoto pohledu se přímo nabízí použití spínaného směšovače, který je výbornou aproximací ideálního směšovače (čtyř-kvadrantové násobičky). Z praktického konstrukčního pohledu je také velmi užitečnou vlastností, že tento typ směšovače pracuje s digitálním signálem lokálního oscilátoru, který se nejenom velmi snadno generuje ale i snadno přenáší. Navíc na tento signál lze snadno fázové zavěsit další digitální obvody, které tak mohou pracovat synchronně se směšovačem.

Hlavní překážkou realizace přijímače se spínaným směšovačem je nedostupnost dostatečně rychlých elektronických spínačů, které by umožňovaly přímé vzorkování navigačního signálu. Tento problém je ale možné obejít použitím optických spínačů. Například v podobě polovodičových laserových diod, které jsou pro spínání na těchto frekvencích dostatečně rychlé.

==== Realizace optického spínaného směšovače ====

Spínaný směšovač lze z optických prvků vytvořit například tak, že klasické elektronické spínače v RF cestě za LNA budou ještě v blízkosti antény nahrazeny za laserové diody ukončené optickými vlákny. Tyto laserové diody budou mít proudový bias napájený RF signálem, který je třeba konvertovat a vzorkovat. Samotné spínání pak bude realizováno přivedením jednoho kvadrantu signálu LO na aktivační vstupy řídící elektroniky laseru. Laserová dioda tak vytvoří impulz jehož energie bude úměrná amplitudě RF signálu za dobu vzorku.  
A tento signál se bude dále šířit optickým vláknem.

==== Digitalizace ====

Výše uvedeným způsobem bude signál rozfázován do čtyř optických vláken podobně, jako v klasické konstrukci spínaného směšovače. Na konci těchto optických vláken budou detekční fotodiody s trans-impedančními zesilovači a  spínané integrátory, které zintegrují každý celý přijatý impulz. Tento impulz bude ovzorkován ADC a integrátor resetován. Následně může být přijat další impulz, který bude opět ovzorkován a integrátor resetován.

Samotná digitalizace signálu pak může být provedena některým komerčně dostupným ADC. Vzhledem k požadavkům na vzorkování více navigačních RF kanálů paralelně je vhodné zvolit některý obvod určený pro zpracování paralelních signálů. Což jsou například ADC určené pro zpracování vícekanálových ultrazvukových signálů. Takový obvod využívá modul [[cs:adcoctospi|ADCoctoSPI01A]].

Tato konstrukce by měla přinášet několik revolučních zlepšení:

- Možnost realizace spínaného směšovače i pro vysoké kmitočty řádově desítky GHz
  - Omezení zpětného vyzařování spínacích prvků do antény. 
  - Snížení nutných požadavků na antialiasing filtr před ADC. 
  - Možnost dynamického nastavení šířky pásma (závisí na nastavení integrátoru a synchronizaci se vzorky spínaného směšovače). 
  - Lepší parametry přenosu signálu od antény - Optická vlákna mají cca o řád nižší útlum. Přenos po optických vláknech také nemůže být ovlivněn elektromagnetickým rušením z prostředí ve kterém je veden.
  - Nemohou vznikat problémy způsobené vedením více paralelních stínění.

===== Korelační jednotka =====

Úkolem korelační jednotky je získávat informace o posuvu navigačních signálů a udržovat jejich sledování.  Skládá se ze soustavy korelátorů, generátoru repliky dálko-měrného kódu a regulační smyčky.  Celý systém je pak implementovaný v FPGA.
Pro testovací účely by v tomto případě bylo možné využít modul [[cs:s3an|S3AN01B]]

===== Komunikační rozhraní =====

Komunikační rozhraní přijímače bude řešit přenos dat mezi výpočetní/řídící jednotkou a  FPGA, ve kterém budou implementovány korelátory a základní komunikační protokol pro přenos dat.  Na samotný přenos dat jsou kladeny tyto požadavky:

Na základě těchto požadavků na datové přenosy připadá v úvahu pouze několik dostupných rozhraní.

==== USB 3.0 ====

Toto rozhraní je nyní velmi rozšířené a jeho přenosové parametry by byly vyhovující pro uvažovanou aplikaci přijímače. Komplikací ovšem je jeho implementace, neboť má velmi složitý komunikační protokol. A jeho implementace v FPGA je náročná a pravděpodobně by vyžadovala přídavné [[http://www.cypress.com/?id=4833|externí periferie]]. Tímto způsobem je řešena například konstrukce bladeRF.

==== PCI Express ====

[[http://en.wikipedia.org/wiki/PCI_Express|PCI Express]] je sběrnice dnes již velmi rozřířená ve výpočetním hardwaru. Oproti USB 3.0 má mnoho vylepšení vhodných pro přenos dat v reálném čase. Jedním z nich je například DMA. Další výhodou je na rozdíl od USB 3.0 poměrně nenáročná implementace v FPGA.  Nevýhodou tohoto rozhraní je jeho problematické vedení na delší vzdálenost. Proto je prakticky omezené pouze na základní desky počítačů.

==== Thunderbolt ====

Jde o komunikační rozhraní vycházející z efektivity rozhraní PCI Express ale rozšiřuje jej o možnost vedení na delší vzdálenosti mimo základní desku počítače. Podstatným přínosem tohoto řešení by byla nezávislost na zvolené výpočetní platformě v době vývoje. Desku s korelátory by bylo proto možné pro účely vývoje propojit se standardním počítačem pomocí modulu [[cs:tbpcie|TBPCIE01A]], 
A po zvolení konkrétního výpočetního hardwaru by přijímač byl připojený přímo na jeho PCI Express sběrnici. Tímto způsobem by bylo možné obejít problematický bod volby řídícího počítače.
===== Řídící počítač =====

Volba řídící jednotky korelátoru GNSS přijímače je spolu se sofwarovou implementací algoritmů pravděpodobně nejkritičtější součástí projektu. Neboť v současné době v tomto směru dochází k intenzivnímu vývoji na straně výrobců výpočetní techniky.  Řídící počítač bude řešit tyto hlavní úkoly:

- Periodickou obsluhu korelátorů (časově kritická záležitost)
  - Akvizice přijímače (Výpočetně náročná záležitost)
  - Výpočet polohy, dekódování navigační zprávy a příprava dat pro uživatele.

==== Obsluha korelátorů ====

Přijímač bude vybaven 50 - 100 korelátory signálu, které budou implementovány v FPGA. Korelátory vyžadují periodickou obsluhu nejdéle jednou za 1 ms vždy na konci posledního bitu PRN kódu. Konec PRN kódu nastává u jednotlivých kanálů v různých časech. Navíc v důsledku Dopplerova jevu dochází k tomu, že
perioda kódu se u každé družice mírně liší.

Obsloužení korelátoru znamená přečtení minimálně 10 až 20 32-bitových registrů, výpočet algoritmu a zápis dvou 32 bitových registrů. Algoritmus sice není výpočetně
náročný a lze jej implementovat i v pevné desetinné čárce. Ale při obsluze korelátorů nesmí nastávat výpadky. V opačném případě nastane skoková chyba pseudovzdálenosti, naruší se synchronizace navigační zprávy a
celého obslužného programu. Opravou je pak provedení opětovného nastavení kanálu, nová akvizice a synchronizace dálko měrného kódu.

==== Akvizice přijímače ====

V tomto režimu je potřeba přenést do výpočetní jednotky vzorky signálu z jednoho
RF kanálu o časovém úseku 10 až 100 ms a vzorky následně zpracovat. Vzorkovací rychlost se bude pohybovat mezi 20 až 25 Msps. Bude vzorkována komplexní obálka, takže jeden vzorek bude reprezentován dvěma
slovy, požadovaný datový objem přenosu tedy je přibližně 40 až 50 MB/s. Celkový objem
přenášených dat pro jeden výpočet je 500 kB až 5 MB.

Základem zpracování naměřeného úseku signálu v počítači je výpočet vícerozměrné korelace.
Tuto korelaci lze s výhodou počítat pomocí FFT. Pro většinu GNSS signálů
se signál rozdělí do úseků o době trvání 1 ms, signál se převede do spektra,
vynásobí spektrem repliky a pak zase zpátky do časové oblasti, jednotlivé úseky
se přitom nekoherentně sčítají. Tento algoritmus lze dnes efektivně počítat v GPU
 
V režimu akvizice je kritický pouze přenos dat z FPGA do počítače, vlastní výpočet
pak může běžet asynchronně.

==== Pomocné procesy na řídící jednotce ====

Výpočet polohy, dekódování navigační zprávy a řízení přijímače jsou časově
nekritické činnosti. Provádí se podle požadované hustoty navigačních dat, výpočty je ale potřeba provádět
v plovoucí desetinné čárce. Jsou vyžadovány maticové operace.
Pro uložení navigační zprávy od 100 družic je třeba cca. 1 MB paměti.
Algoritmy řízení přijímače budou komunikovat s FPGA. Komunikace bude časově
nekritická. Přenášený objem dat bude kolem 1 kB za sekundu v obou směrech.

Z uvedených požadavků na výpočetní výkon a komunikační rozhraní vychází koncepce FPGA s DMA přenosem do paměti výpočetní jednotky jako nejlepší řešení. Navíc v připadě použití operačního systému Linux tak, aby jeden procesor (jádro) obsluhoval jen hardware, tak by byl zároveň odstraněn problém s latencí interruptů (jinak lze řešit i bez přerušení jen semafory v operační paměti). Zbývající jádra by pak mohla být použita na časově nekritické výpočty.

Jako výpočetní jednotka by v takovém případě mohl být použit některý [[https://en.wikipedia.org/wiki/Comparison_of_single-board_computers|jednodeskový počítač]] vybavený více-jádrovým procesorem ARM a GPU jednotkou podporující OpenCL pro výpočet akvizice.

===== Programové zpracování =====

Vytvoření softwaru je nejproblematičtější částí projektu. Jelikož softwarové algoritmy jsou hlavní částí projektu.

Ideálním řešením obsluhy přerušení by bylo přesměrování intrerruptu od korelátorů pouze na jedno jádro procesoru (známé jako afinita procesoru).

* Latence přerušení ve stovkách mikrosekund je obtížně zajistitelná běžnými prostředky OS
  * Použití jiného OS než Linuxu může být problém v ceně a obtížnosti SW realizace (licence, nástroje, know-how).

Na dnešním HW FPGA je k dispozici PCIe Gen 2, tedy cca 500MB/s full-duplex. To znamená, že přenos 5MB  bude trvat přibližně 1ms (reálně počítejme spíš 2-3ms). Za stejnou cenu můžeme mít i PCIe Gen2 x4.

Latence čtení přes PCIe (čas od požadavku do obdržených dat) bývá řádově stovky nanosekund (a hodně závisí na mainboardu a na tom, co počátač dělá). Zápisy jsou příznivější, protože se na ně nečeká. Tedy data ze zařízení je lepší přenášet DMA do paměti PC, zápis z PC do FPGA je možné přímo, ale je to nevýhodné pokud to je víc, než několik slov. Procesor prakticky negeneruje burst přenosy.

==== Real-time operační systémy ====

* [[http://www.qnx.com/products/neutrino-rtos/index.html|QNX]]
  * [[https://rt.wiki.kernel.org/index.php/Main_Page|Real-Time Linux]]

===== Úkoly k vyřešení =====

* Dokončení návrhu potřebných modulů
  * Výběr vhodné výpočetní jednotky
  * Rozhodnutí o nutnosti, nebo zbytečnosti použití RTOS systému
  * Provedení otestování navrženého řešení

===== Výsledky studie =====

Studie se zabývala nalezením řešení na několik technických problémů, které jsou ale vzájemně provázány tak, že pravděpodobně nebude možné nalézt konečné řešení v jednom kroku. Proto by bylo vhodné zvolit postupnou aproximaci, kdy bude nejdříve realizován testovací přípravek, který bude sloužit primárně k ověření správné implementace algoritmů, které jsou realizačně nejnáročnější částí celého problému. Tento testovací přípravek by se měl zaměřit nejdříve pouze na jeden navigační systém, neboť náročnost problému se se vzrůstajícím počtem použitých navigačních systémů škáluje nelineárně, v důsledku toho, že každý navigační systém potřebuje jiný algoritmus obsluhy.

==== Realizace funkčního demonstrátoru ====

===== Reference =====

* [[http://www.nsl.eu.com/primo.html|GNSS SDR Front End and Receiver]]
  * [[http://gnss-sdr.org/|GNSS-SDR]]
  * [[http://www.holmea.demon.co.uk/GPS/Main.htm|Homemade GPS Receiver]]
  * [[http://www.witchnav.cz/doku.php|The Witch Navigator]] - projekt open source GNSS přijímače FEL ČVUT.

Vyplňte, prosím, všechna písmena v poli, abyste dokázali, že nejste robot. J X X J L Ponechte prosím toto pole prázdné:

Komentář k úpravám

Poznámka: Tím, že editujete tuto stránku, souhlasíte, aby váš obsah byl licencován pod následující licencí: CC Attribution-Noncommercial-Share Alike 4.0 International