Счётчик ленты в реальном времени

[Turbo_man]

Т.к. меня интересуют МК технологии в применении к кассетникам, то возник вот такой вопрос. Давно хотел выяснить, как ведутся подсчёты в счётчиках ленты в реальном времени? Если кто-то уже делал такую систему или знаком с этим вопросом прошу рассказать или дать ссылки. И как сделать так, чтобы не нужно было вводить в систему размер кассеты - С90, 120, 60, 46L?

[DrLithium]

Pazx, нет, я понял, имел в виду именно СРВ. Счётчик остатка ленты, м.б. реализован как дополнительная функция. Есть вопросы? Отвечу...

[Pazx]

По моему предложенный вами способ плохо подходит для Счётчика ленты в реальном времени.
1.соотношение n1/n2 будет зависит от длины ленты, вы приводили график. нужно корректировать.
2.соотношение n1/n2 не будет зависеть от скорости движения ленты, как считать при перемотке?.

Offтопик:
как авторизация была горбатой, так и осталась, 20 минут и алес

[DrLithium]

1.соотношение n1/n2 будет зависит от длины ленты, вы приводили график. нужно корректировать.

Зависит, разве может быть по другому? У нас ведь задача показать секунды, а не значение в процентах. Не понял, что корректировать? Лента будет привязана к своему графику. Но можно сделать выбор наиболее подходящего из набора ранее записанных, в ручном или автоматическом режиме.

2.соотношение n1/n2 не будет зависеть от скорости движения ленты, как считать при перемотке?.

Точно так же. Именно деление позволяет получать достаточно точное значение даже в перемотке. Просто снизится точность, но в перемотке это не важно.

Думаю пора напомнить моё видение решения (разумеется предварительное):
1. Т.к. время проигрывания стороны сильно разнится (разные производители, удаление бракованного участка, разная скорость), более точно будет, если строить график для каждой кассеты.
2. График будет записан в файл со своим ID - номер кассеты + номер стороны. Место на современных SD-картах сейчас предостаточно. Файловая система FatFs должна с этим прекрасно справиться.
3. В строке, по мимо данных - времени и отношения, планирую добавлять номер трека. Появляется возможность переходить от трека к треку, как в CD-формате.
4. Можно добавить ШИМ, для управления скорости перемотки. Это позволит более гуманно обращаться с лентой и точно попадать (по значению счётчика) в нужное место.
5. Можно будет добавить описание трека, и выводить на LCD-дисплей (можно оформить подключаемым блоком или при желании встроить).
6. Для лент одной длины (одного производителя) можно копировать график с уже записанной стороны кассеты и поправить на предмет номеров треков и прочих данных определённых форматом.
7. Реализаций м.б. несколько. От минимального функционала с набором предзаписанных графиков, до варианта с ДУ, LCD и ШИМ в перемотке. Т.е. можно выбрать под себя.

[Pazx]

DrLithium, теперь я понял.
По сути это не совсем счётчик, а система определяющая временную позицию на ленте по эталонному графику исходя соотношение n1/n2.

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

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

[DrLithium]

По сути это не совсем счётчик, а система определяющая временную позицию на ленте по эталонному графику исходя соотношение n1/n2.

Результатом имеем значение на счётчике, дальше уже вопрос алгоритма.

имеется ввиду, что необходимо вводить длину ленты, иначе показания не будут точны.

Проще говоря, да. Точнее - каждый график можно записать непосредственно с кассеты или по заранее описанному алгоритму. В этой ветке есть Excel-овская таблица где я дал алгоритм автоматического выбора наиболее близкой кривой (таблицы). Т.е. можно довериться автомату, но сколько это займёт времени пока сказать не могу. Радует, что современные МК довольно шустрые, но огорчает то, что ограничение скорости зависит не только от них. Вводить, возможно, придётся ID кассеты, а не длину. Хотя при отсутствии описания треков и т.п., достаточно выбрать наиболее подходящий по длине график, из ранее записанных, перебором.

Теперь вопрос, как происходит подсчет: количества оборотов за единицу времени или количество импульсов некоего генератора за которое узел поворачивается на некоторый угол(или число пазов на диске)?

Окончательно идею, в моём мозгу, помог оформить Алексей Никитин. Кол-во оборотов не считается. Считается кол-во импульсов от кварцевого генератора, прошедших за время прохождения одной лопасти крыльчатки (или отверстия перфорированного круга - ОПК) над оптическим датчиком. По скольку нам надо уметь считать не только в "play" и "rec", но и в перемотках, то время пролёта одной лопасти над датчиком может составлять не 12,5-125 мС, а уже до 0,2-2 мС +-. Что бы суметь засечь эти величины, нужна высокая частота генератора, 4-20 Мгц и приличная разрядность значений - 24 bit, но не в ущерб скорости расчётов. Алгоритм приблизительно такой:
При прерывании опто-датчика запускается таймер и взводится флаг. При повторном прерывании проверяется состояние флага. Если он уже был взведён, то "фотографируем" набежавшее значение в буффер датчика. После, значении обнуляется, флаг сбрасывается. Со вторым ровно так же. Таким образом в буфферах 1 и 2 всегда имеется свежее значение с оптодатчиков. Сложность в том, что два независимых процесса должны максимально точно измерятся одним контроллером. Это решено. Таймер используется один на 16 bit, при переполнении происходит инкрементирование (+1) назначенного регистра добавляющего ещё 8 бит, т.е. до 24-х. Таймеру не интересно, было ли востребовано значение для расчётов, просто записывает новое, поверх старого. Под рукой имеем n1 и n2, они всегда доступны и могут в любой момент времени участвовать в расчёте отношения по запросу - n1/n2. Отношение можно запросить по таймеру и по прошествии малого времени, результат будет возвращён в ответ. Чем собственно можно любоваться, или писать в график или искать в графике соответствующее время для вывода на индикатор.

[Pazx]

DrLithium,
Может стоило использовать диск с меньшим числом зубьев, но с одинаковыми размерами зуба и расстояния между ними. Что позволило бы несколько снизить частоту генератора и считать всегда, как при закрытии зубом оптодатчика, так при его открытии. Типа: засветился датчик- считаем Fзас, пропала засветка - счётчик остановился Fзас пишем в А1, при этом считаем Fтем. Появилась засветка Fтем пишем в А1, начинаем считать Fзас. При этом значения в А1 будут обновляться непрерывно и так же для второго узла.
Возможно

Такое впечатление, что крутятся два элипса, отсюда и график: чуть вперёд - чуть назад. Т.е. следующая задача, доводка геометрии и разбор полётов.

из-за неравномерно поступающих данных. ведь начала и конец отсчётов на узлах практически не будут совпадать по времени.

Точнее - каждый график можно записать непосредственно с кассеты или по заранее описанному алгоритму

не думали использовать мат-кую функции (вроде что-то напоминает, то ли log или exp, толи просто степенная), ведь и считать быстрее будет и не окажется таких значений n1 и n2, которых нет в таблице.

[DrLithium]

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

Я сначала так и сделал, засвет=тени. Оптика при этом всё равно не даст равных половинок.
Если реже, то в "play" и "rec" не даст возможности построить достаточно подробный график. А после, с изменением плотности намотки, на грубом графике начнут скакать секунды. Хотя это дело ещё будущей практики.
В некоторые детали реализации алгоритма я не посветил. Прерывания от датчика могут быть получены как от засветки, так и от тени. Но если не реагировать на один, то получаем замер тени+засвета, т.е. прореживаем в два раза. При этом имеем сумму половинок. Естественно для измерения нужно получить максимальную длину, по этому лучше брать "сумму"=т+з. Снижать частоту генератора не зачем, мы себе это можем позволить с одной стороны, с другой нам это нужно для перемоток. Я уже проверял значение отношения в "play" и в перемотке - отношение остаётся достаточно точным.

Типа: засветился датчик- считаем Fзас, пропала засветка - счётчик остановился Fзас пишем в А1, при этом считаем Fтем. Появилась засветка Fтем пишем в А1, начинаем считать Fзас. При этом значения в А1 будут обновляться непрерывно и так же для второго узла.

Беда в том, что всё равно придётся использовать один 16-и битный таймер (+8 бит по переполнению), в ATtiny2313 он такой там только один. 8-и битные не интересны, но можно. Да и разбиение одного сигнала на части засветка/тень, выигрыша не даст.
Но если интересно, то я выкрутился так:
С первым прерыванием запустили таймер (он не привязан ни к одному из датчиков), взвели соответствующий флаг. По новому прерыванию, всё равно откуда, "фотографируется" набежавшее значение таймера, он обнуляется и запускается снова. "Фотка" добавляется (суммируется с ранее записанным значением) в нарастающий буффер каждого из датчиков при условии, что первое прерывание у него уже было. В зависимости от ранее взведённых флагов, имеем представление о том, что один из импульсов был завершён. Тогда копируем содержимое его буффера в итоговый буффер этого импульса - n1 или n2. Обнуляем его нарастающий буффер и сбрасываем его флаги. Т.о. ни что не пропадает, и всему успеваем уделить внимание.
Ещё введён учёт кол-ва прерываний на датчик. Т.е. можно получить в нарастающем буффере датчика не только за один импульс, а за от 1-го до 16-и. Т.о. можно подобрать кварц, кол-во "зубов" и выйти на оптимальное заполнение 24-х бит на краях ленты при разработке.

из-за неравномерно поступающих данных. ведь начала и конец отсчётов на узлах практически не будут совпадать по времени.

Буфферы всё простят.

не думали использовать мат-кую функции (вроде что-то напоминает, то ли log или exp, толи просто степенная), ведь и считать быстрее будет и не окажется таких значений n1 и n2, которых нет в таблице.

Это мечта! Было бы круто сравнить тики с датчиков по формуле с реальным временем, и взять нужные переменные автоматом. Вот только сколько времени займёт расчёт для достижения достаточной точности?
В моей реализации отсутствие данных не будет криминалом. Просто можно выводить "----" или "Out" В крайнем случае я попробую скормить сгенерённый итерацией график.

З.Ы. Возникла мысль: а нет ли у меня просадки напруги на оптике, при срабатывании одной пары или от пульсаций по питанию и получение нестабильного результата из-за этого на другом? Нестабильность засветки СД и чуйки датчика, может двигать порог в каких-то пределах. Может попробовать добавить стабилитроны на питание оптики?

[Turbo_man]

Может попробовать добавить стабилитроны на питание оптики?

Ну хуже не будет, это точно. Да и пороговые элементы тоже туда же (триггеры Шмита).

[DrLithium]

Ну хуже не будет, это точно. Да и пороговые элементы тоже туда же (триггеры Шмита).

Кажись триггер Шмитта МК-у уже не нужен. По крайней мере в "мышках" отдельно не ставиться. Вроде как даже игрался с ТШ, но различия в сигнале не нашёл. Хотя надо будет повторить, уже просто не помню на какой стадии это делал.

[Turbo_man]

Кажись триггер Шмитта МК-у уже не нужен.

Действительно, некоторые входы у МК имеют гистерезис (см. даташит), тогда питание для МК требуется улучшенное.

[Pazx]

Буфферы всё простят.

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

Да, может диск в чёрный цвет покрасить, дабы не было каких нибудь боковых подсветок на переходах.

[DrLithium]

Просто замеры будут производится в разное время, возможно это будет влиять на точность.

Это есть неизбежное зло. Понятно, что хорошо бы иметь последний замер тютелька в тютельку закончившийся перед запросом, но этого почти не бывает. Вопрос в том, какую погрешность имеем? Здесь проверить можно только практикой, считать очень сложно, т.к. придётся учитывать на какой угол повёрнут тот или иной "зуб", а после вычислять участника регаты. У меня было видно, что делимое и делитель плавают уже до деления. Думаю, что ещё...

Для снижения погрешности, как раз и беру большое количество "зубов" на оборот и поднимаю частоту. Что бы в момент запроса в n1 и n2 лежало значение очень не далеко отъехавших "зубов". Вот если брать 5-и зубую крыльчатку, то при скорости 1 об./3 сек., в буффере можем иметь значение зуба чуть меньше чем (1/5)*3=0.6 секунды назад, т.е. уже реально просроченное. Т.о. график будет скакать. Уменьшить скачки можно только уменьшением дельты соседних импульсов за счёт большего их кол-ва на оборот. Соответственно и хвосты будут короче.

Offтопик:
"Хвосты у зубов" - надо заканчивать лечение травами.

Т.е. погрешность из-за незаконченного "зуба". При этом увеличение значения делимого и делителя позволят получить более точное отношение. Вроде как противоречие...

Если пофантазировать, то можно представить несколько крыльчаток одетых на одну ось, с небольшим смещением. У каждой свой буффер. Можно для расчёта брать значение из того буффера, который только что закончился. Но реализовать сие не разумно. Теперь представим, что на единственной крыльчатке, "зубов" на оборот, пару тысячь. Т.о. можно сильно точно повысить показатель попадания на предмет свежести замера или отгрызть излишек хвоста. Но естественно результат будет короткий, т.е. собрано мало материала для расчёта отношения, типа 11/7 - грубо.
Тогда можно брать последовательно штук 100 значений и складывать в нарастающий буфер. Теперь осталось научиться брать сумму значений 50-и последних. Опять не реально, столько места нет под данные.
С другого конца (если строим график, условно "раз в секунду" и пишем его на карту):
отсылаем запрос на отношение, но в ответ не берутся готовые значения буфферов, а начинается замер с ближайшего "зуба". Получаем в n1 и n2 суммы из 50-и следующих "зубов". Как только данные готовы, считаем отношение и отдаём ответ. И только тогда пишется значение в таблицу. Т.е как бы уже прошло время, но какая разница с какой стороны временной метки идёт замер, до или после? По сути имеем отложенную запись отношения в таблицу, что ни чего не меняет. Полная секунда ещё не истекла, ждём, по истечению, вывели на индикатор (задержка в единицу не страшна, главное точность графика), повтор.
Теперь сам поиск значения в таблице:
если брать пост-замеры, то хорошо бы, что б "2313" не формировал ответ на запрос старшего, а сам бы давал знать старшему, типа - я тут насчитал "раз в секунду", прикинь что это по таблице... Тогда получается, что задержка за время замеров и расчёта будет иметь разную дельту. Значения на индикаторе будут появляться не во время. Да и "время" должно ложится на плечи "2313". Что не есть хорошо.
Значит задержку индикации на единицу нужно применять и здесь.
Правим голову: смещение времени на единицу можно считать как финал её истечения. После вывода на индикатор уже истёкшего значения, запрашиваем новый замер и расчёт. Есть желание вести частоту замеров 10 раз в секунду, да и для перемотки это полезно.

[Pazx]

Для снижения погрешности, как раз и беру большое количество "зубов" на оборот и поднимаю частоту.

Но ведь временное смещение всё равно останется, и итоговый результат будет то нарастать, то убывать. Потому как будут моменты Т1 и Т2 будут постоянно чередоваться, как на рисунке. а если снимать результаты более плотно, удастся уменьшить временное рассогласование, внизу на рисунке.

[Pazx]

Если пофантазировать, то можно представить несколько крыльчаток одетых на одну ось, с небольшим смещением.

такая штука наверно в простом магнитофоне не чему конечно.

[DrLithium]

Но ведь временное смещение всё равно останется, и итоговый результат будет то нарастать, то убывать.

Здесь надо помнить, что берётся не каждый "зуб", а лишь последний успевший из какого-то количества. Как для n1, так и для n2.
При этом и размеры движутся в разные стороны. Опять же деление помогает получить стабильную дельту. Вот если бы мы складывали, то тут была бы полная фигня, скачки как на ипподроме.

Потому как будут моменты Т1 и Т2 будут постоянно чередоваться, как на рисунке. а если снимать результаты более плотно, удастся уменьшить временное рассогласование, внизу на рисунке.

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

[DrLithium]

Что-то всё вокруг да около, глазками лучшЕе будет:

Естественно UART для отладки...

[DjAndy]

Позавчера прислали на ТО AKAI GX-9. Старый, почти всем известный аппарат.
Вот он и напомнил об этой ветке. К счётчику реального времени добавить бы грамотный Remain, в 9-ке он довольно показателен:
- Сам высчитывает продолжительность ленты (у большинства аппаратов нужно выбирать продолжительность);
- Корректирует показания во время рабочего хода, сразу может и ошибочно показывать если скорость ленты не соответствует, но после подгоняет показания и в конце ленты показывает довольно точно, до секунды (большинство без корректировки считают до 00:00 и замирают, даже если остатка ленты на пару минут);
- Работает во время перемоток, предварительно вычислив во время рабочего хода (у большинства на перемотках прочерки вместо цифр на счётчике, и всякий раз пересчёт при переходе в рабочий режим).
Хорошая и полезная фича, особенно когда много пишешь.
Жаль что в более поздних моделях фирмы эта функция исчезла, как и приличная автокалибровка (GX-F91, GX-F71).
Кто бы взялся за такое. Моих познаний в контроллерах не хватит для реализации.
Считает довольно долго, - 30-35 секунд (вначале ленты пробовал, там и ракорд крутился, потом плёнка, могло сбивать с толку считалку).

[Turbo_man]

Есть у меня живьём GX-9, но я его ЛПМ пока не довёл до ума. Лежит разобранный пока. Как сделаю, изучу его счётчик и Remain.

Тоже хочется сделать приличный счётчик, но пока нет мыслей по алгоритму рассчётов. Будет алгоритм, дальше дело техники.

[DrLithium]

DjAndy,
В этой ветке я писал и даже выкладывал файл в формате Excel-а с демонстрацией работы алгоритма, выбора нужной кривой всего по двум отсчётам. Т.е. если кривая записана с частотой раз в секунду, то чуть более чем за две секунды может определиться своя кривая. Соответственно будет выбрана длина ленты и отображено текущее значение. Пока это конечно в теории. Время выбора зависит от количества кривых, т.к. искать придётся в нескольких файлах, что непросто. Но беда ещё и в том, что длины лент разных производителей, для одного и того же стандарта длины, разнятся. Я вижу выход из этой ситуации следующим алгоритмом (со стороны пользователя, и предварительно):
1. Определяем ID ленты (порядковый номер например),
2. Пишем (через вызов функции) кривую для текущей ленты в файл на флешку (SD-card)
3. При следующем проигрывании достаточно ввести ID, и время будет всегда вестись по своей кривой (т.е. выбирать длину уже будет незачем, остаётся только найти текущее место и вывести на счётчик).
Дополнительно нужно обеспечить приемлемый уровень сервиса для работы с кривыми:
1. если лента повредилась и её длина изменилась, то можно переписать кривую
2. если кривая для кассеты того же производителя уже была записана, то иметь возможность копирования
И т.д...
Возможности: работа в перемотке, отображение остатка ленты, любая произвольная длина ленты, любая скорость записи кривой.

Offтопик:
З.Ы. В личку ответил.

[DjAndy]

Ой, только не флешки и не компы с дискетами. Всё должен считать контроллер и выводить на дисплей.
Почти 30 лет назад такое на дохлых MCU делали... Кривых производителей кассет в расчёт не берём.
Отталкиваясь от времени на оборот (t/об.) каждого подкассетника, и его изменениях,
с учётом правильной скорости ленты, можно высчитывать диаметры рулонов и толщину ленты.
По изменению соотношений t/об. подкассетников можно определить общую длину ленты.