Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
На гитхабе я уже поправил.
А hex-ы пока непоправленные?
hex-ы пока непоправленные?
Не. Только вечером смогу перекомпилить.
А если менять скорость, приемник должен заранее знать, что она изменилась
Ну приемник попеременно принмает. Если он видит, что в четных слотах пакеты приниматься перестали, значит пробует искать по параметрам медленного протокола м другими параметрами. Если принят пакет измененный, значит дальше уже работает по медленной но дальнобойной схеме. Обратный переход при подлете к дому - аналогичный.
приемник попеременно принмает.
Я немного запутался. Вы какой протокол в итоге предлагаете? С двумя типами кадров (разные скорости, размер и структура) с чередованием 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