Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
Может достаточно 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 раз…
Фактически надо в дополнение к основному пакету иметь вспомогательный управляющий канал с очень большим запасом по энергетике
Если позволите, я бы поменял приоритеты. За основной канал лучше считать медленный, а быстрый - чисто вспомогательным.
Приняли быстрый пакет - прекрасно, не приняли - и чорт с ним, есть медленные. А вот если и медленных давно нет, тогда уже караул и ФС.
Имхо, так оно лучше в голове укладывается 😃
Если позволите, я бы поменял приоритеты. За основной канал лучше считать медленный, а быстрый - чисто вспомогательным.
Если бы медленный канал передавал все необходимое сразу, быстрый бы не понадобился. 😃
Собственно дилемма стоит в компромисе между дальностью и скоростью. Можно пойти по простому пути и дать возможность пользователю перед полетом явно выбрать нужный режим (он лучше знает что важнее в данном полете). Например замедлив экспертовский вротокол в 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 бит на управление режимом приема …