Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
Проблема не понятная с только с подключением в 1 и 2 каналы.
Может они каким-то образом режим на PPM/SBUS переключают?
Прочитал ваши последние посты и ведь ошарашило… А ведь у меня аналогичная ситуация была, когда тестировал приемник на Х8.
Игл был снят и я подключил 1и2 каналан прямую на сервы и они не заработали, все симптомы было как и у вас. А по отдельности каналы к сервам на столе, все было ОК. Подключал к компу, связь была.
Но я не придал тогда значения и разбираться не стал, других вопросов было много. Подключил игл, приемник к нему по ППМ. И все заработало. А вчера подключал другое крыло с другими сервами аналогично - проблем не возникло.
Так что получается, сервы иногда эмитируют перемычку?
Александр, может этот случай станет еще одним аргументом для переделки прошивки на программное переключение режимов?
Буду рад вашим замечаниям и дополнениям.
А как быть с ФС? Ведь может оказаться, что мы уже давно принимаем только дискретные каналы, а более важным аналоговым - не везет. Маловероятно, но все-же.
И с синхронизацией как-то заморочено получается… Хотя, если рассматривать быстрые пакеты как необязательное дополнение, то должно нормально получиться.
получается, сервы иногда эмитируют перемычку?
Единственное разумное объяснение - это емкостная связь между разъемами и кабелями (порядок 100 пФ), и небольшое время проверки - 2 мкс. Учитывая высокое входное сопротивление подвешенного к 1 входа меги (30-50 кОм) это приводит постоянной времени порядка 5 мкс, а мы ждем всего 2. Думаю достаточным будет увеленечне времени задержки измерения с 2 до 200 мкс и проблемма будет снята. Эти константы надо увеличить в 3-х вызовах delayMicroseconds(2) в функции check_modes файла functions.ino; На гитхабе я уже поправил.
аргументом для переделки прошивки на программное переключение режимов?
Перейти несложно. Но не хочется терять возможность настройки приемника без ПК.
А как быть с ФС? Ведь может оказаться, что мы уже давно принимаем только дискретные каналы, а более важным аналоговым - не везет.
Да очень просто. Сейчас критерий один - отсутсвие принятых пакетов в течении заданного времени (300-500 мс). Здесь добавляется еще один критерий - отсутствие пакетов с новыми данными по любому каналу в течении некой константы, например 1 сек.
А на передающей стороне с помощью несложной системы приорететов, обеспечиваем гарантированные циклы обновления быстроменяющихя и статичных каналов.
И с синхронизацией как-то заморочено получается…
С синхронизацией как раз все неплохо. Подстраивать частоту и время можно по любым целым пакетам. Медленные пакеты - аналог сжатия информации, но не по содержимому, а по времени доставки.
Кстати, родилась еще одна идея увеличения дальности протокола: учитывая, что вероятность приема преамбулы и сихрослова намного выше вероятности приема целого пакета, можно смещая время отправки в пределах 1 мс и точно измеряя его на приемной стороне (по прерывани от синхрослова) кодировать каждым пактом по 1-му каналу. То есть иметь 3 уровня кодировки: быстрый, медленный и очень медленный. 😃
Вчера провел несколько экспериментов по оценки выигрыша предлагаемого протокола. В целом рассчеты подтверждаются - у медленных пакетов энергетика +5-6 дБ, у быстрых -2…-3 дБ. Моя цель получить 10 км дальности при 10 мВт излучаемой мощности.
Здесь добавляется еще один критерий - отсутствие пакетов с новыми данными по любому каналу в течении некой константы, например 1 сек.
Хмм. Может я неправильно понял идею…
Полное описание каналов содержится в одном быстром пакете или в четырех медленных. Так? Тогда теоретически возможна ситуация, когда пакеты приходят регулярно (чаще чем раз в секунду), но не те. Грубо говоря, принимаем состояние тумблеров, а положения стиков никак не долетят. И раскидывание по хоп-каналам не помогает. Понимаю, что практически невозможная ситуация, но мало ли 😃
Также неясно как быть при выходе из ФС. Нужно ли ловить четыре медленных пакета и только тогда снять ФС или достаточно одного?
смещая время отправки в пределах 1 мс и точно измеряя его на приемной стороне (по прерывани от синхрослова) кодировать каждым пактом по 1-му каналу
Может тогда оставить текущий режим в качестве быстрого, а режим по синхрослову назвать режимом “караул”? 😃
Моя цель получить 10 км дальности при 10 мВт излучаемой мощности.
Ой 😮
Александр, почему просто ради дальности не перейти на 6 битовую кодировку управляющего канала и 3 битовую для сервисных каналов. Зачем вам на расстоянии 10км управлять рулевыми поверхностями точнее, чем 6 бит?
Опять же, почему 1 раз в сек не попытаться принять тестовый пакет, переданный с приемника, в котором приемник сообщит свой уровень RSSI. По нему решить на об удалении самолета от базы и автоматом отключать бродкаст быстрых пакетов? Когда RSSI например выше -80дб автоматом опять переходить на быстрый протокол
почему просто ради дальности не перейти на 6 битовую кодировку управляющего канала и 3 битовую для сервисных каналов.
5*6+3*3=39 бит. Примерно те-же 6 байт, как в меделенном кадре.
Но если эффективность медленного на 10 дБ выше быстрого, получим хорошее управление на первых 3-х км, а затем сразу грубое. Хорошо ли это? И хватит ли 6 бит для триммирования модели?
Полное описание каналов содержится в одном быстром пакете или в четырех медленных.
Не обязательно. Гибкость логики передачи ничем не ограниченна. Для начала я бы предложил такую логику приоритетов.
- Если канал не меняется к его весу на каждом цикле медленной передачи прибавляем 1.
- Если канал меняется незначительно (<1-3%), в каждом уикле прибавляем к нему 2-ку.
- Если сигнал меняется сильно, приоретет возрастает на 4-ку.
- Перед формированием каждого медленного кадра берем 2 канала с максимальными приорететами и один просто по циклу. Приорететы переданных каналов, обнуляются…
а режим по синхрослову назвать режимом “караул”
Если удасться замерить время с точностью нескольких микросекнд, хотя-бы. 😃
PS: Выложил в дневник результаты вчерашних экспериментов. Может кому будет интересно: rcopen.com/blogs/39565/18293
Проверка влияние девиации фильтра полосы пропускания на энергетику связи, полностью потвердило теорию:
- Увеличение девиации вдвое снижает отношение сигнал/шум на 3 дБ
- Лучший фильтр без манчестера - это рекомендуемый Bw=2*Fdev+0.25Rb. Если полосу увеличивать сверх нормы, ворастает уровень шма, а полезный сигнал не меняется. А если уменьшать, уровень сигнала и шума падает почти синхронно, но и разборчивость (вероятность приема) тоже ухудшается.
- Длинна полного пакета при увеличении в 2 раза, требует увелични отношения сигнал-шум на 2-3 дБ.
Еще по поводу самой идеи двойного протокола…
А тоже в свое время по разному все в уме крутил, как бы и “нашим и вашим угодить”. В результате все же остановился на варианте дать юзеру самому откунфигурить протокол и задать сколько ему каналов физически надо и с каким битовым разрешением. Хочешь летать близко, поставь 10бит в канал, хочешь далеко, поставь 6 бит на управление и по 2бита на дискретники.
Вариант2. Почему на передатчике не сделать софтовый конфиг , например, под два варианта канала, ну и переключалку прямо на лету. Пусть пилот сам решает на каком протоколе в данный момент времени ему лететь.
почему 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; На гитхабе я уже поправил.