Мышка называется W-Mouse и WX-Mouse





Программа тестирования нажатий кнопок мыши (проверка двойного клика) MBTester V2.0 описание внутри

Больше трех (существенно больше) приводит к тому, что мышь надо доводить, часть движения теряется. Надо посмотреть, как устроен фильтр, может быть надо учитывать дпи.

интересно не существенно больше а чуть чуть например от 4 до 8

Walkie писал "Установка значений от 0 до 4 - это фиксированная TAU = 4мс." видимо в этом все дело. 4 до 8 я практически не замечаю разницы, немного хуже чем 0-4.

kemsky в 5-8 значения с шагом в 1

Фильтр устроен просто - это ФНЧ первого порядка. С тау 3 мс он лишь чуть-чуть приглаживает поток смещений, поступающий от сенсора.
Общее смещение не теряется с любыми тау. Просто оно запаздывает во времени примерно на тау. Если представить, что скорость мыши с нуля изменилась скачком до V, затем была постоянной V и скачком упала до 0, то такой сигнал, пропущенный через фильтр, выглядит так :
старт - это обратно-экспоненциальное нарастание от 0 до V за время, можно считать, 3*тау (достигается 95% V).
стоп - спад V по экспоненте за 3*тау.
Поскольку движение квантуется довольно грубо (это скачки "курсора" по целым частям приращений, а дробную часть, как движение, глаз не видит, её "видит" только контроллер мышки), то при установленной низкой чувствительности может создаваться впечатление, что последние сдвиги не передаются. То есть, они-то передаются, но уже со значительной задержкой. Мышь резко остановили, курсор по экрану затормозился вначале явно по экспоненте, а в конце, аж через 10*тау ещё и на пикселок сместился (спадающая дробная часть наконец-таки накопилась в целый сдвиг). И не факт, что через 100*тау не сместится ещё . Впрочем, не сместится, потому что в Wxx через 200 мс начинает действовать арретирующий механизм, который сбрасывает всё в ноль - уж лучше этот пиксел недодать, чем устраивать сдвиговые подлянки через секунду.
Поэтому при низких CPI (например, 400) и больших перемещениях смысла в фильтре почти нет. Весь шум движения и так тонет в люфте квантования.
А вот при высоких CPI картина уже иная. Поставьте 3000-4000 cpi и медленными движениями при не очень-то стабильном трении попробуйте попадать в нужные точки экрана. Неприятно, не так ли? Однако, с тау, например, 50 мс эта задача начинает выполняться уже гораздо проще. Люфт квантования низкий, поэтому на первый план вываливается истинная неравномерность сдвигов. Но её гладит фильтр, и управляемость на низких скоростях улучшается, несмотря на некоторое несоответствие движений руки и курсора.

Walkie
А Вы не думали каким-либо образом использовать верхний контакт(nc terminal) микрика?

Например, для увеличения реакции кнопок на нажатие...

Нда, поставил 5.8, порадовался непонятной процессорной активности пару минут, вернул 5.4 обратно.

а совсем линейной зависимости нет? ведь exp0 имеет небольшой прогиб.

Добавлено спустя 37 минут 54 секунды:
Изменил шапку.
обновлены ссылки на программаторы и преобразователь оптики в механику.
косметическое обновление основной принципиальной схемы.

Walkie, на схеме не очень понятно, что делать или как применять таблицу соответствия 9500 и s9500.

Вобщем и так и сяк, лучше всего тау 0-4 и низкий дпи - самый послушный режим, хоть теория и против =).

Я полностью забыл цифровые фильтры, но фильтр по своей природе обрезает/сглаживает, часть информации будет утеряна. Вопрос в том, была ли она полезной. Сейчас настраивается только время - окно, но похоже сам фильтр должен быть другой(с другими параметрами) на высоких дпи, т.к. данные другие, разброс в абсолютном выражении другой, "шумит" сильнее, да и сенсор отдает другие данные(лишь предполагаю). В принципе, можно было бы снять реальные данные, и прокрутить в соотв. программе фильтры и посмотреть на различия в траектории. По ощущениям, на высоких дпи надо сильнее резать, но я бы проверил для начала. Радует, что 4мс вообще не ощущаются, значит вполне себе можно фильтровать.

Walkie, на какой строчке посмотреть реализацию этого фильтра в прошивке?

Васёк... тэк-с, давай-ка я выведу чисто чёрно-белые схемы. Возможно, в pdf. А то и со шрифтами неполадки, и пр.
Таблица соотвествия 9500 - обычная распиновка : ножка "эта" = "ножке той". Просто у датчиков S и неS количество ног - разные.
Зависимость EXP-0 практически линейна. Идеал там ни к чему.

kemsky, см. фрагменты VeloSmoothX, VeloSmoothY. Но в той конкретике, я думаю, будет крайне трудно разобраться.
Фильтр не оконный. Это "БИХ" - с обратной связью. Реальные данные всегда можно снять - есть рекордер, который пишет в файл практически любые, интересные для отладки, потоки в мышке.

retaliation, это нечто из ряда вон выходящее, и я хочу разобраться. Можно посмотреть именно те исходники V5.4, под которыми сейчас идёт твоя мышка?

а мне такие нравятся
очень удобно - сразу видно и связи и номиналы, кроме того при проверке когда все спаял удобно синенькие линии обводить ручкой проверяя каждую связь.
я пробовал чб, както кашеобразно смотрится.
имхо pdf не нужен, всеравно переводить потом в png или jpeg

Добавлено спустя 1 минуту 28 секунд:

я тоже с 4 играю. по ощущениям курсор более послушный в конечной точке.

Не вопрос, отправил в личку. Кстати, можете заодно посмотреть возможный баг со static'ом, про который упоминал чуть ранее тут? Просто часто пользуюсь ctrl+scroll, хотелось бы продублировать его на мышке, но ctrl&&static через некоторое время программно залипает. Спасибо.

Walkie, если поставить точку Smin/max в wcontrol, то будет 100% линейно ведь?

Нетуш-нетуш... Пусть будут чёрно-белые пэдээфы. Там всё красиво видно, а если припрёт, то всегда можно выделить нужный фрагмент в файл изображения.
1) Wmouses - варианты мышей.
2) V1183-1 - программатор на микросхеме AT90usb162.
3) V1183-2 - программатор на микросхеме ATmegaU4.
4) WH518 - варианты преобразователей кодера колеса на микросхемах ATtiny25,45,85 или 2313.
5) V1183-3 - подключение ATtiny к программатору V1183-1 для прошивания "колеса".

---
Lexx13th, да, режим Smin\max всегда держит чувствительность либо Smin, либо Smax. Для переключения этого дела нужным образом биндится какая-нибудь кнопка или поворот колёсика.

Добавлено спустя 10 часов 49 минут 24 секунды:
Если использовать этот контакт, можно сделать абсолютно бездребезговую кнопку с весьма симметричной реакцией "нажатие-отжатие". Однако, как правило, такие попытки пасуют перед ленью : и число проводников удваивается, и RS-триггер из чего-то надо делать.

Да, сходу не разбрешься, нужна формула БИХ фильтра (на что влияет тау), порядок, параметры, интересно также, как они были выбраны.
Эта программа whist или другая? Два года назад фильтры обсуждали, припоминаю, только wav файл неудобно вкручивать в матлаб, может есть какой-нибудь способ их перегнать?

Закрадывается подозрение, что автомат фреймрейта еще влияет, у меня w11, а для нее фрейм рейт минимум 2,7кгц должен быть (опытным путем установлено), я бы отключил для теста, если б знал точно где.

Фильтр. Я же говорю, фильтр - самый обычный ФНЧ 1-го порядка.
Напомню, его передаточная функция в операторном виде :
Y(p) = X(p)/(p*tau + 1).
А разностная схема, если преобразование к ней вести на основе интегрирования простыми трапециями :
Yi = ( Xi + Xi-1 + (k-1)*Yi-1 ) / (k+1), где к=2*tau/T, T - период дискретизации (опрос датчика за 1мс) (блин, не вижу тега, чтоб индексы i, i-1 в субшрифт засунуть) .
В моём случае вычисляется Vout(p) = m*Vin(p)/(p*tau + 1), m - коэффициент усиления фильтра (приведение разношёрстных датчиков к единству для дальнейших расчётов).
Поскольку датчик выдаёт не скорость, а приращения пути, формула переписывается :
Vout(p) = m*Sin(p)*p/(p*tau + 1), где Vin(p) = Sin(p)*p - производная пути. И в приведении к конечно-разностному будет :
Vi = ( 2*m*Si + (k-1)*Vi-1 ) / (k+1), где Si - текущий кусочек пути с датчика.
Вот эта параша и вычисляется в мышке. А далее Vi модулируется сенсой, разворачивается на угол инсталляции датчика, интегрируется в путь, а накапливающиеся целые отсчёты пути выплёвывается системе.
Но фильтр без флажка "static" действует, как шумодав. То бишь k (суть tau) изменяется в зависимости от модуля скорости. Линейно уменьшается от установленной ползунком tau при скорости 0 мм/с до tau=1 при скорости 25.6 мм/с. Грубо говоря, выше 25 мм/с фильтр становится не нужен и перестаёт сглаживать. А с флажком "static" tau сохраняется постоянной во всём диапазоне скоростей. При маленьких tau (до 10 мс) его и надо ставить.
---
Почему неудобно. В матлабе есть же фунции wavread, wavwrite.
Переключение фрейм-рейта см. в "mscan1.inc" (в частности, метки mw040f:, FrameSw:). Там существенно проще, и можно даже самостоятельно подкрутить. А о загадочном - спросишь.

спасибо - помаструбировал...


Walkie такой вопрос - в сенсорах adns60х0 скорость по разным осям была разная, т.е. приоритет был у оси Х, а как с этим делом у сенсоров 9500?
в том плане есть разница установлен он вдоль или поперек мышки т.е. на 90°?

да, это фреймрейт мылит, фильтр работает лучше на постоянном, чем на автомате.

Добавлено спустя 10 часов 32 минуты 22 секунды:
у автомата тоже есть свои плюсы. на низком фреймрейте мышь слабее реагирует на небольшие перемещения, как результат, ее не трясет, когда нажимаешь кнопку, например. Навелся, резко остановился и все, как вкопаная, но платить за это приходится тем, что нажатие без остановки будет неточным и непредсказуемым. Само переключение фреймрейта похоже вносит ошибку, может в это время датчик пропускает отсчеты или это результат фильтрования момента переключения. Я попробую менять границы автомата, посмотрим, что получится.

а когда будет точным и предсказуемым? мне очень важен именно этот момент т.к. из снайпы стреляю часто взмахом, т.е. без остановки на цели.

Не могу сказать, как это работает на 9500 датчике, может его мощи хватает. К своей я привык, много настроек перепробовал. Что интересно, очень точно даже на 300дпи, смысла использовать больше дпи практически нет. Не хочу нахваливать, но так пока ни одна мышь не может.

Фильтрует еще logitech g9, тоже сенсор 6ххх, ставлю 400дпи и рейт 250гц - работает точно, если есть возможность, можете сами попробовать. На старых прошивках она так не умела и я ее сразу в ящик положил, но видно довели со временем, неделю назад перезжал - достал попробовать.