Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
Это настраивается на обеих сторонах? И зачем 24 канала? Вот где избыток раза в 3, ИМХО.
Приемник с хода разбирает пекет и определяет сколько пришло каналов и по ходу парсинга уже смотрит какова разрядность каждого из канала. Ну вообщем, да обе стороны так или иначе имеют поддержку.
24 это не избыток, это запас 😃
И они же не все передаются. Радиопакет конструируется на передатчике под каждую модель индивидуально.
Один пакет == одному каналу.
ИМХО, это совсем плохо, ибо идут прыжки по частотам. Некоторые частоты могут перманентно не пробивать эфир. И пакет можно совсем не собрать. И нужно городить алгоритм устаревания если часть приняли, а другую часть так и не смогли. А не смогли за какое время? И что делать если 7 из 8 приняли, а восьмой старше принятых на 500мс? Какое время устаревания считать допустимым, а какое считать границей и инфа протухает после нее? Лучше не связывайтесь, слишком много гемора и реально большой уровень допущений на приемной стороне по алгоритмам.
Если это даст хотя бы 2-х кратный прирост дальности, то смысл есть.
С прыжками можно договориться, если кол-во прыжков и количество каналов неодинаковые простые числа, например 7 и 11. Тогда и FS понятное дело наступает после 7х11 пакетов подряд, где нарушена полнота представления данных.
ИМХО временная несинхронность данных в пределах 150-200 мс, не критична для большинства применений.
Кстати, если передавать каналы всегда последовательно (и не увеличивать частоту передачи свежеизмененных, как предлагается исходно) то можно и номер канала не передавать, а только бит начала цикла.
Мне кажется не стоит овчинка выделки. Даже если в пределе вам удастся добиться 2 байтов на пакет, у вас еще преамбула syncword и header и CRC.
Чтобы передать 4 джойстика придется потратить 4 пакета и в каждом полный служебный обвес. Но, конечно, если энтузиазм есть это дело попробовать, то почему бы и нет…
Даже если в пределе вам удастся добиться 2 байтов на пакет, у вас еще преамбула syncword и header и CRC.
Я писал 5-6 байт на ВЕСЬ пакет. 1-2 байта преамбулы, 1 синхробайт, 2 байта канал+егономер, 1 байт CRC8. Все итого 5-6 байт (в зависимости от нужности AFC).
и в каждом полный служебный обвес.
Никаких встроенных хеадеров, и CRC16 - все это баловство и излишества! 😃 Всего 5 байт на 19200, даже с паузой на переключение частоты это 2.3 мс!
2.3 мс
и еще умножить на кол-во каналов и паузу межпакетную.
AFC придется включать на начальном этапе, затем, после синхронизации можно выключить, оно особо не плывет после этого. И если преамбула 1-2 байта всего, то AFC может не хватить.
и еще умножить на кол-во каналов и паузу межпакетную.
Паузу на смену частоты я учел. Ну пусть даже будет 3 мс на канал. При 10 каналов (а обычно и 8 достаточно), получается 30 мс на цикл, почти как в действующем протоколе (31.5 мс).
AFC придется включать на начальном этапе,
AFC можно делать программно. Если изначально кварцы синхронизированны, то при близком сигнале захват будет. Тем более девиация предполагается килогерц 10, то есть и без AFC разбежка в 5-7 кГц не страшна. А дальше - самокорректировка.
если преамбула 1-2 байта всего, то AFC может не хватить.
Сейчас 2 байта. И AFC нормально работает. Минимальное требование - как раз 2 байта.
1 байт, если обходимся “своими средствами”. 😃
Большое еще преимущество может быть, что слать надо 4 первых канала постоянно, а остальные можно немного пореже. Тогда и точность управления не пострадает, даже наоборот, и дальность выше из-за более короткого пакета.
Если вдруг интересно кому-то, информация.
Пара вылетов за пару выходных - и проверил OrangeLRS с ХК и с обсуждаемой прошивкой.
В штатном исполнении: антенны в виде штатных сосисок черного цвета и оранжевые модули (ТХ 100мВт).
Набор частот не менял, изменен только номер бинда.
Первый день было похолоднее - дальность окончания связи и включения файлсейфа - около 950 метров.
Второй день потеплее немного - дальность файлсейфа 1100-1250м.
Второй день потеплее немного - дальность файлсейфа 1100-1250м.
Наверное, прохождение было 😁 Оно бывает на УКВ, не так часто .как на КВ (коротких волнах), но тем не менее 😃
Хотя, в вашем случае, скорее всего, зашумленность в месте тестов в теплый день была меньше… А мб что-то то не так в контактах АФУ ваших модулей. А мб все вместе взятое 😃
Наверное, прохождение было
на таких диких расстояниях прохождение только мешает местной связи:)
интересно, что первый день (связь похуже) летал в чистом широком поле, а во второй - заехал на поселок (порядка 150м высоты). Теоретически над поселком помех побольше должно быть.
А вообще интересно, что можно получить в штатном варианте, без улучшенных антенн и других наворотов.
Крамольный вопрос - а кто-нибудь уже сравнивал родную экспертовскую и сабжовую прошивки на дальность на одном и том же железе (например на экспертовой же тини)?
С функционалом понятно, протокол вроде один, но вот одни ли детали реализации и, соответственно, дальность? Потеряю ли я что то из существенного, мигрировав с родной на сабжовую прошивку на передатчике 2г, окромя лоу баттери писчалки?
проверил OrangeLRS с ХК и с обсуждаемой прошивкой.
Тестировали по земле?
Статистику связи покажите, если еще не затерли? (Команды sl, ss из меню, на терминалке включить вывод в файл). По этим цифрам можно многое сказать.
А еще есть очень полезный замер уровня шумов - команда N. Рекомендуется делать на модели до и после подачи питания на остальную электронику.
а кто-нибудь уже сравнивал родную экспертовскую и сабжовую прошивки на дальность на одном и том же железе (например на экспертовой же тини)?
Прецеденты были. Кроме меня еще пара человек тест делала. Разницы по дальности с родными прошивками нет и быть не должно, так как протокол один и тот-же (все настройки RFM, формат кадра, скорость, период передачи и прочее - одинаковы). Вы можете поставить на одной стороне экспертовскую прошивку, на другой мою и они будут работать друг с другом.
Небольшие дополнения по корректировке частоты, добавленные мной, могут сказаться в нештатных ситиуациях (неподстроенные приемники, большая разница температур на концах связи), но в обычных условиях они ничего не меняют.
Потеряю ли я что то из существенного, мигрировав с родной на сабжовую прошивку на передатчике 2г, окромя лоу баттери писчалки?
С предатчиком может не прокатить. У 2G управление мощностью вых. усилителя сделанно через ШИМ меги - и у каждого модуля индивидуальные коэффициенты в регистрах. В моей прошивке такого управления мощностью нет, только программное воздействие на RFMку. Если переделаете управление мощностью бустера на подстроечный резистор, будет работать нормально.
(До сих пор не могу понять, зачем Дмитрий себе такой гемморой с индивидуальной подстройкой придумал? ИМХО, куда проще одним подстроечником вывести все бустеры на нужный режим и менять мощность единообразно RFM-кой, благо в RFM22/23B диапазон регулировки более 20 дБ).
вообще интересно, что можно получить в штатном варианте, без улучшенных антенн и других наворотов
Больше всего дальность зависит от шумовой обстановки на модели и вокруг. Если избавиться от лишних помех на модели и летать за городом, на 100 мВт можно рассчитывать на 5-6 км устойчивой связи (я улетал на 9, но с SAW фильтром). В городе 1.5-2 км.
Наибольший эффект я получил только после добавлнеия SAW фильтра. Уровень шума при этом упал на 10-12 дБ, а уровень приема на 2 дБ. Зато теперь над городом 4-5 км на 100 мВт - обычное дело.
Тестировали по земле?
Статистику связи покажите, если еще не затерли?
Поздновато прочитал, только добрался до инета.
Тестировал “в деле”😃, то есть я с пультом в поле, самолет в небе, высота была 135-145 метров.
Насчет статистики: не затер, но не все так просто. Приемник вклеен в фюз, забыл я насчет статистики и что её можно использовать, каюсь…
Попробую все-таки до него добраться в ближайшее время, самому интересно глянуть, что получилось.
Ну и как вариант, почему не очень дальность - у меня может неудачно место для приемника выбрано. Рядом (в 3-5см) видеорегистратор и плата автопилота на STM 172МГц (а там уж и других гармошек найдется). Возможно картину это немного портит. Дома через N статистику проверял до установки в самолет, но не очень наглядно получается, все дышит и шевелится, оценивать неудобно, т.к. раз от раза отличается. Может какую простейшую ГУИ применить, без расширенных запросов в приемник, а только периодически слать N и графическое отображение результатов в ответ? Я может и сам написал бы, но с тонкостями обмена в конкретном случае не очень знаком.
Когда точно залезу не скажу, постараюсь побыстрее и до следующих полетов конечно.
Статистику связи покажите, если еще не затерли?
вот кусок статистики, но не совсем разобрать можно, где что.
вот кусок статистики,
Шум в 50-60 тугриков при уровне сигнала а 90-100, это типичный порог связи для RFMки.
Основная проблемма, это шум 50-60. На хорошей, не шумящей модели, должно быть 30-40 тугриков, что примерно на 10 дБ лучше по помехам или раза в 3 по дальности. К шуму в 30-40 единиц и нужно стремиться при включенном борте.
Вставлю свои 2 копейки: благодаря помощи Александра baychi, поддержка стандартого протокола SBUS и расширенного протокола Александра (определяется автоматически) добавлена в SwiftAI NG.
Вставлю свои 2 копейки: благодаря помощи Александра baychi, поддержка стандартого протокола SBUS и расширенного протокола Александра (определяется автоматически) добавлена в SwiftAI NG.
Александру- громадное спасибо за исходники!
На основе их на скорую руку для наших пацанов- кружковцев из того что было - дистанционные “таймеры”.
Спасать планер если он “уходит” и маяк для поиска.
Тимофею и Сергею спасибо.
Выложил новую версию прошивок передатчика и приемника. Мануалы тоже обновил.
github.com/baychi/OpenExpertTX
github.com/baychi/OpenTinyRX
Изменений немного.
- Ввел еще один режим кодировки данных (включается 2-й в 5 ом регистре). В исходной версии от Эксперта, длительности импульсов передаются в диапазоне от 988 до 2012 мкс (нейтраль 1500 мкс). Futaba и в том числе sbus используют диапазон 880-2160 мкс. При использовании sbus на обоих концах двойная перекодировка снижала точность представления, да и сам диапазон 988-2012 мкс иногда оказывался недостаточен. Кроме этого в режиме 2 данные каналов пакуются в пакет строго последовательно (это важно для передачи на лету) и контрольным кодом защищаются все байты. Плата за режим 2 - несовместимость с режимами 0,1 и экспертовскими прошивками (параметры передачи не затронуты, на дальность это не повлияет, но кодировка данных в режиме 2 несовместима), поэтому при выборе режима 2 его надо указывать на приемнике и передатчке, иначе связи не будет. Rebind автоматически распознает режим передатчика.
- Добавил в пакет sbus выдаваемый приемником: RSSI (15-й канал) и уровень шума (14-й канал), для отображения на OSD. Это поддерживают АП SmallTim: как новый (о чем пишет Тимофей), так и старый (прошивку сделал, допроверю и выложу в ближайшее время).
Что-бы АП знал, что в пакете sbus есть эта информация в 16-й канал кладется признак- код 0x600. - Исправил несколько ошибок режима автопривязки приемника (rebind), приводящих к зацикливанию, при ошибках в поиске каналов. Заодно выяснилось, что очень большой сигнал (мощный передатчик, рядом с приемником), сильно затрудняет rebind: RFMка ловит тени каналов, принимая пакеты на близких, но других частотах. Избавится от этого не получается, поэтому рекомендуется выполнять rebind на минимальной мощности передатчика, или отнеся его подальше (нескольких метрой обычно достаточно).
- Изменил отладочный вывод длин импульсов у передатчика. Теперь они выводятся либо в микросекундах (R6=1 или 3), либо в шестнадцетиричных кодах (R6=5 или 7) от 0 до 7FF.
Ну и всякие мелкие улучшения и исправления.
всякие мелкие улучшения и исправления.
Если не используется sbus, а только PWM, будет ли разница в режиме 2?
а только PWM, будет ли разница в режиме 2?
Если исходный PPM футабовский, режим 2 имеет смысл. Если нет, то нет.
PS: Визуально разницу между режимами вообще увидеть сложно, потрея 1-2х бит из 11 это мизер…
Интересно, почему у всех приёмников эрефемки без экранов?
Если на борту сильно плотно стоят беки, осд, видео тх, и приёмник РУ, стоит сделать экран для эрефемки?, толк будет ?
Приёмная антенна РУ, от всего этого хозяйства, отнесена достаточно далеко.