Самосинхронизирующиеся коды

[swat24]

Самосинхронизирующиеся коды

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

 

[ESS]

двигается с разной скоростью

Скорость изменяется плавно?

Требования к максимальной скорости считывания и плотности записи?

 

[swat24]

Плотность записи 25 бит(можно больше, главное не меньше). Скорость изменяется плавно, она может не изменяться вообще, а может уменьшаться/увеличиваться в любом месте считывания пластины.
Скорость передвижения пластины (средняя) - 70-80 км/ч.
Максимальная скорость считывания - успеть прочитать все 25 бит за время, пока пластина проходит перед лазером.
Я так понимаю такого кода быть не может. Т.к. если не используется синхроимпульсы, то должна быть постоянная скорость. Или я не прав? Тот же манчестерский код и его разновидности не годятся, т.к. они привязываются к частоте.

 

[lugal]

А можно конкретизацию задачи для тупых программистов? Что конкретно надо и для чего? Физическая длинна бита стандартна? Или частота вращения известна?

 

[Klez]

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

 

[swat24]

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

 

[Klez]

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

для твоего случая удобно будет использовать штрихкод с синхропрефиксом. Т.е. код начинается с синхропробела, например 000000, синхромаркер с последовательностью к примеру 1010101010, по этой последовательности считывающий контроллер будет подстраивать частоту и фазу перед началом данных.
Далее будет идти синхроимпульс - последовательность которая явно отличается от кодировки нулевого и единичного бита. Непосредственно после синхроимпульса будут идти биты данных в NRZ коде например.

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

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

В качестве ознакомления для начала рекомендую изучить способ записи данных на касету на Spectrum'е. Там механизм примерно тот-же самый: Вначале идет пилот-тон (синхромаркер), потом синхроимпульс для индикации начала данных. И сами данные, в виде частотной модуляции, где один бит кодируется одним периодом сигнала.

 

[ESS]

Плотность записи 25 бит(можно больше, главное не меньше).

Размер области, на которую нужно записать данные?

Скорость изменяется плавно, она может не изменяться вообще, а может уменьшаться/увеличиваться в любом месте считывания пластины.

Предположим, что в момент, когда луч находится в самом начале области с данными, пластина движется со скоростью 75 км/ч и скорость начинает резко уменьшаться/увеличиваться. Какой будет минимальная/максимальная скорость в момент, когда лазер будет находиться в конце пластины?

ИМХО, если обработка софтовая, то именно манчестерский код и нужно использовать, только добавить отверстия перед и после области с кодом для синхронизации.
Средняя частота несущей определяется по синхронизирующим отверстиям, если скорость изменяется не сильно, то точности должно хватить для определения одинарных и двойных импульсов/пауз.

 

[swat24]

Размер области сантиметров 20 в высоту и 25-30 в длину. ширина одного бита 1 см. Скорость меняется не сильно, если была 75 то может быть 70, или 80 если увеличивается, могут быть изменения и меньше.
Мы нанесли на пластину данные в таком порядке:
начальная комбинация|данные|конечная комбинация
Считывание начинается с нарастающего фронта(первый бит = 1), мы включаем счетчик, засекаем время до спадающего фронта и потом считываем через половину данного времени значение с пластины. Это должно быть примерно середина бита(если скорость не меняется или меняется не сильно). Но так не получается, т.к. первый бит получается больше, чем одиночный бит в конце считывания, примерно в полтора-два раза.
Например если так расчитывать как описано выше, то в середине пластины или в конце мы считываем уже перепад, а то и пропускаем бит вообще.
Есть идея попробовать распознать код по соотношениям, например расчитать время каждого импульса, от фронта до фронта, всей пластины и потом начиная со второго бита делить его на время первого импульса, мы получим массив с данными, а затем преобразовать его в код. И не будем зависить от скорости.
В файле то что получается(зеленая полоска) и то что должно быть исходя от первого(стартового) бита (красная полоска).

 

[Ferox]

Если скорость может меняться резко - сделайте на пластинке дырки в два ряда....

Если скорость действительно может меняться только плавно закодируйте информацию по избыточному алгоритму чтобы компенсировать ошибки в считывании.

P.S. Я бы делал дырки в два ряда. Так ИМХО лучше и надежнее....

 

[swat24]

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

 

[Ferox]

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

Зачем два лазера два приемника??? Один лазер, один приемник, три уровня сигнала...

 

[swat24]

А как можно организовать 3 уровня сигнала на фототранзисторе? он или открыт или закрыт. Если светит лазер то он открыт, и на ноге МК логический 0, а если лазер не светит то на ноге уровень 1.
Схема подключения транзистора как на рисунке

 

[ESS]

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

Почему?

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

Я предполагал, что обработка будет производиться с помощью обычного компьютера, тогда нужно было бы гнать поток сырых данных с достаточно высокой частотой семплирования.
Если используется контроллер - можно попробовать считать длину импульсов на лету. Стоповый импульс не нужен.
Я вижу такое решение:
Добавляем в начало наших 25 бит единичку, кодируем с помощью Biphase Mark Code (вроде это модификация манчестерского кода, можно использовать и манчестерский код в чистом виде, но мне лень разбираться, как там декодируются данные ) и записываем на пластину.
При считывании работаем с интервалами от фронта до фронта (т.е. "1" там или "0" - не важно).
Нам нужно распознавать короткие (t) и длинные (2t) интервалы, т.к. первые два интервала будут короткими, их среднее значение и берем в качестве t (возможно, правильнее будет использовать разные t для "1" и "0", но это уже зависит от железа), в идеале корректируем t по мере считывания информации, чтобы учесть изменение скорости движения пластины (хотя в данном случае и без корректировки должно работать).
Дальше считываем импульсы и на лету определяем их длину (t или 2t). Если интервал короткий - ждем второй такой же, записываем "1" в считываемое число и увеличиваем счетчик принятых битов на 1, если длинный - сразу записываем "0" и тоже увеличиваем счетчик битов на 1. Когда счетчик будет равен 25, заканчиваем считывание.

Т.к. нам не нужно аппаратно восстанавливать несущую, можем немного упростить код, кодируя единицу одним коротким интервалом.

Все.

Вот пример кодирования в Biphase Mark Code:
https://ru.wikipedia.org/wiki/Файл:Biphase_Mark_Code.svg

Если кратко, то суть в том, сами по себе "0" и "1" не имеют значения, сигнал в Biphase Mark Code можно инвертировать, и это не повлияет на результат декодирования.

Т.о. сигнал на картинке в Biphase Mark Code можно представить в виде интервалов:

S-короткий интервал
L-длинный интервал

1  0 0 1  1  0 1  0 0 1  0
SS L L SS SS L SS L L SS L

Т.к. у нас нет PLL, которая должна синхронизироваться по этому сигналу, можем кодировать как

1 0 0 1 1 0 1 0 0 1 0
S L L S S L S L L S L

т.е.
-__--_-__-__--_--

 

[swat24]

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

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

 

[ESS]

Biphase Mark Code - это почти идеальный код для данного случая. Его и нужно использовать.

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

"расчитать время каждого импульса, от фронта до фронта, всей пластины и потом начиная со второго бита делить его на время первого импульса, мы получим массив с данными, а затем преобразовать его в код" - не совсем понятны нюансы, но отличить 0000000000001000000000000 от 0000000000010000000000000 или 0000000000000100000000000 будет очень непросто (скорее всего невозможно).

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

 

[swat24]

Спасибо за идею, завтра напишу что получилось.

На счет первого бита это или глюк программы, или мы когда проводим табличку в конце ускоряемся

 

[Uvavan]

но отличить 0000000000001000000000000 от 0000000000010000000000000 или 0000000000000100000000000 будет очень непросто (скорее всего невозможно).

Это не так уж и сложно. Это будит массив соотношений и в разных случаях будет разные номера массива.

 

[ESS]

Это не так уж и сложно. Это будит массив соотношений и в разных случаях будет разные номера массива.

Какой такой массив и кто его будит?

Если скорость действительно может меняться только плавно закодируйте информацию по избыточному алгоритму чтобы компенсировать ошибки в считывании.

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

 

[Ferox]

Ладно. Если считать что между двумя соседними битами скорость не может поменяться ВДВОЕ. Поставьте синхродырки через каждые Х миллиметров, а дырки данных сверлить (1), или не сверлить (0) между синхродырками. В этом случае вы как бы используете плотность записи вдвое больше чем нужно, но зато если между двумя битами скорость меняется менее чем в двое - всегда можете правильно расшифровать сигнал.

то есть у вас будет единица, это:
10101
а ноль это:
10001

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