Прошивки CleanFlight/BetaFlight для полетников
На B10 отсутствует SERIAL_TX 12, но это sport. Отчего tramp не работает - я хз.
Почему команда <resource> показывает:
resource SERIAL_TX 12 B10
а команда <resource list> :
B10: FREE
Попробовал вернуть
resource SERIAL_TX 3 B10 как было изначально.
команда <resource> показывает:
resource SERIAL_TX 3 B10
а команда <resource list> :
всё равно
B10: FREE
отключил XSR от контроллера без изменений
ЕМНИП, телеметрия не работает при подключенном конфигураторе.
С чего бы? Всё прекрасно работает - по крайней мере, через хардварный UART у меня.
Конфигурация: контроллер OmniBus F4 Pro Corner, видео передатчик Tramp HV, регуляторы Wraith32, камера RunCam Split v1, приемник FrSky XSR, пульт Taranis QX7.
Подключение:
Uart 1
RX1 - к телеметрии регуляторов
TX1 - SoftSerial 1 - на T-pin Tramp (smart audio)
Uart 3
RX3 - SBUS приемник XSR (беру не инвертированный сигнал)
TX3 - SoftSerial 2 - SmartPort приемник XSR (беру не инвертированный сигнал)
Uart 6
RX6 - на TX RunCam Split
TX6 - на RX RunCam Split
Почему не заработала эта схема так и не разобрался.
Так же остались вопросы почему команды <resource list> и <resource> после перезагрузки контроллера показывают разные значения. По документации после перегрузки должны быть одинаковыми 😵
После экспериментов 😃 было выяснено, что смена местами как вместе так и подключение по одному к TX1 и TX3, как через СофтСериал, так и напрямую ни S Port ни S Audio не заработали.❗
В результате поисков наткнулся на Tramp HV incompatibility issue with F4 hardware UARTs
В итоге эксперименты и чтение как наших, так и импортных ресурсов утомили и было сделано следующее:
- Smart Audio (Tramp Audio) подключено через SoftSerial 1 на pin MOTOR 5
- Smart Port подключен через SoftSerial 2 на pin LED_STRIP
Smart Audio (Tramp Audio) через SoftSerial так же работает на pin LED_STRIP- проверил.
Если кому-то понадобятся мои настройки:
feature SOFTSERIAL
feature TELEMETRY
feature ESC_SENSOR
feature LED_STRIP
resource MOTOR 1 A02
resource MOTOR 2 A03
resource MOTOR 3 B01
resource MOTOR 4 B00
resource MOTOR 5 none
# MOTOR 5 - A01 default value
resource LED_STRIP 1 none
# LED_STRIP 1 - B06 default value
resource SERIAL_TX 11 A01
# Smart Audio on SoftSerial 1 to pin MOTOR 5
# resource SERIAL_TX 1 NONE
# resource SERIAL_TX 11 A09
resource SERIAL_TX 12 B06
# Smart Port on SoftSerial 2 to pin LED_STRIP
# resource SERIAL_TX 3 NONE
# resource SERIAL_TX 12 B10
set sbus_inversion = OFF
set cpu_overclock = ON
set serialrx_provider = SBUS
set current_meter = ESC
set battery_meter = ESC
set tlm_halfduplex = on
set tlm_inverted = on
serial 0 1024 115200 57600 0 115200
serial 2 64 115200 57600 0 115200
serial 5 16384 115200 57600 0 115200
serial 30 8192 115200 57600 0 115200
serial 31 32 115200 57600 0 115200
В общем УРА!!! Можно собирать на раму 😃
телеметрия не работает при подключенном конфигураторе.
Подтверждаю при включенном конфигураторе у меня телеметрия не работает, состояние ARM или DISARM значения не имеет.
Вот видео в тему для экономии юартов и проводов:
Вот видео в тему для экономии юартов и проводов:
Он пока сырой как болото весной - телеметрия лагает жутко, данных на экранах BF LUA вообще хрен дождёшься.
Я уже писал в соседней теме, что полагаю весьма странной идеей - пихать управление, телеметрию, LUA и RSSI в ПОЛУДУПЛЕКСНЫЙ (однопроводный) протокол. Это ж как участок “реверсивного движения” при ремонте дороги - “пробки” обеспечены по определению. Кой смысл было упираться в однопроводный протокол вместо двухпроводного асинхронного (например, вывод SBUS в качестве TX и SPort в качестве RX) - мне непонятною
Кой смысл было упираться в однопроводный протокол вместо двухпроводного асинхронного (например, вывод SBUS в качестве TX и SPort в качестве RX)
допилят все. в этом плане бетафлайт молорики.
допилят все.
Чем раньше сообразят перейти на дуплекс - тем скорее допилят. 😃 Я правда никак не могу понять смысла “упёртости” в 1-проводку, это ж “сам себе злобный Буратино”. 😃
Разработчик в слаке ответил, что на днях уже будет улучшение в протоколе.
Чем раньше сообразят перейти на дуплекс - тем скорее допилят. 😃 Я правда никак не могу понять смысла “упёртости” в 1-проводку, это ж “сам себе злобный Буратино”. 😃
на каждом полетнике уже есть СБАС. Или ППМ.
И их “однопроводные” можно использовать.
если сожрать “живой” уарт - нафиг оно все нужно?
Что-то вы дюже загадочное написали 😁
1)
если сожрать “живой” уарт - нафиг оно все нужно?
SBUS - это и так “живой” UART, причём аппаратный, а не софтовый - на некоторых полётниках этот же UART “продублирован” отдельными RX и TX (на F4, как правило, разница этих “пятаков” в наличии инвертора на пятаке SBUS) И, хотя занят там только RX, порт оказывается занят целиком. Так что для FPort можно было бы использовать тот же “SBUSовский” UART “по полной”, раз уж FPort в том числе заменяет SBUS.
2) По поводу использования SBUS+SPort - я больше имел в виду приёмник (XSR), где изначально не было предусмотренно асинхронного выходного порта.
3)
И их “однопроводные” можно использовать.
Убогость “однопроводности” и проблемы, вылезающие из этой убогости, я уже описал выше - после того как натолкнулся на них на практике.
Тут проблема еще может быть в том, что радиоканал имеет свои ограничения, и полный дуплекс тут не катит, что выглядит вполне логично. Посмотреть бы, как вещают сейчас sbus в одну сторону и s.port в другую, точно ли это может происходить одновременно?
Убогость “однопроводности” и проблемы, вылезающие из этой убогости, я уже описал выше - после того как натолкнулся на них на практике.
Да это бред какой-то. Между аппой и приёмником полудуплексный канал, какой смысл между приёмником и FC делать дуплекс?
после краша (предположительно) стал греться проц на omnibus f4 v1, но только при подключении по usb. При этом гиро уплывает во все стороны сразу же в конфгураторе. Просто приложив палец в качестве охлаждения - гиро возвращается на место. отпускаю - уплывает)). ПК видится в конфигураторе нормально. Но все это только при usb подключении. Ппри подаче 5в от pdb все в порядке, ничего не греется. Есть идеи?
и еще интереснее: подключаю просто 5 в по usb - не греется. Греется только когда определяется как устройство компом. Чудеса.
Да это бред какой-то. Между аппой и приёмником полудуплексный канал, какой смысл между приёмником и FC делать дуплекс?
А при чем тут канал между аппой и приемником? Я сравниваю работу общеиспользуемой связки из sbus/ppm и s.port с “интегральным” протоколом FPort и вижу во втором случае лаги по направлению от полетника к приёмнику (телеметрия и данные по lua-запросам). То ли авторы сильно косякнули с приоритетами прямой и обратной передачи то ли дело в скорости обмена - не знаю. Но если для задачи двунаправленной передачи данных можно использовать полнодуплексный протокол - кой смысл закрывать одну из створок двери у себя же перед носом и использовать полудуплекс? Один фиг второй провод порта никто другой использовать не сможет - к чему эта “экономия”? Разве что вытаскивать FPort на softserial и выводить через моторный пин - тогда да, экономится аппаратный uart. Но вешать канал радиоуправления на softserial - это для экстремалов. 😃
А при чем тут канал между аппой и приемником?
Канал между аппой и приемником - это, по сути, связь между двумя модемами. Stm32 в приемнике просто, грубо говоря, передает данные, пришедшие через этот модем (с конверсией форматов, разумеется) дальше в полетный контроллер. Ну и наоборот для телеметрии. Если модем работает в полудуплексе, то нет никакого смысла как-то ускорять и оптимизировать передачу на участке между stm32 и полетником. А дуплекс на радиоканале с одновременным приемом и передачей организовать сложнее, они просто будут мешать друг другу, надо усложнять конструкцию, и антенна всего одна.
К тому же этот модем, скорее всего, имеет скорость передачи гораздо ниже максимально допустимой скорости UART. У них в прошивке под fport сейчас наверняка просто какие-то косяки наблюдаются, которые мешают корректной работе. Поправят и все будет хорошо.
Кой смысл было упираться в однопроводный протокол вместо двухпроводного асинхронного
к чему эта “экономия”?
Ты реально не понимаешь? 😆 один провод против двух
Убогость “однопроводности” и проблемы, вылезающие из этой убогости, я уже описал выше
Вот это ты дал, “полудуплексу не хватает скорости” 😆
Ещё раз предлагаю не впутывать сюда радиоканал. 😃
Смотрите:
- Есть асинхронно работающие (аж по двум разным uart) sbus и s.port - каждый по одному проводу. Sbus только в одном направлении, s.port в обоих в полудуплексе - но основной объём данных у него идёт в направлении, обратном sbus.Все работает быстро - и туда и обратно.
- FPort объединяет оба канала из пункта 1 (плюс rssi, но это уже мелочи) - и в результате дает лаги в “обратном” направлении (телеметрия). При этом “второй провод” того же uart, на котором висит FPort, этим протоколом не используется и не может быть использован никем другим (так как uart аппаратный - не ремапится и не делится между несколькими протоколами).
Вывод - на хрена было “вставать на одну ногу”? 😉 Uart сэкономили - отлично. А вот один проводок (3 от приемника вместо 4) явно не стоит лагов.
Ещё раз предлагаю не впутывать сюда радиоканал.
Да причем тут радиоканал 😆 решить что fport’у не хватает скорости из за однонаправленного режима работы маразм. Вайфайное оборудование работает в полудуплексе(ну кроме совсем последних версий), езернет может работать в полудуплексе. А там мегабайтами скорость измеряется 😉
и в результате дает лаги в “обратном” направлении (телеметрия)
это временно. не будет никаких тормозов. об этом речь. о бете и релизе…
Вывод - на хрена было “вставать на одну ногу”
Я же открыл тебе глаза, один провод 😆
не будет никаких тормозов.
Конечно не будет )
Тем не менее логика в идеи fullduplex есть, и оно будет лучше и быстрее чем просто один провод.
То что исправят сомнений нет, и это удобно. Тем не менее приоретет будет за управлением, и в определенные моменты телеметрия будет затыкаться, в худшем случае и управление.
У нас же водопровод и канализация не по одной трубе… 😃