Реконструкция часов для последовательного сигнала

Предположим, что у меня есть последовательный сигнал (пример ниже), который передается без сопутствующего тактового сигнала, я хотел бы найти схему (используя дискретные компоненты/ИС, возможно, ПЛИС, но не микроконтроллер), чтобы восстановить часы для этого сигнала .

Основная проблема заключается в том, что частота этого последовательного сигнала меняется со временем. Сигнал поступает от беспроводной ASIC. Когда передатчик ASIC включен, приемник выдает сигнал, как показано ниже.

Кроме того, ASIC может периодически (и асинхронно) отключаться через несколько секунд, и другой передатчик подключается к сети. Номинальная частота любого данного передатчика может составлять от 35 до 65 кГц из-за конструктивных особенностей.

В зависимости от того, какая мощность у передатчика, я видел, как одиночные часы ASIC дрейфовали на целых 2 кГц от номинальных 50 кГц во время непрерывной работы. Я никогда не измерял заметный сдвиг частоты менее чем за 20 кадров данных, но у меня нет фактического показателя скорости изменения тактовой частоты....

введите описание изображения здесь

На кадр приходится один стартовый бит, а в конце — бит четности и стоповый бит. В кадре может быть до 13 последовательных нулей. Между кадрами, поступающими от одного передатчика ASIC, всегда есть 4 нулевых цикла. Последовательно идут кадры с одного передатчика, но, как я уже говорил, передатчик может периодически отключаться, а другой может подключаться на другой тактовой частоте.

То, что я ищу, — это схема для восстановления часов, использующая комбинацию цифровой логики и дискретных аналоговых компонентов (не микроконтроллер!), которая очень надежна, может адаптироваться к дрейфующим часам и может фиксироваться на частотах в что широкий диапазон. Также я хотел бы найти конструкцию, которая хорошо масштабируется до более высоких частот, потому что будущие ASIC будут иметь гораздо более быстрый тактовый генератор передатчика (я слышал, что он будет в 20 раз быстрее).

FPGA будет использоваться для декодирования потока данных (и использования восстановленных часов, на самом деле это уже было реализовано до предположения о доступности часов), и, как таковая, может использоваться как часть схемы восстановления часов, если это поможет.

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

Похоже, что реальная проблема заключается в нестабильной мощности, которой подвергается ASIC. На самом деле, удивительно, что единственным результатом будет разная скорость. Если какой-то осциллятор так сильно меняется, то многие другие вещи тоже должны идти не так. В любом случае покажите график вашего сигнала во времени. Без этого слишком сложно сказать, что у вас есть на самом деле.
У меня нет никакого контроля над выводом ASIC, это работа для кого-то другого. Тем не менее, я буду работать над получением образца данных для публикации.
Я записал некоторые идеи, но у меня есть к вам вопрос, помимо того, что сказал Олин: вам действительно нужно восстановить часы для декодирования сигнала RZ?
Я использовал периферийный таймер микроконтроллера для декодирования сигнала с помощью конечного автомата в программном обеспечении, однако существует новая версия ASIC, которая будет иметь более быстрый сигнал, который необходимо обрабатывать с использованием пользовательской цифровой логики, поэтому я бы хотел бы получить представление о том, как восстановить часы, используя схему, а не алгоритм.
Ну это не РЗ. Вам понадобится PPL, чтобы правильно восстановить часы.
@JayKeegan, чтобы ответить на этот новый вопрос, мне нужно знать, какое оборудование вы можете / вы надеетесь использовать на конце rx. ПЛИС, микроконтроллер, ASIC...
Некоторые источники, которые я читал, описывают такой сигнал как RZ, другие показывают сигнал с положительными и отрицательными битами, сосредоточенными вокруг 0 ​​вольт. Не могли бы вы уточнить, как PLL используется для восстановления часов?
Восстановленные часы и поток данных, аналогичный показанному, будут переданы FPGA для выполнения вычислений и вывода декодированных данных на параллельную шину.
И еще один момент — насколько быстро может меняться скорость передачи данных? Если изменение может быть мгновенным, у вас действительно большие проблемы. Допустим, крайние значения составляют 33 кГц и 66 кГц для периодов 33 мкс и 16 мкс. Теперь предположим, что вы получаете «1» для периода 16 мкс, за которым следует 0 для 33 мкс и 1 для любого периода. Насколько вам известно, 33 мкс 0 могут быть 2 16 мкс 0. Если изменение частоты (и периода) может быть мгновенным, сказать об этом невозможно.
Часы одного устройства не сильно меняются во время работы, я думаю, плюс-минус 2 кГц максимум. Но я думаю, что из-за проблем с изготовлением / дизайном номинальная тактовая частота любого отдельного передатчика попадает где-то в указанный диапазон. Таким образом, один приемник должен иметь возможность захватывать частоты в любом месте этого диапазона. Это похоже на первую попытку создания ASIC для этого приложения в университетской лаборатории, в которой я помогаю.
woah woah woah, вы написали: «Основная проблема заключается в том, что частота этого последовательного сигнала меняется со временем». Это не устройства разные, поэтому я получаю разные частоты. Тогда проблема в другом. И еще раз спрошу: какое оборудование вы предполагаете использовать для восстановления этих часов? Если я правильно понимаю, вы разрабатываете ASIC, так ли это?
Есть ли известный шаблон в начале кадра? Если так, то, что это? Какое максимальное количество нулей может быть подряд в одном кадре? Ваши часы, полученные по шаблону запуска, должны быть стабильными и достаточно точными, чтобы справляться с максимальным количеством последовательных нулей.
Также есть последовательные кадры с одного и того же устройства? Промежуток между кадрами всегда составляет 4 временных интервала или это минимум? Кадр всегда имеет одинаковое количество бит?
Я добавлю все запрошенные дополнительные разъяснения после того, как уточню у людей, с которыми работаю. Прошу прощения за путаницу в этом вопросе, я новичок в этой области (старшекурсник EE).
Тут и Владимир Краверо, WhatRoughBeast. Я внес изменения в вопрос. Я надеюсь, что это проясняет все, что было задано. Я думаю, что уже есть хороший очень подробный ответ, представленный Дэйвом Твидом.

Ответы (4)

Восстановление часов из прерывистого потока импульсов — нетривиальная задача проектирования. Обычно я стараюсь центрировать фронт часов на импульсах, тогда край часов можно использовать для фиксации наличия/отсутствия импульса в триггере. Гибридная цифро-аналоговая схема демонстрирует концепцию более четко:

схематический

смоделируйте эту схему - схема, созданная с помощью CircuitLab

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

Поскольку вы работаете с FPGA, очень похожая вещь может быть сделана исключительно в цифровой области. Предположим, что у вас есть высокоскоростные часы (например, 10–50 МГц). Мы заменяем генератор заряда двоичным счетчиком вверх/вниз, заменяем ГУН на DDS, и вместо того, чтобы полагаться на ширину аналоговых импульсов, мы измеряем фазу DDS на переднем и заднем фронтах входных импульсов.

На следующей диаграмме все «висячие» тактовые входы подключены к высокоскоростным внутренним тактовым генераторам FPGA. Любые контакты с [] на концах их имен представляют собой многопроводные шины.

схематический

смоделируйте эту схему

Асинхронный вход RZ проходит через двухступенчатый синхронизатор, а затем детектор фронта. Регистры U3 и U4 захватывают старшие биты фазы DDS (U2) по переднему и заднему фронтам импульса RZ соответственно. Если мы рассматриваем значение фазы как двоичное число со знаком, передний фронт захватит отрицательное значение, а задний фронт зафиксирует положительное число. Мы сложим эти два числа вместе, и если мы полностью синхронизированы, они отменятся, и результат будет равен нулю. Однако, если часы опаздывают, отрицательное число будет больше, и сумма будет отрицательной. Поэтому мы просто берем бит знака на выходе сумматора (U5) и используем вентили для увеличения или уменьшения значения в нашем счетчике (U1), чтобы ускорить или замедлить часы. Обратите внимание, что вы' Мы хотим настроить этот счетчик так, чтобы он охватывал только интересующий диапазон частот. Другими словами, у него будет как минимальное значение, так и максимальное значение, за пределами которого он не будет учитываться.

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

Большое спасибо. Это уровень объяснения, который я надеялся найти, потому что это казалось, как вы сказали, «нетривиальной» проблемой дизайна. Я ценю, что вы также демонстрируете два разных метода.
Пожалуйста. У меня большой опыт создания точных часов и временных базисов в FPGA из различных источников.

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

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

Чтобы обнаружить все фронты, вы также можете использовать вентиль XOR: один вход для сигнала RZ, другой для того же сигнала, задержанного «бит». Когда и только когда входные данные различны, что происходит, когда у вас есть переход, выход будет высоким. Вам все равно нужно делить на два.

Я знаю, что не предложил практического решения, но надеюсь, что мой вклад поможет вам.

Похоже, этот ответ был написан до того, как изображение было добавлено к вопросу. Его необходимо пересмотреть, чтобы он соответствовал ситуации ОП.
@DaveTweed Я знаю, мне кажется, что ОП до сих пор не пояснил, о чем он спрашивает, особенно о изменчивости часов. Я пересмотрю свой ответ (или удалю его), когда вопрос будет окончательным.

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

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

Можно использовать микроконтроллер для большей части анализа; 50 кГц - это немного быстро, но, возможно, сработает, если у контроллера есть аппаратная поддержка для захвата данных или ему не нужно делать что-либо еще. Шансы микроконтроллера на успех могут быть особенно высоки, если, например, на кадр всегда приходится девять импульсов (если аппаратное обеспечение хранит байт на импульс с его приблизительной длиной, тогда, если текущий промежуток и девять предыдущих длиннее, чем любой из промежуточных, то промежуточные восемь, вероятно, образуют кадр данных, а тактовая частота должна составлять 1/20 их суммы). Выбор наилучшего подхода потребует немного больше знаний о том, что представляет собой входящий поток данных, какие его части являются фиксированными или переменными, насколько чистым или дрожащим он может быть и т. д.

Попробуй это. Предполагая, что данные имеют амплитуду +/- Vl. Используйте два компаратора, один из которых настроен на запуск при V1/2, другой — на -V1/2. Инвертируйте второй, а затем ИЛИ два сигнала. Вы можете сделать это с половиной четверного компаратора и половиной четверного вентиля ИЛИ-НЕ. (Это предполагает, что период данных намного больше, чем время распространения логики, и что отношение сигнал/шум данных достаточно велико.)

Спасибо за вашу помощь, пожалуйста, смотрите редактирование. Нулевой бит представлен как 0 вольт, а не отрицательное напряжение, которое возвращается к нулю.
ХОРОШО. Как заметил Владимир, это не RZ. Для того, что вы делаете, учитывая широкие частотные отклонения, я бы не рекомендовал PLL. Скорее используйте возможности FPGA для синтеза новых часов. Что-то вроде этого: используя высокочастотные часы, измерьте период между нарастающими фронтами. Поскольку вы знаете приблизительные границы частоты данных, установите верхний и нижний пределы того, что можно получить. Используйте измеренный период, чтобы установить период цепочки счетчиков, которая производит новые часы. Всякий раз, когда вы получаете действительную ячейку данных, вы обновляете тактовую частоту.
Хорошо, это звучит как хороший подход. Любая идея, насколько большая дисперсия тактовой частоты может быть допущена при использовании PLL?
Проблема с выполнением этого через PLL - это VCO. На самом деле вы можете получить очень широкий размах частоты (например, несколько порядков), но при этом увеличивается джиттер на восстановленных тактовых частотах. Кроме того, вам необходимо преобразовать зарядовый насос в интегратор по мере изменения частоты, чтобы сохранить неизменное демпфирование контура. Хотя в вашем случае это не проблема. Основная причина, по которой я предложил подход FPGA, заключается в том, что у вас уже есть FPGA, поэтому никаких дополнительных схем не требуется.
В вашем случае вы, вероятно, могли бы получить достаточную производительность от 74HC4046 с AD537 VFC. Многое будет зависеть от самого длинного отрезка всех нулей или всех единиц, с которыми вы столкнетесь.