TOPMO3

Min/Max накладываются на исходные значения АЦП. В исходном виде, когда еще нет калибровки, мы видим например, что максимальный сигнал датчик гуляет например около 3500, мы ставим соответственно Max Calib в 3500 и после сохранения ожидаем увидеть, что теперь ось уже будет добивать до своего максимума в 4095. Если немного не добивает, то можем немного скорректировать предел в 3450 например и т.д. ) Аналогично подбирается нижний предел. Т.е. цель - добиться, чтобы на механический ход педали (или еще чего-то) ось выдавала полный диапазон от 0 до 4095 с нужными нам мертвыми зонами при необходимости Пока никак не работает, это же фотошоп у меня )) Но здесь я особо сложностей не вижу. В ГУИ я могу все значения оси пропорционально укладывать между ползунками, так же как они сейчас укладываются в целый прогресс-бар Кстати, не обязательно ведь ориентироваться на пиксели ) На цифру значения оси лучше - если есть 4095, то в игре соответственно 100% будет гарантировано

Да, в том то и дело, что RAW нет, это и есть проблема для п.3 ) Так сделано специально, чтобы не нужно было калибровать каждый раз в случае другой винды - калибровка хранится в самом контроллере. И это отлично работает, но при калибровке нужно понимать, что происходит. А я пытаюсь сейчас сделать, чтобы это было понятно любому, кто первый раз на это все смотрит ) Точно )

Нет, это не так работает ) АЦП выдает значения от 0 до 4096. Допустим мы откалибровали ось от 333 до 777 - контроллер будет "растягивать" (масштабировать) значения от 333 до 777 в интервал от 0 до 4096 и выдавать это как значение оси Т .е. навежно как откалибровано, винда всегда видит 4К дискретных значений оси от 0 до 4096

Там текущее значение оси. Но диапазон оси всегда от 0 до 4096. А значения калибровки - на ось сенсора (т.е. на исходные значения от АЦП)

@JohnDoe, ползунки хороши для визуализации близости значения калибровки к уровню оси. Без них пришлось бы понемногу уменьшать значения калибровки, постепенно "подползая" к уровню оси. Цифра значения оси в середине шкалы актуальна только в отсутствие калибровки, потом на нее уже нельзя ориентироваться

Согласен, это аргумент. Что думаешь по поводу 3го варианта?

Выскажите плиз мнения по пользовательскому интерфейсу, как лучше сделать? Проблема: Не интуитивно понятен процесс калибровки осей. Например, вот первоначальный сигнал с датчика: Тут пока все понятно. Сигнал полностью ось не заполняет, поэтому нужно калибровать. Пользователь выставляет ползунки: И после сохранения уровень оси уже показывает полную шкалу. Вот этот момент сбивает с толку - что произошло, почему вдруг сигнал усилился? Т.е. это подсознательно воспринимается как сигнал датчика, а не уровень оси. Дальше пользователь начинает снова двигать ползунки и все совсем запутывается. Какие варианты решений тут видятся: 1. После калибровки уводить ползунки на края оси, чтобы визуально уровень оси всегда был между ползунками, а значения калибровки остаются только в полях ввода, пример: из минусов, как я вижу, то что оять будет сбивать с толку - вроде только что двигал ползунки, и вдруг они снова по краям. Плюс нет никакой связи со значениями в полях ввода 2. Показывать ось только между ползунками калибровки: из минусов - при узком диапазоне калибровки плохо видно уровень оси, непроизвольно может казаться, что ось дает мало дискретных значений 3. Сделать отдельно уровень датчика и уровень оси. Калибровка тогда будет происходить всегда над уровнем датчика, а результат можно увидеть на уровне оси: минусы - утяжеляет интерфейс, мне более геморно реализовывать )) Уровень датчика сейчас на ПК никак не отсылается, придется это делать как-то дополнительно.. Что думаете, какой вариант лучший? может какие другие идеи у кого есть?

70мм самый распространённый и у него другое расположение болтов, чем у 74мм

@morganchik, у меня только один вопрос - куда слать деньги??? ))

Да ну, имхо он фигню там написал. И видимо сам это понял и статью из свободного доступа убрал Только через датчик давления реализовать управление нельзя. Даже если добавлять его в помощь энкодеру, все равно совершенно непонятно чем он поможет в реализации ффб

да, есть т.н. pulse switch, например вот. Подключать их можно вместо обычных кнопок, нажатие фиксируется только на момент смены положения. ардуины удобнее тем, что если есть элементарные навыки программирования, то можно крутить под себя как угодно

не тратьте зря деньги ) потом будете думать как Антон, какой бы пакли туда намотать, чтобы не люфтило )

Кто-нибудь должен сказать этому парню, что эти цифры в ире никогда не значили проценты )) Это некие попугаи силы ФФБ, которые для обычных рулей все ставят в пределах 15 - 30. У меня на Г27 емнис 24 было. Во-вторых, для ДД рулей у ира есть специальный "Нм"-режим, когда сила выставляется напрямую в Нм, а не в попугаях. В этом случае можно просто явно рассчитать сколько Нм нужно, столько и будет выдавать руль в максимуме. В конце ролика в минусах указано, что каждый раз нужно центрировать )) В общем, не обзор, а полный BS. Тотальное незнание матчасти ))

Переходник - это не проблема, проблема в том, что на не родных баранках без USB хаба или этого эмулятора не будет ФФБ в принципе. У фанатека так сделано, что база должна снюхаться с баранкой и если не обнаруживает ее, то ФФБ нет

Есть некие зародыши такого, например вот - https://www.simracingmachines.com/WebShop/fanatec-csw-base-wheel-emulator Но поддержки кнопок у него пока нет

Вот все скидки на текущую ЧП https://simxperience.com/News/tabid/94/post/simxperience-fourth-annual-black-friday-promotion/language/en-US/Default.aspx

@stanima вот блин, кругом обман )

В прошлом году в ЧП была версия с МОМО, так что м.б. стоит подождать

Можно и самому перетянуть, на ютубе полно гайдов )

С другой стороны, если в силу специфики механической конструкции получается с аналогового датчика взять не полный диапазон, а только какую-то малую часть, то высокобитный ацп здесь позволит тоже иметь достаточное кол-во дискретных значений. Но сигнал скорее всего будет шумный ) Ну ещё для маркетинговых целей тоже чем больше, тем лучше ))

Рома, я для себя другой тест проводил - на логитековских медалях (у них 255 дискретных значений) пытался найти минимальный интервал, который получается дозировать ногой ) и я не мог дозировать с шагом единица, минимум 2 получалось. )) после этого я для себя закрыл вопрос с необходимой точностью АЦП )

У меня другой вопрос )) нужен ли g-sync, если карточка держит частоту монитора без просадок? )

Почему же не пересекается? ) у меня допустим, миге с 20нм в пике, соответственно я ставлю в драйвере 100%, а в ире 20нм. Это значит, что когда ир по своей физике расчитает например 5нм момента на колонке, то движок у меня выдаст именно 5нм. Что может быть реальнее? )) есть только один нюанс, о котором часто забывают - диаметр баранки тоже должен соответствовать реальному. Если у вас стоит 27см, а в реальности например 32, то естественно будет тяжелее, чем реальным пилотам ) А есть спеки их движков? Я не слежу особо последнее время

А в чем проблема именно аутраннера? Здравствуйте, меня зовут Дмитрий и я использую 100℅ ффб на миге. Первый раз я попробовал это из любопытства и с тех пор уже не могу без этого )) Не вижу проблем юзать дд на полную катушку )

И причём тут цена? Речь исключительно про прочность конструкции была