Activity

Вы все правильно делали, только немножко недочитали… Меню Hardware в последних прошивках спрятано специально, чтобы ненароком не изменить что-то важное. Я тут уже писал как его активировать - надо при включении зажать горизонтальные тримы то ли внутрь, то ли наружу…

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

В меню Hardware по-прежнему есть пункт FrSky Mod Done, при включении которого тумблеры THR и AIL должны быть перенесены на другие ноги микроконтроллера, и заработает телеметрия. В общем дальше все также, как описано в инструкциях.

Датчикам нужно поменять ID, иначе не будет видеть 12S ни на 2.0, ни на 2.1. Ващщще нигде. Для этого нужно это и это.

А разве OpenTX не умеет менять ID датчиков при подключении их к аппе?
Я в детали не вникал, но в er9x (точнее, в ersky9x) есть соответствующий пункт в меню. Мне казалось, что функционал перепрошивки через S.Port в OpenTX позаимствован у er9x…

Это что, для пищалки специально свой стаб 7805?? И без какой либо обвязки!! Прикольно!

Так в оригинале сделано. Работает, поэтому не вижу смысла что-либо менять.

А что сложнее нельзя было придумать схему включения?? А если попроще,-один полевик с резистором и диод от переплюсовки ?? НЕЕ??..

Одним полевиком не отделаемся, т.к. питание на основную плату и на ВЧ-модуль должно подаваться независимо. Т.е. есть случаи, когда питание на плату подается, а на ВЧ-модуль - нет.

Для защиты от переполюсовки в данном случае полевик лучше диода. При использовании полевика, падения напряжения на нем практически нет.
Поэтому он получается “дружелюбнее” к 2S LiPo аккумуляторам. А при питании от 3S LiPo уже все равно - можно и диод использовать.

А давай в Taranis такую штуку впихнем, а? 😃
Там электронная схема управления питанием, но вот как она отрабатывает плохой контакт в выключателе - я не знаю (и проверить сейчас не на чем). А сам выключатель там практически такой же, как и в Turnigy.

Идея заключается в том, чтобы сделать схему подачи питания электронной. Когда выключатель питания включен, напряжение на системную плату подается через электронный ключ. Если вдруг контакт в выключателе питания пропадает, электронная схема продолжит удерживать ключ в открытом положении и аппаратура продолжит работать. Выключение же происходит только тогда, когда замыкаются две другие пары контактов включателя, т.е. только при физическом перемещении ползунка в положение “OFF”. Тема на openrcforums - тут.

Я рисую дизайн новой платы питания для 9x. В целом, пока все выглядит неплохо, но нужно как следует это решение протестировать (чем João сейчас и занимается). Кстати, такая схема заодно добавляет защиту от переполюсовки АКБ (кроме специфического случая включения аппаратуры путем втыкания кабеля в тренерский разъем).

Мы строили, строили и, наконец, построили!
João дорисовал схему, вот что получилось:

Напряжение АКБ коммутируется при помощи полевых транзисторов Q2 (питание на основную плату) и Q3 (питание на ВЧ-модуль). Когда выключатель питания включен, затворы Q2 и Q3 имеют низкий потенциал, полевые транзисторы открыты. Даже при плохом контакте в выключателе, полевые транзисторы будут удерживаться в открытом состоянии при помощи Q4, на базу которого приходит высокий потенциал (через делитель R1, R4). Выключение же аппаратуры произойдет при замыкании базы Q4 на землю. В выключенном состоянии, резистор R1 также защищает схему от самопроизвольного включения (ну, мало ли что!).

Полевой транзистор Q1 защает всю аппаратуру от переполюсовки (кроме случая, когда аппаратура включена через тренерский разъем - тут выключатель питания вообще не при делах).

Печатная плата двухсторонняя, разведена под SMD-компоненты и с учетом возможного переиспользования деталей от штатной платы. Т.е. подразумевается использование такого же выключателя, такой же косички проводов, при необходимости - той же “пищалки” и ее обвязки. Со схемой пищалки есть нюанс: их существует как минимум два вида. Я сделал ту, которая соответствовала имеющимся у меня штатным платам. Тем, у кого установлен звуковой модуль, или выполнен апгрейд до Skyboard, AR9x и т.д., пищалку можно не переносить вообще - она не используется, т.к. на этих платах есть полноценный звук.

Стоит отметить, что схема будет потреблять какой-то ток даже в выключенном состоянии. Однако, ток этот очень незначителен - во время экспериментов мой мультиметр не намерял вообще ни одного микроампера. Так что если Вы пользуетесь аппаратурой хотя бы раз в полгода, Вы можете спокойно оставлять ее с подключенным аккумулятором, не боясь чрезмерного разряда.

Из недостатков отмечу то, что в данной схеме “половина выключателя” коммутирует землю, а другая (отвечающая за цепь зарядки АКБ) - плюсовой провод батареи. Это надо иметь в виду, чтобы случайно не замкнуть два центральных контакта. На плате я отметил где плюс, а где земля на контактах выключателя. Вообще говоря, João хочет бОльших переделок - в т.ч. он планирует изменить всю цепь зарядки АКБ так, чтобы выключатель коммутировал только землю, а не плюс. Возможно, через какое-то время появится обновленная версия (хотя меня нынешняя версия, честно говоря, вполне устраивает).

Я тестирую эту плату в своей аппе. Пока никаких проблем не замечено. Все попытки имитации плохого контакта в выключателе не приводят к выключению аппаратуры, все работает так, как и ожидалось. Однако я не проверял (и не планирую проверять) все, что касается порта для зарядки АКБ, т.к. у меня часть этой проводки используется под телеметрию.

Скачать проект в формате Eagle 6-й версии можно тут.

Если кто решит попробовать на себе - пишите, будет любопытно услышать отзывы и комментарии.

P.S. Если кому-то надо - у меня есть несколько лишних плат. Могу поделиться либо пустой платой, либо готовым изделием!

Не стоит забывать, что если мы используем “Extended Limits” (-125 … +125), то длина импульса для одного канала может превышать 2мс. Это повлияет и на общую длину PPM-фрейма.

Вообще говоря, длина PPM-фрейма в современных аппаратурах может настраиваться пользователем. Во всяком случае в er9x такая настройка есть, подозреваю что в OpenTX она тоже должна быть.

Хотя применительно к Taranis’у и его ВЧ-модулю эта информация не имеет особого значения - надо просто использовать протокол PXX, который является штатным для встроенного ВЧ-модуля, а также для FrSky XJT. Тогда не возникнет никаких проблем с длительностью фрейма.

Ну давайте разбираться в теории…

PWM (Pulse Width Modulation, или же по-нашему ШИМ) - это способ кодирования сигнала, при котором состояние канала (уровень газа, положение сервопривода и т.д.) кодируется длительностью передаваемого импульса. Для передачи информации о состоянии одного канала, длительность импульса может составлять от 1 до 2 миллисекунд (реально даже чуть больше - 2140мкс). PWM широко используется в “классических” приемниках, сервоприводах и т.д. Если каждый сервопривод подключается к своему разъему на приемнике - это, в принципе, и есть PWM.

PPM - это, фактически, несколько PWM, идущих “друг за другом”. Т.е. в PPM информация обо всех каналах передается последовательно. Этот протокол обычно используется для общения аппаратуры и ВЧ-модуля (но не в Taranis - об этом дальше). Добавьте к этому всякие синхронизации, в итоге на передачу полного пакета из 8 каналов уйдет от 9 до 18 миллисекунд, в зависимости от конкретных значений каждого канала.

Производители подумали и пришли к выводу, что современными ВЧ-модулями нужно еще и управлять - переключать их в разные режимы, добавлять контроль и коррекцию ошибок и все такое. Если эти дополнительные сигналы посылать вместе с PPM, то длительность передачи одного полного набора информации о состоянии каналов станет гораздо больше 18мс. А это вряд ли понравится пользователям. В то же время, есть более эффективные методы передачи информации в цифровом виде. Поэтому у каждого производителя появился свой “фирменный” протокол общения аппаратуры и ВЧ-модуля. У FrSky это PXX, и именно он используется в Taranis’е (а также его можно включить в OpenTX и er9x для других аппаратур). Майк как-то говорил, что в протоколе PXX информация о состоянии каналов передается пакетами длительностью 9мс. каждый. Каждый такой пакет несет информацию о 8 каналах. Отмечу, что для передачи 16 каналов нам понадобится 18мс. Но зато со всем “оверхедом” и с гарантией, что за пределы этого интервала мы не выйдем. Это, опять же, передача информации от аппаратуры к ВЧ-модулю.

SBUS - это цифровой сигнал, тут информация кодируется в цифровую последовательность по определенному алгоритму. SBUS достаточно часто используется на приемниках для передачи информации “обо всех каналах сразу”. В некоторых частных случаях может использоваться для общения аппаратуры и ВЧ-модуля. Из того что я нашел, средняя длительность пакета SBUS находится где-то в районе 10-20мс.

Получается, что вроде как SBUS как минимум не медленнее, но давайте рассмотрим реальный пример. Есть у нас Taranis. Аппаратура “внутри себя” общается с ВЧ-модулем по своему фирменному протоколу PXX. Получив пакет с данными от аппаратуры, ВЧ-модуль отправляет его на приемник (тут добавляется время передачи радиосигнала, но для простоты мы его в расчет не берем). Приемник, приняв пакет, может сразу же отправить его на каждый PWM-канал в отдельности - это самое простое, поэтому делается быстрее всего. Если же мы хотим получить на примемнике SBUS, то тут приемник должен сначала получить ВСЮ последовательность (а в случае с 16-ю каналами это ДВА пакета, т.е. те же 18мс), затем ОБРАБОТАТЬ ее, преобразовав в SBUS, и только ПОТОМ он отправит сигнал “на выход”. Вот тут-то и получается задержка в SBUS по сравнению с PWM.

Если Вы думаете, что теперь Вы во всем разобрались - рано радуетесь! 😃
Некто Oscar Liang написал любопытную статью про SBUS и PPM применительно к коптерам. Оказывается, т.к. PPM - сигнал “не очень цифровой” и достаточно слабо защищенный от помех, возможны ошибки при приеме сигнала (ну, мало ли - помеха в эфире, дело, в общем-то, обычное). Поэтому полетный контроллер Cleanflight при работе с PWM-сигналами сначала вычисляет СРЕДНЕЕ из трех последовательно принятых значений, и только затем использует полученную информацию для управления полетом. А это уже 3x18мс = 54мс. И вот тут-то SBUS окажется быстрее, т.к. в протоколе SBUS есть свои методы контроля ошибок и полетному контроллеру нет необходимости “усреднять” принятые значения - каждое поступившее по SBUS значение он сразу “кидает в бой”.

Однако, это реализация конкретного алгоритма в конкретном полетном контроллере. Как работают другие - я не знаю (да и про Cleanflight-то могу судить только из прочитанной статьи).

Вот так…

Таки у какого меньше задержки сигнала, напишите человеку. Я не знаю.

Я тоже не знаю, но если верить обсуждению в ветке про Horus, то у S.Bus задержки выше, чем у PWM. Там в обсуждении, конечно, много флейма и предрассудков, но есть и интересная информация, в частности тут и вот тут.

x4r вообще для квадриков недостаточен - в нем только 4 канала, сбаса, вроде, и нету. x4rsb 3 “аналога” и по сбасу 16.

Угу. Поэтому дело не в задержках, а именно в количестве каналов.

4-пиновый разъем на аппе может быть под что-то типа PHR-4. Но я не уверен и посмотреть сейчас не могу - такой аппы под рукой нет.

Для “полноты картины”:
Вот тут тема про установку Bluetooth в 9XR PRO (на английском).
А вот тут видео на 42 минуты по поводу 9XR PRO и, в частности, Bluetooth.
(Вот поэтому я не люблю “видеоинструкции”)

Приобрел сам блютуз HC-06

Лучше было брать HC-05…

4-х пиновый разъем непонятного мне формата

Распиновка разъема - на картинке.

Ну тогда информации по моим ссылкам должно быть вполне достаточно. А дальше изучаемые области можно будет скорректировать в зависимости от личных предпочтений.

Сергей, Вы сами-то чего хотите?

Если Ваша цель - получить опыт программирования, то рекомендую посмотреть исходники er9x или OpenTX. Это наиболее популярные прошивки с открытым исходным кодом. Они, кстати говоря, поддерживают различные варианты микроконтроллеров - и AVR, и ARM. В них можно много всего интересного узнать. Если с английским хорошо - можете пообщаться с разработчиками на http://openrcforums.com.

Если Вас интересует “железо”, то на том же openrcforums есть несколько любопытных веток. Но тут загвоздка в том, что паять системную плату “на коленке” и в единичных экземплярах получается существенно дороже, чем взять уже готовое решение. Такие решения также уже существуют (пример) и предлагаются по вменяемой цене (т.к. производство даже небольшой партии плат в несколько сотен штук, в пересчете на единицу продукции обходится заметно дешевле, чем покупка комплектующих в розницу). А дальше уже каждый для себя сам решает какую “периферию” ему нужно подключить (тумблеры, слайдеры, внешние и внутренние интерфейсы, и др.) - вот тут можно приложить и руки и голову, интегрируя какой-нибудь новый прибамбас в общедоступную платформу.

Если же создавать аппаратуру целиком, делая все самостоятельно, то … да, проект может быть очень интересным, но очень долгим и чрезвычайно затратным. Тут надо очень хорошо понимать что именно Вы хотите получить и почему этот функционал не сделали (и не планируют сделать!) в вышеупомянутых решениях. Иначе можно потратить кучу сил, времени и, весьма вероятно, денег, а на выходе получить то же самое, что уже давно существует и используется многими.

eepe - программа для обновления прошивок и работы с eeprom аппаратур, основанных на AVR-микроконтроллерах (Atmega 64 / 128 / 2561). К таковым относятся Turnigy 9x / 9XR (не путать с 9XR PRO!!!)

eepskye - специальная версия eepe для аппаратур на ARM-микроконтроллерах (STM32, Atmel SAM и др.). К ним относятся Turnigy 9XR PRO и FrSky Taranis, а также некоторые платы для апгрейда (AR9x, AR Uni, 9Xteme, Skyboard, …)

Если у Вас 9XR PRO, Вы должны использовать eepskye.