Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
почему 1 раз в сек не попытаться принять тестовый пакет, переданный с приемника, в котором приемник сообщит свой уровень RSSI. По нему решить на об удалении самолета от базы и автоматом отключать бродкаст быстрых пакетов? Когда RSSI например выше -80дб автоматом опять переходить на быстрый протокол
Сколько не рассматривал системы с обратной свзью, всегда приходит к выводу, что они позволяют только оптимизировать энерегетику (не слать лишней мощи), но по дальности ничего добавить не могут, а в худших случаях ее ограничивают.
Да и сама идея обратной связи в нашей ситуации мне не вполне нравится…
Александр, а зачем медленному пакету CRC16? Может достаточно CRC8?
5*6+3*3=39 бит. Примерно те-же 6 байт, как в меделенном кадре.
Зато имеем на борту полный срез по управлению, а не собираем из кусочков. Вероятность принять 50% пакетов и иметь комфортное управление будет выше, чем если бы мы собирали полную картину джойстиков из 5 правильно принятых подряд пакетов. И никаких проблем с понимание что такое ФС и прочие прелести
Почему на передатчике не сделать софтовый конфиг , например, под два варианта канала, ну и переключалку прямо на лету. Пусть пилот сам решает на каком протоколе в данный момент времени ему лететь.
Можно и так. Многие LRS имеют такой выбор. Вот только “на лету” я сомневаюсь…
варианте дать юзеру самому откунфигурить протокол и задать сколько ему каналов физически надо и с каким битовым разрешением.
В предлагаемом так и будет. 11 бит - это только идеальные аналоговые каналы. Псевдо дискретные слоты могут быть 2х6 бит, 3х4, 4х3, 6х2 и т.п. (нужно то всего 4-5 вариантов с фиксированным номером слота).
Может достаточно CRC8?
Нет на радиомодуле crc8. Только, если гнать программно. Но CRC8 не даст по сути никаких гарантий правильности. Я бы не стал полагаться на КС в 8бит всего
Сколько не рассматривал системы с обратной свзью, всегда приходит к выводу, что они позволяют только оптимизировать энерегетику
Так эта информация чисто для принятия оптимального решения, она не для контроля за ситуацией ФС или какой другой
Александр, а зачем медленному пакету CRC16? Может достаточно CRC8?
Проверял. Эффективность CRC8 на пределе дальности, когда рушатся >50% пакетов очень низка и вероятность получить искаженные данные, принятые как целые в 10-ки раз выше, чем CRC16 (я получал 2-3 таких пакета в минуту). В случае одноканального варианта (2 байта полезной нагрузки) CRC8 еще оправданно, но я отказался от столь “радикального” решения. 😃
Нет на радиомодуле crc8. Только, если гнать программно.
Если ловить RFM69-й пакеты от RFM22/23 то и CRC16 надо сичтать программно.
Но неужели это так сложно? 😃
unsigned short CaleCRC16(const unsigned char *DataBlock, unsigned DataBlockLen )
{
unsigned short crc = 0x0000;
while(DataBlockLen–) {
crc ^= *DataBlock++ << 8;
for (unsigned char i = 0; i < 8; i++)
crc = crc & 0x8000 ? ( crc << 1 ) ^ 0x1021 : crc << 1;
}
return crc;
};
Сколько не рассматривал системы с обратной связью, всегда приходит к выводу, что они позволяют только оптимизировать энерегетику
Так мы и будем использовать эту информацию только с целью оптимизации. Она не влияет на принятие решений. Для нас важно, что если обратная связь пропала, то мы улетели уже далеко, и гнать быстрые пакеты уже смысла нет. Переходим только на дальнобойный протокол
Может достаточно CRC8?
Нет CRC8 в радиомодуле. Считать самому - изврат, если есть аппаратный CRC16. И 8бит - недостаточно для гарантии небитости пакета
что если обратная связь пропала, то мы улетели уже далеко, и гнать быстрые пакеты уже смысла нет.
Это может быть не дальность, а помеха.
Это требует мощности передатчика и эффективности антенн на борту не хуже, чем на земле. То есть фактически 100 мВт с обеих сторон.
Алгоритм неочевиден, а цена “непереключения” - потеря связи…
Хотите поиграем в игру: Вы будете предлагать логику обратной связи, а я выискивать ситуации, где такая логика только повредит? 😃
Но неужели это так сложно?
Нет не сложно. Тем более на stm32. Этот МК даже не заметит дополнительной вычислительной нагрузки. Но я за то, чтобы максимально скидывать работу на аппаратуру, тем более, если она для этого предназначена. Чем более простые и прямолинейные алгоритмы крутятся внутри девайса, тем лучше, тем менбше возможностей программисту наделать багов.
Хотите поиграем в игру: Вы будете предлагать логику обратной связи, а я выискивать ситуации, где такая логика только повредит?
Если обратный канал пропал и не появляется в течение 5секунд, то перестаем гнать полные быстрые пакеты и гоним только дальнобойные, медленные.
В чем может быть засада?
Чем более простые и прямолинейные алгоритмы крутятся внутри девайса, тем лучше, тем менбше возможностей программисту наделать багов.
Иногда баги в аппаратре бывают похлеще программных. Вспомните пресловутое CRC16 на RFM22/23, без индекса B? Сколько моделей из-з них упало? 😃
Ну так у нас то от этого ничего не произойдет. Мы же не перестаем держать модель под управлением. Медленный протокол никуда не делся, он то в эфир продолжает поступать.
То есть Вы предлагаете играть только длинной, не меняя девиации и фильтров?
На за счет разрядности трудно выиграть более 2-х дБ.
А если менять скорость, приемник должен заранее знать, что она изменилась.
Вообщем при подключении в 1 и 2 канал некоторых серв (в третьем ни чего не подлючено), включается режим S.Sbus. Хотя ожидал что должен включится PPM.
Не совсеми сервами так происходит, у себя отобрал 3 штуки из 9.
Не совсеми сервами так происходит, у себя отобрал 3 штуки из 9.
Попробуйте увеличить задержки при проверке режима с 2 до 200 мкс, думаю проблема будет снята. Эти константы надо увеличить в 3-х вызовах delayMicroseconds(2) в функции check_modes файла functions.ino; На гитхабе я уже поправил.
На гитхабе я уже поправил.
А hex-ы пока непоправленные?
hex-ы пока непоправленные?
Не. Только вечером смогу перекомпилить.
А если менять скорость, приемник должен заранее знать, что она изменилась
Ну приемник попеременно принмает. Если он видит, что в четных слотах пакеты приниматься перестали, значит пробует искать по параметрам медленного протокола м другими параметрами. Если принят пакет измененный, значит дальше уже работает по медленной но дальнобойной схеме. Обратный переход при подлете к дому - аналогичный.
приемник попеременно принмает.
Я немного запутался. Вы какой протокол в итоге предлагаете? С двумя типами кадров (разные скорости, размер и структура) с чередованием 50%/50% по времени, или с переключением на низкую скорость: сначала передаем быстрые кадры, затем по обртаной связи уходим на медленные?
думаю что имеет смысл вначале передавать с чередованием 50%/50% по времени , а при удалении переходить на 100% медленные …
можно не по обратной связи а вручную с пульта (любой дискретный канал) , тогда можно самому решать когда использовать чисто медленный режим …
приемник в течении 5-10 секунд не принял ни одного быстрого пакета - пытается на этом временном промежутке принять медленный , если получается переходим в медленный режим …
если 5-10 секунд стабильно принимаем пакеты через один , пробуем в этом временном промежутке принять быстрый если получается переходим в смешанный режим …
можно не по обратной связи а вручную с пульта (любой дискретный канал) , тогда можно самому решать когда использовать чисто медленный режим …
Еще и пользователя этим напрягать? А если связь отвалится, раньше, чем он кнопку нажмет?
приемник в течении 5-10 секунд не принял ни одного быстрого пакета - пытается на этом временном промежутке принять медленный , если получается переходим в медленный режим …
5-10 секунд без связи - это уже не управление. 😃
В общем я пока не вижу надежного алгоритма переключения, как при наличии обратной связи, так и без нее.
Фактически надо в дополнение к основному пакету иметь вспомогательный управляющий канал с очень большим запасом по энергетике, например передавать всего 4-5 байт с минимальной девиацией 625 Гц на скорости 1200 бод (это потребует 25-30 мс), а уже им, по некой логике замедлять весь цикл передачи (уменьшая бодовую скорость и девиацию) в 2-4-8 раз…
Фактически надо в дополнение к основному пакету иметь вспомогательный управляющий канал с очень большим запасом по энергетике
Если позволите, я бы поменял приоритеты. За основной канал лучше считать медленный, а быстрый - чисто вспомогательным.
Приняли быстрый пакет - прекрасно, не приняли - и чорт с ним, есть медленные. А вот если и медленных давно нет, тогда уже караул и ФС.
Имхо, так оно лучше в голове укладывается 😃