Про енкодер

[Хартиков Сергей]

     О, тут всплыла моя любимая тема! Денис, я, как известно участникам Астрофестов, несколько лет занимался использованием оптомеханических и оптических мышей в электронном позиционировании телескопа. Соответственно, провел массу экспериментов с мышами вне телескопа (аналогичные тем, о которых писали в этой теме) и в самом телескопе.
     Оптомеханические мыши, действительно, точны, но непонятно как простым образом решить проблему передачи вращения с осей телескопа на ось датчика: дело в том, что один оборот такого энкодера соответствует примерно150-200 (в разных мышах) отсчетам, а для полноценной работы телескопа требуется не менее нескольких тысяч отсчетов на оборот. Получается большой коэффициент передачи и неизбежный люфт или проскальзывания. Также реализовал и предложенный Вами способ позиционирования с периодической коррекцией вручную: использовал колесики скроллинга для такой коррекции, когда набегала большая ошибка (кстати, в результате было пользоваться довольно удобно!). Я, наконец, дожался, что еще один любитель повторил мою конструкцию: Леонид Филатов находится на этапе завершения аналогичного устройства на основе моих программ.
     Чисто оптические мыши, действительно, имеют неизвестный алгоритм обработки изображения, что приводит к накоплению случайной ошибки после нескольких достаточно больших поворотов трубы телескопа: поверьте, я провел много экспериментов, по разному выставляя мыши и меняя расстояние до рабочей поверхности. Причина хорошо описана Александром Л.
     Учитывая все это, а также свою неудовлетворенность достигнутым, я к прошлому Астрофесту изготовил вариант устройства не на мышах, а на двух web-камерах. Вот там-то не надо ломать голову над неизвестными алгоритмами: изображение непосредственно считывается с web-камер и декодируется своей собственной программой. Конечно, пришлось разрабатывать простой и надежный способ обработки, но результат оправдал ожидания: определение угла поворота стало абсолютным, случайная ошибка не накапливается.
     Если у Вас есть интерес, с радостью поделюсь опытом и программами.

[Денис Никитин]

Сергей! Как же...наслышан, очень рад встрече.

дело в том, что один оборот такого энкодера соответствует примерно150-200 (в разных мышах) отсчетам, а для полноценной работы телескопа требуется не менее нескольких тысяч отсчетов на оборот. Получается большой коэффициент передачи и неизбежный люфт или проскальзывания.

Единственное до чего я додумался в свое врямя - это ременная передача (шкивы пасик от магнитофона). Работала весьма неплохо. Люфта не было, а вот небольшие проскальзывания это да.

    Чисто оптические мыши, действительно, имеют неизвестный алгоритм обработки изображения, что приводит к накоплению случайной ошибки после нескольких достаточно больших поворотов трубы телескопа: поверьте, я провел много экспериментов, по разному выставляя мыши и меняя расстояние до рабочей поверхности. Причина хорошо описана Александром Л.

Да я Вам верю, верю. Собственно дело вот в чем, у меня готова электроника на однокристалке, но датчиков пока нет. Я бы конечно мог использовать оптомех. мыши, как в старые добрые времена, но хочется чего-то более свежего. Это свежее находится вот тут www.usdigital.com Только проблема заключается в том, что нормальный инкрементный энкодер с 2500 cpr (отсчетов на оборот, такой энкодер при 4Х декодировании дает 10000 отсчетов на оборот, более чем достаточно) стоит порядка $50. Это довольно дорого, я считаю, хотя в случае чего я их конечно куплю. Поиск бэушных отечественных энкодеров к успеху не привел. Поэтому я хочу найти альтернативу.

Сергей, документировали ли Вы свои эксперименты с оптическими мышами? Есть ли графики, конкретные цифры? Если есть, будьте добры поделиться, если не трудно конечно. Прежде всего интересует информация о накапливающейся ошибке, которую так хорошо и подробно описАл уважаемый Александр. Прежде чем писать этот пост подумал вот о чем - хорошо, ошибка накапливается, чем больше перемещение, тем больше ошибка. А что если сделать - жеско посадить на ось телескопа диск прерывателя от обычной оптомеханической мышки (это дас 100-200 отсчетов на оборот). А в промежутках между отсчетами оптомеханической мыши делать отсчеты с большим разрешением оптической мышью и каждый раз с нуля. То есть, чисто интуитивно на этих коротких промежутках значительная ошибка накопиться не успеет.

Не уверен, что я понятно изложил, но все же, как вам идейка?

 

[Хартиков Сергей]

     Документировать там было нечего, так как ошибка возникала непредсказуемо для меня. Например, иногда мне казалось, что все работает хорошо - даже при нескольких поворотах в разные стороны энекодер возвращался в ноль с высокой точностью. А в очередной поворот оси вдруг где-то по пути происходил сбой - возврата в ноль не происходило. Причем, никакой связи с углами поворота обнаружить я не смог: при больших углах ошибка могла быть меньше, чем при маленьких. В уме я все "списал" на алгоритм декодирования и пришел к выводу, что разработчики мышей вряд ли преследовали такую цель, как точность возврата в исходное положение.
     Такая же мысль, как и у Вас по поводу совместного применения оптомеханической и оптической мышей, возникала и у меня. От этого пути я отказался по следующим причинам:
     1.Хотя количество отсчетов на оборот мышь считает очень точно, но совершенно не очевидно, что момент начала очередного отсчета происходит всегда строго при определенном положении - там тоже может оказаться своеобразный "люфт" - тогда все усилия пойдут насмарку. Правда, ошибка накапливаться не будет, но точность нельзя будет улучшить.
     2.Лично я не совсем представляю, как насадить ось энкодера на ось телескопа (я не силен в механизмах).

     Что касается стоимости, то web-камеры стоят почти столько же, сколько и оптические мыши. После того, как я решил проблему довольно простого определения абсолютных координат, появилось и дополнительное преимущество: даже после отключения питания и повторного запуска программы координаты не меняются.
     Поясните подробнее, что за однокристальный контроллер у Вас? Там что, будут проблемы с подключением web-камер? Конечно, есть небольшой минус и у web-камер, но меня он не напрягает: при быстрых поворотах картинка на видео-датчике смазывается, и координата временно теряется. При обнаружении такого смазывания программа автоматически блокирует изменение координат, пока не появится четкость.

[Хартиков Сергей]

     Этим летом меня пригласил в гости старый школьный друг. Он сейчас работает директором инженерной фирмы, которая в частности поставляет и промышленные энкодеры фирмы Kluber. Я побеседовал с его сотрудниками, мне показали каталоги. Слюнки у меня потекли, когда я увидел абсолютный энкодер с 50 тысячами отсчетов на оборот! А вот стоимость - оставляет желать лучшего: 500 баксов за штуку. Нет, уж лучше я web-камерами обойдусь!

[Денис Никитин]

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

Сергей, я ничего не понял, каким образом у Вас вращение передавалось от телескопа на мышь?

Лично я не совсем представляю, как насадить ось энкодера на ось телескопа (я не силен в механизмах).

На экваториал не знаю, но наверняка можно придумать. На добсон спокойно, просверлить дырку и вклеить. Для добсона все и задумывается.

Поясните подробнее, что за однокристальный контроллер у Вас? Там что, будут проблемы с подключением web-камер?

Однокристальный контроллер PIC16F84, с подключением веб-камеры проблем нет никаких, их туда вообще нельзя подключить. Ни единого шанса. Опишу подробней: контроллер PIC16F84 принимает квадратурные импульсы от двух инкрементных энкодеров и осуществляет 4-х кратное декодирование. Отсчеты буферизуются в двух 16-разрядных накопительных регистрах. Из накопительных регистров данные по запросу передаются по 8-разрядной параллельной шине на другой контроллер. Другой контроллер это PIC18F452, осуществляет непрерывное преобразование азимутальных координат в экваториальные, используя алгоритм Тошими Таки (привязка по двум или трем опорным звездам, с коррекцией Z1 Z2 Z3). Так же осуществляется ввод данных с клавиатуры, отображение данных на двухстрочном алфавитно-цифровом LCD дисплее. Имеется внешняя память EEPROM 24xx256, где хранится небольшая база данных небесных объектов. В ближайшее время база данных будет перенесена в MMC и станет практически бездонной.

Конечно, есть небольшой минус и у web-камер, но меня он не напрягает: при быстрых поворотах картинка на видео-датчике смазывается, и координата временно теряется.

Какая именно информация считывается веб-камерами. Какая-то шкала с рисками? Цифрами? Или нечто другое?

[Денис Никитин]

Есть данные по чешскому мегапроекту. На их сайте нашел pdf с секретными сведениями на чешском языке. Чешский язык конечно атасный, но это не проблема. Между прочим это единственный раз в жизни, когда мне пригодилось, что я по национальности чех.

Екселячая табличка ниже, перевод с чешского:

Smer - направление (по и против часовой стрелки)
Stav - значение счетчика
Imp - колво имульсов на оборот
Diff - разница
Снyba[%] - ошибка в процентах
Prumer - среднее значение
Pr.chuba[%] - средняя ошибка

Итак было сделано 8 оборотов телескопа на 360 град туда-сюда без обнуления счетчика. Мышь бегала над белой бумагой. На каждый оборот выходило в среднем 17741 импульс, средняя ошибка на оборот составляла 0,27%, полная накопившаяся ошибка после 8 оборотов составила 1,13%.

Там еще одна табличка есть, при тех же условиях мышь бегала над бумагой в крапинку. На каждый оборот выходило в среднем 17766 импульс, средняя ошибка на оборот составляла 0,18%, полная накопившаяся ошибка после 8 оборотов составила 0,7%.

Я вчера повторил то, что сделали чехи, а именно я не считывал данные из регистров "мышиной микросхемы", а припаялся непосредственно к ёё выходам XA XB YA YB, и подавал квадратурную последовательность сразу на мой контроллер. И тестировал на реальной монтировке добсона. Результат следующий, я получил ошибку в среднем 0,65% на оборот. Повторяемость отличная. Хотя я все сделал на скорую руку, в ближайшее время все сделаю более тщательно подберу зазор между мышью и поверхностью и результат должен улучшиться.

Еще одно замечание, считывать данные с мыши через интерфей PS/2 неправильно, не известно как работает драйвер, на сколько регулярно он опрашивает мышь не известно. Возможно он пропускает отсчеты. Нужно делать так как описано выше.

Вывод, оптическая мышь очень хороший датчик угла поворота для телескопа. Если ёё еще и синхронизировать оптическим энкодером, как я описАл недавно, это будет вообще идеальный энкодер. Шутка ли 17 тыс отсчетов на оборот.
 

[Хартиков Сергей]

     Привет, Денис! В моей конструкции вращение от оси телескопа передавалось на мышь посредством обрезиненного шкива магнитофона (он сделан из дюрали, а снаружи - резиновый обод). Здесь я имел ввиду не способ передачи вращения, а сам механизм работы мышиного энкодера: в каком положении колесика энкодера появляется импульс - этот момент может иметь нечеткое положение.
     Про крепление на Добсоне - я понял: действительно, меньше проблем, чем с экваториальной монтировкой. Про считывание данных через интерфейс PS/2. Я считываю данные через COM, но это не важно: я не использую никакой драйвер - в моей программе имеется собственная процедура обработки прерываний, так что ни одного отсчета не пропускается. Для оптических мышей - данные считываются по USB - опять же применяется собственная программа обслуживания USB - ни одного отсчета не пропускается.
     Про ошибку энкодеров.  У меня получалась ошибка такого же порядка, как приведена. Но 1 процент означает отклонение в 1 градус на оборот - слишком много. Во время домашнего тестирования мне казалось, что при поворотах на 60-90 градусов все будет хорошо. Но когда я выносил телескоп на улицу, то происходило следующее: после привязки по опорным звездам - то все работало отлично, то вдруг проявлялись сильные отклонения (напомню, что никакого пропуска отсчетов не было). Даже возврат к опорным звездам не всегда происходил корректно. Совместное использование  опто-механического и оптического энкодера должно решить ситуацию (если с моментом срабатывания механического энкодера все в порядке).
     Про web-камеры. Теперь я понял, о какой однокристалке Вы говорите: действительно, использование web-камер требует довольно сложой обработки изображения, которую у Вас не осуществить. Когда-то я тоже занимался микроконтроллерами, а теперь у меня нет уже никакой элементной базы и аппаратуры для программирования - в противном случае, я бы с радостью занимался этим, и возможно сделал бы аналогичную конструкцию Если бы я приобретал все указанные Вами микросхемы и аппаратуру для программирования - вышло бы значительно дороже web-камер.
     Теперь поясню, что на лимб оси телескопа наклеена распечатанная на лазерном принтере бумажная полоска со штрихами двух типов: равномерные толстые штрихи, а между ними тонкие штрихи в двоичном коде. Web-камера фотографирует участок ленты, на котором всегда видны 3 толстых штриха, а значит имеется 2 участка с двоичным кодом. Я декодирую один из этих участков, определяя номер "окошка", умножаю его на размер "окошка" и добавляю смещение относительно кадра - получается абсолютное значение угла поворота (на самом деле, принтер печатает неравномерно, поэтому еще используется коррекция нелинейности - она определяется из экспериментов).

[Хартиков Сергей]

     Да, Денис, я вспомнил, что в ноябре 2000 года, перед созданием самого первого варианта своей конструкции, я провел следующий эксперимент, который запротоколирован. Собственно, он и является основой моих слов о нечетком моменте срабатывания механического энкодера. Вы видели, что рабочим элементом энкодера является пластиковое колесико с прорезями. Так вот, вряд ли прорези строго равномерны. Даже невооруженным глазом видны заусенцы. Кроме того, от нас скрыта схема, которая "принмает решение" в какой момент выдать очередной импульс - может оказаться, что этот момент "плавает" относительно физического положения прорези.
     Я не насаживал колесико энкодера жестко на ось телескопа. Я снял маховик тонких движений, установленный на часовой оси. Вместо него я при помощи винта установил резиновое колесико от кассетного магнитофона (прижимной ролик). Затем я при помощи конструктора укрепил мышиный энкодер так, чтобы его колесико было прижато к этому прижимному ролику. Потом я включил часовой привод. Специально написанная мною программа протоколировала моменты очередных отсчетов в сотых долях секунды.
     К этому сообщению я прикрепил 3 файла в формате TXT. В них левая колонка - это условные отсчеты энкодера - они уменьшаются от значения 2000 и ниже. Правая колонка - значение момента времени от начала измерения в сотых долях секунды. Обратите внимание на дикую неравномерность - как сильно меняется разница между очередными отсчетами! Конечно, в среднем все хорошо. Но для параллельного использования механического и оптического энкодеров придется использовать еще и коррекцию нелинейности. Я имею ввиду, что надо будет определить некоторое "нулевое" положение трубы, а затем наводиться на разные звезды и таким опытным путем составить формулу нелинейности энкодера, жестко привязанную к конструкции колесика механического энкодера.
     Конечно, в этом эксперименте у меня была не идеальная конструкция. Но такую сильную неравномерность нельзя объяснить неравномерностью хода часового двигателя и возможными проскальзываниями. Еще раз замечу, что эта неравномерность сильно сглаживается, если усреднять по 10 отсчетов - то есть общее значение немного "прыгает", но работать можно. А вот в конструкции, где механический энкодер будет базой для оптического - там могут быть большие проблемы.

[Денис Никитин]

Привет, Сергей. Спасибо за подробности о работе ваших вебкамер.

Я считываю данные через COM, но это не важно: я не использую никакой драйвер - в моей программе имеется собственная процедура обработки прерываний, так что ни одного отсчета не пропускается. Для оптических мышей - данные считываются по USB - опять же применяется собственная программа обслуживания USB.

Сергей. Так не бывает. Виндовоз работает с устройствами только посредством драйверов. Драйвер вызывает события, которые обрабатываются стандартными APIшными функциями. Так что вы можете и не догадываться, пропускаются у Вас отсчеты или нет.

Хотелось бы спросить, в какой среде работает программа, которая протоколировала отсчеты энкодера с десятимилисекундной точностью? DOS? Windows? В DOS реально делать остчеты с точностью 10 милисек. Для этого нужно записать в 16-разрядный регистр микросхемы таймера 8253 число 11931. Системные часы компьютера идут с частотой 1,19318 MГц, тогда 1193180/11931 = 100,006 Гц То есть практически точно 1 сотая секунды. Другого пути нет.

Если же программа работает в виндозе, то каким образом можно измерять время с точностью 10 милисек, я понимать отказываюсь категорически. APIшный таймер если его заставить отсчитывать 10 милисек имеет серьёзную ошибку (может плюс минус 5 милисек). Вот вам и нелинейность. Плюс добавить еще другие возможные источники погрешностей...и да я согласен, энкодер в мыши выполнен не с прецизионной точностью.

[Денис Никитин]

Сергей, еще ответьте пожалуйста, скалько отсчетов на оборот делае ваше устройство на вебкамерах?

[Хартиков Сергей]

     Извините, Денис! Я думал, что все уже знают , что я пишу программы исключительно для DOS (в смысле той DOS7.0, которая запускается до запуска оболочки Windows98). В любом случае я создаю системную дискету (или CD), с которой можно "раскрутиться" без запуска оболочки Windows на любом компьютере.
     Как раз невозможность полностью контролировать ситуацию в Windows в реальном времени и является для меня поводом работы в DOS. К тому же, это позволяет создавать своеобразные контроллеры из низкоскоростных компьютеров.
     В моих программах обработчик прерывания (и COM-портов и USB-портов) "вешается" непосредственно на эти аппаратные прерывания, поэтому, совершенно точно, пропуска отсчетов не происходит (этим DOS и хороша, что я могу полностью отказаться от ее услуг при обслуживании прерываний!). Эти процедуры обслуживания прерываний (и DOS и USB) написаны мною "с нуля", поэтому я полностью контролирую ситуацию (тут нет Windows со своими API ).
     И программа протоколирования тоже работала в DOS. Как Вы правильно заметили, она использовала системные часы компьютера, которые "висят" на соответствующем аппаратном прерывании - они работают с кварцевой точностью. Их единица измерения и составляет 1 сотую секунды. Причем, даже если считывание показаний часов будет происходить не совсем точно, то это не окажет влияния на результат, так как измеряется не промежуток времени между отсчетами энкодера, а общее время, прошедшее с начала отсчетов - а оно с этими отсчетами никак не связано. В общем, погрешности в часах нет!
     Насчет web-камер: на один оборот моя система выдает около 6500 отсчетов. Это зависело от диаметра диска лимба, на который я наклеил штриховую полоску, а также от того насколько близко можно было расположить объектив web-камеры к поверхности, чтобы при этом еще обеспечить нормальную подсветку поверхности.
     В качестве контроллера у меня используется простой Pentium с частотой всего 150 мегаГерц. На нем моя программа успевает декодировать 15 кадров в секунду, что соответствует 7,5 кадров в секунду в расчете на каждую из двух web-камер - вполне достаточно для наведения. основные потери времени при декодировании - это декодирование JPEG-формата в растровый формат.

[Денис Никитин]

     Извините, Денис! Я думал, что все уже знают , что я пишу программы исключительно для DOS (в смысле той DOS7.0, которая запускается до запуска оболочки Windows98).

     
Привет, Сергей. Всё понятно, но откуда ж мне знать было, что Вы пишете под DOS.

Вскрыл уже три оптические мыши, обнаружил, что повсеместно используется несколько иная микросхема (не ADNS 2051, ссылку на которую привел Александр), а HDNS 2000, то же фирма Agilent. Обе микросхемы похожи, но некоторые отличия все же есть. У этих микросхем есть квадратурные выходы (ножки 2-5) и последовательный интерфейс для доступа к регистрам. Для чего это было сделано, согласно фирме Agilen, квадратурные выходы нужны, для того, что бы облегчить жизнь разработчикам мышей, а именно, микросхема HDNS 2000 может подключаться к существующим контроллерам опто-механических мышей, вместо оптопрерывателей. Во всех трех мышах именно так и сделано. Мыши Genius, Logitech и еще одна (название стерто), все мыши made in China.

Обнаружил две неприятные вещи:

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

2.   Светодиод, когда мышь простаивает, моргает. Он включается примерно на 1 мсек каждые 7 мсек (так видно на осциллографе), в руководстве на микросхему же написано, что но включается на 2/3 мсек каждые 8 мсек. Попробую завести его непосредственно на питание, чтоб горел постоянно.

Просьба: Паша Бахтинов, если у тебя найдется свободное время, не откажи, посмотри пожалуйста, чего там за помехи. Щуп надо поставить на одну из ног микросхемы (2-5) и подвигать мышью, что бы поймать низкий уровень. Посмотри на что это похоже, у тебя все же опыта вагон, а я не догоняю что за дела. Я не настаиваю, только если у тебя есть свободное время.

[Александр Л.]

      Светодиод, когда мышь простаивает, моргает. Он включается примерно на 1 мсек каждые 7 мсек (так видно на осциллографе), в руководстве на микросхему же написано, что но включается на 2/3 мсек каждые 8 мсек. Попробую завести его непосредственно на питание, чтоб горел постоянно.

      Денис, описание на ADNS2051 читал давно, но по памяти ситуация там такова. Существует как возможность настройки выдержки, так и возможность настройки яркости подсветки, т.е. тока через этот самый светодиод. Дома у меня две логитечевские мышки, ведет подсветка себя точно как Вы описали, только по всей видимости Вы перепутали милисекунды с микросекундами. Происходит по всей видимости вот, что. Когда мышка не передвигается, контроллер не в состоянии обнаружить перемещение и начинает менять яркость подсветки, на тот случай, если резко изменилась яркость фона. Попробуйте непрерывно двигать мышь и Вы увидите, что светодиод моргать перестал, т.е. найдена оптиамльная освещенность и к ней подобрана выдержка. Поэтому светодиод на питание лучше не паять.

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

 

[Денис Никитин]

Александр, Вы меня обижаете. Я именно так и смотрю. Земля осциллографа на землю микросхемы, сигнал снимаю с выхода микросхемы. В единицах измерения времени тоже ошибок нет, все как я написал. У микросхемы выход двухтактный, при отрицательном уровне выход закорачивается на землю, то есть я должен наблюдать на выходе потенциал земли. Вот я его и наблюдаю, но он каждые 8 миллисекунд подпрыгивает  иногда до 3 вольт, и длится эта помеха, примерно 4 мили сек. Выглядит она не просто как повышение уровня, а скорее как многочисленные очень быстрые переходы от уровня земли до 2-3 вольт и обратно. Подробно я рассмотреть не могу, у осциллографа очень маленькая полоса пропускания. Я склоняюсь к тому, что это PS/2 порт так шумит.

Как я уже писал в предыдущем сообщении, там другая микросхема - не ADNS 2051, а HDNS 2000. У нее нет такого сложного алгоритма работы со светодиодом. Согласно руководству, когда мышь движется, светодиод горит постоянно. Когда мышь простаивает, светодиод работает циклически с периодом 8 миллисекунд, при этом он загорается на 2/3 миллисекунды, потом остальное время 7 1/3 миллисекунды он не горит. Визуально это выглядит, как будто он очень тускло горит.

[Хартиков Сергей]

     Денис! Я, конечно, не знаю схемотехнику мышей, но рискну предположить происхождение и интервал импульсов на светодиоде. Когда я разбирался со спецификацией шины USB, то наткнулся и на то, что мышь требует обязательного опроса каждые 8 мс. Так как многие мыши могут работать и с протоколом USB и с протоколом PS/2, то можно предполагать, что это некоторый стандартный цикл работы микросхемы мыши.

[Денис Никитин]

Сергей, опрос мыши происходит каждые 8 мс, а не подскажите сколько времени длится опрос мыши?

[Хартиков Сергей]

     Денис, я естественно, могу отвечать только за мышь, работающую по протоколу USB. Мыши относятся к устройствам low-speed, которые описаны в спецификации 1.1. Протокол USB 1.1 делит время шины на кадры по 1 миллисекунд каждый. Общее количество байт, которые могут быть вообще переданы по шине в течение одного кадра составляет около 1500 байт. Если во время очередного опроса мышь передает данные, то - это 4 байта данных плюс адресная часть пакета USB (еще несколько байт). Во время "пустого" запроса, когда данные не передаются, речь идет только об адресной части запроса с ответом "не подтверждено".
     Таким образом, длительность опроса не более десятка байт из 1500 байт каждую миллисекунду, то есть 1мс * 10 / 1500 - это несколько микросекунд, во время которых микросхема мыши вынуждена либо передать несколько байт на шину USB, либо хотя бы сгенерировать пакет отказа "NAK". Частота шины - 12 мегагерц.

[Павел Бахтинов]

Просьба: Паша Бахтинов, если у тебя найдется свободное время, не откажи, посмотри пожалуйста, чего там за помехи.

Денис, выяснилось, что в моей мышке стоит датчик ADNS-2610 (8-выводный), квадратурных выходов у него вообще нет, смотреть, увы, не на что (но земля и все уровни "чистые", только питание слегка "просаживается" при мигании светодиода).

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

[Александр Л.]

Открыл мышку логитеч и нашел там вот такую микросхему -  http://www.pixart.com.tw/productdetail.asp?num=35   .  Видимо делать их стали немало.

[Tseh_Valery]

Я как-то здесь содавал подобную тему, но чего-то она не нашла интереса.
У меня такие энкодеры:
Колёсики с оптопарами выдернул из обычной мыши. На колёсах 50 спиц - получается 200 импульсов на оборот. Всё это собрал в отдельных коробочках с осями на подшипниках, добавил пару эмитерных повторителей для улучшения формы сигналов и подключил к PIC микроконтроллеру. Он в свою очередь
опрашивает энкодеры, и передаёт координаты по СОМ порту протоколом lx200 в планетарий, который
поддерживает такой протокол (я пользуюсь Cartes du Ciel). Также из планитария можно передать координаты в микроконтроллер для начальной установки или привязки к нужной звезде. В нём ещё реализованы часы звёздного времени для модификации координаты RA.
  Сами энкодеры я прикрутил к червякам. передача у меня 1:345, так что "цена деления" получается
вполне достаточная.
О тестировании. На монтировке пока не испытывал, потому как ещё достраиваю. А так крутил оборотов 100
в одну сторону, потом столько же назад. Энкодер с достаточной точностью возвращается в ноль.