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

[Orshansky]

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

Возможно ошибаюсь, но зачем изобретать велосипед? Почему бы вам не воспользоваться практикой записи CD дисков. На CD pits и lands напрямую не соответствуют нулям и единицам двоичного кода. При этом каждый край pit - это своего рода отсчет для синхронизации, а все остальные области диска - "неслышимые" отсчеты. Если бы pits и lands имели большую протяженность, то генератор считывающего привода сбивался бы с синхронизации. C целью гарантировать запись pit определенной длины, предполагается, что между каждой единицей может быть не менее двух и не более десяти нулей. Это достигается путем преобразования каждого байта в 14-разрядный - EFM-модуляция (Eight to Fourteen Modulation). И при обнаружении рассинхронизации вносите соотв. коррективы.

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

 

[ESS]

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

Записывать придется не в 2, а в 4 раза больше информации (причем бесполезной), т.к. нужно учитывать еще и расстояние между отверстиями.
Этот метод не дает никаких преимуществ. Наоборот, повышается физическая плотность записи и повышаются требования к быстродействию контроллера.
Если использовать тот метод, который я описывал, то в худшем случае (все "0") нам придется повысить плотность записи в 2.08 раз, в лучшем (все "1") - в 1.04. Причем нам не придется измерять длину коротких синхроимпульсов, т.к. синхронизация будет происходить по фронтам.
Причем помехоустойчивость такого кода можно легко менять за счет изменения плотности записи, т.е. увеличивая или уменьшая длину интервалов, соответствующих "0".

Возможно ошибаюсь, но зачем изобретать велосипед? Почему бы вам не воспользоваться практикой записи CD дисков. На CD pits и lands напрямую не соответствуют нулям и единицам двоичного кода. При этом каждый край pit - это своего рода отсчет для синхронизации, а все остальные области диска - "неслышимые" отсчеты. Если бы pits и lands имели большую протяженность, то генератор считывающего привода сбивался бы с синхронизации. C целью гарантировать запись pit определенной длины, предполагается, что между каждой единицей может быть не менее двух и не более десяти нулей. Это достигается путем преобразования каждого байта в 14-разрядный - EFM-модуляция (Eight to Fourteen Modulation). И при обнаружении рассинхронизации вносите соотв. коррективы.

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

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

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

 

[Гість 6636]

Можно измерять текущую скорость движения и вносить поправки в синхронизацию.
А вообще, если особых скачков нет, можно очень просто кодировать
Это же в железе окна штампуются? Первое окно (дост широкое) - синхросигнал. После него Два узких (1) или одно узкое (0).
И так дальше. По синхро можно подстраиваться прямо во время работы.

 

[Klez]

Мы нанесли на пластину данные в таком порядке:
начальная комбинация|данные|конечная комбинация
Считывание начинается с нарастающего фронта(первый бит = 1), мы включаем счетчик, засекаем время до спадающего фронта и потом считываем через половину данного времени значение с пластины. Это должно быть примерно середина бита(если скорость не меняется или меняется не сильно). Но так не получается, т.к. первый бит получается больше, чем одиночный бит в конце считывания, примерно в полтора-два раза.

1. естественно, учитывая девиацию несущей частоты и возможные помехи (например блики, или просто пролетевшая муха ), одного бита для синхронизации недостаточно. Чем больше может быть разброс частоты (скорости в вашем случае), тем длинее нужна синхронизирующая последовательность.
2. дискретность выборки равная 1/2 от частоты несущей недостаточна, т.к. несущая значительно меняется. Такую дискретность можно было бы задавать если бы скорость была очень стабильной, и задавалась с очень высокой точностью.

Дискретность выборки в вашем случае лучше выбирать так чтобы на один бит сигнала приходилось хотябы 50 выборок.

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

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

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

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

Запись на диск производится аналогичным описанным мною выше способом. Если детальнее - биты данных записывается магнитными доменами с помощью MFM кодировки. Но есть специальные маркерные байты (A1 либо C1), биты старшей тетрады которых записываются с нарушением правил кодирования методом MFM путем пропуска одного бита синхросигнала. Это делает его отличным от любого другого байта A1. Эти специальные маркерные байты записываются для идентификации начала данных. В самом блоке данных значения байт A1 и C1 записываются обычным образом.


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

4E \
4E GAP (пробел), записывается обычным способом (как данные),
... этот участок может содержать другие значения, что часто используется для сокрытия ключей
... в защитах от копирования
4E /
00 \
00 SYNC (синхропробел), записывается обычным образом (как данные), служит
... для подстройки частоты и фазы несущей декодера.
00 /
A1 либо C2 \
A1 либо C2 AM (адресный маркер), записывается особым образом (не так как кодируются биты данных),
A1 либо C2 / служит для идентификации начала данных
FE либо F8 либо FB - идентификатор данных (FE - адрес дорожки, F8 - активный массив данных, FB - удаленный массив данных)
XX \
XX массив данных, либо данные идентификатора дорожки или сектора
...
XX /
RR \ CRC блока данных, включая идентификатор данных и адресные маркеры
RR /
4E \
4E GAP (пробел), записывается обычным способом (как данные),
... этот участок может содержать другие значения, что часто используется для сокрытия ключей
... в защитах от копирования
4E /

 

[Гість 6636]

Если делать в 2 ряда можно просто сделать верхний ряд нулями, нижний единицами (или наоборот). Вначале - синхросигнал, потом данные.

 

[Klez]

Если делать в 2 ряда можно просто сделать верхний ряд нулями, нижний единицами (или наоборот). Вначале - синхросигнал, потом данные.

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

 

[Гість 6636]

можно просто RFID метки вешать

 

[ESS]

Можно измерять текущую скорость движения и вносить поправки в синхронизацию.

Чем, и главное зачем ее измерять?

А вообще, если особых скачков нет, можно очень просто кодировать
Это же в железе окна штампуются? Первое окно (дост широкое) - синхросигнал. После него Два узких (1) или одно узкое (0).
И так дальше. По синхро можно подстраиваться прямо во время работы.

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

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

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

MFM - это да, отличный способ кодирования 25 бит, особенно если нечем заняться.

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

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

Если делать в 2 ряда можно просто сделать верхний ряд нулями, нижний единицами (или наоборот). Вначале - синхросигнал, потом данные.

Если делать в два ряда, то синхросигнал не нужен.

И еще: на самом деле тут две задачи:
1. собственно запись/чтение информации;
2. контроль целостности/коррекция ошибок.

Поэтому очень желательно добавить как минимум контроль четности.

 

[Klez]

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

я вообщето про FDD говорил, а если брать HDD, то при современных плотностях записи, там подстройка 6 раз за один оборот всеравно даст погрешность попадания на нужный бит плюс минус 10 мегабайт Так что можно считать что скорость не известна. Подстройка лишь снижает погрешность и тем самым дает возможность непрерывной записи блока большего размера, без синхронизирующей последовательности.

Что касается FDD, то для диска 1.44, плотность записи такова что один магнитный домен (половина бита) записывается на участке 1/208000 диска, т.е. угловой размер сегмента хранящего 1 бит составит где-то 2*1/569 = 1/285 градуса. Диск вращается со скростью 300 оборотов в минуту, т.е. 5 оборотов в секунду, соответственно за 1 секунду под магнитной головкой успевает пролететь 1040000 магнитных доменов. Малейшая девиация скорости и без синхронизации данные уже не прочитать.

Тут работы на день, если есть нужное железо.
Конечно, если придумывать всякие "длинные синхронизирующие последовательности" или кодировать в MFM, то можно и месяц делать (пока не станет понятно, что работать оно таки не будет).

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

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

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

 

[ESS]

По поводу MFM: вообще я имел в виду формат записи с маркерами и т.п.
Сам по себе MFM применить можно, только следует учесть, что в этом случае нам придется различать интервалы 3t и 4t, что может значительно усложнить считывание при нестабильной скорости.
MFM создаст больше проблем, чем преимуществ.

 

[Uvavan]

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

Не совсем понял вопрос, а точнее совсем не понял))

 

[ESS]

Не совсем понял вопрос, а точнее совсем не понял))

А я не совсем понял твой ответ. Какой там массив должен быть? Там все и так замечательно считается при неизменной скорости, а при изменяющейся - никакие массивы не помогут.

 

[Uvavan]

ESS спасибо за подсказку с Biphase Mark Code кодированием, с ним получилось сделать))

 

[Гість 3253]

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

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

P.s. Не плодите сущностей... Не надо там ни чего кодировать.