MLAB wiki

Uživatelské nástroje

Nástroje pro tento web

Historie:
cs:gnss

Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

Obě strany předchozí revizePředchozí verze
Následující verze		Předchozí verze
cs:gnss [2013/11/23 22:49] – [Akvizice přijímače] kaklikcs:gnss [Unknown date] (aktuální) – upraveno mimo DokuWiki (Unknown date) 127.0.0.1
Řádek 1: Řádek 1:
 ====== Multikonstelační přijímač GNSS ====== ====== Multikonstelační přijímač GNSS ======
  
-Přijímač by měl být určený ke zpracování signálu a navigaci na základě aktuálně dostupných družicových navigačních systémů. +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 ===== ===== 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.  V řetězci zpracování signálu se 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ř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: 
  
-{{:cs:designs:gnss:gnss_sdr.png?direct&600|}}+{{:cs:designs:gnss:gnss_sdr.png?direct&850|}}
  
 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:  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: 
Řádek 16: Řádek 26:
   * XRAD-3200    * 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. +Ve všech případech je ale překážko jejich vysoká cena, která neumožňuje efektivně realizovat vícekanálový přijímač a dále také (kromě HackRF) uzavřený design. 
  
 ==== Směšování ==== ==== Směšování ====
Řádek 22: Řádek 32:
 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]].  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. +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 principiálně 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é.  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é. 
Řádek 30: Řádek 40:
 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.   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. A tento signál se bude dále šířit optickým vláknem.
 +
 +Tento způsob přenosu je znám jako [[http://arxiv.org/pdf/1308.5481.pdf|Radio-Frequency-over-Fiber link for large-array
 +radio astronomy applications]]
  
 ==== Digitalizace ==== ==== Digitalizace ====
Řádek 48: Řádek 61:
 ===== Korelační jednotka ===== ===== 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. +Ú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. Jde o zařízení, které obsahuje časově kritické výpočty na velkém objemu dat. Datové toky uvnitř soustavy korelátorů dosahují běžně řádu stovek MB/s neboť je pracováno paralelně s relativně dlouhými úseky signálu. 
-Pro testovací účely by v tomto případě bylo možné využít modul [[cs:s3an|S3AN01B]]+Tyto vlastnosti vzhledem k dostupnému výpočetnímu výkonu dnešních CPU a GPU implikují nutnost hardwarové implementace korelačních algoritmů. Z tohoto důvodu je pak celý tento systém implementovaný v FPGA. 
 +Pro testovací účely by v tomto případě bylo možné využít některý ze série modulů [[cs:s3an|S3AN01B]]
  
  
Řádek 61: Řádek 75:
 |Pomocné operace | Upload/Download cca 1kB/s | Časově nekritické | |Pomocné operace | Upload/Download cca 1kB/s | Časově nekritické |
  
-Na základě těchto požadavků na datové přenosy připadá v úvahu pouze několik dostupných rozhraní.+Na základě těchto požadavků na datové přenosy připadá v úvahu pouze několik dostupných rozhraní. Konktrétní volba komunikačního rozhraní souvisí se způsobem implementace obsluhy korelačňí jednotky. Viz sekce [[cs:gnss#obsluha_korelatoru|Obsluha korelátoru]] 
  
 ==== USB 3.0 ==== ==== 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. +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. Na druhou stranu však existuje [[http://www.xilinx.com/products/intellectual-property/USB3_DEV.htm|USB 3.0 device IP core]] od Xilinx, který deklaruje i možnost použití DMA.
  
 ==== PCI Express ==== ==== 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čů. +[[http://en.wikipedia.org/wiki/PCI_Express|PCI Express]] je dnes standardní expanzní sběrnice rozšířená ve výpočetním hardwaru včetně průmyslových aplikací. 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 nativní podpora [[http://cs.wikipedia.org/wiki/DMA|DMA]]. Další výhodou je na rozdíl od USB 3.0 poměrně nenáročná implementace v FPGA, jelikož většina dnešních FPGA obsahuje HW core blok, který připojení na sběrnici PCIe podporuje.  Nevýhodou tohoto rozhraní je jeho problematické vedení na delší vzdálenost. Proto je prakticky omezené pouze na základní desky počítačů a jejich nejbližší okolí. 
  
 ==== Thunderbolt ==== ==== 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]],  +Jde o komunikační rozhraní vycházející z efektivity použití PCI Express jenž rozšiřuje o možnost vedení na delší vzdálenosti mimo základní desku počítače. Toho je dosaženo použitím aktivních metalických, nebo optických kabelů. 
-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.+ 
 +Podstatným přínosem tohoto řešení je 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 PC 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. A tím se vyhnout zastarání výpočetního HW před ukončením vývoje. 
 ===== Řídící počítač ===== ===== Řídící počítač =====
  
Řádek 82: Řádek 99:
   - Akvizice přijímače (Výpočetně náročná 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.   - Výpočet polohy, dekódování navigační zprávy a příprava dat pro uživatele.
 +
 +Vzhledem k tomu, že aktuálně je velmi perspektivní architektura ARM, která se však velmi rychle vyvíjí. Tak by bylo vhodné jako výpočetní jednotku pro testovací účely využít standardní PC a pak přejít na ARM po základním otestování algoritmů.
  
 ==== Obsluha korelátorů ==== ==== Obsluha korelátorů ====
Řádek 88: Řádek 107:
 perioda kódu se u každé družice mírně liší. 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ě +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álkoměrného kódu.  
-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.+Protože obsluha korelátoru je pak časově náročným problémem existují dva možné přístupy k jeho řešení.  
 + 
 + 
 +=== Obsluha korelátoru výpočetní jednotkou umístěnou v FPGA === 
 + 
 +Pro obsluhu korelátorů, které musí být za současných technických možností nutně hardwarově implementovány se nabízí jejich obsluha přímo v FPGA.  
 + 
 +Výhody tohoto přístupu: 
 + 
 +  * Menší nároky na přenosovou kapacitu a latenci datové linky mezi FPGA a nadřazeným výpočetním systémem. 
 +  * Větší efektivita algoritmů a menší latence obsluhy korelátorů. 
 + 
 +Tento přístup využívá například konstrukce [[http://www.holmea.demon.co.uk/GPS/Main.htm|Homemade GPS Receiver]]. 
 + 
 +Nevýhody tohoto řešení: 
 + 
 +  * Problematická možnost aktualizace a úpravy algoritmů obsluhy. V podstatě nemožnost dynamické adaptace algoritmů. 
 +  * Nutnost specifické komplikované konstrukce výpočetní jednotky pro každý navigační systém zvlášť. 
 +  * Problematická realizace konstrukce výpočetní jednotky. (Nejsou dostupné vhodné vývojové nástroje) 
 + 
 +Většinu nevýhod tohoto přístupu by sice bylo možné eliminovat použitím FPGA s integrovaným MCU architektury ARM. Avšak tyto hradlová pole jsou dostupná pouze v nepřijatelných cenových relacích řádu stovek USD.  
 + 
 +=== Obsluha korelátoru vnější výpočetní jednotkou === 
 + 
 +Obsluha korelátorů implementovaných v FPGA může být také realizována vnější výpočetní jednotkou. Která bude dynamicky provázána se stavy korelátorů v FPGA, toto je umožněno například komunikačním rozhraním s možností použití DMA. V takovém případě pak nadřazená výpočetní jednotka periodicky kontroluje stav všech korelátorů pomocí obrazu ve vlastní paměti.  
 +A na základě těchto stavů řeší jejich obsluhu.  
 + 
 +Výhody řešení: 
 + 
 +  * Snadná možnost dynamické aktualizace metody obsluhy korelátorů změnou programu v nadřazené výpočetní jednotce. 
 +  * Implementační obtížnost je podobná pro všechny navigační systémy. 
 +  * Systém lze téměř libovolně škálovat, protože jeho rozsah je limitován pouze přenosovou kapacitou použitého rozhraní a výpočetním výkonem nadřazené řídící jednotky. 
 + 
 +Nevýhody řešení: 
 + 
 +  * Nutnost dobře implementovaného driveru a řadiče DMA.  
 +  * Nutnost vysokorychlostní datové komunikační linky mezi FPGA a nadřazenou výpočetní jednotkou.  
  
 ==== Akvizice přijímače ==== ==== Akvizice přijímače ====
Řádek 103: Řádek 159:
 se signál rozdělí do úseků o době trvání 1 ms, signál se převede do spektra, 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 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+se přitom nekoherentně sčítají. Tento algoritmus lze dnes efektivně počítat v GPU pomocí OpenCL
    
 V režimu akvizice je kritický pouze přenos dat z FPGA do počítače, vlastní výpočet V režimu akvizice je kritický pouze přenos dat z FPGA do počítače, vlastní výpočet
Řádek 118: Řádek 174:
 nekritická. Přenášený objem dat bude kolem 1 kB za sekundu v obou směrech. 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 na víceprocesorovém systému 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.
- +
-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.  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. 
Řádek 127: Řádek 181:
 ===== Programové zpracování ===== ===== Programové zpracování =====
  
-Vytvoření softwaru je nejproblematičtější částí projektu. Jelikož softwarové algoritmy jsou hlavní částí projektu. +Vytvoření softwaru je nejproblematičtější částí projektu. Jelikož softwarové algoritmy jsou hlavní částí probrému. 
  
 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).  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). 
Řádek 143: Řádek 197:
   * [[https://rt.wiki.kernel.org/index.php/Main_Page|Real-Time Linux]]   * [[https://rt.wiki.kernel.org/index.php/Main_Page|Real-Time Linux]]
  
 +===== 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. 
 +
 +==== Testovací přípravek ====
 +
 +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 korelační jednotky. 
 +
 +Pro realizaci testovacího přípravku by bylo vhodné využít již existující řešení kombinace FPGA a přijímače a rozhraní k výpočetní jednotce. Přijímač v této fázi může být řešen libovolným způsobem, protože v této fázi jde primárně o vyřešení algoritmických problémů.
 +
 +Vhodným existujícím přijímačem by v takovém případě byl přímo [[http://www.witchnav.cz/doku.php|WitchNavigator]], který má parametry vyhovující i pro případnou implementaci obsluhy korelátoru výpočetní jednotkou umístěnou v FPGA. Pro přenos dat WitchNavigator používá rozhraní PCI Express, které je svými parametry dostatečné pro implementaci obou přístupů implementace obsluhy korelátorů, navíc nemá problém s přenosem dat v režimu akvizice. 
 +
 +Jako nadřazenou výpočetní jednotku by bylo rozumné pro testovací účely použít standardní PC Ix86 platformu s operačním systémem Linux, nebo unix. Důvodem k tomuto postupu je skutečnost, že PC poskytuje aktuálně největší dostupnou výpočetní kapacitu pro signálové výpočty.  
 +
 +Během vývoje softwaru na testovacím přípravku by měla být řešena hardwarová realizace směšování a digitalizace vstupního signálu. 
 +
 +==== Realizace funkčního demonstrátoru ====
 +
 +Rozšířením testovacího přípravku na další navigační systémy a na více kanálů by došlo k realizaci funkčního demonstrátoru zařízení.  Toto rozšíření může být provedeno jednak přidáním redukčních karet na [[http://en.wikipedia.org/wiki/ExpressCard|ExpressCard]] pro Witchav do standardního PCIe slotu. A nebo použitím rozhraní Thunderbolt a [[https://secure1.sonnettech.com/product_info.php?cPath=139_140&products_id=483&osCsid=5029180b717416fd01080441c68d0d03|adaptéru pro PCI Express card]].  
 +
 +{{ :cs:fpga:sonnet-echo-thunderbolt-to-expresscard34-adapter-echo-e34.jpg?direct&300 |}}  
 +
 +Tyto adaptéry pak mohou být propojeny externě mimo skříň počítače v konfiguraci "daisy chain", výsledné zařízení proto může být připojeno pouze jedním kabelem. 
 +
 +==== Prototyp GNSS přijímače ====
 +
 +Pro konstrukci prototypu přijímače by bylo vhodné realizovat kompletně nový návrh celého přijímače včetně výpočetní jednotky, která by měla být založena na [[cs:arm|architektuře ARM]] s těmito požadavky:
 +
 +  * GPU podporující OpenCL (Výhodné pro výpočet akvizice)
 +  * MCU s PCIe rozhraním (Vhodné pro komunikaci mezi FPGA a MCU)
 +
 +Zatím bohužel ale takový ARM MCU není dostupný. Nejvhodnější vývojová deska tohoto typu je zatím ODROID-XU, která sice obsahuje GPU s podporou OpenCL. Avšak nemá PCI Express. Jedinné vysokorychlosní rozhraní je USB 3.0
  
 ===== Úkoly k vyřešení ===== ===== Úkoly k vyřešení =====
  
   * Dokončení návrhu potřebných modulů   * Dokončení návrhu potřebných modulů
-  * Výběr vhodné výpočetní jednotky +  * Výběr vhodné výpočetní jednotky pro realizaci prototypu 
-  * Rozhodnutí o nutnosti, nebo zbytečnosti použití RTOS systému+  * Rozhodnutí o nutnosti, nebo zbytečnosti použití RTOS systému (na základě experimentů s testovacím přípravkem)
   * Provedení otestování navrženého řešení   * Provedení otestování navrženého řešení
  
 +
 +===== Prezentace =====
 +
 +  * [[http://prezi.com/hrbsgbuaecnc/multikonstelacni-prijimac-gnss/|Multikonstelační přijímač GNSS]]
  
 ===== Reference ===== ===== Reference =====
  
   * [[http://www.nsl.eu.com/primo.html|GNSS SDR Front End and Receiver]]   * [[http://www.nsl.eu.com/primo.html|GNSS SDR Front End and Receiver]]
 +  * https://en.wikipedia.org/wiki/GNSS_software-defined_receiver
   * [[http://gnss-sdr.org/|GNSS-SDR]]   * [[http://gnss-sdr.org/|GNSS-SDR]]
 +  * [[http://orbit.dtu.dk/files/118775559/Software_defined_GPS_receiver_on_the_Parallella16_board_v10.pdf|Software-Defined GPS Receiver Implemented on the Parallella-16 Board]]
   * [[http://www.holmea.demon.co.uk/GPS/Main.htm|Homemade GPS Receiver]]   * [[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.  +  * [[http://www.witchnav.cz/doku.php|The Witch Navigator]] - projekt open source GNSS přijímače FEL ČVUT. 
- +  * [[http://www.navipedia.net/index.php/Main_Page|ESA Navipedia]]
cs/gnss.1385246963.txt.gz · Poslední úprava: 2013/11/23 22:49 (upraveno mimo DokuWiki)