Манчестер-кодирование.

[menzoda]

Здравствуйте, РадиоКотаны. Пришлось мне по долгу службы, так сказать, использовать этот метод кодирования, и у меня появилось несколько вопросов, ответов на которые я не нашел.

1. Исходные данные кодируются в Манчестер-код, который далее преобразуется в частотно-манипулированный сигнал (1400Гц и 2200Гц если интересно). Правильно ли я понимаю, что вся эта ммм... байда, типа нулевой постоянной составляющей и каких-то особенностей спектра этого кода, мне побоку? Я же не сам Манчестерский сигнал передаю, а модулированный.

2. Манчестерский код декодируется чисто программно. Грубо говоря я сэмплирую с некоторой частотой текущий уровень сигнала - 1 или 0 и там уже разбираюсь, где переходы и т.п.
Так вот я не знаю какую мне использовать преамбулу для синхронизации начала кадра. Есть некий старый код, который писал человек давно уволившийся (да-да, как всегда). Вот там эта преамбула очень сложная, что-то типа "0101010101010101 00000000000000000 11111111 0101010101010101 0000 11" (может не совсем точно, но суть ясна). Она действительно такая нужна? У меня ведь никаких ФАПЧ и аппаратных декодеров, а бодрейт известен заранее.

3. И если такая сложная преамбула не нужна, то какую использовать? Я нашел несколько вариантов, но не знаю чем грозит выбор того или иного варианта.

[Goldsmith]

...я не знаю какую мне использовать преамбулу для синхронизации начала кадра. ... эта преамбула очень сложная... Она действительно такая нужна?

3. И если такая сложная преамбула не нужна, то какую использовать?

Если смысл преамбулы - обеспечить разделение фреймов и заодно синхронизацию манчестерского приемника, то для этой цели вполне достаточно использовать, например, стандартный Frame Delimiter 01111110, как в протоколе HDLC и ему подобных. Чтобы не путать FD и случайно попавшийся в двоичных данных байт 0x7E, используется вставка бита (bitstuffing).

[menzoda]

Если смысл преамбулы - обеспечить разделение фреймов и заодно синхронизацию манчестерского приемника, то для этой цели вполне достаточно использовать, например, стандартный Frame Delimiter 01111110, как в протоколе HDLC и ему подобных. Чтобы не путать FD и случайно попавшийся в двоичных данных байт 0x7E, используется вставка бита (bitstuffing).

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

[menzoda]

Если говорить о других вариантах, то вот допустим нашел Microchip-овский appnote. Там преамбула представляет собой "1010...10101 0000 10". Причем, как я понял из кода, последовательность нулей и единиц никак не используется, а начало кадра и длительность бита вычисляется с помощью вот этого вот интервала из четырех нулей и последнего стартового бита "10". Но как-то слишком просто.

[Goldsmith]

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

Если двоичные данные достаточно равномерно распределены, то вероятность появления последовательности из пяти единиц подряд 1/32. В среднем на блок из 32*5=160 бит) будет добавляться еще один "лишний". Накладные расходы не превысят 1%, не слишком велики.

Насчет "расточительности" самого манчестерского кодирования (два такта на бит) - тут все равно деваться некуда, уж таков он по определению. Зато масса других преимуществ благодаря этому.

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

IMHO 6-битный флаг коротковат, чаще придется вставлять паразитные биты. Возрастут накладные расходы.

[menzoda]

Думаю, пока начну реализовывать вариант с байт-стаффингом. Если появятся лучшие варианты - переделаю.
Кстати, сейчас возник еще один вопрос. Чтобы полностью отловить последовательность "01111110" в начале кадра, необходимо, чтобы манчестерский декодер уже был синхронизирован по границе бита и уверенно декодировал эти самые биты, так? Значит перед флагом придется добавить еще несколько незначащих бит, чтобы декодер к моменту поступления флага не "съел" его биты в целях своей синхронизации.

[Goldsmith]

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

Я бы попробовал обойтись бит-стаффингом, вроде Ваш протокол должен позволить.

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

Вполне реально обойтись без лишних битов, последовательность "01111110" это позволяет. Для синхронизации достаточно единственного перехода из 0 в 1 или из 1 в 0.

Декодер синхронизируется по первому встреченному переходу 0->1 в начале последовательности, и приемник переходит на поиск флага (6 идущих подряд единиц). Обнаружив флаг, начинает прием фрейма, пока не встретит второй такой же флаг, обозначающий конец фрейма.

[menzoda]

Я бы попробовал обойтись бит-стаффингом, вроде Ваш протокол должен позволить.

Пардон. Конечно же бит-стаффинг. Перепутал.

Вполне реально обойтись без лишних битов, последовательность "01111110" это позволяет. Для синхронизации достаточно единственного перехода из 0 в 1 или из 1 в 0.

Хм... А ведь верно. Спасибо.

[menzoda]

Ну что же. Я реализовал битстаффинг с помощью конечного автомата, если кому интересно. Все работает отлично. Спасибо.

[Goldsmith]

Куда более интересно, какие инструментальные средства использовали для проектирования и реализации конечного автомата?

[menzoda]

Какие инструментальные средства использовали для проектирования и реализации конечного автомата?

Хм. Голова, руки и клавиатура, вот мои инструментальные средства! А если серьезно, то автомат простенький выходит, чего его проектировать. Да и не люблю я автоматы (даже сложные) каким-то особым образом моделировать/проектировать/отлаживать. Рисую на бумажке, реализую в коде и отлаживаю.

[Goldsmith]

Да и не люблю я автоматы (даже сложные) каким-то особым образом моделировать/проектировать/отлаживать. Рисую на бумажке, реализую в коде и отлаживаю.

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

Сам я пока остановился на Quantum Framework, но интересуюсь и другими возможными решениями. Потому и задал этот не праздный вопрос.

[menzoda]

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