Alver

Хорошая тарелка имеет подавление сигнала помехи в задней полусфере F/B=-25-35 dB. То есть как направлена антенна в сторону источника помех имеет значение. Встроенный анализатор спектра обычно показывает сигнал вайфайного типа, сигналы 3G/4G он не видит и часто ( в зависимости от того что он может декодировать) может даже не видеть синхронные TDD/TDMA каналы FWA например такого оборудования как Cambium ePMP/ PMP. Если RSSI=-60 dBm а помеха - 88 dBm то отношение сигнал/ помеха 28 dB что позволяет например Мимозе работать на модуляции 64 QAM и поэтому при такой помехе оборудование работает достаточно стабильно. Тем самым - если при перестройке рабочего канала влияние помехи меняется , то имеется помеха в рабочем частотном канале частот устройства и если эту помеху СА устройства не видит , то она синхронная TDMA/OFDMA/SC-FDMA и по своей структуре не вайфайного типа. Источником помех в 5.8 ГГц которую СА не видит может быть станция РЭБ ( например против VTx канала 5.8 ГГц дронов) , либо зеркальный канал близко расположенной станции 4G. Может быть и старая советская релейка 5.8 Ггц типа Курс , но это редкость (но может кто то поставил ). Такая помеха - как раз ваш случай. Поможет только перестройка рабочего канала, фильтры не помогут. - у Toksiк другой случай. У него похоже от перестройки рабочего канала влияние помехи не меняется, и это внеполосная помеха от мощного источника помех , работающего совсем на других далеких от 5.8 ГГц частотах. Ключевой момент-этот сигнал помехи приходит в приемник вне рабочего диапазона частот устройства то есть за пределами 4.9-6.4 ГГц и обычно это ниже частот 4.9 ГГц. Эту помеху встроенный СА также не видит и она настолько мощная, что приходит в приемник устройства если там нет фильтров 4.9 -6.4 ГГц или фильтры слабые и приемник не супергетеродинного типа. Такая помеха искажает параметры работы АРУ ( автоматическая регулировка усиления) приемника и устройство перестает нормально работать . Источником такой помехи может быть РЛС ( например аэродромная для навигации или РЛС ПВО в том числе РЛС для обнаружения дронов, станция РЭБ например на частотах в районе 1.5 ГГц (против GPS дронов) или типа того. В моей практике это были случаи РЛС аэродромной навигации, а также запомнился случай когда по реке Днепр проплывал один необычный корабль с локатором который создавал проблему рядом работающим устройствам FWA. Сейчас когда вокруг работают много станций РЭБ и РЛС ПВО такие случаи участились. Cледует особо обратить внимание всех нас , включая военных ( которые читают наш форум ) что у рашистов недавно появились станции Mobile 5G (Китай) которые уже развертываютcя в некоторых рашистких городах, работающие в диапазоне частот 4.6-4.9 ГГц и у них имеется упрощенный ( предположительно ) вариант Fixed 5G на частотах 4.3-4.6 ГГц который уже применяется на рашистких дронах и на земле для связи. Мощность передатчика таких станций относительно небольшая не выше 33-34 дБм ( грубо порядка 3 Ватт ), НО если станция FWA 4.9-6.4 ГГц попадает в створ антенны близко расположенной такой станции 5G то будет воздействие внеполосной помехи или даже помехи в рабочем диапазоне частот FWA на 1 м или 2-м cоседнем канале ( 4900+40 =5.3 ГГц) станций рашисткого 5 G потому что у них скорее всего нет фильтров на их передатчиках 5G и вероятно слабая АЧХ (спектральная маска сигнала ) так как Китай. Против таких помехи помогают внешние фильтры и/или применение современного продвинутого оборудования ( c фильтрами , с cупергетеродинным приемником и др), а также работа на частотах 5.9- 7.125 ГГц.

Я имею в виду диапазон частот 5950-7125 МГц, то есть если точнее то 6.4+ ГГЦ.

То что вы говорите , что если смена частоты в вашем случае с 6+ Ггц до 5.8 ГГц и чуть ниже ухудшает канал связи ( любой не только Мимозы). то это именно то что я сказал выше- базовая станция 4G работающая на частоте например Vodafone в Downllink 1845-1865 МГц создает помеху на зеркальном канале 5575-5595 МГц распространяющуюся на 5700+ МГц и выше. Это значит что если Мимоза или любая другая станция FBW типа Cambium, Ubiquiti и Микротик ( и его клоны в том числе военные станции PTP образца 2014-2015 года ) при работе скажем на частоте 5740 МГц в канале 80 МГц попадают под воздействие помехи по зеркальному каналу БС 4G. Мощность помехи зависит от дальности до станции 4G ( обычно до 1-1.5 км) , куда направленна антенна вашей станции ( КУ и параметры ее ДН side lobe supression и Front to back ratio и другое . Если ваша станция находится слишком близко к станции 4G скажем в нескольких десятках метров то эта помеха будет создавать проблему даже если секторная антенна 4G направлена в зад антенны вашей станции. Что можно и нужно делать ? - Применять устройства под внешние антенны типа диш с узким лучом ДН и высоким F/B ratio и старайтесь ( если возможно) не направлять антенну в сторону станции 4G - если вы ставите устройство на одной крыше со станциями 4G то держитесь от них подальше - применять современные устройства с высоким энергетическим бюджетом System Gain = Tx мощность передатчика + Rx чувствительность приемника + Antenna gain (КУ ). - применять устройства реализующие современные радиотехнологии c радиосигналом устойчивым к интерференции от сигнала 4G ( в том числе по зеркальному каналу ) например на базе 802.11ax с доступом TDD/TDMA /OFDMA и сигналом OFDM1024 256 FFT ( количество поднесущих) - уходить в диапазон частот 5950-7125 МГц Использование частотных фильтров для борьбы с этим типом помехи не поможет. ЗЫ Это теория подкрепленная профильным образованием и многолетним практическим опытом.

В точка-точка у Мимозы и другого аналогичного оборудования FWA протокол TDD (Time Divison Dupleх ) это метод поддержи дуплекcа передача - прием. TDMA ( Time Division Multiply Access) - это совсем другое- метод разделения множественного доступа от множества клиентов в малтипойнт . Оба метода никакого отношения к помехоустойчивости к внеполосным помехам не имеют . Кроме того TDMA у Мимозы не реализован , как бы было в них в планах еще лет 5-7 назад сделать это на 802.11ас , что то там пилили , но в следующем поколении оборудовании Мимоза 802.11 ax TDMA нет . Если есть подозрение что влияет не внеполосная помеха, а помеха по зеркальному каналу от станции 4G на частотах 5 ГГц( кратные частоты рабочих каналов 4G) и встроенный СА сигналы 4G не видит то это легко понять просто перестроив рабочий частотный канал . В данном случае признаков что это помеха по зеркальному каналу 4G - нет.

C5c позиционируется как устройство для построения каналов точка-точка. Как бы поддерживается также малтипойнт . но там есть ньюанс - до сих пор нет полноценного TDMA (и видимо никогда не будет) и поэтому по идее там должны быть фильтры , подавляющие внеполосные ( ниже 4.9 ГГц и выше 6.4 ГГц) помехи. Но что стоит в C5c доподлинно неизвестно поскольку используется редкое радио на SOC Quantenna, что применяет для сетей FWA только Mimosa ( ныне Airspan) . Все другие производители FWA применяют SOC Atheros-Quacomm и там для точка-точка и базовых станций фильтры точно есть . Судя по тому что СА C5с показывает сигналы аж до 4400 МГц, то фильтров скорее всего нет. Ставьте фильтры на частоты ниже 4.9 ГГц, есть на рынке с затуханием 30-40 dB по цене в пару десятков USD, нужно два на каждый канал MIMO 2x2. Или меняйте оборудование где используется SOC Atheros лучше с современным радиочипсетом 802.11 ax или SDR 802.11ax.

По видимому, воздействует мощная внеполосная помеха, она проникает в радиоприемник вне его рабочего диапазона частот ( СА такую помеху не видит) и подсаживает его усилитель. Частотные фильтры по бокам рабочего диапазона гасят помеху , но видимо или фильтры слабые или (если это CPE - клиентская станция ) фильтров вообще может не быть. Источником помех могут зеркальные частотные каналы мощных РЛС, РЭБ и др. Решить проблему можно поставив внешние 5 ГГц фильтры в разрезе кабеля между внешней антенной и устройством и не применять для каналов точка-точка клиентские станции.

OSD -это телеметрия накладывается на видео и в потоке видео передается на пуль управления/очки. Поскольку сейчас видео тяжелое, требующее высокой скорости передачи данных ( и не всегда с низкой задержкой , разве что в мелких спортивных FPV дронах для гонок, которые нам сейчас особо то и не нужны) любая даже легкая помеха радиоканалу передачи данных тормозит видео ( что не есть проблема ) но и вместе с видео также и телеметрию, что уже совсем другое дело и может иметь критическое значение. По поводу задержки я уже сказал выше. А отдельный FEC ( равно как ACK/ NACK) в видеоканале , это проприетарный протокол передачи видео на физическом уровне радио ( типа как у у видеосистемы DJI ) как раз направленный на снижение задержки для спортивных дронов. Решая эту задачу которая мало востребована в наших условиях (зачем нам недешевые гоночные болиды для наших задач в наших полях и лесах ?) мы жертвуем эффективностью много чего другого, что нам реально нужно. Насчет Интернет. Если вы хотите упаковать проприетарное на ` FHY уровне видео с низкой задержкой ( да еще плюс телеметрию) сразу в IP канал на транспортном уровне ( минуя канальный уровень) и даже выше -выходите на уровень приложений, то это надевать сову на глобус. Вы теряете все преимущества видеосистемы с низкой задержкой , потратив на создание такой системы немалые ресурсы и лишившись при этом необходимой совместимости с работой других систем и, в итоге, ничего толкового и эффективного не получаете .

Отдельно следует сказать за видеоcистему DJI, там действительно минимальная задержка (именно видео) и протокол видео не RTSP ( что есть L5 уровень Application level OSI) , а свой проприетарный протокол L2 ( вместо стандартного L2 MAC ) без стека TCP/UDP IP ( 3 и 4 level OSI) - просто цифровое видео передается по их L2 . И в ее разработку вложено не миллионы, и не десятки млн $, а значительно больше, и много лет работы тысячи китайских программистов и инженеров по видео и радио ( изначально много лет назад этой были приглашенные американские инженеры). Но это другая отдельная история и главный вопрос в постановке задачи, надо ли оно нам сейчас (для каких задач) в подобной нестандартной ( в этом есть ключевая проблема) реализации. Как по мне - такой задачи и необходимости в функционале БПЛА за такие деньги, что дает решение этой задачи, в нашей складывающейся тактике боевого применения БПЛА - нет. Иными словами то технологическое преимущество ( низкая задержка и джиттер), что реально есть в видеосистеме DGI , интегрированной в их в общем то неплохую систему радиосвязи ( в сравнении с радиотехнологией LORA в реализации TBS Crossfire ,ELRS, но уступающую по многим параметрам радиотехнологии 4G, 5G мобильного и фиксированного доступа в реализации например Qualcomm ) страдает многими побочными но критичными недостатками в целом ( из-за проприетарности) и невостребовано ( я бы сказал больше - архитектурно несовместимо и поэтому непригодно ) для реализации широкого круга потребного функционала для БПЛА различного назначения для многих ( если не всех ) вариантов их боевого применения. Фиксация DJI на снижение задержки именно в передаче видео и управления для "гоночных" FPV дронов за счет потери функционала для решения других задач БПЛА играет против экосистемы DJI и это уже имеет свои последствия.

В чем проблема передавать видео с цифровой IP камеры по RTSP ? Задержка ? Она там в этом протоколе минимальная из возможных по IP сети. Совершенно точно меньше чем например по HLS. И собственно зачем вам нужно именно live-streaming? Передавать видео по Интернет ? Для этого есть другие решения. Задержка в RTSP в основном определяется медиаплеером , например у VLС она может быть высокой из-за буферизации потока. Есть плейеры RTSP под Linuх или железячные видеорегистраторы где она минимальна. Большинство IP камер дронов и отчасти систем видеонаблюдения работают именно по RTSP. Передача видео с камер дронов или видеонаблюдения -тема хорошо проработана. Использование стриминговых протоколов, в основном предназначенных для медиасервисов TV/Video типа OTT, для этих задач -непонятно что хотите получить и улучшить, то есть сама постановка задачи изначально тупиковая.

У тебя не хватило ума подключиться к сети и посмотреть к какой именно точке доступа ты подключился и даешь отзыв не по фактам, а высказываешь свои измышления и делаешь ложные предположения.

На антеннах с усилением 30 dBi, 15 км LOS, без помех ( noise floor < -87 dBm), data rate PHY ( в радио) 866 Mbps, 256 QAM 5/6, канал 80 МГц. -600 Mbps в Ethernet в UDP тестах пакетами 1500 байт, - 400+ Mbps в Ethernet в TCP на реальном трафике со средним размером пакета +-900 байт ( микс видео , http, телефония и др. ), без помех.

Это и есть SDR -Software Defined Radio.

Релейки НЕ работают ( от слова совсем) при помехах, равно как в NLOS/NearLOS, над водой и др Причин много, одна из которых -там не OFDM сигнал. Почему дорого, потому что FDD, SDR и др. недешевые фичи.

Есть, но дело не только в частоте. Имеет значение против чего они разработаны и тактика ( способы) их эффективного применения Задача сложная и плохо решаемая для радиолинков (что я сказал ) и не только в существующих условиях применения. Ну вот возьми и подави например сигнал 11-12 ГГц Старлинк ? Системы подавления разрабатываются рашистами и как бы они уже есть, но толком не работают, пока ( что есть для нас хорошо).

Ты говоришь ни о чем. Тебе же не позволят поставить глушилку на одной мачте с подавляемым линком. Вот и расскажи чем и как именно ты сможешь удаленно подавить помехой линк скажем 1-10 км на частоте 7 ГГц , ширина ДН антенн 7 град, F/B подавление антенн 30 дБ, железки c сигналом OFDM FFT 256/1024 с системным усилением System gain 140 дБм. Хотя бы формула расчета зон подавления тебе известна ? Изучал вопрос в профильном вузе ( если ты вообще там учился)? Может знаешь как рассчитать требуемую спектральную плотность потока мощности помехи ( Spectral Power Flux Density )? С какой стороны и как близко нужно подойти к линку и какой должен быть сигнал помехи и ее параметры ? Или у тебя есть обширная практика испытаний и применения готовых систем ? Ну расскажи мне и заинтересованным людям , как это все правильно делать. Можешь даже здесь, потому что ничего толкового ты сказать не можешь. Или хотя самое простое - зайди в тлг канал Флеша и расскажи всем там как эффективно поставить помеху наземному ( или воздушному !!!! ) ретранслятору канала передачи видео с дрона на частоте 5.8 ГГц .