Vbar Touch. Первое впечатление
Настройка и телеметрия, это отдельные ОЧЕНЬ приятные бонусы .
Я бы отдельно упомянул интеграцию с YGE. Вот действительно где воткнул провода и полетел. Даже конечные точки газа не требуется настраивать!
Если кому нужно, можно выставить напряжение БЕКа, GovStore и передаточное число прямо с VBC, на этом все настройки окончены.
все подстройки в первом вылете
На первом VBC при настройке можно покрутить одну из двух крутилок, и до конца полета параметр привязывается к этой крутилке. Можно подстраивать в воздухе, особенно удобно чуйку. После отключения питания это назначение крутилки отвязывается. Очень удобно использовать такую схему.
На VBCt я такого не нашел кроме как Modify parameters, но это не так удобно потому что после настроек нужно отключать вручную, иначе можно случайно накрутить…
Может кто знает как временно назначить параметр на крутилки?
И ещё главное отличие связки VBC + Neo от FrSky - это скорость передачи сигнала (латентность) у ВБЦ она очень маленькая, в разы. И это чувствуется при переходе от FrSky+Microbeast к VBC+Neo. Я переходил, при переходе показалось что мой скил управления вырос вдвое! Я не ожидал от такого эффекта.
Тоже самое и в симуляторе - при переходе с беспроводного подключения (приёмник SBUS + arduino) на шнурок - тоже скил повышается. А всего навсего уменьшается задержка передачи сигнала.
Хоть как не восхваляйте FrSky - но задержка у него большая. И не просто так гонщики на квадриках переходят на приемники. TBS Crossfire - не тз-за дальности, а из-за скорости передачи сигнала.
И ещё большой плюс VBC - как проходит бинд пульта: включил бинд, включил Нео и все. Никаких кнопок ничего. И огромный плюс: все настройки сохраняются в Нео а не в пульте. Можете легко подключить свой пульт к чужому вертолету и полетел со своими настройками режимов стиков и тумблеров. В пульте хранятся только информация доп.приложений (батарейки).
Может стоит полетать и на новом бисте, что б, так сказать, объективно сравнить? Вот я не летал с NEO, а вы с последним бистом и как, вот как без покупки конкретного девайса можно попробовать как он летит 😐
Не думаю что по полету, новый Бистплюс отличается от старого …
По “психотипу” я консерватор и если нахожу то что меня устраивает, останавливаюсь на долго 😃 … с удовольствием читаю обзоры на новые девайсы, но сам экспериментировать не люблю… да и время все меньше 😌…
Так что по новому Бисту, я пасс …
ПС Полностью солидарен с Игорем насчет задержек в ФрСкае …
Видимо популярность среди ФПВ гонщиков обусловлена тем что даже аналоговый видеотракт имеет некоторую задержку, а цифровой и подавно … вот видимо “совпадение” этих “задержек” определяет удобство управления от первого лица …
Даже после 11мс задержки на Футабе 14СГ (из тех что были у меня в пользовании-самая быстрая) 28 мс на Таранисе ощущаются очень сильно!
С Микадо вообще не сравнить … 😒
Макс, поверь при любом стиле полета … ты это почувствуешь…
И не пожалеешь! 😉
Еще добавлю плюса к VBCt и почему я поменял обычный VBC на тач:
- тач умеет писать логи оборотов, температуры, напряжение борта, сигнал газа на Нитро вертолёте! Микадо так и не реализовало это на старом ВБЦ. Я спрашивал у них на форуме, сказали - купи тач. Так и сделал.
Но тач не только пишет логи полёта но можно и посмотреть графики прямо в поле без подключения компа и программы VBCAnalyzer.
Микадо пошли дальше и сделали облако куда скидываются логи полетов телеметрии при наличии WiFi и можно их посмотреть на компе! Это же очень здорово.
Я постоянно приезжал с поля и переливал данные с ВБЦ на комп. А сейчас достаточно включить пульт дома и логи сливаются в облако!
Экосистема у Микадо очень классная!
По поводу аккумулятора: наверное можно в пульт поставить 2 аккумулятора по 6000мАч и он будет держать дольше. Старый ВБЦ мне хватало заряда на 40 полетов. Если аккумулятор садился, подключал PowerBank и летал с ним, пока аппаратура заряжалась. Современные автомобили оснащены USB разъёмами и проблема зарядки пульта в поле - не проблема.
Я бы отдельно упомянул интеграцию с YGE. Вот действительно где воткнул провода и полетел. Даже конечные точки газа не требуется настраивать!
Если кому нужно, можно выставить напряжение БЕКа, GovStore и передаточное число прямо с VBC, на этом все настройки окончены.
Для YGE (Saphir 125A под 6s сетап) докупил YGE->V Bar провод:
www.amainhobbies.com/…/p-qtaxq2kqbczxactz
Можно, при желании, смастерить самому.
это скорость передачи сигнала (латентность) у ВБЦ она очень маленькая, в разы
Ну не в разы, а скорее в два раза. У новых ACCESS арчеров, средняя задержка до 13ms. У модуля кроссфаер тоже самое. +4 ms на межфреймовый интервал S.Bus надо добавить (VBC это касается тоже). Мне кажется, что вы берете данные по frsky 3-5 летней давности, а сравниваем здесь с топовой, самой свежей аппой.
Со шнурком по USB там тоже может быть так, что отклик быстрее лишь по ощущениям. Потому что, большие задержки (в сравнении передатчик-приемник) вносит и буфферизация на USB хосте плюс, если монитор хотябы 60 герц, то добавляется минимум 16мс задержка между командой и отрисованным кадром, а это ни двойной, ни тройной буфферизацией не лечится. И вообще, везде где встречается слово буффер - это значит есть задержка.
Ну не в разы, а скорее в два раза. У новых ACCESS арчеров, средняя задержка до 13ms. У модуля кроссфаер тоже самое. +4 ms на межфреймовый интервал S.Bus надо добавить (VBC это касается тоже). Мне кажется, что вы берете данные по frsky 3-5 летней давности, а сравниваем здесь с топовой, самой свежей аппой.
Со шнурком по USB там тоже может быть так, что отклик быстрее лишь по ощущениям. Потому что, большие задержки (в сравнении передатчик-приемник) вносит и буфферизация на USB хосте плюс, если монитор хотябы 60 герц, то добавляется минимум 16мс задержка между командой и отрисованным кадром, а это ни двойной, ни тройной буфферизацией не лечится. И вообще, везде где встречается слово буффер - это значит есть задержка.
Инпут может поступить в любой момент времени, далее осуществляется пересчёт в зависимости от значения инпута. Т.о. следующее положение модели зависит от delta time * value от контроллера. Чем меньше delay между контроллером и движком, тем точнее будет просчитываться положение модели в симуляторе. Критичным в данном случае является время доставки данных от контроллера и fps в симуляторе. Т.е… к примеру, если в 120 fps симулятор работает, это ~8мс на кадр, если задержка у контроллера больше, то симулятор будет ждать данные от контроллера.
Буферизация изображения предназначена не для уменьшения задержек инпута, предназначеня для борьбы с screen tearing (разрыв экрана) и напротив она создаcт дополнительный инпут лаг.
Буферизация изображения предназначена не для уменьшения задержек инпута, предназначеня для борьбы с screen tearing (разрыв экрана) и напротив она создаcт дополнительный инпут лаг.
Двойная и тройная (у опенГЛ) буферизация предназначена для того, чтоб вовремя вывода изображения на дисплей процессор не простаивал, а подготавливал следующий кадр. К tearing это не относится почти никак. Чтоб на экран не выводился непрорисованный фрейм используется вертикальная синхронизация.
UPD. Но да, если рисовать в аппаратный “буфер”, который на данный момент отображается на экране, то никакая синхронизация не поможет. Тут надо отличать софтовую буферизацию и аппаратное переключение страниц.
Двойная и тройная (у опенГЛ) буферизация предназначена для того, чтоб вовремя вывода изображения на дисплей процессор не простаивал, а подготавливал следующий кадр. К tearing это не относится почти никак. Чтоб на экран не выводился непрорисованный фрейм используется вертикальная синхронизация.
UPD. Но да, если рисовать в аппаратный буфер, который на данный момент отображается на экране, то никакая синхронизация на поможет. Тут надо отличать софтовую буферизацию от аппаратной.
Это актуально если у GPU есть что рисовать, и чтобы не ждать CPU, рисуем. Актуально для игр и не актуально для симулятора где мы имеем одну простую модель, с примтивными шейдерами, и 1 источником которая летает внутри sphere / sky box с текстурой и задачей максимально быстро и по возможности похоже отразить действие управления. Если инпут будет долгий, то мы либо попадём в какую-то часть кадра, но уже изменить его невозможно и отрисуем на следующем, либо если fps низкий будем скипать кадры беря актуальный инпут на момент подготовки кадра. Т.о., повторюсь, решающим фактором для симулятора является fps и задержка инпута.
Ну так я об этом и писал
Д
UPD. Но да, если рисовать в аппаратный “буфер”, который на данный момент отображается на экране, то никакая синхронизация не поможет. Тут надо отличать софтовую буферизацию и аппаратное переключение страниц.
Максим, я в рзработке игр 15 лет. Давайте не будем просто продолжать. Вы уже напридумывали каки-то буферы инпутов (наверное про клавиатуру речь) и т.д. Которые если и спользуются то для тач управления или ввода текста. Можно скрутить настройки сима и увидите результат. В жизни вертолёт летает гораздо выше 60 и даже 144 fps
Ну а я 18 лет в низкоуровневой разработке и что?, а на данный момент уже лет 6 как разрабатываю сетевые симуляторы для тестирования роутеров в сетях 4 и 5 поколений, и с сетевыми адаптерами приходится работать через регистры. А подобные заявления в мой адрес, что я мол чего то напридумывал, ну это как то опрометчиво, мягко говоря. Вы хотя бы спросили, что именно я имел ввиду.
Вот вам спецификация контроллера от интел. intel.com/…/extensible-host-controler-interface-us…
С 57 страницы начинается описание архитектуры, вы можете для себя изучить и понять как, где и чего происходит буферизация. Пакет/транзакция ни из какого USB устройства мгновенно в ядре операционной системы не появляется, а максимальная задержка, определяется длинной кольцевого буфера и частотой пакетов/транзакций, а так же как именно устройством настроена толерантность задержки.
Вау ! Да тут собрались СПЕЦИАЛИСТЫ !😃
То есть шанс разобраться в происходящем значительно возрастает!
Но давайте так сказать вернемся “к истокам” …
В системе: пилот - аппа - приемник - исполнительный механизм(серво) - реакция модели.
Работают следующие “задержки”:
Пилот - собственно реакция пилота
Аппа - время от воздействия на стик до момента формирования управляющего сигнала. Включая время отработки АЦП, опрос всех каналов, формирование пакета в данном протоколе и его отправка по ВЧ.
Приемник - время на распаковку (проверки пропущенных пакетов и все такое), формирование канального PWM или Sbas сигнала.
Серво - собственно быстродействие самого сервопривода
Реакция модели - зависит от конструктивных особенностей (площади поверхностей, углы отклонения, центровка и балансировка) и люфтов в шарнирных соединениях.
А еще кроме скорости, огромное значение имеет точность! То есть разрешающая способность, начиная от датчиков стиков и дальше по списку…
В случае с вертолетами, добавляется “черный ящик” ФБЛ которая вносит свои задержки как по железу, так и по ПО … 😵
Подключив (желательно по ЮСБи без промежуточных устройств) аппу к симулятору, ситуация несколько упрощается 😒
Теперь важно оценить это самое “быстродействие/ точность” в поведении симуляторной модели, отбросив субъективность ощущений конкретного пилота …😛
Опять все не просто ! 😉
Измерить задержку между включением переключателя и изменением значения канала (с точностью до 1мс) в пакете S.Bus можно с помощью той же ардуины как для VBCt так и для FrSky. Уже делал для FrSky PWM выходов. На PC не знаю, не занимался этим. Проще всего взять камеру с 1000fps и поснимать одновременно движение стика и ответное движение визуализации канала на мониторе. Потом на раскадровке измерить время отклика.
Все равно те измерения (только передатчик приемник) ничего не решат. Эти же данные написаны у производителя в спецификации к продукту. Я ими и занимался только потому, что тут же на форуме был “спор”, что у frsky задержка аж 60мс.
Если в симе летать комфортно, то что те измерения дадут? Что и в какую сторону настраивать без детального анализа они всеравно не покажут.
+4 ms на межфреймовый интервал S.Bus надо добавить (VBC это касается тоже).
У VBC нет SBUS. Как раз фича в том что приемник встроен в ФБЛ и нет промежуточных протоколов типа SBUS. Поэтому скорость передачи у ВБЦ быстрее других, включая Футаба. Хотя протокол передачи именно Футабий используется FHSS
Об этом я почему то не задумывался. Тогда это минус еще ~4-6 ms
Я писал - то что я почувствовал: летал в симуляторе по воздуху (приемник+ардуино) тут же включил шнурок и полетел гораздо лучше.
Летал на FrSky Taranis+Mikrobeast поменял на VBC+Neo - и полетел гораздо лучше и точнее. Филиппы и ролы стали не размашистые а ближе к одной точке.
А что поменялось? Задержки остались, как вы говорите ну почти такие которые на полет не влияют - а я увидел другую картину. Вертолет тот же самый, сервомашинки и лопасти и аккумуляторы остались те же. Просто замена Аппаратура+Приемний+ФБЛ на другую Аппаратура+ФБЛ.
И топ пилоты квадратов наверное не просто так перешли на Crossfire, им эти миллисекунды ничего не дают.
Просто убирая задержки в одном месте - повышается качество управления ЛА. Да не в разы, но точность возрастает. Попробуйте сами и тогда говорите - что разницы нет.
Та надо бы попробовать. Я своим скептицизмом и прагматизмом отдаляю от себя это событие.
Есть у нас в клубе один начинающий вертолетчик с старым Гоблином и VBC (не touch). Возможно он и поделится, но его еще поймать надо. Достаточно редко его вижу
У VBC нет SBUS. Как раз фича в том что приемник встроен в ФБЛ и нет промежуточных протоколов типа SBUS. Поэтому скорость передачи у ВБЦ быстрее других, включая Футаба. Хотя протокол передачи именно Футабий используется FHSS
FHSS это контейнер / метод передачи. Что там внутри, какой компрессор (алгоритм сжатия) можно же передавать 10кб, а можно и 3 кб но нужен будет распаковка, какой декодер, который может быть soft, но будет создавать задержку, а может и чип паяный - это всё проеприетарщина каждого производителя в которой они сейчас и соревнуются. Замерить можно при желании.
Ну а я 18 лет в низкоуровневой разработке и что?
То что вы не шарите если по простому - тестер или QA судя по компетенциям, может быть PM. Но точно не дев который код копал 18 лет.
😃 Очень опрометчивое заявление. В чем именно я не шарю?
Очень опрометчивое заявление. В чем именно я не шарю?
Пусть будет опрометчивое.
Вау ! Да тут собрались СПЕЦИАЛИСТЫ !😃
Опять все не просто ! 😉
Всё достаточно просто - чем больше данных передаём, тем дольше будет их обработка-распаковка. Теоретически даже может быть prediction (предсказание). Даже в случае с USB, больше кидаем - дольше задержка, меньше кидаем объем payload - меньше латентность (размер буффера разный для 64 байт и для 2 килобайт). Чтобы прокинуть 4 канала ненужно много информации и это там на уровне 0,2ms для одного пакета данных. Никаких там 16-20 ms нет. Поэтому и ощущается разница по шнуру и воздуху. А дальше решает либо депакер (драйвер) софт или хард или какие-то свои методы упаковки / оптимизации. Если всё хранится в Neo, часть данных можно кидать контрольными битами в одном int, а не упакованные integer / float. Грубо говоря в В бар мне нужено перекинуть 1 byte оффсет по кривой с разрешением 0…255, а сама кривая сидит в Neo в виде float значений. То. мне не нужно кидать по радио каналу 4 байта float. Или же паковать его, потом там распаковывать. За счёт этого и достигается скорость.
Давно уже платится за софт.