|
|
Когда мы коннектимся к плате bbxm по ssh, каждый раз замечаем что ssh сервер спрашивает подтверждение на внесение ip адреса в постоянный список известных хостов. Это наводит на мысль, что после включения плата bbxm получает разный ip адрес по dhcp. И не стоит искать причину в том, что dhcp сервер не дает постоянную аренду ip адреса: такое поведение платы вызвано тем, что она не имеет постоянного mac адреса и каждый раз при загрузке ядра сетевой драйвер выбирает его случайным образом. Соответственно, каждый раз bbxm получает новый ip адрес.
Если такое поведение BeagleBoard XM вызывает дискомфорт, то можно сделать MAC адрес фиксированным. Сразу замечу, что бесполезно править сетевые настройки /etc/network/interfaces: это ничего не изменит. Задача решается патчем сетевого драйвера smsc95xx.c, который находится в дереве ядра по адресу drivers/net/usb (именно usb, потому что Ethernet в bbxm работает именно так!).
Будет разумно, если требуемое значение MAC адреса мы поместим в строку конфигурации, которую u-boot передает ядру. Чтобы не трогать настройки переменных окружения в самом u-boot, который на bbxm и не собирается сохранять их на SD карту, заведем в загрузочном разделе файл переменных окружения uEnv.txt, в котором и пропишем значение MAC адреса:
|
|
optargs="mem=114M ethaddr=00:02:03:aa:bb:cc" |
Значение mem=114M к нашему примеру отношения не имеет и просто показывает, как перечислить несколько параметров в командной строке. Загрузчик u-boot по умолчанию просматривает файл uEnv.txt, поэтому все что в этом файле будет передано как параметры ядру.
Патчи, которые я находил в инете, приходилось править. Вот рабочий патч для ядра 3.0.50:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
--- drivers/net/usb/smsc95xx.c 2015-04-18 11:30:15.561156357 +0300 +++ drivers/net/usb/smsc95xx.c 2015-04-18 15:21:09.409853866 +0300 @@ -63,6 +63,18 @@ module_param(turbo_mode, bool, 0644); MODULE_PARM_DESC(turbo_mode, "Enable multiple frames per Rx transaction"); +static char *boot_ethaddr_mac = NULL; + +static int __init ethaddr_setup(char *str) +{ + boot_ethaddr_mac = str; + return 1; +} + +/* Read "ethaddr=xx:xx:xx:xx:xx:xx" boot command line parameter */ +__setup("ethaddr=", ethaddr_setup); + + static int smsc95xx_read_reg(struct usbnet *dev, u32 index, u32 *data) { u32 *buf = kmalloc(4, GFP_KERNEL); @@ -602,8 +614,28 @@ static void smsc95xx_init_mac_address(struct usbnet *dev) { + int ret; /* try reading mac address from EEPROM */ - if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN, + if (boot_ethaddr_mac) { + /* try to get MAC address from the boot CLI parameters first */ + printk("MAC ethaddr: %s\n", boot_ethaddr_mac); + ret = sscanf(boot_ethaddr_mac, "%02x:%02x:%02x:%02x:%02x:%02x", + (unsigned int *)&dev->net->dev_addr[0], + (unsigned int *)&dev->net->dev_addr[1], + (unsigned int *)&dev->net->dev_addr[2], + (unsigned int *)&dev->net->dev_addr[3], + (unsigned int *)&dev->net->dev_addr[4], + (unsigned int *)&dev->net->dev_addr[5]); + + if (ret > 0) { + /* CLI values are valid so use them */ + if (netif_msg_ifup(dev)) + netif_dbg(dev, ifup, dev->net, "MAC address read from command line\n"); + printk("MAC addr is valid\n"); + return; + } + } + else if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN, dev->net->dev_addr) == 0) { if (is_valid_ether_addr(dev->net->dev_addr)) { /* eeprom values are valid so use them */ |
Патч добавляет функцию __setup(), которая принимает наш параметр командрой строки ethaddr из переменной окружения, которая задана в uEnv.txt. Дальше логика проста: исходный драйвер или находит MAC адрес в постоянной памяти, или задает его случайным образом. Мы добавляем дополнительное условие: если задан параметр ethaddr, то MAC адрес устанавливается значением этого параметра.
Строки printk() добавлены для отладки, в заключительной версии драйвера их можно удалить.
Адаптивная фильтрация сигналов сродни магии. И в самом деле, делая самые общие предположения о природе сигнала и помехи, адаптивный фильтр весьма эффективно использует дополнительную информацию о мешающих сигналах — например, о той же самой помехе.
Самая распространенная постановка вопроса в области адаптивных фильтров — это синтез речи, то есть нахождение такой структуры фильтра, которая обеспечит имитацию голосовой структуры человека. Наш контекст совершенно другой: это поиск методов эффективного подавления помехи от базовой станции в когерентной пассивной локации. При этом у нас есть отличный источник информации о помехе: это сигнал с антенны со сформированной прямо на базовую станцию диаграммой, в котором не должен присутствовать полезный, отраженный от цели сигнал.
Хороший пример из медицины
До того как перейти к тому, как адаптивная фильтрация будет использоваться в нашем пассивном радаре, вначале рассмотрим более понятный (и поэтому может быть распространенный) пример из медицины. В этом примере наш адаптивный фильтр пассивного радара, изображенный на рисунке, будет использоваться следующим образом.
 Адаптивный фильтр Существует известная задача снятия электрокардиограммы, которая формируется на основе электрических сигналов сердечных мышц. Эта задача усложняется, когда необходимо записать сердцебиение у плода беременной женщины. В этом случае ее собственное сердце является источником помехи в записи электрических импульсов сердца ребенка (полезный сигнал), которую можно и необходимо устранить. Задачу подавления этой помехи выполняет наш адаптивный фильтр. В данном конкретном случае, источником дополнительной информации о помехе является второй датчик, который записывает только сигнал сердца матери.
Прямо в этом месте у читателя возникает легкое недоумение. Зачем городить огород с адаптацией, если можно просто вычесть сигнал матери из записи и останется только сигнал ребенка? К сожалению, ничего хорошего из этого не выйдет. Результат будет отвратительным по следующим причинам:
- помеха которую мы наблюдаем в смеси с полезным сигналом не является точной копией помехи которую мы снимаем с источника дополнительной информации; эти сигналы взаимозависимы, коррелированы но не идентичны;
- ситуация непрерывно меняется со временем, внося амплитудные и фазовые искажения.
После этого становится очевидным, что задача, которую решает адаптивный фильтр, следующая: приведение дополнительной информации о помехе к такому виду, чтобы она стала по возможности полностью идентичной самой помехе содержащейся в смеси со входным сигналом, и только после этого выход фильтра можно вычесть из наблюдаемого сигнала. Что приведет к подавлению помехи.
Применительно к нашему примеру, структура адаптивного фильтра описывается следующим образом:
- d + n : смесь искомого сигнала (сигналы сердца ребенка) и помехи (сигналы сердца матери, которые дошли до датчика снимающего сигнал ребенка);
- n’ : дополнительная информация о помехе: сигнал с другого датчика в районе сердца матери; подается на вход фильтра который за счет коэффициентов W подстраивает его под помеху n;
- y : выход фильтра, который по возможности должен как можно точнее совпадать с помехой n в суммарном сигнале d + n;
- e : сигнал ошибки, указывающий на то, насколько наше представление о помехе y разошлось с ее реальным значением n.
Фильтр непрерывно отслеживает сигнал ошибки e, изменяя на его основе свои коэффициенты W для обеспечения лучшей адаптации. Сигнал ошибки e и является результатом всей нашей системы, как бы странно это не звучало. Если бы адаптация прошла идеально, то этот сигнал ошибки и будет представлять собой искомый сигнал d, то есть сигнал сердца плода.
Магия адаптации
Как мы видим из медицинского примера, на самом деле все просто. Надо всего лишь минимизировать ошибку за счет подбора коэффициентов фильтра. Все дело в том, каким образом определить эти коэффициенты.
Не буду углубляться в теорию: она достаточна сложна. Замечу лишь, что существует строгое теоретическое решение, связанное с обращением матриц, и которое совершенно не подходит для реальных средств обработки сигналов. Для реального мира работают итерационные алгоритмы, которые приводят практически к тем же самым результатам. Тех, кто ожидает таинства процедуры нахождения коэффициентов W, ждет глубокое разочарование: они определяются довольно топорным методом как подбираемая экспериментальным способом доля от смеси сигнала ошибки фильтра и сигнала помехи, наблюдаемой на определенном интервале. В этом проблема с адаптивными фильтрами: ускользает физический смысл внутреннего принципа работы. Зато результаты работы вполне можно использовать для своих целей.
Давим FM-станцию в пассивном радаре
Вначале пару слов о том, зачем нужна адаптация в PCL. Основной алгоритм обработки пассивного локатора — это функция неопределенности, уровень боковых лепестков которой сложно сделать меньше чем минус 40 — 50 дБ относительно пика за разумное время. С учетом того, что помеха превышает сигнал на уровни соизмеримые 100 дБ, этого явно недостаточно. Дополнительный (20 — 40 дБ) выигрыш может дать использование направленных свойств антенной системы, что несколько улучшает ситуацию. Но если мы можем получить дополнительную информацию о помехе, то грех не использовать это для адаптивной фильтрации, не правда ли?
По отношению к пассивному радару сигналы адаптивного фильтра приобретают следующий смысл:
- d + n : смесь полезного сигнала отраженного от цели и помехи — сигнала базовой станции;
- n’ : дополнительная информация о помехе: сигнал базовой станции, полученный с антенной системы;
- y : выход фильтра, в котором подавляется помеха;
- e : сигнал ошибки, представляющий собой сигнал d, который не может быть подавлен адаптивным фильтром, поскольку фильтр не получает информацию об этом сигнале.
Теперь пришло время смоделировать поведение адаптивного фильтра. Будем использовать для этой цели Python, поскольку он содержит мощные библиотеки работы с массивами и обработки сигналов. Воспользуемся записью реального сигнала с эфира FM станции Sfile для моделирования поведения адаптивного фильтра, это будет сигнал n. Для получения полезного отраженного сигнала применим к n процедуры временного и частотного сдвига. Питоновская функция target, которая это делает, выглядит следующим образом.
|
|
import numpy as np def target(Sfile, count, delay, dopler, Ts): St = Sfile[delay:delay+count] tall = np.linspace(-Ts*count/2., Ts*count/2., count) exf = np.exp(1j * 2. * np.pi * dopler * tall) Stf = St * exf return(Stf) |
Помимо собственно выборки записи FM сигнала Sfile, функция принимает в качестве параметров:
- count : размер выходного сигнала, который нужно сформировать;
- delay : имитируемая задержка;
- dopler : имитируемый доплеровский сдвиг;
- Ts : расстояние между выборками по времени.
Фильтр использует размерность входных выборок nsamples и количество звеньев фильтра taps:
|
|
for n in np.arange(nsamples): for i in range(0, taps): if n >= i: sOutput[n] = sOutput[n] + w[i] * antFm[n-i] sError[n] = antTarget[n] - sOutput[n] |
Адаптивный фильтр формирует выходной сигнал ошибки sError как разность сигнала цели antTarget, содержащего также помеху, и выход FIR фильтра sOutput. На вход FIR фильтра подается сигнал помехи antFm (выделенный антенной сигнал базовой станции), который суммируется с учетом весовых коэффициентов w.
Здесь видимо уместно сделать следующее замечание: в питоновском коде циклы for оставлены только для наглядности (как и оператор if). На самом деле, возможности обработки массивов библиотеки numpy позволяют обойтись без циклов, что существенно повышает производительность программы.
Фильтр у нас уже есть, дело за правильными коэффициентами w. Вот этот кусочек магии:
|
|
for i in range(0, taps): if n >= i: w[i] = w[i] + (beta * sError[n].real * antFm[n-i].real) else: w[i] = 0 |
Из этого кода также следует, что изначально значения используемых сигналов — комплексные.
Магический кусочек кода содержит магическую константу beta. Она определяет сходимость фильтра и его быстродействие. Как и все в этом мире, эти два параметра выбираются исходя из компромисса: на сходимость фильтра требуется время, и если его у нас мало, то точность его работы будет хуже.
Как это работает
Теперь все готово для того чтобы запустить нашу адаптивную машину. Все действующие лица и исполнители, то есть сигналы, представлены на рисунке в цвете:
 Сходимость адаптивного фильтра Синим цветом представлен искомый сигнал, красным — помеха. По уровню помеха больше сигнала; сигнал также смещен по частоте относительно помехи (доплеровский сдвиг). Смесь сигнала и помехи подается на вход фильтра; кроме этого модифицированная помеха используется как источник дополнительной информации. Сигнал ошибки, или выход фильтра обозначен зеленым цветом.
Из рисунка следует, что на адаптацию ушло 8 — 10 периодов полезного сигнала. Вначале выход адаптивного фильтра полностью представлен сигналом помехи; дальше, по мере адаптации, помеха давится и выход фильтра соответствует уже искомому полезному сигналу. Также видно, что в установившемся режиме выход фильтра несколько запаздывает относительно полезного сигнала: это связано с фазовой задержкой в FIR фильтре.
 Антенна опытного образца АРП «Платан», развернутого в Пулково Просто РП
Хотелось по привычке написать в заголовке — АРП, автоматический радиопеленгатор. И тут сразу же вспомнилось, что начиная с далекого 1983 года, когда я начал работать в радиопеленгационной тематике, мне всегда хотелось избавиться от этого слова — «автоматический». И в самом деле, этот анахронизм ведет свое начало с тех времен, когда на место пеленгаторов, которые наводились на источник сигнала вручную, пришли более современные, которые делали это самостоятельно. После того как автоматическим и автоматизированным начало именоваться буквально все что попадется — АРП, АС УВД, АСУ, АРМ и так далее, это слово начало набивать оскомину. Поэтому здесь радиопеленгатор будет именоваться скромным сочетанием — РП, как и его английский эквивалент Direction Finder (DF). Просто, скромно и со вкусом.
Сравниваем радиопеленгатор и радиолокатор
Радиопеленгатор и пассивный локатор, или пассивный радар (как кому нравится), используют разные физические принципы для работы с целью. Самая простая задача — у РП. Если брать аэродромные радиопеленгаторы, то 5 ваттной радиостанции на борту вполне достаточно для того, чтобы на расстоянии 360 км при высоте полета 10 000 м РП определил угловые координаты. С учетом использования современных SDR с низким уровнем шума, приведенным ко входу, это расстояние может быть еще больше, вплоть до загоризонтной пеленгации.
Как мы видим, проблем с энергетическим бюджетом радиолинии у радиопеленгатора нет. Зато они есть у пассивного радара, PCL (Passive Coherent Locator), потому что он использует принципиально другой, радиолокационный, принцип работы. Вообще, когда речь заходит о пассивной локации, возникает неловкое ощущение — сродни тому, которое появляется после ухода гостей, и связано оно с куда-то запропастившимися серебряными ложечками (а осадок-то остался!). Причина дискомфорта в том, что PCL использует чужие источники радиоизлучения, такие как FM, GSM и DVBT станции (халява, сэр). И, соответственно, полностью от них зависит (естественно, в случае их физического присутствия в месте развертывания пассивного радара). Все на свете имеет свою цену: благодаря этому PCL приобретает свойство скрытности, что чрезвычайно важно для военных применений, а особенности выбранного частотного диапазона позволяют ему обнаруживать Stealth цели точно также, как и обычные.
И, если бы речь зашла об обычном радиолокаторе, к сравнению с РП добавить было нечего: между локатором и радиопеленгатором — бездна различий. Разные частотные диапазоны; у одного — вращающаяся антенна, у другого — стационарная, в локаторе мощные радиопередатчики — пеленгатору они не нужны, разные сигналы: РП работает с модулированной несущей в диапазоне МВ-ДМВ, радиолокатор — с широкобазовыми импульсами (ЛЧМ, кодовая модуляция). Но это только для обычного локатора. Если мы присмотримся к пассивному радару, то обнаружим, что по своей архитектуре он мало чем отличается от радиопеленгатора. Фундаментальное различие — только в принципе работы.
РП и PCL: найти 10 отличий
Диапазон частот
Пассивный радар использует частотные диапазоны, привычные для радиопеленгатора. Самые распостраненные это FM диапазон коммерческих вещательных станций и телевидение DVB. Для аэродромного РП традиционный диапазон 118 — 136 МГц (для любителей точности — до 135.975 МГц). Радиопеленгаторы, использующие военные каналы связи, дополнительно имеют поддиапазон 220 — 400 МГц. Судовой РП, такой как «Пихта-2С», работает в диапазоне 100 — 180 МГц.
Непрерывность сигнала
В отличие от обычных первичных радиолокаторов, которые работают в импульсном режиме, как PCL так и радиопеленгатор используют протяженные по времени сигналы. Для вторичного радара протяженность носит принципиальный характер: это означает, что отраженный от цели полезный сигнал полностью перекрыт по времени более мощным сигналом используемой базовой станции. Это обстоятельство принципиальным образом меняет подход к обработке сигналов в PCL в отличие от обработки первичного локатора: для последнего разнесенность по времени излученного и отраженного сигнала является необходимым условием, а для PCL их перекрытие является непреодолимым обстоятельством.
Антенная система
Разница налицо: во вращающейся габаритной антенне первичного радиолокатора трудно заподозрить что-либо похожее на неподвижную антенну радиопеленгатора или пассивного радара. Более того, структура антенного тракта PCL полностью идентична структуре антенного тракта РП, если учесть следующее обстоятельство исторического характера: квазидоплеровский способ обработки сигнала в РП означает использование одного приемного тракта для всех вибраторов антенной системы, которые сканируются последовательно по кругу. Для тех РП, где важно быстродействие (мониторинг эфира), используется параллельная обработка по принципу один вибратор — один приемный тракт. Точно также построена антенная система пассивного локатора.
Следует отметить, что PCL фактически содержит функцию радиопеленгации. Данная функция позволяет оценить направление на источник сигнала цели; данная информация позволяет существенным образом упростить разрешение неоднозначности положения цели в системе координат задержка / доплеровский сдвиг.
Параллельная структура антенной системы пассивного радара естественным образом ведет нас к схеме адаптивной антенной решетки, в которой реализуются следующие важные для PCL функции:
- формирование максимума диаграммы в предполагаемом направлении цели;
- формирование минимума диаграммы в направлении базовой станции для ее подавления.
Приемный тракт
Приемные тракты PCL и РП, помимо общих радиотехнических параметров, имеют схожесть с точки зрения поддержки когерентности в тракте, или другими словами — обеспечение синхронизированного двухканального приема.. В радиопеленгаторе когерентность необходима для сохранения фазовой информации коммутируемого кольцевого вибратора относительно центрального. В ранних версиях РП, для избежания дублирования приемного тракта, данная задача решалась с помощью однополосного модулятора в антенном тракте.
В пассивном радаре когерентность (по определению) необходима для синхронного приема как сигнала цели, так и помехи, с целью их дальнейшего различения. При этом структура тракта в обеих случаях примерно соответствует традиционной; разница начинает проявляться в математических методах обработки сигнала, которые реализуются в программном домене.
Когда я встретился с темой пассивной локации, было очень интересно узнать в госте из совсем другой области старого знакомого — РП. Несмотря на то, что обработка сигнала в PCL существенно сложнее чем в радиопеленгаторе, наш старый знакомый, которого мы разрабатывали для разных применений аж с 1983 года, получил свое второе рождение. Ну а что делать с математикой мы знаем: для этого есть богатый инструментарий АРМ + ПЛИС + DSP, который обеспечивает параллельную обработку в реальном времени.
 Принцип работы пассивного локатора Тема пассивной когерентной локации — PCL, Passive Coherent Location возникла буквально ниоткуда последнее десятилетие. Пассивный локатор, или пассивный радар знаменует собой хороший пример того, как определенные физические принципы, выглядевшие абстрактно и существовавшие сугубо в теоретическом поле, с развитием технологий получили возможность своего воплощения. В чем же состоит физика работы PCL, или пассивного локатора, и какие технологии дали ей путевку в жизнь?
Локация или пеленгация?
Вначале устраним путаницу, которая на сей день существует в терминологии, особенно отечественной. Некоторые практики зарезервировали понятие пассивной локации для обычной радиопеленгации, когда цель обладает собственным источником излучения и ее угловые координаты определяются в процессе пеленгования. Мне трудно сказать, какие обстоятельства сыграли свою роль для такой подмены понятий: то ли локация звучит весомее и престижнее, чем пеленгация; то ли подразумевалось отсутствие собственного передатчика — мы будем называть пеленгатор не пассивным локатором, а пеленгатором. Наш, настоящий пассивный радар, PCL, полностью соответствует идее локации — прием переотраженного от цели сигнала. Единственный нюанс в том, что передатчики, которые работают на облучение цели, не являются принадлежностью PCL: они составляют часть местного радио-окружения, такого как FM, телевизионные и сотовые базовые станции и другие источники излучения.
Вот мы и сформулировали базовый принцип PCL, благодаря которому пассивный локатор иногда называют «паратизирующим» радаром, который использует передатчики, ему не принадлежащие, без их ведома. Этот ключевой аспект PCL — отсутствие радиоизлучения и он в основной степени определяет плюсы и минусы PCL. Пассивный радар имеет и другие значимые особенности, такие как возможность работы в трехмерных координатах и на малой высоте цели.
О плюсах и минусах
Отсутствие собственных радиопередатчиков и соответственно сложных движущихся антенн, как в традиционных радиолокаторах, определяет скрытность работы PCL и значительное сокращение объема оборудования.
Фактор скрытности, несомненно, обладает сильной привлекательностью для военных применений. Возможность слежения за целями, не обнаруживая себя, позволяет пассивному локатору разместиться в непосредственной близости от наблюдаемых объектов. PCL трудно подавить антирадарными вооружениями, как это происходит в случае обычных излучающих наземных средств.
Пассивный локатор позволяет закрыть разрывы в полях наблюдения, в частности на низкой высоте (менее 1000м), где традиционные радиолокаторы бессильны. Это позволяет ему обнаруживать пересечение границ и контролируемых зон низколетящими цели и фиксировать запуски ракет и мин.
«Невидимые» для традиционных военных радиолокаторов Stealth — подобные цели также обнаруживаются с помощью PCL.
Пассивные радары также используются для аэродромов в сложных условиях размещения, например в горах, где возможности традиционных средств ограничены.
Минимизация аппаратуры PCL также дает следующий выигрыш:
- компактность, низкая стоимость и малое (до 1 кВт) энергопотребление;
- легкость транспортирования и быстрое развертывание на месте, что актуально для быстроразвертываемых центров УВД, в том числе для чрезвычайных ситуаций, и для военных применений;
- позиция PCL не требует обслуживания.
С точки зрения международной организации гражданской авиации ICAO, подтвержденной документом ACP-WGF16/WP-11, пассивные радары обладают рядом следующих привлекательных преимуществ по сравнению с существующими средствами наблюдения, что позволяет использовать их в целях управления воздушным движением:
- лучшие характеристики обнаружения в условиях дождя и других помех, в том числе на низкой высоте полета и в горной местности;
- обеспечение полноты данных за счет информации о высоте и скорости цели;
- повышенная точность определения местоположения;
- низкая стоимость.
Что мы знаем о недостатках пассивной локации? Они также следуют из базового принципа работы. Отсутствие собственных передатчиков ставит пассивный локатор в зависимость от радиоизлучающих средств, находящихся поблизости. Точность его работы также зависит не только от характеристик этих передатчиков, но и от вещательной программы. Характеристики обнаружения PCL также зависят от его взаимного расположения по отношению к внешним передающим станциям и расположению цели. Поэтому их невозможно декларировать, абстрагируясь от внешней радиообстановки.
В некоторых случаях, если внешних излучающих станций не хватает, что нам мешает развернуть свою собственную? Обеспечить ей высокостабильную несущую (что понравится PCL с его когерентным принципом работы) и транслировать не музыку и новости, а шумоподобный сигнал (это ему понравится еще больше). Правда, в этом случае название «пассивный» будет уже не очень честным.
Почему только сейчас?
В начале статьи мы упомянули о том, что пассивная локация стала реальностью относительно недавно. С чем же связано ее возрождение? Для того, чтобы понять с какими сложностями может столкнуться реализация PCL, посмотрим на то, какая помеховая обстановка ему сопутствует. Как следует из приведенного рисунка, полезным сигналом для локатора является сигнал, отраженный от цели. Этот сигнал содержит полезную информацию: приобретенную задержку, связанную с дополнительным путем распространения излучения FM станции до цели и далее — до локатора — Δτ и приобретенный доплеровский частотный сдвиг, связанный с движением цели — Δθ. Этот отраженный сигнал s'(t+Δτ, f+Δθ) принимается пассивным локатором на фоне мощной помехи — сигнала собственно самой FM радиостанции s(t, f). Величина этой помехи по отношению к полезному сигналу может составлять +100 dB и более.
Для различения полезного сигнала на уровне столь мощной помехи необходимо вычислить функцию неопределенности (Ambiguity Function) в двумерной плоскости параметров (Δτ, Δθ). Очевидно, что для классических аналоговых радиоприемных средств задача такой вычислительной сложности практически нереализуема (точнее, реализуема с неприемлемыми затратами). И только с появлением в настоящее время быстродействующих средств обработки радиолокационных данных, таких как ПЛИС/FPGA и DSP, позволило использовать технологию Software Defined Radio (SDR) для прямого переноса радиосигнала в цифровой домен и выполнения вычислительных задач уже в цифровом домене.
Однако, и здесь все оказывается не так просто. SDR технологии прекрасно работают при уровне помех соизмеримых с уровнем сигнала. Для нашего случая, когда помеха превышает полезный сигнал на 100 dB и более, это означает только одно: для аналого-цифровых преобразователей (АЦП), входящих в состав SDR, требуется такая разрядная сетка, чтобы максимальный диапазон входного сигнала, масштабируемый под уровень помехи, обеспечил для полезного сигнала хотя бы пару младших значащих разрядов. При этом АЦП должен обеспечить соответствующую скорость преобразования хотя бы на уровне 200 Msamples/s.
На самом деле, скорость выборки должна быть еще больше, чтобы использовать преимущества передискретизации и выиграть дополнительный динамический диапазон для исключения подавления полезного сигнала уже на входе АЦП. И именно такие компоненты стали появляться в течение последних 5 лет. Применение унифицированных модулей АЦП со стандартизированными FMC коннекторами и использование сигнальных процессоров, также стандартизированных под шину VPX, позволило резко снизить стоимость реализации и длительность разработки PCL. Это обстоятельство явилось спусковым крючком, или триггером к тому, чтобы на считавшимся ранее элитным рынок радиолокационного оборудования хлынули новые игроки…
О новых игроках
Мы живем в удивительное время. Еще только казалось бы недавно я собирал ламповые передатчики и транзисторные регенеративные приемники. А сейчас по цене $50 доступны компоненты, о которых раньше только можно было мечтать. Это — стоимость цифрового SDR приемника диапазона 60 — 1100 MHz размером меньше флешки, который показан на фото. Этот приемник, который формирует 8-битную I/Q последовательность с частотой выборки 2,56 MS/s на USB порту, плюс мощные возможности языка Python по спектральной и корреляционной обработке сигналов — и цифровой радиотракт для PCL готов.
 SDR тракт 60 — 1100 MHz на малогабаритном тюнере С помощью этого приемника мы анализировали различные алгоритмы обработки для PCL в диапазоне FM вещательных станций. Вот как например выглядит функция неопределенности развлекательного канала 99.0 MHz во время трансляции музыки:
Забегая вперед, отметим, что даже визуально заметно, какой высокий уровень боковых лепестков у функции неопределенности, что практически уничтожает шансы по обнаружению и разрешению более слабого сигнала. Тем не менее, существует ряд взаимосвязанных методов, с помощью которого можно достигнуть результата. Эти методы относятся не только к домену программного обеспечения, но и связаны с построением радиотракта и антенной системы пассивного радара.
Организация «Research and Markets» подготовила отчет под названием ‘The Military and Civil Aviation Passive Radar Market: 2013- 2023’ , в котором рассмотрела рыночные перспективы пассивных локаторов как для военных приложений, так и для гражданской авиации на период с 2013 до 2023 года. Из этого отчета хочется отдельно процитировать следующий абзац, как раз касающийся новых игроков:
«Few companies have developed effective, marketable systems. However, as the technology becomes more sophisticated and affordable, more and more competitors can be expected to enter the market, particularly in defence and homeland security»
Перевод этой фразы выглядит примерно следующим образом:
«Только несколько компаний разработали эффективные и востребованные системы. Однако, по мере того как технологии становятся более продвинутыми и доступными, ожидается проникновение на рынок все большего количества конкурирующих компаний, в частности в военной области и безопасности»
По данным этого же отчета, к концу 2023 года ожидаемые инвестиции превысят 10 млрд. долларов, и в области военных радиолокаторов пассивные локаторы займут свою долю в размере 41%.
Под «несколькими» компаниями подразумеваются всемирно известные радиолокационные мэтры, поставляющие такие пассивные радары как:
- «Silent Sentry» (Lockheed Martin, USA);
- «Celldar» (Roke Manor & BAE Systems, UK);
- «CORA» (FGAN — Die Forschungsgesellschaft fur Angewandte Naturwissenschaften e.V., Germany);
- «Cristal» (Thales, EU)
- Cassidian, EADS, Germany
Давления на рынок PCL молодых, небольших, агрессивных и инженерно продвинутых компаний осталось ждать не так долго. Базовые компоненты уже обкатываются в системах подобного рода, хотя они поначалу и выглядят игрушечными. Но не будем забывать, что когда-то такой игрушкой «для домохозяек» называли и процессоры Intel 8080. По прогнозу некогда знаменитой корпорации DEC, рынок этих процессоров не мог превышать десятков штук в год. Через пару лет объем продаж интеловских процессоров составлял уже сотни тысяч.
Так получилось, что ставить новую версию Убунты пришлось на трех компьютерах, включая один лаптоп. И каждый раз приходилось докручивать одно и то же.
Проблема с UEFI
В BIOS Security Boot заменяется на Legacy Mode. После этого загружаемся с флешки, открываем gparted и по новой устанавливаем разделы: вместо разбивки gpt, которая хочет UEFI, ставим ms-dos и ставим свои разделы.
Инсталлятор Убунты также предлагает редактировать разделы, но разбивка gpt все равно останется. В результате, после перезагрузки машина будет требовать режим UEFI.
Сносим Unity и возвращаем Gnome Classic
Доустанавливаем требуемые пакеты:
|
|
sudo apt-get install gnome-session-flashback |
Покидаем сессию, логинимся снова, вместо обычной Убунты выбирая Gnome Compiz.
Поддержка мультимедиа
Если не были отмечены соответствующие галочки в инсталляторе, ставим:
|
|
sudo apt-get install ubuntu-restricted-extras |
Тут же установятся майкрософтовские шрифты.
Активация индикатора рабочих столов
Я работаю с четырьмя рабочими столами, выбирая их справа на нижней панели. По умолчанию в Убунте 14.04 установлен только один рабочий стол. Вначале ставим Compiz Manager:
|
|
sudo apt-get install compizconfig-settings-manager |
Далее, запускаем его командой ccsm, выбираем Общие настройки и идем на последнюю вкладку Размер рабочего стола. Ставим четверку для виртуального размера по горизонтали.
Активация Alt-Tab
Это для тех, кто привык быстро переключаться между окнами традиционным способом. Ставим плагины к Compiz:
|
|
sudo apt-get install compiz-plugins-extra |
Запускаем ccsm, идем в раздел Управление окнами, там отмечаем Static Application Switcher, заходим в этот пункт, отключаем все настройки, задаем Alt-Tab для позиции Следующее окно (Все окна).
 VoIP радиостанция и приемник: прототип для использования в СКРС/VCS
Существуют различные подходы к организации передачи VoIP трафика через радиотракт, такие например как RoIP: Radio over IP. Что касается систем управления воздушным движением, в частности таких как СКРС/VCS, основанных на IP, здесь всякая вольница заканчивается и работа радиостанций, с помощью которых диспетчер обменивается с бортом, жестко регламентируется документально. Европейская организация Eurocae выпустила два таких документа: ED-136 и ED-137, посвященных принципам организации СКРС/VCS и в частности — как должна быть построена радио подсистема. Документы в публичном доступе отсутствуют, но их можно приобрести. Оно того стоит: работа проделана огромная; в распечатке это увесистые тома насыщенного техникой текста, без всякой воды.
Eurocae ED-136, ED-137
Самое приятное здесь — это сам факт наличия документа ED-137. Если ED-136 описывает целевые требования к архитектуре и параметрам и в некотором роде является аналогом нашего технического задания, то ED-137 — каким образом это лучше сделать. Соответственно, этим рекомендациям мы и будем следовать.
Поскольку парк аналоговых радиостанций, используемых для УВД в нашей стране огромен, и мне во всяком случае неизвестен ни один факт использования VoIP радиостанций в этой области, практическую ценность будет представлять ответ на вопрос: каким образом аналоговую радиостанцию можно сделать VoIP радиостанцией. Как частный случай, если мы не желаем влазить в ее внутренности — как построить радиошлюз, который обеспечит сопряжение IP среды СКРС с аналоговой радиостанцией.
И если с передачей голоса все более или менее понятно, гораздо занимательнее найти ответ на вопрос: как СКРС должна формировать сигнал нажатия тангенты PTT (Push-to-Talk) и каким образом радиошлюз должен формировать сигнал SQ наличия несущей (срабатывания шумоподавителя, Squelch).
В документах ED подразумевается использование протокола SIP для обмена между всеми устройствами сети, и радиостанции не исключение. Каждая из них должна иметь свой SIP адрес. С чем мы имеем дело — с приемником или передатчиком, или с обоими одновременно, определяется заголовками recvonly, sendrecv и sendonly SIP протокола. Если мы рассчитываем на то, что поддержку PTT, SQ предлагается реализовать на уровне SIP, как это было бы логично, нас ждет легкое разочарование. Казалось бы, эти сигналы, ответственные за процедуры установления радиосоединения, должны работать на уровне SIP сигнализации, но не тут то было. В рекомендациях этого нет, и вместо этого реализация PTT/SQ, а также других управляющих сигналов и сообщений радиолинии сделана на уровне расширенных заголовков протокола RTP: Headers Extention.
Конечно, можно сделать предположение, почему было принято именно такое решение. Eurocae жестко регламентирует задержки в СКРС и в радиотракте, как для управления, так и для голоса. Так, время между нажанием PTT и поступлением этого сигнала на передатчик не должно превышать 80 мс. Еще 20 мс отводится передатчику на то, чтобы при получении этого сигнала он начал излучение в эфире. Для приемного тракта, задержка делится поровну: за 50 мс после появления сигнала в эфире приемник должен сформировать SQ, и за 50 мс СКРС после получения SQ должна включить тракт прослушивания на рабочем месте авиадиспетчера. Всего 100 мс в ту и другую сторону. Думаю, SIP протокол вряд ли гарантировал такие задержки, и поэтому решение было принято в пользу RTP.
Здесь рассматривается обмен между рабочим местом СКРС — CWP (Controller Worker Position) и радиостанцией.
Сказанное не означает, что процедура INVITE/200OK для радиостанций не поддерживается вообще: она присутствует. Только ее функция — это активация радиостанции, возможно один раз за все время эксплуатации (что не исключает требования обязательной процедуры пересоединения REINVITE). Выход на передачу и прием сигналов с борта — все это целиком существует на уровне RTP, а точнее на уровне Extended Headers. Коль скоро это так, посмотрим, что это за расширенные заголовки.
RTP Headers Extention
Вспомним, как организован стандартный заголовок RTP пакета. Он имеет следующий вид:
 Расширение заголовка RTP В составе заголовка есть X бит, значение которого обычно равно нулю. Если же X=1, это означает, что заголовок содержит дополнительные поля RTP Header Extention, следующие за ним. Один байт отводится на тип дополнительного заголовка и еще один указывает длину оставшейся части, в которой может содержаться любая пользовательская информация. ED-137 как раз регламентирует структуру этого информационного поля.
Структура заголовка зависит от направления медиапотока VoIP. Если мы имеем дело с приемником, то есть СКРС принимает аудио и авиадиспетчер слушает, то информационное поле имеет структуру RTPRx, если с передатчиком, т.е. СКРС передает аудио и авиадиспетчер говорит, то информационное поле будет иметь структуру RTPTx. Содержание этих полей показано далее.
Поле RTPTx: направление от CWP к радиостанции
 Поле RTPTx В этом двухбайтовом блоке существенными для нас являются следующие поля:
- PTT-type: CWP передает на радиостанцию признак выхода на передачу PTT ON, впрочем как и признак отсутствия передачи PTT OFF;
- PTT-ID: четырехбитный идентификатор передатчика. Откуда CWP берет этот код, сказано ниже.
Здесь возникает пара вопросов.
Несколько неожиданно наличие признака PTT OFF: зачем передавать поток RTP, если голоса нет? На самом деле при остутвии аудио-передачи RTP поток не прекращается: в нем идут Keep-Alieve пакеты без голоса с этим признаком PTT OFF. Четкое различение состояний PTT ON/OFF совершенно необходимо, и в СКРС предпринимаются специальные меры для исключения «залипания» признака передачи в том или ином состоянии. Существуют дополнительные состояния PTT ON, которые я для краткости опускаю, они касаются приоритета выхода на связь.
Присутствует интересное поле: идентификатор передатчика PTT-ID. Эти данные СКРС получает по SIP адресу радиостанции во время SIP сессии INVITE/200OK от радиостанции: так она сообщает свой ID.
Поле RTPRx: направление от радиостанции к CWP
 Поле RTPRx Как видно, структура этого блока соответствует блоку RTPTx, только смысл интересующих нас полей меняется, а именно:
- PTT-type: содержимое этого поля говорит CWP о выходе радиостанцию на передачу, причем инициатива выхода на передачу может быть с других CWP;
- SQU: признак наличия сигнала в эфире;
- PTT-ID: четырехбитный идентификатор передатчика, который вышел на передачу;
- SCT: признак одновременного приема.
Поскольку как отмечалось выше пакеты RTPRx идут не только во время радиоприема, а также и во время молчания на данном канале как Keep-Alive пакеты, то CWP получает информацию о том, кто выходит на передачу на тех радиостанциях к которым он подсоединен.
В поле RTPTx, точнее в его расширении передается еще одна важная информация об уровне и качестве принимаемого сигнала. Эта информация используется подсистемой BSS (Best Signal Selection).
С точки зрения диспетчера, механизм PTT-ID позволяет ему наблюдать за событиями связанными со «своими» радиостанциями:
- факт выхода на передачу с другого рабочего места;
- с какой радиостанции идет выход на передачу.
Таким образом, на уровне протокола расширенных заголовков RTP поддерживается важная сетевая функция — распределенный доступ к радиостанциям.
VoIP радиостанция: прототип
Теперь, когда мы знаем как работать с Header Extensions, сделаем VoIP радиостанцию. Как я отмечал выше, эта задача решается добавлением к обычной аналоговой радиостанции VoIP радиошлюза. Конечно, на уровне прототипа радиошлюз не будет конструктивно встраиваться в радиостанцию: наша цель это проверка концепции, а не разработка VoIP радиостанции. Однако, базируясь на аппаратно-программных решениях прототипа, ничего не мешает сделать встраиваемый в радиостанцию шлюз.
В качестве платформы для прототипирования был выбран SBC (Single Board Computer) на основе процессора CM-T3730. Этот процессор имеет OMAP архитектуру и включает в себя ARM и DSP ядра. Его размеры чуть более размеров спичечного коробка: на фото видно как SBC закреплен на несущей плате. На несущей плате располагается соответствующее обрамление: электропитание, Ethernet, аудио-интерфейсы.
 CM-T3730 на несущей плате Для прототипирования были использованы стандартные серийные приемник и радиостанция. Аудио и PTT/SQ подключение осуществлялось через интерфейс E&M. Для того, чтобы перейти к встраиваемому варианту шлюза, необходимо всего лишь поменять E&M на внутренний цифровой аудио-интерфейс радиостанции и разработать несущую плату, конструктивно и интерфейсно совместимую с радиостанцией — контроллер VoIP.
Для прототипа было разработано следующее ПО:
- SIP модуль с поддержкой процедур обмена с радиостанциями в соответствии с Eurocae ED-136, ED-137;
- модуль RTP с поддержкой Headers Extension;
- голосовые кодеки и система эхоподавления.
В ходе экспериментов имитировались сигналы PTT/SQ и тестировалась совместная работа подсистем SIP и RTP. Для радиостанции использовался эквивалент нагрузки. Источником сигнала был микрофон и плеер, речь выводилась на гарнитуру и на внешние громкоговорители. Также оценивалась задержки, вносимые как радиотрактом, так и прототипом.
В ходе эксперимента также оценивалось суммарное прослушивание двух приемных трактов при наличии изменяемой задержки в одном из них. Были определены величины задержек, которые влияют на разбираемость речи. Также оценивалась эффективность эхоподавления.
Эксперименты и тесты полностью подтвердили работоспособность принятой концепции с реальными радиоустройствами.
 АЗН-В/ADS-B приемник с использованием технологии Software Defined Radio (SDR) (кликните по картинке для увеличения) Использование технологии SDR (Software Defined Radio) позволяет работать напрямую с радионесущей уже в домене программного обеспечения. Очевидно, что для профессионального использования необходимо учитывать вопросы электромагнитной совместимости (ЭМС), а говоря проще — воздействия помех со стороны других источников излучения, которые не обязательно должны находиться в этом же диапазоне. Близлежащая ФМ станция может очень просто создать такую помеху, которая повлияет на характеристики обнаружения сигнала сквиттера с борта. И как следствие — необходим входной полосовой фильтр, далее с учетом потерь фильтрации малошумящий усилитель, и так далее. Но в данном случае нас интересует принципиальная организация тракта радиоприема АЗН-В, который нашел воплощение в прототипе который показан на фото. Данный приемник представляет из себя, как говорят в таких случаях, POC: Proof of Concept, доказательство верности концептуальных подходов к реализации, реализуемость ключевых принципов, положенных в основание системы.
Описание начнем с первого вопроса: в каком виде с борта к нам приходит сигнал сквиттера?
Сквиттер АЗН-В: Pulse Position Modulation и код Манчестера
Адресно — навигационная информация с борта как последовательность бит включается в пакет, который излучается бортом как широковещательная (сквиттер) рассылка. Пакет состоит из преамбулы, состоящей из неизменной фиксированной и заранее известной последовательности из 8 бит длительностью 8 мкс и следующих за ней 56 или 112 блоков данных, каждый из которых занимает 8 мкс. Биты данных кодируются кодом Манчестера, который показывает переходы из 0 в 1 или наоборот в исходных данных. Такое кодирование дает следующее:
- исчезает «постоянная составляющая» в потоке данных (эфир не может передать постоянную составляющую!): если в исходной комбинации преобладают нули или единицы, выходная последовательность все равно будет периодичной и состоять из перемежающихся нулей и единиц;
- перемежающаяся последовательность содержит информацию о синхронизации, то есть является самосинхронизирующейся.
Использование кода Манчестера приводит к кодированию местоположением импульса (Pulse Position Modulation, PPM). При скорости передачи 1Мбит/с на несущей 1090 МГц во временном интервале 1 мкс, выделенном для каждого бита, единица будет представлена импульсом 0,5 мкс находящимся в начале этого интервала, нуль будет представлен импульсом 0,5 мкс который будет находиться в конце интервала:
 Структура пакета АЗН-В Таким образом, в потоке бит данных с частотой 1 МБит/с всегда будут присутствовать импульсы, и только их положение по времени говорит о том, ноль это или единица.
Теперь немного о преамбуле. Она используется для распознавания начала пакета, поскольку ее битовая структура известна, и к тому же она (как и любая другая правильная синхронизирующая последовательность) не может встретиться в потоке данных, посколькую содержит пропуски в импульсах. По преамбуле в реальном времени идет настройка максимального и минимального уровня сигнала, чтобы адаптироваться под конкретные характеристики образуемой радиолинии борт — земля. Кроме этого, контролируется целостность преамбулы, которая может быть разрушена наложением сквиттера с другого борта. Используя настроенные параметры, приемник использует их для определения порога обнаружения информационных импульсов. При обработке информационных импульсов используются и другие критерии целостности данных, помимо контрольной суммы.
Proof of Concept: структура прототипа
Как показано на фото, прототип состоит из следующих узлов: простейшей широкополосной антенны, приемного модуля с антенным входом и USB выходом, который в свою очередь подключен к USB разъему одноплатного компьютера SBC (Single Board Computer).
Приемный модуль фактически является приемником прямого преобразования и оснащен быстродействующим АЦП с частотой выборки 2 Ms/s. Оцифрованный поток векторных данных I/Q направляется в USB SBC.
SBC имеет ARM архитектуру и работает под ОС Linux. Входной поток I/Q данных проходит демодуляцию и преобразуется в вещественную форму. ПО обработки содержит отдельный тред (thread), который обеспечивает поиск преамбулы во входных данных в соответствии с описанными критериями, и при нахождении преамбулы декодирует информационную часть пакета, извлекая информацию о номере борта ИКАО, его координатах и скорости. В соответствии с документом RTCA DO-282B, используется Downlink Format (DF) DF=17, предназначенный для АЗН-В. Декодированные SBC выдает по протоколу TCP/IP (желтый Ethernet кабель на фото), где они могут быть использованы в трекинговых системах, мультисенсорных системах наблюдения и КСА УВД/ATC.
Операционная система и программы обработки располагаются на флеш-карте. Источник питания на фото не показан.
Тесты
Собственно говоря, для тестов нашего POC прототип размещается на столе, антенна находится там же, включаем электропитание и наблюдаем на экране что летает сверху. Надо мной (Северо — Запад Москвы) в тот момент летало следующее:
 Лог приемника АЗН-В. Показаны все сообщения со всех бортов в порядке поступления В данном режиме, приемник АЗН-В просто выводит лог всех сообщений со всех бортов, которые к нему поступили так, как они пришли во времени. Так, например для воздушного судна с адресом ИКАО 42498d показаны сообщения расширенного сквиттера. В другом режиме отображения, который приведен ниже, все данные разнесены по бортам, которые в настоящий момент находятся в зоне действия приемника:
 Список бортов, находящихся в воздухе, с координатами АЗН-В Здесь каждой строке соответствует один борт со своим номером рейса, и приведены данные по его скорости, широте и долготе. Параметр Seen показывает на периодичность обновления информации: это таймер, который сбрасывается в ноль каждый раз, когда приходит сообщение. Из списка следует, что для борта с идентификатором 424049 последнее сообщение было 44 секунды назад и он вышел из зоны действия приемника. Для рейсов AFL1422, AFL205 и AFL1123 высокая частота обновления сообщений: их таймеры постоянно сброшены в ноль.
Есть возможность наложить полученные геодезические данные на карту Google Maps. Например, для борта с адресом ИКАО 42498d, которому соответствует номер рейса AFL521, так выглядит его положение на карте Московской области и даже трек с указанием направления движения:
 Данные приемника АЗН-В, наложенные на карту Google Maps
Таблица справа содержит список всех бортов, находящихся в данный момент в воздухе, в зоне действия приемника АЗН-В.
Таким образом, наш Proof of Concept подтверждает реализуемость тракта обработки приемника АЗН-В с использованием принципов SDR. Для улучшения характеристик этого приемника, а также для возможности его использования на профессиональном рынке необходимо сделать следующее:
- добавить входной фильтр и малошумящий усилитель;
- для зон с высокой интенсивностью полетов использовать многосекторную антенну;
- использовать дополнительные алгоритмы обработки для дискриминации помех;
- добавить программный интерфейсный модуль Asterix для сопряжения с КСА УВД;
- сделать редизайн конструкции для размещения приемника в стандартном конструктиве Евромеханика 3U;
- добавить функции контроля и управления, в том числе удаленного.
Но самое главное — работают базовые технологии.
Теперь, когда мы немного прояснили с форматами, организуем передачу видеопотока с машины cam, где стоит Rpi, на ноут bingo. Будем смотреть различные варианты транспортных протоколов.
NetCat
Поиграем со знаменитой хакерской программой netcat, которая обеспечит TCP транспорт для медиаданных нашей камеры на Rpi.
Вначале запускаем на ноуте:
|
|
legolas@bingo:~$ nc -l 5555 | ffplay - |
Запись означает, что мы слушаем на порту 5555 (произвольном) и все, что получим по сети, через конвейер передаем на вход плеера. Плеер уже немного другой — ffplay из последней полной версии ffmpeg которую я поставил из исходных кодов, для чистоты эксперимента.
Как откомпилировать ffmpeg под Убунту подробно написано здесь.
Далее, запускаем на Rpi:
|
|
pi@cam ~ $ raspivid -t 99999 -w 320 -h 240 -o - | nc bingo 5555 |
Здесь поток с видеокамеры через netcat отправляется на порт 5555 ноута bingo и плеер на bingo показывает кино. Отлично.
По умолчанию netcat использует TCP. Попробуем поменять транспорт на UDP ключом -u:
|
|
legolas@bingo:~$ nc -ul 5555 | ffplay - pi@cam ~ $ raspivid -t 99999 -w 320 -h 240 -o - | nc -u bingo 5555 |
Опс… картинка разваливается. Не нравится кодеку H264 протокол с негарантированной доставкой пакетов.
С вариантом TCP транспорта все работает, и формально можно заключить что задачу использования Rpi как клиента мы решили: принимающая сторона (сервер) принимает поток H264 через netcat и плеером смотрит фильм. Однако у этого метода есть существенный недостаток: сервер ничего не знает о параметрах кодека (а их может быть множество). Поэтому о параметрах нужно договариваться заранее, если клиент и сервер полностью под нашим контролем, или использовать один из способов передачи этих параметров. Один из таких способов — протокол SDP, описывающий медиаданные. Следующий шаг — использование SDP совместно с RTP.
RTP внутри ноута
RTP работает через UDP, но за счет вставки отметок времени поддерживает поток выровненным на принимающей стороне. Сразу скажу, что трансляция RTP с Rpi на ноут bingo у меня не пошла. Картинка не плеере не появлялась и было много сообщений об ошибках на принимающей стороне. Сразу возникло подозрение на avconv/ffmpeg из пакетов который стоит на Rpi — на ноуте-то я собрал его из исходников, а на Rpi — нет. Остановила необходимость разбираться с кросс-компилятором.
А пока запускаем RTP локально на ноуте, смотреть будем с его собственной камерой:
|
|
legolas@bingo:~$ ffmpeg -r 25 -s 320x240 -f video4linux2 -i /dev/video0 -vcodec h264 -f rtp -an rtp://bingo:1234 |
Пояснения к ключам команды:
- -r 25 частота фреймов;
- -s 320×240 размер картинки;
- — f video4linux2 входной формат видео (raw формат);
- -i /dev/video0 камера ноута, откуда идет поток;
- -vcodec h264 камера ноута дает raw формат, поэтому кодируем его со сжатием в h264;
- -f rtp выходной формат RTP;
- -an звук не нужен;
- rtp://bingo:1234 направляем поток RTP на этот адрес:порт (порт произвольный, адрес ноута).
После запуска ffmpeg выдаст нам данные RTP, которые как раз и нужны принимающей стороне:
|
|
v=0 o=- 0 0 IN IP4 127.0.0.1 s=No Name c=IN IP4 127.0.1.1 t=0 0 a=tool:libavformat 55.36.102 m=video 1234 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1 |
Сохраняем их в файле laptop.sdp и запускаем плеер с этими параметрами:
Все нужное для работы плеер берет из SDP файла. Появляется картинка — все работает, трафик RTP крутится локально на ноуте. Здесь мы впервые использовали ffmpeg для перекодирования данных из raw формата в h264. RTP — удобный формат для передачи h264, поскольку слайсы h264 один к одному ложатся в пакеты RTP которые имеют отметку времени.
Raspivid -> ffmpeg -> RTP
Вернемся к Rpi и попробуем запустить RTP с этой машины. Для того, чтобы отбросить любые сомнения, компилим ffmpeg под ARM архитектуру для Rpi. Самую краткую и понятную процедуру кросс-компиляции, включая предварительно установку кросс-компилятора и toolchains я нашел здесь. Все работает, только во время конечной сборки появляется ошибка о том, что не найдена библиотека libx264, несмотря на то что она уже скомпилирована и ключи компилятора (сама библиотека и путь к ней) проставлены правильно. Я вылечил это дополнительной опцией -ldl
Копируем полученные файлы на Rpi и включаем камеру через RTP:
|
|
pi@cam ~/bin $ raspivid -t 999990 -w 320 -h 240 -o - | ./ffmpeg -v info -i - -vcodec copy -an -f rtp rtp://bingo:1234 |
Ffmpeg запускается из локального каталога pi/bin, перед этим я удалил все пакеты, связанные с ним. Замечу, что raspivid уже отдает поток в формате h264, поэтому никакого кодирования не требуется: ffmpeg использует простое копирование данных (кодек copy) и только пакует h264 в RTP пакеты. Следует заметить, что в данном режиме загрузка процессора ffmpeg’ом всего около 3%.
Сформированные данные RTP:
|
|
v=0 o=- 0 0 IN IP4 127.0.0.1 s=No Name c=IN IP4 192.168.0.29 t=0 0 a=tool:libavformat 55.36.102 m=video 1234 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; sprop-parameter-sets=J2QAKKwrQKD9APEiag==,KO4BDyw=; profile-level-id=640028 |
Сохраняем их в файле rpi.sdp на ноуте bingo и запускаем плеер:
|
|
legolas@bingo:~$ ffplay -i rpi.sdp |
Все работает. Точно так же принять поток можно и плеером VLC:
|
|
legolas@bingo:~$ cvlc rpi.sdp |
После всего проделанного, можно сделать следующий вывод: никогда не используйте ffmpeg из пакетов, всегда собирайте последнюю версию!
Вначале, подготовим два файла для опытов. Экспериментируя с видео, я каждый раз возвращался в одну и ту же точку, в которой приходилось разбираться с видеокодеками. Мы сейчас находимся в этой точке, и лучше прояснить все с самого начала.
Снимаем кино
Зайдем на Rpi и сделаем маленький фильм командой
|
|
pi@cam ~ $ ls -l -rw-r--r-- 1 pi pi 10154858 Апр 5 15:12 cam.h264 |
В течении нескольких секунд на камере появится красный огонек, и потом появится файл cam.h264. Имя и расширение — совершенно произвольные. Я дал расширение h264 потому что утилита raspivid пишет в формате кодека h264.
Проверим, в каком формате прошла запись файла (повторю, расширение никакой роли не играет). Вначале очень полезной командой file:
|
|
pi@cam ~ $ file cam.h264 cam.h264: JVT NAL sequence, H.264 video @ L 40 |
Потом — более специализированной командой avprobe из состава медиабиблиотек libav:
|
|
pi@cam ~ $ avprobe cam.h264 avprobe version 0.8.10-6:0.8.10-1+rpi1, Copyright (c) 2007-2013 the Libav developers built on Mar 22 2014 02:13:15 with gcc 4.6.3 [h264 @ 0x1a69660] Estimating duration from bitrate, this may be inaccurate Input #0, h264, from 'cam.h264': Duration: N/A, bitrate: N/A Stream #0.0: Video: h264 (High), yuv420p, 1920x1080, 25 fps, 25 tbr, 1200k tbn, 2400k tbc |
Из этого делаем вывод, что файл действительно записан в формате h264, размером 1920×1080 (да-да, это Full HD камера, кто бы мог подумать!), частота кадров — 25 в секунду.
Едем дальше: будем пробовать смотреть наше произведение в видеоплеере. Поскольку мы отказались от дисплея на Rpi, то будем смотреть вывод на своем компьютере bingo. Для этого перезайдем командой
|
|
legolas@bingo ~$ ssh -X pi@cam |
В результате сетевой адрес дисплея моего компьютера bingo (переменная окружения DISPLAY) будет экспортирован на машину cam и все графическое что я буду запускать на cam будет отображаться на bingo.
Теперь не терпится проиграть этот файл в плеере и посмотреть что сняла камера? Ничего не получится. Запустим mplayer cam.h264 и увидим одну ругань. В чем же дело?
Кодеки и контейнеры
Дело в том, что хотя файл содержит полную видеоинформацию о фильме, этого недостаточно. Данные кодека h264 должны быть помещены в контейнер. Контейнер — это нечто, позволяющее внешним программам работать с аудиоданными в упорядоченном режиме. Можно привести аналогию: кодек это куча песка, но чтобы его куда-то отвезти, нужен железнодорожный состав с вагонами. Продолжая аналогию, говорим о том, что вагоны — это фреймы которые содержат данные кодека.
Для того чтобы сформировать контейнер нам подойдет команда avconv. Она умеет много чего другого, в частности перекодировать видео и аудио с одного формата в другой. Но это нам не нужно: мы просто сохраняем кодек h264 и помещаем его в контейнер mp4. При желании, можно выбрать какой нибудь другой контейнер, например avi. Тип контейнера указывает ключ -f. Командная строка будет выглядеть так:
|
|
pi@cam ~ $ avconv -i cam.h264 -vcodec copy -f mp4 cam.mp4 |
Ключ -i указывает на входной файл, опция copy говорит о том что видеоданные перекодировать не нужно и они просто копируются в контейнер cam.mp4. В результате получаем контейнер с данными кодека:
|
|
pi@cam ~ $ ls -l -rw-r--r-- 1 pi pi 10154858 Апр 5 15:12 cam.h264 -rw-r--r-- 1 pi pi 10156809 Апр 5 15:38 cam.mp4 Аналогично, смотрим что за файл получился: |
|
|
pi@cam ~ $ file cam.mp4 cam.mp4: ISO Media, MPEG v4 system, version 1 |
|
|
pi@cam ~ $ avprobe cam.mp4 avprobe version 0.8.10-6:0.8.10-1+rpi1, Copyright (c) 2007-2013 the Libav developers built on Mar 22 2014 02:13:15 with gcc 4.6.3 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cam.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf53.21.1 Duration: 00:00:00.04, start: 0.000000, bitrate: 2031361 kb/s Stream #0.0(und): Video: h264 (High), yuv420p, 1920x1080, 2030971 kb/s, 3575 fps, 1200k tbn, 2400k tbc |
Заметим, что размер контейнера чуть больше чем размер файла кодека. Так и должно быть: вагоны тоже чего-то стоят.
Берем попкорн и садимся смотреть видео:
|
|
pi@cam ~ $ mplayer cam.mp4 |
Не забываем, что благодаря команде ssh -X смотрим видео не на Rpi, а на своей машине.
Здесь, справедливости ради, надо отметить, что мы смогли бы проиграть «чистый» файл cam.h264 и без контейнера. Для этого достаточно указать скорость поступления фреймов, которую плеер берет из контейнера:
|
|
pi@cam ~ $ mplayer -fps 25 cam.h264 |
Замечу, что поскольку в конечном счете нам нужен именно контейнер, то можно обойтись без промежуточного файла cam.h264:
|
|
raspivid -o - | avconv -i - -vcodec copy -f mp4 cam.mp4 |
Таким образом, различаем кодеки и контейнеры (в терминологии libav — форматы). Полезные команды:
узнать какие кодеки поддерживаются:
|
|
pi@cam ~ $ avconv -codecs |
узнать какие форматы (контейнеры) поддерживаются:
|
|
pi@cam ~ $ avconv -formats |
Дальше поговорим о том, как обеспечить live streaming — передачу видео по сети.
Продолжение в следующем номере:
Смотрим Raspberry Pi: часть 3
Когда-то же она должна была у меня появиться, эта малышка-игрушка Raspberry Pi. Поскольку все у кого она есть считают нужным непременно сделать ее фото в своем блоге (от этого Rpi не становится какой-то особенной и отличной от других), не буду отступать от традиций и тоже выкладываю фото.
Итак, что мы имеем? Флешка на 8 Gb внутри адаптера, торчит справа на фото, вставленный в один из двух USB разъемов Wi-Fi донгл слева, и камера которая коннектится к разъему на плате.
Камеру я долго не мог запустить; последняя печальная версия которая у меня появилась это то что я убил ее статикой. Оказывается я просто подсоединил ее не к тому разъему на плате: два разъема совершенно одинаковы.
Плата имеет аудиоинтерфейс, что может быть интересно в будущем, и возможность подключения клавиатуры/мышки/монитора, что неинтересно, потому что с такими вещами мне комфортнее работать через удаленную строку. Да, и конечно же Ethernet интерфейс.
Источник питания на 1А, о чем честные юзеры в сети предупреждают что может не хватить если подключен USB донгл и камера. Я пока с этим не столкнулся.
Приобрел также корпус для платы и отдельно для камеры. После этого сразу же понял, что мне на самом деле нужен корпус в который можно установить камеру и плату одновременно, и будет совсем замечательно если он будет длиннее чтобы не задевать торчащие разъемы и флешку. А выступают они очень хорошо, как видно на фото где Rpi в сборе.
На борту — ARM процессор плюс собственно изюминка: специальный графический сопроцессор GPU, который очень быстро работает в некоторых из кодеков. Доступиться к GPU можно через родные утилиты Rpi, такие как raspistill и raspivid, или через интерфейс драйверов OpenMax. Утилиты имеют исходники, так что можно написать что-нибудь свое. Есть родной плеер omxplayer, который также использует GPU.
Сразу скажу, что надо сразу отказаться от мысли использовать ARM под медиаприложения стандартным способом через ffmpeg и тому подобное. Загрузка процессора под 100% гарантирована. А раз стандартные способы не проходят, то надо быть готовым к урокам танцев с бубном.
Интересная тенденция получилась с процессорами ARM архитектуры, а точнее OMAP, которые кроме ARM содержат еще DSP ядро. Изначально предполагалось что DSP возьмет на себя основную нагрузку по компонентам, которые требуют высокой производительности и реалтайма. Поначалу так оно и было, и до сих пор у Texas Instruments есть соответствующие библиотеки для DSP.
Но пару лет назад на одной из конференций Texas’а я ощутил другой тренд — использование сопроцессоров для ARM ядра, особенно для обработки видеоданных. Предполагаю, что это связано с бурным развитием рынка IP камер и как следствие — необходимость автоматического распознавания различных ситуаций (драка, ограбление) без участия оператора. Видимо, DSP отойдет в область специализированных приложений, в частности обработки радиолокационных данных, где требуется скоростная свертка и доплеровская фильтрация.
Теперь плавно переходим к тому, что можно сделать с Rpi. На флешку сразу поставил дистрибутив Raspbian, который мне привычнее, потому что моя десктопная система — Ubuntu. После загрузки Rpi смотрим IP адрес платы в DHCP списке Wi-Fi, чтобы доступиться по ssh. Можно и не смотреть адрес и использовать в адресной строке hostname:
Маршрутизатор DLink умеет работать с именами хостов, поэтому здесь cam — имя платы Rpi, bingo — мой ноут, pi — имя пользователя на cam. Все, теперь мы внутри. Нас интересует все, что связано с удаленным медиа-доступом к Rpi. Ждут ответа следующие вопросы:
- отправка видео с камеры Rpi (клиент) на удаленных хост (сервер);
- доступ с удаленного хоста (клиент) к видеокамере на Rpi (сервер).
Продолжение в следующем номере:
Смотрим Raspberry Pi: часть 2
|
|
Last comments