Беспроводная передача видео в full HD
вся фишка в том что такие аппаратные ресурсы и размеры вполне позволяют вывести электронную начинку летательного аппарата на качественно новый уровень, в рамках одной платы можно объединить все, начиная от автопилота и ОСД до систем телеметрии и видео.
… и все это на вполне комфортном уровне программинга и отладки, в отличие от всяких мег и кортексов
Максим, тссс, не бегите впереди паровоза 😃, никому не говорите, скоро будет!
Видел в сети один сайт, разрабы впихнули кодер DVB-T в плисину Spartan-3a, на выходе уже промежуточная частота для передатчика, за IPcore хотят порядка 30к евро, так что спецы по плисинам все в ваших руках )))
в воздухе получить стабильный вай-фай линк 10мбит/сек до 2 км вполне возможно без всяких усилителей. На земле, конечно, лучше иметь чтото направленное.
Практический результат:
Wi-Fi мост на двух точках доступа Bullet M2 HP 600мВт, на автомобиле антенна 8.5 дБи - штырь, на базе 27дБи направленная, следящая.
В динамике(скорость авто до 120км/ч) на дальности 5 км пропускная способность до 6 Мбит/c, на 2 км - до 20-30Мбит/c.
Цифры получены через внутреннюю программу диагностики точки доступа, так что реальная скорость примерно вдвое ниже.
Испытание проводились на границе города, так что эфир был “в меру засран” 😉
А потери линка происходили в процессе тестирования?
Как быстро линк восстанавливалося?
А потери линка происходили в процессе тестирования? Как быстро линк восстанавливалося?
Потерь в смысле полного разрыва соединения не было (потеря по пингам не более 1-2%), но возникали дополнительные временнЫе задержки и артефакты изображения. Возможно, так работало железо ip-видеосервера, через который и гнали изображение. Видео постоянно “запаздывало” на 0.3-0.5 с даже при 54 Мбит/c. При снижении уровня сигнала (за кустами, за домами) получалось примерно так:
видео будет запаздывать всегда это особенности алгоритма сжатия, ключевой кадр плюс к нему 10-20 вспомогательных, при таком раскладе получим 0.6 -0.8 сек задержку при 30 к/с.
Вывод: нужно либо применять альтернативные алгоритмы сжатия, без участия ключевых кадров, либо передавать сырой поток от камеры, но там ширина канала нужна большая
я тут встречал USB радиоудлинители, если взять вебкамеру и заменить на радиоканал не IP участок путем трансляции потока от IP сурвера, а сам USB, приемопередатчики соответственно забустить для увеличения дальности
Не спец в кодировании видео, но вроде при однопроходном кодировании каждый дельта-кадр рассчитывается на основе пред.истории а не пост. Поэтому не очень понятно зачем тянуть с его отправкой. Тем более для ключевого кадра…
не важно пред или пост, ведь отправляем мы не исходный кадр а результат кодирования, в результате результирующий набор кадров мы сможем рассчитать только приняв всю последовательность необходимую для создания выходного набора ключевой и вспомогательные, в итоге ждем.
Хотя я то же не спец могу и ошибаться, но опыт и логическое мышление меня редко подводит…
Тогда на уровне логики докажите, что задержка необходима… 😃
Закодировали K1-кадр -> передали
Закодировали D11-кадр -> передали
…
Закодировали D1n-кадр -> передали
Закодировали K2-кадр -> передали
Закодировали D21-кадр -> передали
…
Закодировали D2n-кадр -> передали
итп…
На приеме все абсолютно симметрично, задержка 1кадр…ну может + время кодирования+время передачи+ время декодирования.
При кодировании аудио, насколько помню, латентность определяется необходимостью буфера для хранения пред. истории, а здесь вроде все детерминировано размером кадра.
Тогда на уровне логики докажите, что задержка необходима
Сергей, Ваш пример для теоретического кодека, кодирующего только опорные кадры и кадры отличия от них (предсказание) на канале с неограниченой полосой… В реальности даже MPEG2 кодирует три типа кадров: базовые, отличия и двунаправленные, для которых нужен буфер.
Плюс к этому задержка возникает при упихивании базовых кадров в реальный канал с ограниченной пропускной способностью. Например, если передавать только базовые кадры (jpeg фотки), то это можно делать без задержки на канале в 20-30 Мбит, а когда мы сжимаем поток в 5-10 раз,это означает что базовый кадр занимает 80-90% объема всего потока, поэтому никак не может передаться за свои штатные 30 или 40 мс. Типичный mPEG2 поток это один опорный кадр на 15 предсказаний, то есть задержка на 0.4 сек уже гарантированна.
Поэтому не очень понятно зачем тянуть с его отправкой. Тем более для ключевого кадра
Нужно рассматривать задержки не только при формировании кадра, но и при передаче его через стек TCP/IP. У меня время пинга с одной AP на другую по радиоканалу варьировалось от 10 мс до 800мс! Т.е. повтор кадров TCP, сам протокол обмена и т.п. тоже вносят свою лепту. Кстати, видеосервер, что был у меня, давал задержку даже при проводном подключении 100 Мбит и MJPEG компрессии. Возможно, что еще и клиентский софт притормаживал. Просто от меня реалтайма тогда не требовали, поэтому глубоко не копал
Итак попробовал использовать выходной каскад передатчиков фокстеч =http://www.betatvcom.dn.ua/…/hmc408lp3.pdf
Выходной каскад усиливается, проверено, но результат нулевой 😦
При отключенных передатчиках дальность 10 метров, при включенных,
маскимальная дальность которая получилась в поле 30 метров.
Вывод не все так просто как казалось в начале.
посмотрел еще раз внимательно
неправильно сделано было просто
- Внешние уселки нужно кидать не на выход штатных (там уже 19 дбм) а на вход, разорвать цепь (отпаять согласующий резистор или кондер там обычно) и подкинуть внешний усь
- Система передачи дуплексная! Там есть пятый канал это приемник
1-4 передача, 5 прием
Соответственно нужно бустить еще и в приемнике 1 канал.
Что бы не обрастать кучей уселков лучше взять комплект
www.aliexpress.com/item/…/564523540.html
там передатчик имеет всего два канала один прием второй передача.
Соответственно понадобится два бустера, один на приемнике второй на передатчике.
Что бы ослабить взаимное влияние передающей части на приемную еще не плохо бы антенны разной поляризации поставить, например пару клеверов противоположного вращения, а на земле сдвоенный хеликс разного направления.
Аслан тестовый комплект еще жив?
Попробуйте сделать по уму, не обязательно бустить все 4 передающих, для теста достаточно будет одного уселка на передающей и одного на приемной части
Что бы ослабить взаимное влияние передающей части на приемную
Там скорее всего не дуплекс, а полудуплекс и пока идет прием передачи нет.
Коль уж использовать протокол с подтверждениеми и перепосылкой потеряных кадров, так значительно проще.
А еще лучше чисто симплексная передача, ИМХО…
Нужно рассматривать задержки не только при формировании кадра, но и при передаче его через стек TCP/IP
Зачем здесь нужен TCP/IP вообще непонятно. Да и нет его там. Прямая связь точка-точка, никакой маршрутизации. Обычный радио-Ethernet, в кадры которого напрямую упакованы видеоданные.
Там скорее всего не дуплекс, а полудуплекс и пока идет прием передачи нет.
полу или полный в данном аспекте не важно, ибо для того что бы инициировать процесс приема и отключить передатчик нет другого пути кроме как постоянно слушать эфир и ждать кодовую посылку от приемника на земле. Если при этом местный бустер будет заваливать приемник борта то мы в принципе в режим приема не перейдем.
Главная проблема таких систем отсутствие синхронизации, в итоге всегда идут по схеме мастер-слэйв, слэйв слушает эфир постоянно и по сигналу от мастера рулит процессами приема и передачи. Чисто же полудуплекс только в радиостанциях возможен, когда все больше слушают чем говорят.
ибо для того что бы инициировать процесс приема и отключить передатчик нет другого пути кроме как постоянно слушать эфир и ждать кодовую посылку от приемника на земле.
Зачем постоянно слушать? Инициатива у передатччика. Он регулярно шлет пакеты с паузами между ними. В паузах слушает ответы. И все, не надо мудрости лукавой. 😃
Чисто же полудуплекс только в радиостанциях возможен, когда все больше слушают чем говорят.
Весь радио Ethernet работает в полудуплексе. Обычный принцип, прежде чем передавать, слушаем, если канал свободен - шлем свой пакет (при этом приемник отключен).
В данном же случае даже этого не требуется, так как канал не широковещательный, а точка-точка…
Зачем постоянно слушать? Инициатива у передатччика. Он регулярно шлет пакеты с паузами между ними. В паузах слушает ответы. И все, не надо мудрости лукавой. 😃
тут и кроется проблема, решают которую по разному конечно, но тем не менее она есть.
Без синхронизации весьма высока вероятность что передатчик ничего не услышит, поскольку приемник может и не принять пакте передатчика, а не приняв пакет как он поймет что пора передавать?
Тут не все так просто как с виду выглядит, обычно решают проблему путем ввода неких безусловных таймингов однозначно перекрывающих время приема и передачи что бы гарантировать хоть какую то синхронизацию. В любом случае все эти решения приводят к снижению пропускной способности канала за счет лишних таймингов.
Хотя конечно все это лирика и отношения к самому решению имеет мало. В потенциале схема вполне работоспособна имхо, главное правильно забустить. Возможно конечно дальности будут не так как у аналога, так и фиг бы с ним, ну будет на модели бустер не 600мвт а 1.5 ватта.
Без синхронизации весьма высока вероятность что передатчик ничего не услышит, поскольку приемник может и не принять пакте передатчика, а не приняв пакет как он поймет что пора передавать?
Если протокол регулярный: длительности пакетов и пауз между ними одинаковы - синхронизация элементарно удерживается, даже при отсутсвии связи на протяжении в десятков секунд. Если больше - начинается другой режим - сканирование со стороны приемнника и безответная передача со стороны передатчика.
Максим, я уже 20 лет занимаюсь подобными протоколами - там есть особенности, но нет неразрешимых задач, поверьте. 😃
Аслан тестовый комплект еще жив?
Попробуйте сделать по уму, не обязательно бустить все 4 передающих, для теста достаточно будет одного уселка на передающей и одного на приемной части
Комплект жив конечно, но усиление одного канала ничего не дает. Дело в том, что без приборов невозможно понять, что выходит из передающего модуля (нормальный сигнал, или непонятно что, усиленный или…). Единственная возможность понять что что то передается или нет, это включить все вместе. Обратный канал тоже был усилен на стороне приемного модуля, но ничего это не изменило…
Дело в том, что без приборов невозможно понять, что выходит из передающего модуля
так вы для начала подключите правильно бустер, тогда можно будет говорить об усилении…