"Вильма-104"- и схема есть! вопрос к вильмоведам

[Vygandas]

А головки 3Д24.092, пермаллой, попадались?

Навалом ! Гнали смежникам, да и в Вильму 312 ставили.
Вильма 204 то с пермалоя начиналась, так и 104 вариант с пермалоем есть

[Андрей-I]

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

gjПоясните что значит средние параметры?

Ежели посмотреть на параметры в паспорте, также возникает вопрос аналогичный: что значит средние параметры?

[411i6470r]

104 вариант с пермалоем есть

Ужасть ... первый класс аппарата, и на пермаллое ? не приемлимо .
то ли дело - даже 207 (правильных серий), и те все на 080ых. вот уж головки - так головки.

[Tofiq62]

Пермаллой в Вильма 104 что то не верится.Почти каждый день включаю свою Вильма104 и убеждаюсь что одна из лучших дек в союзе была и многим зарубежным декам даст фору.

[Самый !]

на 080ых. вот уж головки - так головки.

прочность, красивые цифры и звон.

[devel]

Речь же шла про 8440, которая не комбо. И на Вильмы не ставилась. 04х/05х тоже не ставились на Вильмы 102-207. Сквозной пермаллой был в В102/110, безусловно. 3АВ24.Н1 очень мягкая пермаллоевая голова, с ресурсом 2500 часов.

Поясните что значит средние параметры?

Исходя из области их применения, основное отличие их от 810 - это возможность применения при температурах от 0 градусов в автомагнитолах. Но индуктивность меньше, чем у 810. До 10кГц по АЧХ все относительно ровно. Разброс по каналам в области НЧ (63 и 125Гц), и ВЧ (12500 и выше) может достигать 5-8дБ. Имею таких голов несколько штук, как новых, так и б/у. Ничего выдающегося. Но из десятка можно было выбрать одну-две более-менее ровных по параметрам. 8440/8441 соответствует ТУ 65-02 08628815-92, и если посмотреть сроки действия этого ТУ - это 1991-1994год. Думаю, давать пояснения, почему в эти годы практически ничего не соответствовало ТУ не нужно 810е головки ТУ 4-МВ3.253.068ТУ-88 (88й год), головки 080-082 - СЫ3.253.214 ТУ (84 год).

П.С. Насчет пермаллоя в В104/204. Я не утверждаю, что такого не могло быть, но лично мне не попадались. Кроме того, головки 091/092 соответствуют ТУ более позднего периода, чем 080я серия. ТУ 090й серии ТУ 4-СЫ3.253.216ТУ-86 (86й год). Не могло быть в 1984 году головок ТУ на которых был утвержден в 1986м. Но не исключаю, что ТУ мог быть другой, более ранний. По крайней мере, гуглится только 86й год. Ну и фото 092й головы ранее 1986г я не встречал. Делаем выводы

П.П.С. Если еще точнее: ЗД24.091 - ТУ 4-СЫ3.253.216ТУ-86, а ЗД24.092 и ЗД24.192 - ТУ 4-СЫ0.З25.01ЗТУ-89

[Игорь40]

devel, Я почему спросил про головы? имею пару таких новых и обе стоят в Маяках, вот вторая голова установлена в 231 маяк, и вот так она пишет на первом типе TDK D90 при -20 db.

[devel]

Игорь40, не вижу криминала, данный экземпляр вполне годный, примерно соответствует по разбросу 081й головке. 4мВ разницы на 18кГц и 5мВ на 6300Гц это некритично. 6300, конечно могло быть и лучше, но и так неплохо. Другое дело, каким образом вытягивается АЧХ. Тут я для себя выбрал такую методику: сначала через резистивный делитель с генератора на вход УВ подаю стандартные частоты от 40Гц до 18кГц, и выравниваю АЧХ самого УВ, чтобы каналы были максимально идентичны. АЧХ, разумеется, нелинейна, и соответствует стандарту (за 0дБ принимается 315/400Гц, реальный уровень минус 30дБ). Относительно этой точки выставляется подъем на НЧ и ВЧ. Точнее, он задан цепями коррекции, а я лишь контролирую идентичность коррекции по каналам, и соответствие кривой, которая должна получиться (описание есть во всех инструкциях по ремонту Вильм). После этого просто подкидываются разные головки, в УВ максимум, что корректируется - входная емкость. И снимается АЧХ головы с ленты часть "Ч" или мультитон. Получается довольно достоверная картина параметров и состояния головки, по которой можно сразу отбраковать или отобрать максимально ровные. Небольшой нюанс - высота головки. Её придется выставлять каждый раз, т.к. двух одинаковых головок не существует. В Планке такая возможность есть, но крайне неудобная. Но лучше такая, чем никакой. Я заменил винты высоты/наклона на винты с крестовой шляпкой, и так более-менее оперативно выставляется головка. Для контроля использую софт (фигуры Лиссажу для контроля фазы), и В3-38 для удобства оценки уровня в дБ, чтобы не пересчитывать мВ в дБ. В крайний раз массово отбирал десяток новых 3Д24.080, с нетипичным "окном". 9 из 10 головок до 16кГц имели разброс до 1.5дБ. На 18кГц уже крутит фазу, и уровни там скачут. Обязательно наличие стирающей головки (просто как направляющей), и новый мягкий ролик 13мм. Получается довольно точный тестер голов. Последней тестировал Canon 36001, которую и оставил в В102. 3АВ24Н1 сильно большой разброс параметров по каналам, хотя она имеет чуть большую отдачу на НЧ, и звучит "жирнее".

[Игорь40]

Ну так это если есть из чего выбирать, а как правило выбирать не из чего.

[devel]

Это даже не столько нужно для отбора "одной из", сколько при ремонте понять, головка кривая, или УВ. Буквально неделю-две назад в Орбите МП-121 (тоже на Планке) долго искал причину разброса АЧХ. По НЧ разброс сократился размагничиванием ЛПМ и головки, а по ВЧ было непонятно, кто виновник. Выяснилось, что к естественному разбросу параметров головы добавляется неравномерность усиления К157УЛ1А левого и правого канала. Перекидыванием обмоток обнаружилось, без установки чужой ГУ в свой Планк. Обвязка УЛ1 была проверена, она идентична. Но прогнав сигналы с генератора выяснилось, что АЧХ самого УВ все-таки разная. Пришлось подбирать УЛ1, а затем уже выставлять ГУ в среднее (но не идеальное) положение, чтобы АЧХ каналов хотя-бы до 16кГц не вылетало за стандарты. При этом, можно было выставить один канал "в идеал" до 18кГц. Но поскольку ГУ изначально стояла с неправильным "кивком", то получилось просто "хорошо". Кроме того, влияет емкость проводов от ГУ к УВ, и их расположение в магнитофоне. Выглядит бредом, но укладывая по-разному провода "на ходу", я был очень удивлен, как смещается горб АЧХ на ВЧ. К тому же, в магнитофонах Вильма 104/204 на выходе УВ есть ФНЧ (у 204 на 16кГц, у 104 на 18кГц), который давит ВЧ выше этих частот. Это к тому, что искать 18кГц, например, в В204, не переделав ФНЧ хотя бы на 18кГц - дело бесполезное =)

Насчет выбора. Сегодня нет нужды гоняться за сендастом 080/810. Пермаллой DYNY62 (DM62) за 200р продается на Али. Параметры его вполне, а срока его эксплуатации хватит, поскольку большинство присутствующих не слушают кассетники без перерыва. Задача состоит только в том, чтобы настроить эту головку, подобрав входные емкости, и выровняв АЧХ (если такие регулировки предусмотрены. В Орбите, например, их нет. В Маяках не знаю. В Вильмах 104-204 есть).

[devel]

Вот тут тёзка скрупулезно настраивает Вильму 207 с такими головами:
https://www.youtube.com/watch?v=3hD4A6RemD4

И по тематике топика соответствует, и по заданному вопросу о головах

[alias]

Появились вопросы по теме и не только.

Длительность кассет указывается по времени воспроизведения/записи того куска ленты который покрыт рабочим слоем. А с учетом 2-х кусков ракорд? Как правильно считать? Длительность ракорд в разных кассетах разная и колеблется в пределах 2х(5..7) секунд.

Играясь с разными типами кассет случайно угадал коэффициент для С74, ну-у почти угадал. Где-то уже читал что были аппараты с СРВ и переключателем типов кассет по времени звучания. У меня все идет к тому что это возможно придется сделать, так как это самый простой вариант решения для часто встречающихся стандартных типов кассет С46, С60, С74, С90. А как тогда быть с резанками-студийками или с редкими 100, 120? С авто-подбором все как-то туманно в силу того что слишком много параметров надо учесть одновременно. А как будут обстоять дела с повторяемостью реализации счетчика на разных аппаратах?

[devel]

alias, мне далеко до ваших изысканий, но в силу любопытства я время от времени возвращаюсь к этой теме (интересуюсь теорией в основном), счетчика "попугаев", счетчика КРВ, и счетчика РВ. Всем давно понятно, что основная проблема подсчета разделяется на два сегмента: 1) счетчик реального времени движения ленты и 2) счетчик реального метража. С первым, казалось бы, все просто: активирован режим Воспр, запущен секундомер, и считай себе секунды/миллисекунды сколько хочешь. Но нет привязки к конкретной области ленты. А без условного "ноля" нет понимания отклонения от этого "ноля" в секундах. Учитывая механику (проскальзывание, перемотку и т.п.) сам по себе СРВ бесполезен без точки отсчета. Но и с точкой отсчета, на разных кассетах может быть разное сопротивление (тугие кассеты, например), и в режиме перемотки идеальный счетчик СРВ нахапает ошибок. Плавно приходим к необходимости считать метраж (2). Сотни постов на эту тему сводятся к тому, что в кассетнике это невозможно. Согласен на 99%. Единственная идея, которая мне не показалась совсем бесперспективной - оптический сенсор (типа компьютерной мыши). Поясню почему так. Механический способ (обводной ролик) существовал и в кассетниках. Сейчас не вспомню конкретную модель, но еще в 80-х такой датчик в кассетнике был. В то время не боялись экспериментов, не страдали "шаблонностью", поэтому часто головки делали стирающую совмещенную с ГУ, а в окне ГС стоял ролик. Могу путать, но вроде бы такое было. Сегодня такой вариант - скорее не вариант, потому что он не универсален. Но в Планке для этого есть простор. Сегодня головки единого типоразмера. ГС изъять тоже нельзя. Остается два пути: отпилить у ГС одну боковину, и прилепить ей сбоку сенсор, или поставить зеркало где-то в окошке между ГС и ГУ, а сенсор будет сканировать зеркало. Но "мышиный сенсор" заточен на две координаты, и сканирующий чип состоит из МК, светодиода (лазера), и оптодатчика. Уместить это все на каретке сложно. Выходные данные тоже не являются "готовыми" с точки зрения ТЗ. Мы получаем иные "попугаи", со своими погрешностями, и условностями, преобразовать которые в сантиметры - отдельная задача. Пока я не встретил ни один проект в кассетной тематике, где был бы реализован счетчик на все случаи. Когда я только заинтересовался кассетами, 9 лет назад, первое, что мне пришло в голову - записывать на частотах за звуковым диапазоном отметки времени, или даже более, чем просто отметки (тогда я думал о тегах к музыкальным произведениям). Но тогда я еще не знал о физических ограничениях магнитной записи, особенно выше 15кГц. К тому же, что делать с тиражными кассетами? Даже была мысль записи "между дорог", но когда увидел реальные размеры дорожек, расстояние между ними и осмыслил качество головок - эта идея отпала сама собой. Понимая суть проблемы, приходишь к мысли, что сам формат компакт-кассеты на это не способен.
В "золотой эпохе" кассетной техники этот вопрос тоже не решили. У меня на Teac V-900X года примерно 1984-1985 есть кнопка указания длительности кассеты, типа С60, С90, и т.п. Дека на МК. По сути, это компьютер, управляющий ЛПМ. Но и там или часы, или попугаи, без конкретной привязки к метражу.
Головка в ЛПМ Планк (ГУ) сидит на 4-х опорах, две из которых отвечают за высоту и кивок, а другие две - стандартно за азимут. Если "платформу", на которой базируется ГУ сделать более широкой, то на ней можно разместить что-нибудь. Обводной ролик с сегментами ч/б, например, или тот же "мышедатчик". Ролик проще, т.к. он сразу выдает конкретное значение оборотов, но он не контактирует с лентой в перемотке. В перемотке каретка находится внизу. И тут мы приходим в тупик. Не только в ЛПМ Планк, но и в других ЛПМ.
П.С. европейцы по-моему делали кассету с прозрачным уголком (там где вращается внутренний обводной ролик самой кассеты), и считывали данные с нее. Понимаете, какой уровень безысходности был уже тогда? =)

[devel]

Поделюсь своими мыслями, кмк, что можно сделать, если нельзя изменить источник (компакт-кассету). Примерно год я время от времени прикасаюсь к языку программирования Python. В его репозиториях есть библиотеки распознавания речи/идентификации музыки, а также создания fingerprint (отпечатка) музыкальной композиции, включая ее занесение в локальную (а по сути можно и в глобальную) базу данных. Я НЕ программист. Но библиотеки основаны на известных сервисах (не всегда они используют эти сервисы в соответствии с их правилами), но ничто не мешает "копить" личную базу фонотеки ничего не нарушая.
Суть идеи заключается в следующем. Если мы не можем наверняка узнать длительность композиции на своем магнитофоне, мы можем обратиться к "компетентному источнику". Под этим подразумеваются такие базы, как Shazam, Discogs, Lirics, и т.п. Анализируя свою кассету мы получаем "отпечаток" (fingerprint) каждой композиции, ищем ее в публичных базах, получаем информацию о длительности (и кучу другой информации). Задача заключается в "корректировке" нашего счетчика относительно "компетентного источника". Задача непростая. Тут нужно глубокое погружение, и понимание сути показометра. В рамках трех семисегментных индикаторов такое не реализовать. Точнее, можно, но овчинка выделки не стоит.
Если мы можем по первым секундам сопоставить (идентифицировать) песню с БД, получить все ее данные (длительность, год, альбом, текст и т.п.) и потом вывести просто коррекцию длительности - это стрельба из пушки по воробьям. Нужен полноценный дисплей. Текст, конечно, тут малоуместен, но стандартные теги вполне уместны, даже бегущей строкой.
С технической стороны нужно отправить на "некий сервис" аудиопоток (с которого считается fingerprint), значение СРВ на момент начала композиции, вернуть обратно ее длительность, и с каким-то периодом (до окнчания композиции) сопоставлять расхождение "пиков" сигнала с "эталонным" от сервиса. Сервис при этом может быть свой, локальный. Но ничего не мешает реализовать на этом моменте бизнесс-модель. Главное - доступность сервиса, и простота интеграции в старые магнитофоны. Коррекция счетчика по принципу: "есть связь с сервисом? есть! дай теги на этот wav (кусочек wav). Идентификация. Теги отправлены. Забрали из тегов длительность. Дай снимок песни (пики) с привязкой ко времени. Забрали снимок. Сопоставили текущие пики со снимком, вычислили расхождение по времени, внесли корректировку, и ждем следующий пик для контроля. И так пока не кончится песня. Если связи с сервисом нет - показываем честно намотанные попугаи, или время."
В практической части мне удалось распознать таким алгоритмом самописный сборник (моно рип с катушки на 38ск) с примерно 15-ю композициями две песни (они оказались в базе Shazam), остальных не было. Но репертуар был сильно древний (55-65гг). Альбом Queen был разложен по полочкам. На выходе - текстовый файл с названием и длительностью песен. Отпечатки я не осилил, для начинающего это сложновато. Но я делюсь идеей, а "рукастые" и "головастые" уловят суть, и найдут решение оптимальнее. Самое главное - не трогаем ЛПМ. Считываем, оцифровываем налету, посылаем потоком в сервис, сервис также налету по первым пикам идентифицирует (или нет) трек, отправляет назад данные. Задача - в доработке визуализации и корректировке счетчика.
Пардонте за многослов. В двух словах такие идеи не укладываются =)

[DrLithium]

1. Варианты с привязкой к ленте как к источнику импульсов (сканер поверхности, записанные или перфорированные "хлебные крошки", обводные ролики и м.б. ещё что-то) отпадает ввиду того, что кассету можно вынуть на середине и положить на полку. После вставить и смещение от начала будет не известно. Придётся перематывать к началу и это не удобно. В катушечниках обводной ролик оправдан, т.к. всегда идёт с начала и просвет ракорда может обнулить значение автоматом.
2. По ID фрагмента - придётся быть в онлайне, иметь огромную скорость сети и низкий пинг, доступность сервиса и гарантию того что он распознает, где-то надо считать в какой последовательности что записано, с какими перерывами, в случае повреждения ленты имеем уход от достоверного результата, слишком геморно и громоздко - д.б. более элегантное решение!

Вывод: принцип Бритвы Оккама ни кто не отменял! Проще достичь результата локальными методами решения - формула! И результат уже есть.

[alias]

Идея с "обводным роликом" не такая уж непригодная для кассет как кажется на первый взгляд. Например в прозрачных кассетах можно использовать в качестве "крыльчатки" датчика паразитные ролики(2 шт.) со сквозными окошками, но это своего рода экзотика. Проскальзывание ленты будет иметь место, увы.

Да, есть такие неприятные моменты как "тугие кассеты", "рыхлые рулоны" после перемотки, проскальзывание/прокручивание слоев пленки в рулоне при торможении и т. д. ... и это все никуда не денется.

Переключатель типов кассет - да, вполне возможно сделать, циклический С46, С60, С74, С90 и опять сначала. И с сохранением выбранного в EEPROM и кратковременной индикацией на дисплее при обращении к счету времени.

Если брать в качестве точки отсчета именно начало стороны кассеты, то это достаточно близко к реально осуществимому, хоть и вызывает некоторые неудобства. Это будет реальная привязка к месту на ленте(конкретной стороне кассеты) при счете суммы количества оборотов подкассетников, и счет будет реверсивным. Точность счета с учетом погрешностей реализации в пределах +-5 сек кажется вполне достижимой, и "чудес" как-бы не предвидится. Да, формула рулит и тут главное - обойтись без "фанатизма".

Можно реализовать счетчик как счет ленты(реверсивный), времени(по таймеру, не реверсивный) и времени как СРВ(реверсивный).

принцип Бритвы Оккама ни кто не отменял!

Но "Бритва Оккама" может быть и очень опасной — даже Платон не смог обойтись без уточнений.

[devel]

2. По ID фрагмента - придётся быть в онлайне, иметь огромную скорость сети и низкий пинг, доступность сервиса и гарантию того что он распознает, где-то надо считать в какой последовательности что записано, с какими перерывами, в случае повреждения ленты имеем уход от достоверного результата, слишком геморно и громоздко - д.б. более элегантное решение!

Конечно, это уже не просто счетчик. Это целая система. И геморрно, и громоздко. Но без внесения изменений в конструкцию (механику).
Вообще, изначально, мне пришла такая идея не ради счетчика. Как и у многих, у меня есть куча кассет, которые непонятно откуда, и непонятно что на них. На базе ЛПМ БС-02 я планировал собрать эдакий "оцифровщик" неизвестных кассет. БС-02 выбран исключительно из-за того, что у меня их с десяток, и они от природы умеют работать на 9ск, значит кратковременно могут работать на скорости и выше. Вместо ГУ ставится 4-дорожечная реверсная головка. Захват wav производится сразу всех 4 дорожек. Сканирование кассеты занимает около 10-15 минут. Полученный стерео-wav делится на два моно (Л и П). Дорожек у нас 4, а записать мы можем лишь две, не прибегая к разного рода коммутаторам. Но две достаточно. Один wav записан прямо, второй надо реверсировать. Полученные правильные wav-файлы обрабатывает библиотека, которая нарезает эти wav по композициям, ориентируясь на свои встроенные функции (аналог поиска по паузе, только в софте). В итоге, получаем две папки с данными кол-ва треков, их порядке, длительности каждого, и принадлежность к конкретной стороне. Как распознать, я уже рассказал выше. Все это мной было проверено (правда без 4-дорогой головы, на обычном 810 сендасте), и это работает.
Получается, что длительность трека, полученная таким образом, и есть "хлебная крошка", которую можно использовать. Применение метода к корректировке счетчика, это мысль, которая пришла мне в голову позднее. Корректировка счета является задачей факультативной. Понятно, что локально и проще, и правильнее, с инженерной точки зрения. Но ведь пока никак?
Пока не делал связку с discogs (а его api тоже доступно). На этом этапе порядок песен и их длительность может быть сверен с базой дискогса, и вынесен вердикт: какого года этот альбом/сборник. Полный/неполный он, и т.п. Для коробки кассет без вкладышей и подписей - это "сканер", который позволяет отсеять кассеты по репертуару, например. Или по принципу "альбом", "сборник", "самиздат" и т.п. Скан делается единожды. Потом всей кассете присваивается уникальный ID (его также можно связать с шифрами изданий от Дискогс, например).
Последний этап - это дать магнитофону узнать, какая кассета в него вставлена, есть ли она в базе и т.п. Согласен, работа "на лету" требует определенных условий: скорость связи, вычислительная мощность, и т.п. Но если до начала ленты, между ракордом, и рабочим рулоном с обеих сторон вклеить кусок ленты с информацией об ID, стороне (или записать ее туда, если есть место), то запрос будет короткий, и ответ будет включать в себя уже ранее полученные данные, не нагружая магнитофон в данный момент, а просто используя данные из локальной базы. Все данные текстовые. Данные о пиках в композиции будут выполнять роль контрольных точек для корректировки.

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

[411i6470r]

Длительность кассет указывается по времени воспроизведения/записи того куска ленты который покрыт рабочим слоем. А с учетом 2-х кусков ракорд? Как правильно считать? Длительность ракорд в разных кассетах разная и колеблется в пределах 2х(5..7) секунд.

оно-конечно да. но это всего лишь верхушка айсберга. попробую пояснить. ракорды - ракордами, и ими, а вернее их длинами, в конкретно-данном случае, можно (и даже НУЖНО) пренебречь, ибо показания счётчика на двух кассетах, скажем с-60, будут различаться, если одна скажем, будет макселл ЮР-60, а другая - тдк-Д. да они обе японские, обе 60 мин, фактически по 31 мин в сторону. но у них хоть и не значительно, но различается толщина ленты. штатный счётчик вильмы на макселле Юр-60 покажет 470, в то время как у тдк Д-60 он покажет 490. так же 470 он покажет и на знаменитых синих макселлах ЛН-60. там потому что лента толстющая ! и при 60 минутах, толщина рулона получается различной, соответственно с толстой лентой, принимающий узел сделает меньшее кол-во оборотов. а теперь прикинем, что есть кассеты с-60 с ещё более тонкой лентой , какая применяется для кассет с-90 - то там счётчик ещё большей показатель выдаст .. кроме того, японские кассеты - 31 минуту СМЕЛО в сторону имеют, а немецкие (басфы там ..) , про советские молчу, американки сюда же - бывает "в тютельку" - 30 мин, а то и 29 с копейками.
то же самое касается и 90 мин кассет - у тех хоть с толщиной ленты такой свистопляски нет - там более-менее толщина одинаковая. но ! возьмём опять же практически любую японку (сони-макселл-тдк-денон), запросто 46 мин, а то 46 с половинкой. возьмём какую нибудь корейку - 47 !! минут запросто, у всяких саеханов - типа самсунг, коника, и прочие "саехан-медия" . а теперь - вернёмся к немкам - басфы ка к пример . старенькие. там СТРОГАЧ 45 мин в сторону, как кстати и у американок (меморексы, реалистики, ампексы, ещё чё там . . скотч - но тут его не только амеры делали - по этому не заостряем внимание), так вот - у басфов даже на индекс-карте (вкладыше) писалось, что он 132 метра, в то время как японки - 135 (на соньках СЧФ поглядите), а корейки - и того длиннее. ......

А Вы говорите - ракорды, ракорды ... да ими не то что можно, ими НУЖНО принебречь в данном случае, ибо и без учёта их незначительных длинн - погрешности хватает , грубо говоря плюс-минус метр .

вместо п.с. : а как между собой различаются кассеты с46 и того меньше - (совсем мелочь не рассматрвиаем), у правильных старых японок - лента такая же толстая, как у 60-мин, а рассмотрим более новые, в том числе которые использовались для студиек, всякие ЕСР и прочие, там тоже лента тонкая , и толщина намотки будет в два раза меньше... и что нам намеряет наш счтчик, ориентируясь на кол-воо оборотов принимающего узла ?? : )

[alias]

дать магнитофону узнать, какая кассета в него вставлена

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

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

Использование RF-ID, или магнитных или ультразвуковых ID(как на товарах в супермаркетах) тоже отдельная интересная тема.

А Вы говорите - ракорды, ракорды ...

Да уж, все непросто, и мир не совершенен. Однако есть какие тайные решения у буржуинов, которые пока нами не раскрыты.

[411i6470r]

Да уж, все непросто, и мир не совершенен. Однако есть какие тайные решения у буржуинов, которые пока нами не раскрыты.

если речь о счётчиках реал-тайм по ленте, там на самом деле всё не так просто , там иёдт анализ-сравнение частоты оборотов приёмного и подающего узлов .... хотя, реал-таймы у тех же пресловутых техниксов серии RS-TR, начиная с 474 (373 не умеет), довольно точны .
не забываем, что всё выше-мной написанное, справедливо лишь для счётчиков, которые считают "условных попугаев" ТОЛЬКО с подающего узла .,.

[devel]

Мне кажется что штрих-код на ракорде с 2-х концов ленты будет практичнее.

Такая тема тоже рассматривалась. Но все помнят Spectrum, который прекрасно хранил и воспроизводил цифровые данные. Достаточно записать два-три экземпляра ID в двухтональном виде, предварительно записав старт-тон, и в конце стоп-тон, и все. Я прикинул, на все должно хватить 5-7 секунд. Лента по краям кассеты, как правило в плохом состоянии, поэтому ID дублирован. Старт-стоп посылки нужны, чтобы следящая схема смогла начать прием данных, и остановить, когда ID успешно считан 2-3 раза. Если не прочитался - возврат к началу (перемотка), и вторая попытка (Воспр). Если не прочиталось во второй раз - выдать сигнал ошибки чтения, и начать Воспр. Если цифровых данных в начале нет - выдать сообщение об отсутствии данных, и начать Воспр. Чтобы не страдали уши, частоты можно вынести в область 12-14кГц. Их уже слышно гораздо хуже, но они еще вполне уверенно читаются.
С ШК/QR/RFID придется городить сканер. Первые два безопасны, третий не очень. RFID это все-таки магнитная история, и ей нежелательно соприкасаться с магнитной лентой. Это сложнее, чем воспользоваться возможностью записи ID на ленту. Тем более, ничто не мешает вставив кассету отмотать ее в начало, запустить счетчик (таймер), определить длину (время) ракорда, и длительность тишины до начала первого трека. Далее сообщить, есть возможность записи ID или нет. В большинстве случаев, 5-7 секунд должно быть везде.
А как быть, если ID не записан, или кассета вставлена не с начала? Надо уведомить, что кассета Unknown, и предложить ее распознать по ходу воспроизведения. Если это не нужно - будет "обычный Воспр с каким-то счетчиком". Если нужно, то начнется процесс захвата аудио, распознавания "на лету".
Прикола ради, я испытывал захват и распознавание на лету на записи речи, с переводом в текст. Задействовал google-сервис распознавания. Речь М.С. Горбачева и Р.Рейгана была распознана довольно сносно. Порядка 80% слов были угаданы точно, причем Горбачев говорил на русском, а Рейган на английском. Но с песнями такое не прокатывает =)

[alias]

Лента по краям кассеты, как правило в плохом состоянии

А если вспомнить как приходилось каждый раз крутить азимут головки под чужие кассеты, то распознавание ID будет делом непростым. И грязь с кассет на головках тоже радости не добавит.

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

грубо говоря плюс-минус метр

Один метр ленты это ни много и ни мало это целая 21 секунда!

Точность аппроксимации в excell кстати та еще. Перешел на maple, результаты намного точнее и есть интерактивный выбор типа интерполяции.

[DrLithium]

Понятно, что локально и проще, и правильнее, с инженерной точки зрения. Но ведь пока никак?

И чуть выше:

И результат уже есть.

Видимо придётся пускать в ход тяжёлую артиллерию:
Тест. С-68 студийка. Делал на скорую руку, из того что подвернулось.

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

У меня строится уникальная формула для длины, с не важно какими: диаметром катушек, толщиной ленты и толщиной+длиной ракорд. Данные собираются с обоих катушек. Работает в перемотке и с любого места после остановки/включения выемки/вставки+включения. Дальше надо решать вопрос о выборе своей формулы для текущего экземпляра.

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

Идея прикольная, но...
1. Надо было закладывать на этапе разработки стандарта
2. Нужно приложить сколько-то усилий, что б добавить код на нужный участок.
3. Снова нужно мотать на начало.

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

Этот вариант кажется оптимальным (если не предложат что-то лучше) - доступно по цене на единицу, приемлемо по скорости получения ID, но надо добавлять сканер. Если с АвтоРеверсивной Головкой, то две штуки. М.б. плавающее зеркало над обоими кодами. Если без АРГ, то для одного поля сканирования.

Как вариант, при открывании кассетоприёмника, активировать WiFi (ESP8266), добавлять связь со сканером вне аппарата (т.е. ручное сканирование ID перед вставкой самой кассеты) и отключение до следующего открывания кассетоприёмника.

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

[alias]

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

Этот вариант кажется оптимальным (если не предложат что-то лучше) - доступно по цене на единицу, приемлемо по скорости получения ID, но надо добавлять сканер.

Есть еще экзотические варианты: Proximity карта, формата Mifare, тонкая 1К толщиной 0,84 мм, 86*54 мм, под принт, просто вложить в коробочку с кассетой. А как насчет NFC? А бесконтактный чип из брелка от домофона? Или 1-wire touch memory?

По поводу ID, или уникального cassette-ID, который строится из:
- тип кассеты: С46, С60, С74, С90 и т.д.
- длина ленты
- толщина ленты
- длина ракорды (?)
- диаметр подкассетника(-ов)

А уже по снимку характеристики на любом мерном участке(например 10 сек), определяем cassette-ID и ... текущее местоположение на стороне кассеты?

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

[DrLithium]

...86*54 мм, под принт, просто вложить в коробочку с кассетой.

Не. У нас задача для каждой стороны получить ID. Хоть формула одна и та же, но время треков и описание, скорость записи, долби, коррекция, могут быть разные. Нужно максимально быстро и без наводок на запись, при вставке кассеты, получать короткий ID для стороны. Далее по ID ищем файл на SD-карте с описанием данных именно стороны кассеты и уже из него достаём всё что нужно. Это программа максимум. А пока, на первых порах, просто получаем значение времени на счётчике.

А как насчет NFC? А бесконтактный чип из брелка от домофона? Или 1-wire touch memory?

Тоже самое. Не обеспечит ID стороны. Хотя в некоторых ЛПМ существует датчик стороны по центральному крепежу. Правда не у всех кассет это можно использовать (из-за отсутствия такового), что накладывает свои ограничения на исполнение.

По поводу ID, или уникального cassette-ID, который строится из:
- тип кассеты: С46, С60, С74, С90 и т.д.
- длина ленты
- толщина ленты
- длина ракорды (?)
- диаметр подкассетника(-ов)

Это будет включено в пакет с описанием формулы, более 30 байт. Т.к. это общая для сторон информация, нет смысла её расписывать отдельно. Длину в секундах используем для вычисления остатка ленты по желанию. Толщина не нужна. Длина ракорды определяется смещением от начала в самой формуле. Этот параметр надо будет давать корректировать пользователю, совместно с инструментом построения формулы. Подразумеваем, что длина ракорды с обеих сторон одинаковая. В случае не равенства выбираем длинную, что б вовремя нажать Fader или активировать AutoFader и не попасть на длинный участок ракорда при записи. Длина ленты C46, C60, C74, C90 для отображения (при желании), будет строится из определения кол-ва секунд в пакете.

А уже по снимку характеристики на любом мерном участке(например 10 сек), определяем cassette-ID и ... текущее местоположение на стороне кассеты?

Не совсем понимаю фразу. Что в данном случае является хар-кой? Имея, по ID, точное значение членов формулы из нужного пакета, просто скармливает ей (формуле) данные. Ни чего больше определять не надо. Требуется чуть времени, что б получить значение времени от формулы, по аргументу в виде отношения импульсов подкассетников.

Будет ли пакет ленты внутри файла стороны - пока не решил. Есть смысл сделать отдельным файлом, т.к. почти всегда в наличии имеются одинаковые кассеты. Использование одного файла с пакетом для конкретной ленты (производитель+длина), для большого кол-ва одних и тех же файлов с описанием содержимого кассет - разумно. Условный пример: 1234567A.txt в содержимом (помимо всего остального) имеет название файла - BASFC90FE1.txt. А уже в файле BASFC90FE1.txt - данные самого пакет для конкретной длины. Другой экземпляр кассеты имеет другое описание, но файл пакета может содержать тот же.

[alias]

Примерно год я время от времени прикасаюсь к языку программирования Python. В его репозиториях есть библиотеки распознавания речи/идентификации музыки, а также создания fingerprint (отпечатка) музыкальной композиции, включая ее занесение в локальную (а по сути можно и в глобальную) базу данных. Я НЕ программист. Но библиотеки основаны на известных сервисах (не всегда они используют эти сервисы в соответствии с их правилами), но ничто не мешает "копить" личную базу фонотеки ничего не нарушая.

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

А уже по снимку характеристики на любом мерном участке(например 10 сек), определяем cassette-ID и ... текущее местоположение на стороне кассеты

Не совсем понимаю фразу. Что в данном случае является хар-кой?

Последовательность точек на мерном отрезке(инкремент данных) сравниваем с расчетным по формуле или табличным на предмет совпадения(с заранее заданной точностью).

По дальнейшему накоплению точек за период допустим T_финальный=T_предварительный*3 - уточнение места на стороне кассеты.

[alias]

анализ-сравнение частоты оборотов приёмного и подающего узлов

Таки ДА! Определенный интерес представляет разница количества оборотов приемного и подающего узлов.

По знаку производной и скорости изменения значений можно судить где мы сейчас находимся на данной стороне кассеты...



И есть возможность достроить недостающие участки "назад" и "вперед".

[DrLithium]

Таки ДА! Определенный интерес представляет разница количества оборотов приемного и подающего узлов.

Было пройдено.
Сумма, разница, умножение - тупиковые ветки.

[alias]

Сумма, разница, умножение - тупиковые ветки.

Принято к сведению.

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

[devel]

Интересно, а чем можно объяснить перехлест графиков оборотов подкассетников на всех типах кассет.

Если это график левого и правого узла, то причины, наверно, такие: 1) разная "ошибка" счета 2) косвенное действие фетрового фрикциона (натяжение подающего узла) - разная плотность рулона. Динокассета (Torque Meter) обычно на настроенном Планке показывает 45г/см на приемном узле, и примерно в 10 раз меньше на подающем. 45 получается "вытягиванием" из под тонвала (хотя там нет вытягивания, только подбор, т.к. ленту выталкивает ПР+тонвал, а приемный ее подбирает, но с натяжением 45), а 4.5 на подающем - для обеспечения натяжения на отрезке "подающий узел - тонвал", это рабочий отрезок с ГУ/ГС. По логике, основным отрезком, отвечающим за плотность намотки, является отрезок "тонвал - приемный узел", он и регулируется электронно. "Подающий узел-тонвал" регулируется пружинкой (чем глубже шкив узла насажен на ось, тем плотнее сцепление фрикциона), но он лишь препятствует сваливанию рулона, и образованию петель. Интересно, меняется ли график, если прогнать кассету в обе стороны? Сначала "уплотнится" бобинка, затем с таким же усилием перемотается на новую. Это если причина в плотности рулона. В этом случае точка перехлеста должна как минимум двигаться. А в идеале - исчезнуть. А если это ошибка счета, то ее поймать сложнее. Поскольку точность на индикаторе достигнута при счете в один попугай, то можно этим перехлестом пренебречь, я думаю.

[alias]

Интересно, меняется ли график, если прогнать кассету в обе стороны? Сначала "уплотнится" бобинка, затем с таким же усилием перемотается на новую. Это если причина в плотности рулона.

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

[BillyDOS]

504 когда как в вильме 506.25?

Вариантов деления было несколько, как и основной кварц. Было 2-3 варианта на частоте 2МГц и 4МГц. Опыты.

поправка в вильме 505.8гц у вас 504.почему?)

Как я уже говорил, вариантов деления было несколько. Я выбрал на опыты где диодов было мало, и 0.4% это не тот уровень отклонения из за которого стоило бы беспокоиться

[DrLithium]

Принято к сведению.

Хотя у меня и на делении проблемы. Основной процент счёта идёт точно, но вот в начале есть проблемы и так же в конце. Замерил (не точно т.к. разрешение микрометра 0,01 мм) толщину ракорда, ленты и места склейки. Соответственно близко к: 0.05, 0,015 и 0,075. Далее за примерно 6 секунд дины ракорда (в текущей версии при использовании усреднения) буфер с данными наполняется отношением основного рулона к... толщине ракорда! А при переходе места склейки, отношение меняется с 0,05/X на 0,015/X. И как результат, если я не выкидываю отношения данных с участием ракорда, то получаю погрешность в 13 секунд (на начале самой ленты) и размазанный шлейф этой ошибки, благодаря буферу и из-за изменения самой формулы (по сути изменяется кривизна "прогноза"), длится ещё 121 секунду! При выкидывании этих данных (т.е. оставив данные где в отношении участвует только сама лента), шлейф ошибки тянется всего на 3-и секунды. В этом случае ошибка формируется из присутствия в буфере остатка данных с отношением ракорда и полностью затирается за полный оборот "медленного" из двух подкассетников. Попробую собирать данные без буфера, но тут данные скачут из-за геометрии. За одно изменю 24-е лопасти на оборот на 8.

[alias]

...

Я такого не писал. Увы. Перепутали с другим автором.

у меня и на делении проблемы

Да, я заметил как "шумит" начало ленты.



Попутно добавлю, что разница, по форме графического представления, подобие arcsin(x). А тут и до аппроксимации степенными рядами рукой подать...



Погрешности полученных данных меня не удивляют, точность изготовления крыльчатки - низкая, это вам не лазерная резка, увы.

[BillyDOS]

Я такого не писал. Увы. Перепутали с другим автором

Прошу извинить, цитирование бывает глючит и вставляет Ник другого автора

[DrLithium]

Раз видно, что ракорд влияет, то следующий момент о котором стоит подумать - место склейки, в случае обрыва. Точно на середину попасть почти не реально, по этому, раз сняв с такой ленты данные и оформив как положено, получаем рабочую версию... для одной стороны. Что б вторая сторона смогла отработать точно, формула должна отличаться. Но получается, что при почти равенстве формул для двух сторон, автовыбор "своей" формулы, найдёт "свою" для одной стороны, как и для другой, с почти равной вероятностью. Выход - привязка стороны кассеты к ID формулы. Т.е. прямой ввод, с кнопок (фэйс/ПДУ) или сканер. Это конечно в идеале и не всем будет нужно, но м.б. не приятно осознавать, что склейка даст счётчику соврать, а мы не предусмотрели. Тогда можно продумать возможность использования двух разных формул для разных сторон одной кассеты. По сути это не создаст проблем, т.к. ID для стороны кассеты и так задумывалось использовать разные. Т.ч. просто в данных для стороны 'B', иногда можно будет указать другой пакет с формулой. Получается при автовыборе ID формулы (пакета) для стороны кассеты, допустимо враньё и тогда вообще есть смысл не заморачиваться, а сразу делать только ввод для разных версий. В простой версии (реанимация без нарушения пластики фэйса) - перебором, одно-кнопочный интерфейс или доп.кнопки, для выбора из существующего набора: C46L, С46, С60, С90... В сложной версии (возможно нарушение внешнего вида аппарата) - ввод ID цифрами, заранее записанного на стороне кассеты, в отсутствии сканера. Думаю о варианте: использовать ДУ как отдельный модуль со всеми вытекающими. Т.е. работа с SD-картой + поддержка дисплея (любого варианта) + связка с управлением ЛПМ + м.б. сканер.

[alias]

В простой версии (реанимация без нарушения пластики фэйса) - перебором, одно-кнопочный интерфейс или доп.кнопки, для выбора из существующего набора: C46L, С46, С60, С90...

Я не в курсе, как дела обстоят на более поздних выпусках Вильмы, у меня в раме ЛПМ и кармане кассеты пробиты дырки для установки концевика под блокировку записи для реверсного варианта. Можно использовать по своему усмотрению ...



Например для сброса данных при смене кассеты или как переключатель типов кассет с перебором вариантов при необходимости + RGB подсветка окна кассеты.

[alias]

Интересно, меняется ли график, если прогнать кассету в обе стороны? Сначала "уплотнится" бобинка, затем с таким же усилием перемотается на новую. Это если причина в плотности рулона.

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

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

[DrLithium]

Чесал репу по поводу ID. Порылся вокруг контактного варианта. Подумал, что на дно окошка блокировки записи можно положить DS2401 (TSOC6). Размер чуть более 4x4 мм. Но дорого, около 40 рублей за единицу. А при цене рубля в три, я бы согласился на такой вариант. Печатаем на 3D-принтере кубики, клеим на них микрухи, паям контакты. Фиксируем на дне окошка. На датчике блока записи добавляем два токосъёмника. В момент контакта читается ID и далее по цепочке...

Может кто что-то встречал? А то подходящего найти не могу. Сплошь домофонные, дешёвые, но огромные снаружи - курочить устанешь.

[alias]

В общем - да, задача определения квази-реального времени воспроизведения может быть решена с точностью в 1..2 секунды с учетом всех имеющихся погрешностей в изготовлении оптических датчиков и их размещении в ЛПМ.

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

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

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

* Для подбора функций аппроксимации excell не годится, грубый инструмент. (!)

В теории АСУ - это как Отрицательная Обратная Связь для получения линейной передаточной функции.





А наклейку с лазерной насечкой 3-D принтером QR-кода на торце кассеты сложно будет считывать?

[DrLithium]

Что б QR-код считать нужно что-то подороже обычного штрихкода. И это совсем не хочется вживлять. Вариант передавать ID со смартфона по WiFi на ES8266. Что такое "наклейка с лазерной насечкой 3-D принтером..." я понять не смог. Может есть картинка того, что имелось ввиду?

[alias]

Что такое "наклейка с лазерной насечкой 3-D принтером..."

Это если по простому, а если подробно, то лазерная гравировка по алюминиевой фольге(самоклеющейся) выполненная при помощи механизма позиционирования от 3D-принтера после смены печатающей головки на лазерную в домашних условиях. По типу гарантийных пломб(стикерах) на изделиях. Как-то так:

[DrLithium]

Так. Ясно. Но зачем нужно использовать фольгу и 3D-принтер с лазерной головкой, когда печать QR-кода можно произвести на обычной само-клеящейся бумаге? Типа что б не затёрлось? Дак дешевле просто перепечатать. Другой вопрос какую площадь будет занимать и куда клеить?

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

[alias]

печать QR-кода можно произвести на обычной само-клеящейся бумаге

В смысле долговечности лучше не бумага, а пленка(ORACAL например) или фольга. Вопрос в том что будет обходиться дешевле.

Хорошим тестом для верности подхода и реализации, будет попадание с разных сторон перемотками и рабочим ходом, на одно и тоже место на ленте.

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

[DrLithium]

В идеале бы... 5*5мм клеить на дно блока записи стороны кассеты. При этом сам пакет записать можно. Но 61 рубль на сторону при цене за сотку - слишком дорого.

[alias]

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

С суммой количества оборотов разобрались, можно реализовать. НО! Адекватно работает только если кассета вставлена с начала.

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

А вот тут уже становится интереснее. Есть предпосылки к однозначному определению своего места на ленте в любом произвольном месте и совсем не обязательно работать от начала кассеты. Погрешность определения тоже будет, куда же без нее. Но, уже неважно с какого места на ленте мы стартуем ...

В идеале бы...

Да, согласен. Ах, еще бы дисплейчик ко всему этому, на который выводить данные о треке, и ва-а-ще улЁт будет.



Разбомбить табло с режимами и цветной МФУ-дисплейчик туда ... УХ!

[DrLithium]

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

[alias]

Снял данные... пришёл в ужас.

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

[DrLithium]

Дак собственно о чём и речь. "Хвосты" можно подрезать при сборе данных, но отклик системы д.б. моментальным и точным. И вероятно этого можно достичь идеальной геометрией. Теперь я лучше понимаю то чего достиг на своём первом видосе, с двумя усреднениями и "хвостом" в начале и в конце, это ещё нормальный успех с такими колебаниями. И вот теперь когда "тело" в принципе послушно, борьба за приручение "хвостов" предвещает самое трудное! Основная сложность, это точность попадания в рамках разброса данных ленты, при наследии данных с ракорда, при использовании буфера. Обманка типа - счёт по таймеру и коррекция его периодов, возможна при условии точного попадания. В перемотке не так важно. И как доп.тест будет проверка точности на месте склейки самой тонкой ленты из доступных, C-150 или C-180.

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

В любом случае думаю, что время на начальном ракорде выдавать как "00:00" и только при переходе на рабочую часть, давать значения в момент определения. Конечно лучше бы -0006,-0005 и до 0000, но пока это ещё одна проблема. На конечном ракорде, отображать максимум "47:33" (это как пример).

Я так понимаю, нужно ввести режим отображения в попугаях т.е. без знака ":" между минутами и секундами, на то время пока точность места на ленте не установлена. Вопрос в том, на сколько это будет раздражать? Или можно писать прочерки на время определения "--:--". М.б. это не будет большой проблемой в течении 2-5 секунд? Нам-то нужна точность в режиме рабочего хода при подходе к какому-то моменту, типа лента заканчивается. Если ещё точнее по периоду ожидания, то достаточно полного оборота быстрого из двух, что б буфер заполнился и можно было получить Ср. Ар. Зн. для одного из двух операндов деления. Полная точность будет при заполнении второго буфера. Т.ч .условие можно описать так: пока не заполнился один из буферов, данные не считаем и не выводим. А пока можно показать длину ленты "C-47".

Если точнее взвесить источник проблемы, то это ступенька момента смены толщины ракорда на толщину ленты. Подающий подкассетник выдаёт минимальное враньё, т.е. есть период, когда ракорда на нём уже нет, а приращение на приёмном пока ещё идёт "усиленными темпами". При использовании буферов, данные в подающем уже приходят в норму - затираются данными при сматывании самой ленты. В приёмном всё ещё враньё из-за намотки ракорда. На 22-м диаметре С-90, как только лента пошла наматываться, подающий успевает сделать полный оборот, и там уже "ленточные" данные, только после этого приёмному нужно сделать полный оборот, что б "вылечится". Т.о. есть смысл отодвигать условный ноль начала ленты ещё на один оборот приёмного после начала намотки на него. Тогда потери не велики, а проблему можно упростить. Для конкретно 22-го диаметра и С-90 - 14 см ленты, при реальном времени 47:33, потеряем 14*2(два раза: начало и конец)=28см или ещё по 2*3-секунды на сторону = 47:27, при 9 секундах на общий хронометрах одного ракорда (6 реального + 3 проблемного места на ленте).

Уже голова опухла от проблем. Если удастся добиться достойной геометрии, то как поступать тем у кого она не "фонтан"? Нужно лечить или программно или аппаратно. Пока у меня кривая геометрия, пробую программно, но д.б. какой-то минимум точности геометрии для приемлемой работы системы.

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

[alias]

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

Мигание "--:--" или надписи "СALС" я думаю будет вполне понятным сообщением, а далее краткий вывод типоразмера кассеты С46, С74 ... или "nOrC"(not recognized, не опознано) для всяких леваков и далее - вывод самих данных.

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

Либо считаем за какой-то мерный промежуток времени(пусть 0.5 сек) и получаем данные синхронно с обоих подкассетников как "фотографию" в какой-то момент времени и далее считаем текущее квази-реальное время.

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