Разработка системы (аналог 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]

Трудновато это будет довести. По поводу записи данных на ленту уже высказывался, но интерес реализации присутствует.
Идеи у самого где-то роились по поводу "компьютеризации" дек. Если руки дойдут, то буду использовать I2C для передачи данных между узлами. Думаю надо будет наперво набросать прошивку для Attiny13A, для передачи и считывания по I2C, что бы она в свою очередь кидала полученный байт (или больше) на сдвигов(ые)ый регистр(ы). Вроде как будет не дорого и компактно, особо в SOIC-е.
А так по теме, надо конкретизировать вопросы - покумекаем...

[Turbo_man]

Трудновато это будет довести.

В чём сложность? Я не понял.
1. Опыт приёма кодов по протоколу Сони есть. ДУ от пультов Сони работают на ура. Протокол самый простой из всех.

надо конкретизировать вопросы - покумекаем...

Вопросы такие - что ещё забыл из служебной информации для записи на ленту? И просто мысли по теме.

кидала полученный байт (или больше) на сдвигов(ые)ый регистр(ы). Вроде как будет не дорого и компактно, особо в SOIC-е.

Согласен. Обсуждали уже.
Мой опыт управления релюшками в УВ по проводам из платы МК говорит, что появляется приличная помеха от динамической индикации, которую я перехватываю на время вывода своей информации. Изоляция оптопарами не спасает.

[DrLithium]

В чём сложность? Я не понял.

Дай то Бог, что бы было всё гладко. Просто у меня какое-то не хорошее предчувствие, типа по-вылезает проблем...

что ещё забыл из служебной информации для записи на ленту?

EQ-REC не планируется пока? Понимаю что это будет сложно, но думается здесь золотая жила. Nak 1000ZXL, вроде как в rec-е колдует?
Всё равно придётся записи что-то отдавать, 70 или 120? Или это пока вручную?

Ещё я бы определил стоп-бит. Т.е. Считал всё до стопа -> пошёл разбирать: есть 2 байт - хорошо, пришло 3 - ещё лучше. Если dbx отсутствовал, чего его писать? Забить его нулями, и брать следующее. -> далее отправить данные по адресам. Этакий динамичный формат, если чего захочется добавить, то будет не поздно. А сейчас голову лишний раз не ломать и после локти не кусать...

Мой опыт управления релюшками в УВ по проводам из платы МК говорит, что появляется приличная помеха от динамической индикации, которую я перехватываю на время вывода своей информации. Изоляция оптопарами не спасает.

Вот здесь по-подробнее, не всё понял: с одной стороны реле, с другой динамическая индикация. У меня не сходится, т.к. ДИ в моём понимании есть вывод на восьмёрки. Т.е. тот же счётчик, но он не фонит. На счёт перехвата, то же на догнал. Нужна структурная схема и последовательность жестов.

[Turbo_man]

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

Да, некоторые проблемы создаются. Т.е. пока я поимел помеху от динамической индикации.

Всё равно придётся записи что-то отдавать, 70 или 120?

Я буду писать 4 бита для EQ-PB. 16 значений тау 40....190 с шагом 10мкс.

EQ-REC не планируется пока?

А с какой целью. Ведь запись уже прошла. Её повторять зачем? Чтобы не проводить новый цикл оптимизации, если делать новую запись на эту кассету?

Ещё я бы определил стоп-бит. Т.е. Считал всё до стопа -> пошёл разбирать: есть 2 байт - хорошо, пришло 3 - ещё лучше. Если dbx отсутствовал, чего его писать? Забить его нулями, и брать следующее. -> далее отправить данные по адресам. Этакий динамичный формат, если чего захочется добавить, то будет не поздно. А сейчас голову лишний раз не ломать и после локти не кусать...

Согласен, можно в коде указать, сколько дальше будет байт. И ещё одна проверка на корректность будет.

Вот здесь по-подробнее, не всё понял

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

Nak 1000ZXL, вроде как в rec-е колдует?

Как я сумел разобраться, в нём RAMM пишет только номер композиции, 70/120, ШП (внешняя, внутренняя, Долби Б). Вроде всё. Информация о REC-EQ не пишется на ленту.

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

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

[DrLithium]

А с какой целью. Ведь запись уже прошла. Её повторять зачем? Чтобы не проводить новый цикл оптимизации, если делать новую запись на эту кассету?

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

Согласен, можно в коде указать, сколько дальше будет байт. И ещё одна проверка на корректность будет.

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

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

Это происходит с помощью реле? Тяжко догадываться не видя схемы. Да и сама реализация интересна, м.б. тогда станет понятнее где косяк?
Может в шапочку под спойлер спрятать идеологию и узлы с текущей реализацией? Глядишь и тупых вопросов поубавится! А за то дельных советов посыпется...

Как я сумел разобраться, в нём RAMM пишет только номер композиции, 70/120, ШП (внешняя, внутренняя, Долби Б). Вроде всё. Информация о REC-EQ не пишется на ленту.

Опа! Я думал он хранит всё. Свой пока валяется, не до него пока... Мотаю на ус!

[Turbo_man]

Чувствуется заточка под разовую запись на всю сторону до конца.

Точно. Поэтому и скорость выбирается такой, чтобы тютелька в тютельку. Например, 47 минут в 19 (или в 20, если 1 минуту выделить для тест тонов).

---------- Добавлено в 18:09 ---------- Предыдущее сообщение в 18:03 ----------

Я думал он хранит всё.

В ячейках памяти A, B, C и D скорее всего, но не на ленте.

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

По-началу я не планировал писать на ленту точное значение скорости (точнее значения коэффициентов - числитель/знаменатель), а самому его вычислять по тону 400 Гц. Это не сложно, и даже сделал точный частотомер на этом же МК в составе основной программы. Но столкнулся с тяжёлой арифметикой для преобразования измеренного значения в отношение двух целых чисел. А перебирать все варианты долго.

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

Это происходит с помощью реле?

Нет, просто перевод в третье состояние (Z) либо буфер штатной шины 74HC245 (я его туда врезал), либо выходы регистра 74HC595 от моей схемы управления индикацией. Таким образом осуществил мультиплекирование шины управления штатного контроллера индикации.

Может в шапочку под спойлер спрятать идеологию и узлы с текущей реализацией? Глядишь и тупых вопросов поубавится! А за то дельных советов посыпется...

Постараюсь.

[Turbo_man]

Интересен такой вопрос - какой алгоритм придумать для поиска ДВУХ целых чисел, отношение которых равно заданной (искомой) величине. Скажем, как найти пару, равную "Корень из 2". Ответ я знаю =99/70. Точность нужна высокая, а пары из чисел не более 99.

[Игорь Гапонов]

x приблизительно или точно=n/m

- n,m- взаимно простые (не имеющие общего делителя) натуральные числа.

Надо просто составить таблицу .

Всего частных- 100*100=10000. Из них надо исключить равные отношения. После этого останутся только отношения взаимно простых чисел до 100, но зато ВСЕ! И их будет гораздо меньше 10000 (например, 1/3- оставляем, а =2/6=3/9=4/12=5/15=6/18=
=7/21=8/24=...=33/99...- исключаем). Отсюда видно, что "соседние точки", соответствующие "взаимнопростым отношениям" расположены на числовой оси от 0 до 100, типа, хаотически по плотности. И, следовательно, для "взаимнопростых приближений" на каких-то произвольных интервалах числовой оси (т.е. для какого-то диапазона исходных чисел) погрешность будет низкая, а для каких-то других- высокая (Ваш пример- из интервала, где погрешность приближения очень низка!). Эта "хаотичность", кстати, не позволяет математикам до сих пор вывести "формулу простого числа". Поэтому и надо составлять таблицу "разных исходов" для 10000 опытов

[DrLithium]

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

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

В ячейках памяти A, B, C и D скорее всего, но не на ленте.

Я про ячейки, на ленте места мало, да и пишется на 5 Гц.

По-началу я не планировал писать на ленту точное значение скорости (точнее значения коэффициентов - числитель/знаменатель), а самому его вычислять по тону 400 Гц. Это не сложно, и даже сделал точный частотомер на этом же МК в составе основной программы. Но столкнулся с тяжёлой арифметикой для преобразования измеренного значения в отношение двух целых чисел. А перебирать все варианты долго.

Я бы предпочёл писать точное значение скорости. При чём чтение-запись вести исключительно на штатной скорости. А уж опосля...

Нет, просто перевод в третье состояние (Z) либо буфер штатной шины 74HC245 (я его туда врезал), либо выходы регистра 74HC595 от моей схемы управления индикацией. Таким образом осуществил мультиплекирование шины управления штатного контроллера индикации.

Вот это надо хотя бы блочно показать и пояснить, на каком этапе вылезает косяк. Народ больше любит изображение, чем фантазии. 245-е валяются, но вроде как не пересекался, надо в справочник лезть. Общий смысл уловил - то одно тело в ауте, то другое - на одну нагрузку. Но что происходит с реле пока недопетрил.

[Turbo_man]

Общий смысл уловил - то одно тело в ауте, то другое - на одну нагрузку.

Совершенно верно.

Но что происходит с реле пока недопетрил.

Так ведь с помощью 4-х реле я коммутирую резисторы в ОС у ОУ в УВ. Таким образом изменяется тау УВ. от 40 до 190 мкс с шагом 10 мкс. Изначально я полагал, что само реле уже даёт гальваническую развязку цепей управления и аналоговых, а релюшки управлялись при помощи ULN2803A от 74HC595, питались обмотки от цифрового питания. Опыт сказал - фиг, наводка пролезает по паразитной ёмкости реле (?). Тогда я обмотки этих 4-х реле отделил 4-мя оптопарами TLP621 от управляющей 74HC595 (ULN2803A исключил за ненадобностью) и обмотки запитал аналоговым питанием. Картина слегка улучшилась, но пока далека от идиллии.
Теперь думаю от аналогового питания запитать 74HC595, ULN2803A и обмотки реле. А оптопарами разделить управляющие сигналы (DATA, CLOCK, LOAD у 74HC595), чтобы не объединять земли. В 1000ZXL все регистры управления аналоговыми ключами тоже запитаны от аналоговых источников питания.

[DrLithium]

Так ведь с помощью 4-х реле я коммутирую резисторы в ОС у ОУ в УВ. Таким образом изменяется тау УВ. от 40 до 190 мкс с шагом 10 мкс. Изначально я полагал, что само реле уже даёт гальваническую развязку цепей управления и аналоговых, а релюшки управлялись при помощи ULN2803A от 74HC595, питались обмотки от цифрового питания. Опыт сказал - фиг, наводка пролезает по паразитной ёмкости реле (?). Тогда я обмотки этих 4-х реле отделил 4-мя оптопарами TLP621 от управляющей 74HC595 (ULN2803A исключил за ненадобностью) и обмотки запитал аналоговым питанием. Картина слегка улучшилась, но пока далека от идиллии.
Теперь думаю от аналогового питания запитать 74HC595, ULN2803A и обмотки реле. А оптопарами разделить управляющие сигналы (DATA, CLOCK, LOAD у 74HC595), чтобы не объединять земли. В 1000ZXL все регистры управления аналоговыми ключами тоже запитаны от аналоговых источников питания.

Я так понимаю что происходит: динамическая индикация создаёт пульсации по питанию +5В, это же изгаженное питание заводится на обмотки релюх, которые в свою очередь фонят на цепи УВ. Можно попробовать навешать ёмкостей или запитать релюхи от своего отдельного +5В (по этому можно не стесняться брать реле на 12В или на 15В, в зависимости от бортового). 7805 не большая цена для проверки. Индуктивная помеха мне кажется более вероятной, чем ёмкостная.

[Turbo_man]

Теперь думаю от аналогового питания запитать 74HC595, ULN2803A и обмотки реле. А оптопарами разделить управляющие сигналы (DATA, CLOCK, LOAD у 74HC595), чтобы не объединять земли.

Проще будет сделать тоже самое, но для самой схемы коммутации цепей динамической индикации. Т.е. удалить как можно дальше сам источник помех.

[speedster]

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

[Turbo_man]

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

Скорее всего, проще. Но если переоборудованных аппаратов несколько (а я не собираюсь останавливаться ), то встаёт проблема реплицирования и обновление БД на всех аппаратах. А это уже трудно.
По моим прикидкам 1 минуты должно хватить на всё (это включая пилот-тоны 400 Гц, итп.).


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

[DrLithium]

speedster, похожие мысли бродят и в моей голове. Нужно иметь ID кассеты(стороны). Пытался найти на базе штрих-кода, но пока мимо. Вариант, вводить номер кассеты+стороны с пульта. Хранение и запись данных на SD-карте. Отсюда необходимость использования файловой системы, а значит привязка к библиотекам сторонних разработчиков и к языку C++. На сколько я помню, уважаемый Turbo_man, делает на ассемблере. Хотя для вновь записанных кассет интересно было бы хранить ID в начале стороны. А если не найдено, то тогда возможность ввода с пульта. На коробке можно помечать, есть ли ID на ленте.

[intell]

если уж мастурбировать -то по серьезному, rfid чип вклеивать внутрь кассеты и готово.

[Turbo_man]

Написал и отладил софт в симуляторе для передатчика и приёмника своей реализации RAMM (цифровая часть готова). Теперь "дело за малым". Записать и воспроизвести реальные сигналы (дело за аналоговой частью).
Несколько слов о данной реализации: формирование 15-ти слов (16-ти битовых) в формате, похожем на SONY SIRC (несущую пока не выбрал 8кГц или 7,2кГц). Т.е. передаётся информация из 15-ти регистров данных + у каждого регистра свой адрес. Вся посылка занимает 900 мс. Повторяем её столько, сколько хотим при записи. Потом считываем многократно повторенные слова, "битые" слова просто отбрасываются.
Как сделаю аналоговую часть и запущу систему, помещу скриншоты.

Перечень 8-ми битовых регистров:
1. Числитель дроби коэффициента скорости (1...99)
2. Знаменатель ---"---
3. ID ленты и её стороны (старший байт)
4. ---"--- (младший байт)
5. Год записи (старший)
6. ---"--- (младший)
7. Число, месяц (старший)
8. ---"--- (младший)
9. Время записи (старший)
10. ---"--- (младший)
11. PB-EQ (4 бит) + PB-LEVEL (4 бит)
12. Тип ШП (4) + Тип ленты (4)
13. REC-EQ (4-MID + 4-HIGH)
14. REC-LEVEL
15. BIAS
В 3 и 4-м номерах не уверен в полезности для себя.
А вот удваивать регистры 11, 13,14 для обоих каналов (L,R) скорее всего придётся.

---------- Добавлено в 02:49 ---------- Предыдущее сообщение в 02:28 ----------

если уж мастурбировать -то по серьезному, rfid чип вклеивать внутрь кассеты и готово.

Научите, попробуем.

[DrLithium]

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

[speedster]

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