Baychi OpenLRS - дружелюбная ЛРС с широкими возможностями )
Ща со встроенном модуле использую такую: “6.5 Inch UHF Antenna for Vertex Standard”, тож неплохо работает
Усиление чуть поменьше чем у нагои, но зато короткая и легкая.
Кстати, а какая длинна у неё?
упс увидал, 6,5дюймов
Эксперименты с модулем RFM69, и модулем приемника на STM32, любезно предоставленном Алексеем (AlexSneg), наконец-то дали положительный результат. Экспертовский протокол с RFM22B/23BP ловится без каких либо изменений. Из извращений - только программный подсчет CRC16 и коррекция частоты, но это уже мелочи. 😃
Напомню, что основное преимущество RFM69 - на 10-15 дБ большая избирательность (заявленно по даташиту). Провел несколько предварительных экспериментов на этот счет. Действительно, повышенная избирательность чувствуется. Приемник на RFM22, глушился рацией ощутимо раньше, чем RFM69. Разницы в чувствительности не заметил.
Из прочих вкусностей 69-й - аппаратное шифрование AES 128 бит, так что если кому надо защитить данные - включайте. Для РУ может тоже когда пригодится. 😃
А STM32 с какой целью тестировалась? С мегой RFM69 будет работать?
STM32 с какой целью тестировалась?
STM заложил Алексей. В его проектах все на STM. 😃
С мегой RFM69 будет работать?
Разумеется будет. Но аппаратно эти модули немного несовместимы, так RFM69HBW отличается от RFM22/23B буквально на одну ножку, при одинаковом типоразмере.
Александр, хорошо, что заработало. Если удастся завести AFC, то предлагаю заслать мне список ваших хотелок по изменению в аппаратной части и я внесу изменения. После этого hardware в виде герберов для этого варианта будет опубликовано для всех желающих. Тем более, что RFM22 уже сняли с производства.
Не стоит бояться STM32. Они дешевле - раз. Снижают уровень затрат разработчика раз так в десять - два. Имеют встроенный, нестираемый UART загрузчик фирмвари - три. Никаких глюков с фюзами и слетами прошивок - четыре. Позволят существенно расширить функционал проекта - пять. Я только боюсь, что при попытке вернуться назад к проекту на ATMega у Александра возникнет “ломка” со всеми вытекающими последствиями для исходного проекта на Мегах. И это, наверное, единственный потенциальный “минус”.
так 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 варианта приемника:
- Полный - со множеством разъемов и дополнительными АЦП входами - который Вам нужен в Ваших проектах (для тех кто не в курсе - Алексей предпочитает архитектуру, когда все сервы и некоторые датчик вешаются на приемник, фактически приемник - разводящая колодка разъемов, а АП, при наличии, не только получает от него сигнал, но и управляет выходами).
- Лайт версию с 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) и желательно применить другой “отбеливатель” данных.
Поэтому родилась такая идея:
- С периодом в 14 мс передаем не один, а 2 пакета разной структуры “медленный” и “быстрый”.
- Быстрый пакет содержит 24 байта (полный пакет s.bus: 16ть 11-и битных каналов + байт флагов) полезных данных и имеет полную длину 32 байта (4 б. преамбулы, 2 синхрослова и 2 на CRC16). Бодовая скорость - 24000, девиация 12000, включенный алгоритм отбеливания RFMки. Время передачи - 11 мс. У такого пакета “энергетика” хуже на 3 дБ, чем у текущего.
- Медленный пакет содержит всего 6 байт данных и 7 вспомогательных байт (обрамление как у быстрого, но 1 синхрослово). Битовая скорость 7500, девиация 3750 Гц. Пакет передается за 14 мс. Энергетический выигрышь - 6 дБ.
- В медленном пакете информация кодируется слотами - порциями по 2 байта. В такую порция кодируется либо один аналоговый канал: 11 бит данных + 4 бита на номер канала + 1 бит - признак типа), либо от 3 до 10 условно-дискретных каналов (разные разрядности, подробности позже). То есть в пакете 3 слота.
- Учитывая что обычно в процессе управления одновременно меняются 1-2 канала, в первых 2-х слотах всегда кодируем свежеизмененные каналы (если есть), а в третий - фоновый - остальные. На самом деле лучше измененные каналы класть в конец - так сокращатся время отклика, но это уже детали…
- Полное количество “медленных” кадров настраивается ровно такое, какое требуется данной модели. Например всем моим моделям достаточно 2-х кадров или 6-ти слотов: 4-5 полных аналоговых и одного условно-дискретного с 3-4 каналами разрядностью 3-4 бита.
- Количество частотных прыжков выбирается от 5 до 9, так что-бы оно было некратно количеству медленных кадров. Надеюсь, понятно зачем.
- Полный цикл передачи 2-х кадров 28-30 мс. Учитывая что за это время на близких расстояниях мы фактически имеет 2-х кратное обновления активно меняющихся каналов, улучшаем динамику управления в 2 раза. На больших расстояниях, когда быстрые кадры уже не доходят, сохраняем существующу динамику управления (30 мс).
Буду рад вашим замечаниям и дополнениям.
Из накопившихся к самому себе вопросов (может, кто знает ответ).
- Что конкретно влияет на отношение c/ш бодовая скорость или девиация. Понятно, что они связаны, но хотелось бы понять, что причина, а что следствия.
- Как народ относится к индексам модуляции меньше 1?
- Мое предположение о влиянии длинны пакета на отношение сигнал/шум кто-нить может обосновать научно или подтвердить?
- Как в домашних условиях получить ослабление сигнала в 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 каналан прямую на сервы и они не заработали, все симптомы было как и у вас. А по отдельности каналы к сервам на столе, все было ОК. Подключал к компу, связь была.
Но я не придал тогда значения и разбираться не стал, других вопросов было много. Подключил игл, приемник к нему по ППМ. И все заработало. А вчера подключал другое крыло с другими сервами аналогично - проблем не возникло.
Так что получается, сервы иногда эмитируют перемычку?
Александр, может этот случай станет еще одним аргументом для переделки прошивки на программное переключение режимов?
Буду рад вашим замечаниям и дополнениям.
А как быть с ФС? Ведь может оказаться, что мы уже давно принимаем только дискретные каналы, а более важным аналоговым - не везет. Маловероятно, но все-же.
И с синхронизацией как-то заморочено получается… Хотя, если рассматривать быстрые пакеты как необязательное дополнение, то должно нормально получиться.