cs:gnss
Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
Obě strany předchozí revizePředchozí verzeNásledující verze | Předchozí verze | ||
cs:gnss [2014/01/05 22:52] – kaklik | cs:gnss [Unknown date] (aktuální) – upraveno mimo DokuWiki (Unknown date) 127.0.0.1 | ||
---|---|---|---|
Řádek 26: | Řádek 26: | ||
* XRAD-3200 | * XRAD-3200 | ||
- | Ve všech případech je ale problémem | + | Ve všech případech je ale překážko |
==== Směšování ==== | ==== Směšování ==== | ||
Řádek 32: | Řá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:// | 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:// | ||
- | Z tohoto pohledu se přímo nabízí použití spínaného směšovače, | + | Z tohoto pohledu se přímo nabízí použití spínaného směšovače, |
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 40: | Řá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:// | ||
+ | radio astronomy applications]] | ||
==== Digitalizace ==== | ==== Digitalizace ==== | ||
Řádek 58: | Řá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í. | + | Úkolem korelační jednotky je získávat informace o posuvu navigačních signálů a udržovat jejich sledování. |
- | Pro testovací účely by v tomto případě bylo možné využít modul [[cs: | + | 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 |
+ | Pro testovací účely by v tomto případě bylo možné využít | ||
Řádek 71: | Řádek 75: | ||
|Pomocné operace | Upload/ | |Pomocné operace | Upload/ | ||
- | 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í. |
==== 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, | + | 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, |
==== PCI Express ==== | ==== PCI Express ==== | ||
- | [[http:// | + | [[http:// |
==== Thunderbolt ==== | ==== Thunderbolt ==== | ||
- | Jde o komunikační rozhraní vycházející z efektivity | + | Jde o komunikační rozhraní vycházející z efektivity |
- | 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í | ||
+ | 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č ===== | ===== Řídící počítač ===== | ||
Řádek 92: | Řá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 98: | Řá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, |
- | 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, | + | |
- | 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. | + | 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 === | === Obsluha korelátoru výpočetní jednotkou umístěnou v FPGA === | ||
Řádek 111: | Řádek 121: | ||
* Větší efektivita algoritmů a menší latence obsluhy korelátorů. | * Větší efektivita algoritmů a menší latence obsluhy korelátorů. | ||
+ | Tento přístup využívá například konstrukce [[http:// | ||
Nevýhody tohoto řešení: | Nevýhody tohoto řešení: | ||
- | * Problematická možnost aktualizace a úpravy algoritmů obsluhy. | + | * 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ý systém zvlášť. | + | * Nutnost specifické komplikované konstrukce výpočetní jednotky pro každý |
* Problematická realizace konstrukce výpočetní jednotky. (Nejsou dostupné vhodné vývojové nástroje) | * Problematická realizace konstrukce výpočetní jednotky. (Nejsou dostupné vhodné vývojové nástroje) | ||
Řádek 127: | Řádek 138: | ||
Výhody řešení: | Výhody řešení: | ||
- | * Snadná možnost aktualizace metody obsluhy korelátorů změnou programu v nadřazené výpočetní jednotce. | + | * Snadná možnost |
* Implementační obtížnost je podobná pro všechny navigační systémy. | * 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. | * 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. | ||
Řádek 148: | Řá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, | V režimu akvizice je kritický pouze přenos dat z FPGA do počítače, | ||
Řádek 163: | Řá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 | |
- | + | ||
- | 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:// | Jako výpočetní jednotka by v takovém případě mohl být použit některý [[https:// | ||
Řádek 172: | Řádek 181: | ||
===== Programové zpracování ===== | ===== Programové zpracování ===== | ||
- | Vytvoření softwaru je nejproblematičtější částí projektu. Jelikož softwarové algoritmy jsou hlavní částí | + | Vytvoření softwaru je nejproblematičtější částí projektu. Jelikož softwarové algoritmy jsou hlavní částí |
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 187: | Řádek 196: | ||
* [[http:// | * [[http:// | ||
* [[https:// | * [[https:// | ||
- | |||
- | ===== Ú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 ===== | ===== Výsledky studie ===== | ||
Řádek 202: | Řádek 203: | ||
==== Testovací přípravek ==== | ==== 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ě, | + | 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ě, |
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ů. | 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:// | + | Vhodným existujícím přijímačem by v takovém případě byl přímo [[http:// |
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, | 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, | ||
+ | |||
+ | 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 ==== | ==== 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í. | + | 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í. |
{{ : | {{ : | ||
Řádek 220: | Řádek 223: | ||
==== Prototyp GNSS přijímače ==== | ==== 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: | ||
+ | * 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í ===== | ||
+ | |||
+ | * Dokončení návrhu potřebných modulů | ||
+ | * Výběr vhodné výpočetní jednotky pro realizaci prototypu | ||
+ | * 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í | ||
+ | |||
+ | |||
+ | ===== Prezentace ===== | ||
+ | |||
+ | * [[http:// | ||
===== Reference ===== | ===== Reference ===== | ||
* [[http:// | * [[http:// | ||
+ | * https:// | ||
* [[http:// | * [[http:// | ||
+ | * [[http:// | ||
* [[http:// | * [[http:// | ||
- | * [[http:// | + | * [[http:// |
- | + | * [[http:// |
cs/gnss.txt · Poslední úprava: 2017/05/28 21:31 (upraveno mimo DokuWiki)