Search in topic

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

так RFM69HBW отличается от RFM22/23B

Я не нашел HBW, может HCW?
Как я понял, 69-я серия бывает максимум на 100mW. Передатчик на них делать смысла нет?

Тем более, что RFM22 уже сняли с производства.

На RFM23B тож хорошо работает.

Не стоит боятся STM32.

Дело не в страхе к STM32. Смена платформы обычно несет за собой несовместимость с предыдущей, а “вкусности” новой приводит к не желанию далее поддерживать предыдущие разработка.

Передатчик на них делать смысла нет?

Если только делать бустер на отдельном чипе, как в проекте Алексея.

Я не нашел HBW, может HCW?

chip-nn.ru/87.php
RFM69HW-433S2 - 390руб

chip-nn.ru/81.php
STM32F100C8T6B - 65руб

chip-nn.ru/7.php
LM1117IDT-ADJ - 35руб

Остальное - резисторы и конденсаторы, кварц, разъемы штырьковые. Вот все, что нужно для того варианта, что сейчас на руках у Александра.

На ебей если не один модуль заказывать, то вообще дешого получится. Три штуки допустим, обойдутся в 18,4$.
www.ebay.com/itm/…/181275079213

Не стоит бояться STM32.

Алексей, извиняюсь за лень свою, не поделитесь ссылками с чего начать Вы как прошедший этот путь?
Программатор, среда программирования, библиотеки- все что нужно для начала.
Может есть статья в инете- которую Вы б посоветовали?
Спасибо.

chip-nn.ru/51.php
STM32F4-DISCOVERY (Цена завышена, можно найти дешевле.)
Здесь и камень и ST-LINK уже в сборе. ST-LINK подойдет для отладки любых других STM32 на других платах. Там есть 6 проводов для подключения сторонних плат вместо встроенной.
Документации и примеров полно на st.com
В качестве среды разработки я пользуюсь IAR 6.5 ST-Link им полностью официально поддерживается для любых кристаллов STM32. Ставим, создаем проект, настраиваем отладчик в свойствах проекта, грузим прошивку и прямо в риал-тайме дебажимся. Раз попробовав, к меге вы больше никогда не вернетесь.

Персонально я в качестве внутрисхемного отладчика использую китайский клон J-link v8. На алиэкспрессе они по 15 баксов с доставкой.

Если удастся завести AFC, то предлагаю заслать мне список ваших хотелок по изменению в аппаратной части и я внесу изменения.

AFC в том виде, как оно работает на RFM22 у меня тоже не пошло. Поправка скачет как бог на душу положит. ИМХО основная проблемма - отсутствие явного ограничитела (afc_limiter), не позволяющего отсечь бредовую поправку, что при включенном AFC иногда и происходит - мощная помеха, принятая за преамбулу, уводит частоту так далеко, что больше уже ничего не ловится. Я остановился на таком алгоритме: 1) AFC запрещена. 2) По прерыванию от приема синхрослов, запускаем измерение FEI. 3) По прерыванию от payload, вычитываем пакет, FEI (показания очень стабильные) и RSSI. 4) Усредняя погрешность FEI, корректируем главные регистры частоты.
Для наших протоколов, когда передатчик один такой алгоритм вполне приемлим. Хоже многоточечным системам, не представляю как удобно каждый раз подстраиваться на разные передатчики. 😦

Насчет аппаратруры. Помимо ранее высказанных пожеланий, я бы предложил Вам 2 варианта приемника:

1. Полный - со множеством разъемов и дополнительными АЦП входами - который Вам нужен в Ваших проектах (для тех кто не в курсе - Алексей предпочитает архитектуру, когда все сервы и некоторые датчик вешаются на приемник, фактически приемник - разводящая колодка разъемов, а АП, при наличии, не только получает от него сигнал, но и управляет выходами).
2. Лайт версию с 4-мя универсальными серворазъемами (PPM/PWM/SBUS/и .п. - на любом), 2-мя UARTами, разъемом для подключения внешнего акка маяка, 1-2 индикаторами, 1-й кнопкой и USB.
   USB считаю особенно важдным для удобства пользователя. Понимаю, что это потребует другого кристалла и “лишнего” разъема, но удобство и универсальность, ИМХО, перевешивают все.

Не стоит бояться STM32. Они дешевле - раз

Дешевизна - это да. Кристалл с 4-10 раз большей памятью и в 10 раз большем быстродействии по оптовой цене Atmega328…

Снижают уровень затрат разработчика раз так в десять - два.

Это не факт, так как освоение любой новой среды требует времени. И кстати такой удобной и бесплатной “обертки”, как Arduino здесь нет, все функции извольте программить сами, а IAR и Keyl в неурезанных версиях стоят денег…

Я не нашел HBW, может HCW?

Да, HCW, я ошибся.

69-я серия бывает максимум на 100mW. Передатчик на них делать смысла нет?

Для передатчиков лучше всего подходит RFM23BP. Избирательность 69-й для него бесполезна. Если только шифрование кому пригодится…

В качестве среды разработки я пользуюсь IAR 6.5 ST-Link им полностью официально поддерживается для любых кристаллов STM32.

Угу. Только я целую неделю не мог заставить их работать вместе (Алексей в курсе моих мытарств). Знаете что оказалось в итоге: упрощенный режим эмуляции SWD надо было указать отдельно для всего проекта и отдельно для библиотек. 😃

PS: Недавно Hope RF анонсировала еще одну серию трансиверов: www.hoperf.com/rf/fsk_module/RFM96W.htm
Spread spectrum Long Range. На первый взгляд нам не очень подходит, но мало ли… 😃

Spread spectrum Long Range. На первый взгляд нам не очень подходит, но мало ли…

Образцы этого дела уже ко мне едут 😉

Коллеги!

У меня созрела идея нового протокола 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. Почему на передатчике не сделать софтовый конфиг , например, под два варианта канала, ну и переключалку прямо на лету. Пусть пилот сам решает на каком протоколе в данный момент времени ему лететь.