Разработка системы (аналог RAMM) хранения и считывания служебной информации в КК

[Turbo_man]

Хотелось бы, чтобы была ветка для обсуждения этой тематики.
Я в процессе выбора решения данной задачи.
В планах писать в начале стороны кассеты тон-посылки (F=8кГц), несущие в закодированном виде служебную информацию о сделанной записи:
- кодировка как в IR-протоколе SONY, но количество бит данных больше (по потребности).
- 1 байт на адрес устройства, чтобы исключить ложные срабатывания (возможно, разные адреса для разных типов данных, чтобы сократить число бит данных)),
- 2 байта на 4 цифры для скорости (до 99.99),
- 4 бита на EQ-PB,
- 2 бита на Долби-dbx,
- .....что ещё забыл?
Продолжительность записи ~ 10...20 сек противофазно в L-R каналах (как и у RAMM).

После этого для целей точной настройки канала ГВ-УВ под именно эту кассету записать
- тон 400 Гц синфазно в каналах с уровнем Долби 20...30 сек. Чтобы ИМС Долби в точности работали как и при записи. Процессором регулировать уровень воспроизведения так, чтобы на соответствующем выводе ИМС Долби получить требуемый уровень.
- несколько тонов 8...16 кГц для выравнивания АЧХ УВ. Процессором коммутировать тау УВ до получения плоской АЧХ при воспроизведении данных тонов. Это актуально для лент, хранившихся какое-то продолжительное время.
- ......что-то ещё?

Прошу заинтересованных людей поделиться своими мыслями по данному вопросу. Заранее спасибо за отклики по существу.

[DrLithium]

штрих код?))))))))))))))))))))

Да! Дёшево и сердито. У меня более 1000 кассет, во что обойдутся rfid-метки для каждой, я пока не знаю. А полосок со штрих кодом (размером 20x5 мм.) на липучем А4 можно напечатать 500 шт. Переписать каждую с оглавлением - несколько лет.

[Turbo_man]

не потрёт ли, ЭДС катушки считывателя, запись на ленте?

А если наклеить на коробку этой кассеты и считыватель где-то сбоку подальше? Не решение?

---------- Добавлено в 15:19 ---------- Предыдущее сообщение в 15:17 ----------

Да! Дёшево и сердито.

А сколько бит данных можно поместить в штрих-код и в метку?

[DrLithium]

А если наклеить на коробку этой кассеты и считыватель где-то сбоку подальше? Не решение?

Можно и по-дальше, но потом кассету, если надо переворачивать, то коробку тоже? Как-то это не здорово. Если вблизи, то вся беда данной технологии для нас, это кол-во ЭДС отданное во вне, а нам его совсем не надо. Очень хочется заблуждаться, но пока не просвещают. Проверить можно взяв с собой свеже-записанную кассету с уровнем, на пропускную с rfid-доступом.

А сколько бит данных можно поместить в штрих-код и в метку?

Согласно википедии по rfid:

Объём памяти От 10 до 10 000 байт

А по штрих-коду:

Объём памяти До 100 байт

Вероятно в последнем случае имеется ввиду уже 2D штрих-код.

[Turbo_man]

Пришла в голову идея как прочитать и декодировать записанную фонограмму с RAMM, но на другой скорости, не равной скорости записи. Это нужно для того, чтобы не переводить скорость ЛПМ на стандартную при записи и чтении RAMM (хотя это и не сложно совсем).
Суть идеи заложена в самом протоколе SONY SIRC. В нём все тайминги (а именно они изменяются при другой скорости чтения) привязаны к длине первого стартового импульса (=4Т). "0" представляет собой паузу =1Т + импульс =1Т. А "1" - пауза =1Т + импульс =2Т. Теперь если перед декодированием измерить длину самого длинного импульса (за некий интервал времени) и поделить её на 4, то мы получим новое значение Т. Зная его нет проблем декодировать следующие посылки, считанные со скоростью, отличной от скорости при записи. Причём само чтение может начинаться и не обязательно с самого начала посылки, а с любого места.


Сейчас стандартное значение Т=10. Но скорее всего, для снижения погрешности чтения лучше перейти на 30...45. Тогда при тройной скорости чтения Т станет =10...15. (Это для случая записи RAMM при скорости 1х, а чтении 3х).

[DrLithium]

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

[Turbo_man]

писать данные везде и всегда на стандартной скорости

Не исключаю этого. Но по другим причинам.

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

Тут вы не правы. У меня свободного места сколько угодно (в диапазоне 47/15.....47/99 94). Любое значение для С-90. Я сам выбираю.
Для себя я пока принял такой сценарий:
1. Беру винил и считаю суммарную продолжительность фонограммы для одной стороны пластинки.
2. Полученное значение округляю вверх до целой минуты. (скажем 19:36 до 20:00). То есть из 47 (или 46 для некоторых кассет) минут (длина стороны кассеты) я должен получить в итоге 20.
3. Прикидываю сколько мне нужен запас на запись дополнительной информации и прибавляю это значение к знаменателю. Нужное мне время я получаю автоматически (почти даром). Например, хочу ещё 2 минуты, тогда мне нужно задать скорость не 47/20, а 47/22. И нет проблем.
И ещё, цифра 47 не является фиксированной, я могу взять и 46, и 45. Т.е. тоже любое значение от 1 до 99. Правда программно я не даю задать дробь менее 0,5 и более 3,1.

---------- Добавлено в 14:37 ---------- Предыдущее сообщение в 14:26 ----------

И ещё у меня в запасе есть трюк: умножая числитель и знаменатель на 2 я могу повысить дискрет установки времени c 1 минуты, до 30 сек. Вместо 47/22 (см выше) я могу задать 94/44 (при этом скорость не изменится), и теперь изменяя знаменатель на 1, я изменяю время на половину минуты.
Для С-60 аналогично, только тут можно умножить на 3 и получить дискретность 20 сек.

[DrLithium]

Тут вы не правы. У меня свободного места сколько угодно (в диапазоне 47/15.....47/99). Любое значение для С-90. Я сам выбираю.

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

[Turbo_man]

можно и без перемотки обойтись

Конечно.

---------- Добавлено в 14:53 ---------- Предыдущее сообщение в 14:51 ----------

Я бы считал до секунд.

Нет проблем, но скорее всего, лишние хлопоты. Да и вводить скорость тоже сложнее - 8 цифр вместо 4-х. В моей системе дельта на установку скорости 1/5271 (это почти 0,5 сек при длине стороны 2835 сек или длине 135 м).

---------- Добавлено в 15:02 ---------- Предыдущее сообщение в 14:53 ----------

В ближайших планах в синтезаторе скорости уйти от PLL к DDS, тогда доступная точность установки частоты клока станет 0,01 Гц (сейчас дискрет 497,ххх Гц при номинальной частоте клока 2,62 МГц).

[DrLithium]

Да и вводить скорость тоже сложнее - 8 цифр вместо 4-х.

Если приходится пользоваться калькулятором для суммирования длин треков, то почему бы за одно и не поделить? Тогда останется ввести кратность скорости, условно - 2.781, без точки. Эту же самую кратность писать на ленту.

[Turbo_man]

У меня нет в принципе возражений. Да и точность синтезатора это позволяет, но вот сам ЛПМ и лента дадут бОльшую погрешность. Поэтому смысла я не вижу. Плюс в начале и конце ленты хотелось бы иметь пустые "хвостики" по 15-20 сек (при скорости 1х), т.к. бывает покоробленная лента там.

[Turbo_man]

Да, и ещё не забываем про погрешность скорости вертушки.

[Turbo_man]

Таки удалось провести реальную запись на ленту и воспроизведение с ленты сигналов RAMM. И главное, УСПЕШНО ДЕКОДИРОВАТЬ принятую последовательность. Правда пришлось немного поправить программу в части констант, отвечающих за тайминги, в том месте где анализируется кодовая последовательность. Пришлось уменьшить реальное время паузы между импульсами, вызванное задержкой в детекторе импульсов.
Скриншоты прилагаю. Последний скриншот это тоже самое, но считанное со скоростью 47/22. На нём видно, что паузы между импульсами стали совсем маленькими из-за инерционности детектора.




Появилась мысль отказаться совсем от аналогового детектора импульсов и сделать его программно. Тогда не будет таких задержек. Т.е. программно сделать одновибратор на величину чуть более периода несущей (сейчас 7 кГц). Это и будет детектор огибающей.

И ещё один момент. На слух эта "музыка" весьма неприятна хотя и записывалась с уровнем -10дБ. Нужно делать mute.

Записывал на начальном участке стороны, слегка пожёванном. Полное считывание всех регистров произошло на 3...4 повторе последовательности (т.е. за 3...4 сек).

[3dnow]

Аналогичный метод кодировки служебной информации в МЗ был использован задолго до 1000ZXL, например в проф.записях с Dolby A. Подробной информацией не располагаю, может кто ещё подскажет из форумчан (спросите Intell-a, SIA_2, ???). На мой взгляд, метод записи получился слишком "аналоговый", с присущими ему недостатками. Т.е. соответственно используется метод повторов, а не коррекции ошибок. Просто мысли вслух.
Записывать достаточно с уровнем -20дБ.

[Turbo_man]

например в проф.записях с Dolby A

Я читал про то, что в профаппаратах в начале ленты пишется пилот-тон 400 Гц с уровнем Долби и с фазовой коммутацией в зависимости от типа Долби, использованной при записи этой фонограммы. Скорее всего сам тоже так попробую сделать с приёмником на LM567N. Такие мысли у меня давно были.

Аналогичный метод кодировки служебной информации в МЗ был использован задолго до 1000ZXL

На приоритет никогда не претендовал.

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

Согласен, метод примитивный. Но всё можно и доработать, если есть кокретные предложения.

метод повторов, а не коррекции ошибок.

Можно подумать над усовершенствованием алгоритма кодирования-декодирования.

Записывать достаточно с уровнем -20дБ.

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

[intell]

intell,
присоединяюсь к вопросу по rfid и два сверху:
не потрёт ли, ЭДС катушки считывателя, запись на ленте?
цена за единицу метки и габариты?
З.Ы. помню этот вариант уже предлагался в ветке по СРВ. Удобно до жути, но боязно.

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

[Turbo_man]

Доработал алгоритм для возможности записи и считывания на любой скорости от 0,5х до 3.0х. В симуляторе работает. Правда там анализ без учёта несущей. Пошёл проверять на натуре.

[Turbo_man]

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

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

[Partagas]

Вы так скоро дойдёте до bluetooth и mysql Про звук не забудьте

[intell]

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

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

[Turbo_man]

Пошёл проверять на натуре.

Натура сказала, что при таком аналоговом детекторе может работать только при отличии скорости чтения не более 1,5 раза вниз и 2 раза вверх от скорости записи. В общем пока неплохо.

---------- Добавлено в 22:44 ---------- Предыдущее сообщение в 22:43 ----------

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

Так ведь сначала информацию надо считать с аппарата, потом уже её записывать в метку. Или в ней только идентификатор?

---------- Добавлено в 22:45 ---------- Предыдущее сообщение в 22:44 ----------

Про звук не забудьте

То есть вы сюда ещё и лампы предлагаете? Если серьёзно, то оснащается этим сервисом не самый слабый тракт.

---------- Добавлено в 22:51 ---------- Предыдущее сообщение в 22:45 ----------

Вы так скоро дойдёте до bluetooth и mysql

Это не мои идеи. Я от них брыкаюсь. Я за запись инфы на ленту.