Прошивки CleanFlight/BetaFlight для полетников
Тут проблема еще может быть в том, что радиоканал имеет свои ограничения, и полный дуплекс тут не катит, что выглядит вполне логично. Посмотреть бы, как вещают сейчас 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 есть, и оно будет лучше и быстрее чем просто один провод.
То что исправят сомнений нет, и это удобно. Тем не менее приоретет будет за управлением, и в определенные моменты телеметрия будет затыкаться, в худшем случае и управление.
У нас же водопровод и канализация не по одной трубе… 😃
Скоро приёмник подключат через SPI, там уж точно дуплекса не будет. МУХАХА!
Тем не менее приоретет будет за управлением, и в определенные моменты телеметрия будет затыкаться, в худшем случае и управление.
О чём с самого начала и говорил. Но некоторым в силу “дюже образования” это сложно понять. 😃
Скоро приёмник подключат через SPI
Было бы неплохо. Правда, высокая скорость передачи потребует нормальной экранировки линии данных - уже абы как проводками не соединишь. И это будет относительно нишевой продукт, способный работать лишь напрямую с контроллером, и требующий от контроллера соответствующей аппаратной и программной поддержки.
Хотя… пошёл же DSHOT в массы - может, и здесь так получится.
Скоро приёмник подключат через SPI, там уж точно дуплекса не будет. МУХАХА!
Помимо спи, там ещё нужно управлять антеннами, то есть минимум 8 проводов.
Кстати насчёт spi, в последней бете беты добавили:
3. Added FrSky X SPI RX protocol
Кто знает о чем речь? Вроде не слышал о приемниках фриски с spi
Это и есть вариант приёмника по спи, на котором нет стмки и всем рулит сама бф.
Класс ))
Минимум 6 проводов, если всё остальное притянуть куда нужно - это только для связи, не считая питания и земли. Ну и прошу, либо к ф3 паять.
Вероятно, SPI для приёмника, распаянного на той же плате, что и полётник. Ещё больше “всё в одном”. Тогда вполне логично.
Ибо шесть проводов между модулями - это чересчур.
Я говорю о возможности реального применения этого, а не о древнем ф3, который так в серию и не пошёл. Если матек заинтересуется - возможно внедрит в ф7.
у кого получилось успешно подцепить осд камеру к мозгам?
diatone fury f3 3.2.1
резисторы пробовал 180 и 150, разную задержку (200,180,125) ресурс led strip и rx1 на свободном uart - на вольтметре ноль реакции при движении стика, осд не появляется.
камера - аналог hs1077, джойстик от фоксира с ней работает.
возвращаясь к камеропроблемам…
а вот на матеке 405 аио всё заработало. телеметрия по софтсериал на мотор5, а камера на мотор6 через резистор на 150 ом, все настройки по умолчанию. переключение конечно тормозное относительно джойстика, но сойдёт . камера runcam night eagle 2