Search in topic

Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )

Коллеги!

У меня созрела идея нового протокола LRS. Цель - получить выигрыш по отношению сигнал/шум в 6 дБ по сравнению с реализованным (экспертовским), не проигрывая в динамике, как вблизи, так и на пределе дальности.

Теоретически известно, что увеличить чувствительность на 3 дБ, можно снижением в 2 раза скорости передачи, и, как следствие, девиации частоты. Кроме того вероятность разрушения пакета пропоционально его длинне. Расчеты показывают, что уменьшение длинны в 2 раза должно давать выигрыш в те-же 3 дБ.

Напомню, в существующем протоколе: длинна пакета: 22 байта (16 байт полезной нагрузки), девиация 8750 Гц, бодовая скорость 7400 бит/сек, длительность передачи кадра - 24 мс, период следования - 31.5 мс. Девиация 8750 Гц при бодовой скорости 7400 есть следствие манчестерского кодирования, требующего удвоенной полосы. Если отключить манчестер, то девиацию можно уменьшить до 3700 Гц (индекс модуляции = 1). Но при этом преамбулу придется увеличить в 2 раза (что-бы сохранить кол-во колебаний =32) и желательно применить другой “отбеливатель” данных.

Поэтому родилась такая идея:

1. С периодом в 14 мс передаем не один, а 2 пакета разной структуры “медленный” и “быстрый”.
2. Быстрый пакет содержит 24 байта (полный пакет s.bus: 16ть 11-и битных каналов + байт флагов) полезных данных и имеет полную длину 32 байта (4 б. преамбулы, 2 синхрослова и 2 на CRC16). Бодовая скорость - 24000, девиация 12000, включенный алгоритм отбеливания RFMки. Время передачи - 11 мс. У такого пакета “энергетика” хуже на 3 дБ, чем у текущего.
3. Медленный пакет содержит всего 6 байт данных и 7 вспомогательных байт (обрамление как у быстрого, но 1 синхрослово). Битовая скорость 7500, девиация 3750 Гц. Пакет передается за 14 мс. Энергетический выигрышь - 6 дБ.
4. В медленном пакете информация кодируется слотами - порциями по 2 байта. В такую порция кодируется либо один аналоговый канал: 11 бит данных + 4 бита на номер канала + 1 бит - признак типа), либо от 3 до 10 условно-дискретных каналов (разные разрядности, подробности позже). То есть в пакете 3 слота.
5. Учитывая что обычно в процессе управления одновременно меняются 1-2 канала, в первых 2-х слотах всегда кодируем свежеизмененные каналы (если есть), а в третий - фоновый - остальные. На самом деле лучше измененные каналы класть в конец - так сокращатся время отклика, но это уже детали…
6. Полное количество “медленных” кадров настраивается ровно такое, какое требуется данной модели. Например всем моим моделям достаточно 2-х кадров или 6-ти слотов: 4-5 полных аналоговых и одного условно-дискретного с 3-4 каналами разрядностью 3-4 бита.
7. Количество частотных прыжков выбирается от 5 до 9, так что-бы оно было некратно количеству медленных кадров. Надеюсь, понятно зачем.
8. Полный цикл передачи 2-х кадров 28-30 мс. Учитывая что за это время на близких расстояниях мы фактически имеет 2-х кратное обновления активно меняющихся каналов, улучшаем динамику управления в 2 раза. На больших расстояниях, когда быстрые кадры уже не доходят, сохраняем существующу динамику управления (30 мс).

Буду рад вашим замечаниям и дополнениям.

Из накопившихся к самому себе вопросов (может, кто знает ответ).

1. Что конкретно влияет на отношение c/ш бодовая скорость или девиация. Понятно, что они связаны, но хотелось бы понять, что причина, а что следствия.
2. Как народ относится к индексам модуляции меньше 1?
3. Мое предположение о влиянии длинны пакета на отношение сигнал/шум кто-нить может обосновать научно или подтвердить?
4. Как в домашних условиях получить ослабление сигнала в 70-90 дБ, не используя эфир? У меня есть несколько аттенюаторов, суммарным ослаблением децибелл в 60 и несколко направленных ответвителей, но в реальности цепочка длинее 40 дБ уже не работает, по эфиру сигнала идет больше.

Столкнулся с непонятной проблемкой.
Собираю не большое ЛКрыло. Ставлю проверенный приемник оранж(прошит и откалиброван) на борт, 1 и 2 каналы элевоны, 3й газ. Включаю лрс, светодиод загорается на приемнике, а связи нет. Сервы аналоговые зудят и не реагируют на управление, мотор тоже не откликается. Стоит отключить одну любую серву и вновь включить питание борта- связь есть, тут же подключаю отключенную серву на место- все нормально, связь есть пока не переткнешь питание. Меняю подключение серв местами, перезапускаю - все нормально, запускается всегда. На борту кроме приемника серв и регулятора с мотором ни чего пока не стоит. Пробывал отключать регулятор и запитывать приемник от 4металгидридов, тоже самое. Ставил другой приемник , тоже самое. Подключил элевоны в 4 и 5 серворазъем тоже все норально, даже если местами их поменять. Проблема не понятная с только с подключением в 1 и 2 каналы. Пробывал два разных вида разных серв.
😵😵😵
Хочется разобраться по чему так происходит, завтра еще помучаю с другими сервами.

завтра еще помучаю с другими сервами.

Это верное направление поисков. Судя по симптомам, что-то с питанием, кто-то его проваливает. Попробуйте замерить напряжение на сервах в этой ситуации. Мониторить UART выдачу приемника тоже не помешает…

что-то с питанием, кто-то его проваливает

Вроде исключил питание, три разных источника пробывал и плюс два источника в параллель. Да и тем более, стоит местами поменять подключение серв, тоже все ок.
Т.е.
Серва №1 в первый канал
Серва №2 во второй канал
При подключении питания связи нету, что хочешь делай, хоть все сервы вытащи связи не будет уже(хотя диод приема пакетов горит как положено.

А когда
серва№1 во второй канал
Серва№2 в первый канал
Все ок, запускается стабильно.

UART выдачу приемника тоже не помешает…

Ноута с собой не было, хотелось бы посмотреть что там происходит.

Серва №1 в первый канал Серва №2 во второй канал При подключении питания связи нету, что

Может они каким-то образом режим на PPM/SBUS переключают? Там логика несложная, дается лог. ноль на второй канал, смотрится он-же на входе 1 и 3-го. Затем то-же с единицей, если проходит, значит перемычка установлена в соотв. положение. Но как серва может менять состояние входа, непонятно.
Можно в коде отключить проверку любых перемычек… Вот это место (openTiny_rx.ino)
---------------------------------------------
receiver_mode = check_modes(PPM_MODE_JUMPER); // режим PPM
if(receiver_mode) {
reciever_outs = PWM_OUT_NUM; // максимум PWM каналов в режиме PPM
} else if(check_modes(SBUS_MODE_JUMPER)) { // проверяем на SBUS
receiver_mode = 2;
…
---------------------------------------------------

Может они каким-то образом режим на PPM/SBUS переключают?

Сейчас в мозгах прокручиваю анализирую все вчерашние действия, скорее всего(95%) так и есть. Не догался я подключить в этот момент серву в четвертый или выше канал, наверняка бы она заработала. В этих режимах PWM выходы же начинаются с 4канала(вернее 5серворазъема). Прям одним местом чую, что это так)))

Проблема не понятная с только с подключением в 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.
2. Если канал меняется незначительно (<1-3%), в каждом уикле прибавляем к нему 2-ку.
3. Если сигнал меняется сильно, приоретет возрастает на 4-ку.
4. Перед формированием каждого медленного кадра берем 2 канала с максимальными приорететами и один просто по циклу. Приорететы переданных каналов, обнуляются…

а режим по синхрослову назвать режимом “караул”

Если удасться замерить время с точностью нескольких микросекнд, хотя-бы. 😃

PS: Выложил в дневник результаты вчерашних экспериментов. Может кому будет интересно: rcopen.com/blogs/39565/18293

Проверка влияние девиации фильтра полосы пропускания на энергетику связи, полностью потвердило теорию:

1. Увеличение девиации вдвое снижает отношение сигнал/шум на 3 дБ
2. Лучший фильтр без манчестера - это рекомендуемый Bw=2*Fdev+0.25Rb. Если полосу увеличивать сверх нормы, ворастает уровень шма, а полезный сигнал не меняется. А если уменьшать, уровень сигнала и шума падает почти синхронно, но и разборчивость (вероятность приема) тоже ухудшается.
3. Длинна полного пакета при увеличении в 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 мВт с обеих сторон.
Алгоритм неочевиден, а цена “непереключения” - потеря связи…

Хотите поиграем в игру: Вы будете предлагать логику обратной связи, а я выискивать ситуации, где такая логика только повредит? 😃