Фух, осилил я всю ветку на Вегалабе... Застрелиться можно. Напомнило соревнование по забиванию гвоздей: кто-то забивал пассатижами, кто-то кирпичом, кто-то вообще бил доску с гвоздем об пол. В результате гвоздь забит, но процесс со стороны похож на что-то противоположное правильному... Ну это шутка, конечно. Просто, чтобы вычленить оттуда полезную информацию, видимо, придется взять от каждого понемногу. Самое печальное, что проследив весь путь авторов, я понял, что они не просто использовали разные алгоритмы, но и получили разные результаты. У Turbo_man получилось что-то более-менее осмысленное, но натянутое за уши разными коэффициентами коррекции ошибки на разных участках (и как мне кажется, этим компенсировалась кривизна графика СКО, и это пока самый точный результат, а главное реализованный в виде тестового железа), а DrLithium просто сложно понять, поскольку у него мысли опережают действия, и мыслит он глобально (что совсем неплохо, но мешает сконцентрироваться на простой задаче). DrLithium использовал отношение числа оборотов узлов, а Turbo_man - сумму. Затем TheCalligrapher предложил усреднение мгновенных значений с датчиков для того, чтобы не копить ошибку вносимую неидеальностью крыльчатки, проверил это с ардуиной, и тоже получил приемлемые результаты. DrLithium использовал в качестве меры счета кол-во тактов внешнего генератора, а не прямых импульсов с датчиков, увязал их с оборотами бобышек, и по отношению этих оборотов предложил создавать БД кривых, по которым можно максимально точно угадать кассету, и рассчитать время. Похожий алгоритм применил Rickw в теме про реинкарнацию Веги МП-122С, но только в режиме воспр, а в перемотках - СКО с корр.коэф-ми, и без БД кривых, "на лету". Леонид Иванович, к сожалению, к теме СРВ отнесся прохладно, просто неинтересно человеку уже кассетная тематика, но в его описании СРВ для Олимпа есть очень интересные и правильные вещи, которые можно использовать в кассетнике. но основная математика у него от обводного ролика, что совсем нам не подходит. Потом появился Bobby_ii и предложил свой кусочек алгоритма в виде квадратного уравнения. Вот последнее решение мне показалось сложным, но единственно обоснованным математически. Нет, предложений и формул там в ветке масса, но нет главного - функции, по которой может быть описана кривизна характеристики СКО. Коэффициентами это корректируется довольно близко, но это практический подход, который не учитывает что-то еще, из-за чего характеристика СКО кривая. В теме озвучили, как и предположил Vygandas, что причина кривизны - неравномерность натяжения и плотности намотки на разных участках. Возможно и так, но симметрия намекает на какую-то явную математическую зависимость. Те же графики Liv показывают, что на кассетах с меньшим кол-вом ленты парабола острее, а с чего бы? Неужели неравномерность натяжения и намотки там сильнее повлияло? Мне кажется вряд ли.
Какие из всего этого можно сделать выводы. Готового к повторению решения в виде схемы, п/п и прошивки на самом деле нет. Есть продолжающиеся эксперименты. Чтобы полностью проникнуться темой, скорее всего нужно опробовать все это лично. Для реализации СРВ в Вильме понадобится доработка обоих узлов, но по кол-ву секторов у каждого своё мнение. Кто-то использует 6/12/24, кто-то 5/10. Поскольку начинать все-равно придется с этого, то и с алгоритмом нужно определяться с привязкой к конкретной крыльчатке. В противном случае, свои результаты придется подгонять делителями. Хорошо, если это окажется всего лишь константой в коде =) Механический штатный счетчик Вильм можно поставить на низшую ступень эволюции, поскольку он тоже неравномерно ведет отсчет в начале и в конце кассеты из-за разных скоростей узлов. Поэтому даже вариант на PIC-контроллере из РХ будет лучше него. Но он работает по СКО, с корр.коэфф-м, а значит на нестандартных и коротких лентах будет ошибаться прилично. Зато он максимально прост. Правда, его смоделировали, и в нем есть ошибки. Собирать его на 10+ корпусах я бы не стал. Ну и его дополнительный недостаток - динамическая индикация. Питание у Вильмы общее на все цепи, поэтому могут быть сложности. Поэтому лично для меня вопрос замены механического счетчика на электронный остался не решен.
Виталий Онуфрович, который на маяковском форуме, разобрался в исходнике, и делает что-то свое. Может быть ему повезет исправить недочеты в программе ...
