Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
приемник попеременно принмает.
Я немного запутался. Вы какой протокол в итоге предлагаете? С двумя типами кадров (разные скорости, размер и структура) с чередованием 50%/50% по времени, или с переключением на низкую скорость: сначала передаем быстрые кадры, затем по обртаной связи уходим на медленные?
думаю что имеет смысл вначале передавать с чередованием 50%/50% по времени , а при удалении переходить на 100% медленные …
можно не по обратной связи а вручную с пульта (любой дискретный канал) , тогда можно самому решать когда использовать чисто медленный режим …
приемник в течении 5-10 секунд не принял ни одного быстрого пакета - пытается на этом временном промежутке принять медленный , если получается переходим в медленный режим …
если 5-10 секунд стабильно принимаем пакеты через один , пробуем в этом временном промежутке принять быстрый если получается переходим в смешанный режим …
можно не по обратной связи а вручную с пульта (любой дискретный канал) , тогда можно самому решать когда использовать чисто медленный режим …
Еще и пользователя этим напрягать? А если связь отвалится, раньше, чем он кнопку нажмет?
приемник в течении 5-10 секунд не принял ни одного быстрого пакета - пытается на этом временном промежутке принять медленный , если получается переходим в медленный режим …
5-10 секунд без связи - это уже не управление. 😃
В общем я пока не вижу надежного алгоритма переключения, как при наличии обратной связи, так и без нее.
Фактически надо в дополнение к основному пакету иметь вспомогательный управляющий канал с очень большим запасом по энергетике, например передавать всего 4-5 байт с минимальной девиацией 625 Гц на скорости 1200 бод (это потребует 25-30 мс), а уже им, по некой логике замедлять весь цикл передачи (уменьшая бодовую скорость и девиацию) в 2-4-8 раз…
Фактически надо в дополнение к основному пакету иметь вспомогательный управляющий канал с очень большим запасом по энергетике
Если позволите, я бы поменял приоритеты. За основной канал лучше считать медленный, а быстрый - чисто вспомогательным.
Приняли быстрый пакет - прекрасно, не приняли - и чорт с ним, есть медленные. А вот если и медленных давно нет, тогда уже караул и ФС.
Имхо, так оно лучше в голове укладывается 😃
Если позволите, я бы поменял приоритеты. За основной канал лучше считать медленный, а быстрый - чисто вспомогательным.
Если бы медленный канал передавал все необходимое сразу, быстрый бы не понадобился. 😃
Собственно дилемма стоит в компромисе между дальностью и скоростью. Можно пойти по простому пути и дать возможность пользователю перед полетом явно выбрать нужный режим (он лучше знает что важнее в данном полете). Например замедлив экспертовский вротокол в 2 раза (до 50-65 мс) и отказавшись от манчестера, можно выиграть те-же 6 дБ. Пределом замедления в случае RFM22/23b является девиация 625 Гц и битовая скорость порядка 1200 бод, что 6 раз меньше текущей. То есть максимально можно замедлится до 150 мс на пакет и тем самым выиграть около 10 дБ. Дальше можно только сокращать размер пакета, что при разумных 4-5 аналоговых и 2-3 дискретных каналов при минимальной точности в 8 бит, можно сделать вдвое и выиграть еще 3 дБ.
Я же предлагаю компромис по замедлению, без потери оперативности на больших расстояних и ее удвоение вблизи.
Правда отсается открытым вопрос важности “целостности” - одновременности изменения данных на приемной стороне…
Если позволите, я бы поменял приоритеты. За основной канал лучше считать медленный, а быстрый - чисто вспомогательным.
Я бы не стал однозначно утверждать, что дальнобойный протокол в приоритете - на рекорды не каждый день летаем.
А тем кто на коптерах, скорость существенно важнее!
на коптерах, скорость существенно важнее!
Кстати, Александр, а вам-коптероводом, сколько обычно каналов требуется?
Я тут просчитал еще несколько вариантов 2-х скоростного протокола при соотношении времен пакетов 50/50 (другая пропорция ИМХО бессмысленна). Если экономить на битах и дать пользователю индивидуально настроить их кол-во для каждого канала, то лично мне , например для управления всеми FPV самолетиками сейчас достаточно: 3х10 бит (элероны, РВ и РН), 7 бит на газ, 2 бита на закрылки (заранее заданные 4 положения), 3 бита управления АП (5 позиций), 1 бит переключния между камерами, 1 бит переключения OSD и 1 бит включения пищалки. Итого 45 бит или 6 байт. Что прекрасно вписывается в целый “медленный” пакет. Положив предельную длительность пакета в 18-19 мс (для цикла передачи не более 20 мс) и играя с наполнением медленного пакета от 5 до 10 байт, можно на медленном пакете получить выигрышь от 4.5 до 8 дБ, при потерях в 1-2 дБ на быстром пакете. Причем если сделать быстрый “конфигуратором” для медленного, то все настройки достаточно будет делать на передающей стороне без ПК, хоть перед полетом или при смене модели. Наверное именно этот вариант (а не слотовый) и реализую в первую очередь…
Еще и пользователя этим напрягать? А если связь отвалится, раньше, чем он кнопку нажмет?
50% медленных пакетов идет в любом случае … просто когда перестают доходить быстрые пакеты ухудшается динамика , для улучшения динамики можно заменить быстрые пакеты медленными , те перейти в режим 100 % медленных пакетов , это вполне можно делать вручную …
при возврате домой когда хочется опять увеличить динамику , включаем режим 50%+50% …
5-10 секунд без связи - это уже не управлени
5-10 секунд не без управления , а на 50% медленных пакетов … если много можно 1-2 секунды … просто если получаем 50% , а вторые 50% не получаем вообще - пробуем менять режим …
иначе придется выделять в медленном пакете 1 бит на управление режимом приема …
Я же предлагаю компромис по замедлению, без потери оперативности на больших расстояних и ее удвоение вблизи.
Как я понял, 7500 + 24000 оптимально влезают в интервал передачи (рассчеты не проверял). По-моему, компромисс вполне приемлемый.
Мое предложение больше относится к терминологии. Для упрощения понимания логики работы.
Потому что если я начинаю в голове представлять алгоритм работы на базе быстрого протокола, то у меня очень быстро сносит крышу. А если наоборот - все стройно и понятно 😃
50% медленных пакетов идет в любом случае … просто когда перестают доходить быстрые пакеты ухудшается динамика , для улучшения динамики можно заменить быстрые пакеты медленными , те перейти в режим 100 % медленных пакетов , это вполне можно делать вручную …
Да, это хорошая идея. 1 бит в медленном для перключения всегда можно отыскать.
Хм… А ведь получается, что “быстрый” пакет нужет теперь только для конфигурирования медленного (в том числе ввода FS) или если требуется большое число каналов с большой разрядностью… То есть идея вырождается в просто максимально короткие пакеты на минимально приемлимой динамике, с очень короткими “конфигурационными” вставками (например на максимальнльной скорости 256 кбит , длительностью 1 мс), что-бы еще вблизи приемник мог подстроится под передатчик, а дальше брать только длинные кадры…
Самостоятельное конфигурирование разрядности каналов - это вообще супер!
Мне на коптере требуется, к примеру, 3х10 бит (крен, тангаж и направление), 8 бит на газ, 2 бита на переключение режима, 10 бит на поворот камеры, 5 бит на крутилку для настроек (на обязательно), 1 бит на пищалку. Итого 56 бит. То есть 7 байт, но можно ужать и до 6.
А если научить приёмник делать экспоненту, то на крен, тангаж и направление будет достаточно и 8 бит, тк триммирование не требуется
если делать полностью настраиваемый протокол , то переносить параметры протокола из передатчика в приемник можно в момент бинда , приемники обычно не переставляют с одной модели на другую , а протокол оптимизируется под конкретную модель … грубую подстройку частоты приемника также можно делать во время бинда …
конфигурировать протокол на передатчике всеравно придется с компа , а вот как выбирать нужный протокол если есть несколько разных моделей а передатчик один ??? иметь несколько наборов настроек и выбирать кнопкой на паредатчике ??? тогда нужно чтобы приемник видел передатчик только если он работает с тем набором настроек который получил при бинде …
иметь несколько наборов настроек и выбирать кнопкой на паредатчике ???
Именно это. Предлагаю 3 профиля настроек для каждой модели: стандартный, быстрый и точный. Профиль переключается, например, тумблером на передатчике и отсылается постоянно очень короткими кадрами (1-2 мс) на фиксированной частоте, в паузах между основными пакетами, но приемник принимает профиль только первые 30-60 сек, после установления связи и дальше его не слушает (что-б потом не сбиться случайно).
Уникальным для приемника является только ID настроек (16 бит), что-бы отличить свой передатчик или модель от чужого (ID можно поменять кнопкой BIND на приемнике).
Все остальное - структуру пакета, разрядности каналов, количество и набор частот прыжков, скорость, девиацию и период следования он узнает из профиля - быстрого пакета. Им же (и только им) можно поменять настройки FS. В принципе даже такие детали, как “логические каналы” и растяжку хода серв, частоту и мощность маяка можно передавать профилем (приемник вообще не конфигурировать заранее), но можно и оставить вариант настройки с обеих сторон (подумаю).
А если научить приёмник делать экспоненту, то на крен, тангаж и направление будет достаточно и 8 бит,
Это, думаю, лучше оставить передатчику. А вот “псевдоаналоговые” каналы с 4-8 мпредустатовленными положениеями могут пригодиться - например для закрылков. Настройку (в том числе и триммирование) этих положений можно будет делать перед стартом с посмощью того-же конфигурационного пакета…
PS: А может наоборот - все настройки на приемнике и передатчик под него подстраивается? Что удобнее?
PS: А может наоборот - все настройки на приемнике и передатчик под него подстраивается? Что удобнее?
тогда приемник будет работать на передачу , чтобы скинуть настройки передатчику , чего не хотелосЪ бы …
а чем не устраивает вариант переливать все настройки при бинде ??? зачем каждый раз слать их с передатчика ???
просто в передатчик под конкретную модель забиваем разрядность всех каналов , соответственно получаем пакет минимально необходимой длины для этой модели , выбираем скорость и получаем оптимальный для данной модели пакет … набору настроек присваивается уникальный ID (16 бит) … приемник биндим на этот ID и в процедуре бинда переливаем в него все настройки … дальше для этой модели можно вообще настройки не менять …
другой набор настроек , другой ID , другой приемник на другой модели …
тогда приемник будет работать на передачу , чтобы скинуть настройки передатчику , чего не хотелосЪ бы …
Почему? Достаточно передавать их первые секунды. Все равно передатчик включается перед включением приемника.
чем не устраивает вариант переливать все настройки при бинде ??? зачем каждый раз слать их с передатчика ???
Потому что у меня несколько моделей с разными настройками. И я не хочу каждый раз “перебиндевать” приемник. Считаю “биндом” - уникальный номер связи между моим передатчиком и всеми моими приемниками (что-бы отличить их от чужих пар). И кстати этого бинда в основном протоколе не будет (нет места), там для различения свой-чужой будет только синхрослово и свой набор частот. А вот параметры связи уникальны с точностью до модели (включая скан помеховой обстановки). Поэтому приемник будет говорить передатчику в каком режиме и как передавать каналы.
другой набор настроек , другой ID , другой приемник на другой модели …
Тогда надо переключать на передатчике и номер модели и номер настроек, а это уже трудно…
Попробуйте увеличить задержки при проверке режима с 2 до 200 мкс, думаю проблема будет снята. Эти константы надо увеличить в 3-х вызовах delayMicroseconds(2) в функции check_modes файла functions.ino; На гитхабе я уже поправил.
Теперь все ок))) проблемка устранена, спасибо.
Только вот св.диод на приемнике с предыдущими прошифками при включении делал две вспышки, а сейчас просто горит до появленния связи.
Кстати, Александр, а вам-коптероводом, сколько обычно каналов требуется?
У меня получается так:
Четыре точных канала - управление.
Один трехпозиционник - полетные режимы.
Одна крутилка - настройка пидов.
Два двухпозиционных тумблера на доп режимы.
Одна крутилка на Тильт камеры.
Один тумблер на пищалку.
Еще один запасной тумблер. (Ракеты, мины, переключение камер).
При этом, обычно все каналы идут по ППМ, кроме трех последних.
Прежде чем приступать к новому “гибкому” протоколу, внес все последние изменения и дополнения на гитхаб, а так-же доделал режим 3 (обратный порядок 10-ти 11 битных каналов). Прошивки тоже перекомпилил, описания дополнил.
github.com/baychi/OpenExpertTX
github.com/baychi/OpenTinyRX
На выходных дошли у меня руки до прошивки моих модулей.Два передающих “оранжа” 0,1Вт и 1Вт(условно 😃),приёмники “оранжи” 2 шт и “хоки” 2 шт.Пришлось несколько раз прочитать и вникнуть в инструкции,перестроиться на особенность управления через терминал,чтобы примерно понять что есть что.Немного повоевал с программатором и ФТДИ-адаптером.Ардуиновская прога периодически не видела програматор.Первая попытка прошивки передающего модуля 0,1Вт оказалась неудачной,долго пытался связать модуль с приёмником,потом интуитивно понял, что проблема в модуле подозрение на криво вставшую прошивку или вообще загрузку,загрузил в него ардуиновский загрузчик(до этого стоял родной,только фьюзы подправлены были),почистил память,и загрузил прошивку по новой.Всё стало адекватно.Сначала я вбивал значения каналов в регистры приёмника такие же самые как и в соответствующих регистрах каналов передатчика.Передатчик предварительно был включён в режиме авто-настройки, т.е. он выбрал каналы на его усмотрение исходя из эфирной обстановки,после этого я переписал значения регистров отвечающих за каналы связи,чтобы вбить их в регистры приёмников.Значение регистра 2(подстройка частоты) на передатчиках и приёмниках было 199.В принципе всё работало,сервы шуршали,маяк работал и т.д.На дальность возможности проверить нет,погода плохая.В одноватный модуль я тупо скопировал значения регистров со 100-милливаттного и он тоже работает.
Но вот сегодня вечером после прошивки приёмника “хок” я решил попробовать “ребинд” приёмника,т.е. чтобы он сам нашёл передатчик.Предварительно на модуле 0,1Вт я занизил мощность(значение регистра =1),оттащил передатчик в другую комнату и приёмник никак не смог настроиться,хорошо принёс передатчик поближе и попытка номер два…Настроился,но значения регистров немного другие,номера каналов совпадают но номера регистров нет.Например регистр 11 на передатчике значение 92,а на приёмнике 63.63-й канал тоже есть но в передатчике он в регистре 17.Далее регистр подстройки частоты тоже поменял значение,вместо 199 стал 195.Попробовал забиндить другой приёмник,значения регистров отвечающих за каналы тоже отличаются и от передатчика и от первого приёмника(в смысле по другому перемешаны номера каналов),сами каналы совпадают просто стоят в других регистрах,регистр 2 имеет значение 192.При этом всё работает нормально,во всяком случае в пределах квартиры.
Так вот у меня вопрос.Как предпочтительней оставить значения регистров каналов и регистра подстройки частоты,вручную их установить или лучше чтобы они установились в автомате?В каком случае связь будет устойчивее?
Доброе время суток!
Во-первых, спасибо Александру (автору) за большой объем работы по доработке программной части модулей LRS!
Во-вторых, хотелось бы прояснить несоклько моментов по железу: есть у меня старенький передатчик WFLY FT-06, на модели Бикслера приемник Corona 35MHz, все работает вполне нормально. Хочу попробовать канал на 433 МГц, сам радиолюбитель с позывным и имею пару р/ст на 144, 433 МГц. Понимаю, что на эти частоты проще сделать направленную антенну, чем на 35МГц 😃
Вопросы такие:
- Я не нашел, какого типа сигнал PPM идет из моего передатчика (JR/Turnigy или Futaba совместимый). Соответственно, принципиально ли это? Планирую взять OrangeRX Open LRS 433MHz Transmitter 1W ( JR Compatible) на HK, паяльник в руках держать умею. Могут быть проблемы, если передатчик т.н. Futaba-compatibe? Если да, то как это можно проверить (осциллограф есть).
- Общий набор: OrangeRx Open LRS 433MHz 9Ch Receiver, OrangeRX Open LRS 433MHz Transmitter 1W ( JR Compatible), OrangeRX USB Firmware Update Kit for JR/Futaba Style Transmitter Module - является достаточным для того, чтобы на первых порах получить канал управления моделью на 433? Цена, к сожалению, не на последнем месте…
P.S. автопилот и ОСД Eagle Tree. Заранее благодарен за ответ
значения регистров немного другие,номера каналов совпадают но номера регистров нет
Это нормально. Набор каналов - это кольцо, у него нет начала, а важна только последовательность частот.
Далее регистр подстройки частоты тоже поменял значение,вместо 199 стал 195
И это правильно. У каждого своя модуля индивидуальная подстройка. В данном случа приемник подстроился под передатчик.
.Как предпочтительней оставить значения регистров каналов и регистра подстройки частоты,вручную их установить или лучше чтобы они установились в автомате?
Регистры частот - без разницы, лишь бы сохранялась последовательность. Подстройка частоты - лучше вычисленная при rebind.
- Я не нашел, какого типа сигнал PPM идет из моего передатчика (JR/Turnigy или Futaba совместимый). Соответственно, принципиально ли это?
Нет. Более того, подключив передатчик к модулю и включив на последнем отладку (R6=3), Вы увидете сколко каналов идет с РУ и какой у них диапазон, а следовательно и тип.
- Общий набор: OrangeRx Open LRS 433MHz 9Ch Receiver, OrangeRX Open LRS 433MHz Transmitter 1W ( JR Compatible), OrangeRX USB Firmware Update Kit for JR/Futaba Style Transmitter Module - является достаточным для того, чтобы на первых порах получить канал управления моделью на 433? Цена, к сожалению, не на последнем месте…
Почти. Нужно еще чем-то проверить и при необходимости поправить фьюзы Мег. Если в составе Update Kit есть SPI программатор, то все ОК, если нет, желательно что-бы где-то рядом такой был (правка делается один раз).