Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: востановление тактовой частоты из Ethernet пакетов
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам
kvv_spb
Здравствуйте, подскажите плз. как лучше реализовать,
применительно к передачи E1 трафика поверх Ethernet:
приходят Ethernet пакеты
Задача на приёмной стороне выделить тактовую из этих пакетов.
восстановление планируется делать на FPGA Cyclone3.
Mahagam
эзернет - вещь пакетная. а прохождение пакетов через свитчи и прочие езернет-устройства и даже к "несущей" частоте эзернета не дадут привязаться.
как мне видится - только большой буфер и динамическая регулировка частоты.
_pv
Цитата
Задача на приёмной стороне выделить тактовую из этих пакетов.
восстановление планируется делать на FPGA Cyclone3.

ieee 1588

Цитата( @ Jan 27 2010, 21:23) *
эзернет - вещь пакетная. а прохождение пакетов через свитчи и прочие езернет-устройства и даже к "несущей" частоте эзернета не дадут привязаться.

если все устройства, через которые пакет проходит, поддерживают такую синхронизацию, то почему бы и нет.
zltigo
Цитата(_pv @ Jan 27 2010, 22:32) *

Вы совсем не поняли о чем речь sad.gif


Цитата(kvv_spb @ Jan 27 2010, 17:05) *
Здравствуйте, подскажите плз. как лучше реализовать,

Никак. Обычно мирятся с проскальзываниями (выбрасывая/дублируя отсчеты). При этом канал сигнализации выделяют из потока и инкапсулируют в IP фреймы. Или используют глобальную синхронизацию GPS (это совершенно отдельная хорошо оплачиваемая тема), либо городите, как Вам тут уже намекали, подстройку ведомого по анализу проскальзований.
kvv_spb
как говорят RFC (5087,4553,5086,4197) тактовую можно выжелить несколькими способами(как я себе это понял):
выбелю 2 из них:
согласно RFC4197:
1.общая линия синхронизации <-- в моём случае недоступна=> вариант отпадает.
2 . В этом сценарии синхросигналы могут явно передаваться PE на входе устройству PE на выходе (например, с помощью RTP).
<-- так пишет RFC
как я понял (из анализа других RFC) тактовая выделяется из пакетов, по разнице времени их прихода и их кол-ва
хатя я сдесь не уверен....
TU-104
Подниму тему. Может за 6 лет появились какие-то готовые математические алгоритмы? Или еще какие-то идеи подскажут...
krux
а что там сложного?
на передающей стороне на частоте, которую хотим передать, крутится счетчик-часы, его значение пишется в заголовках RTP.
на приемной стороне из заголовков RTP счетчик вынимается, по дельте за длинный промежуток определяется уход тактовой на N тактов на приемной частоте. приемная частота корректируется при помощи коэффициентов для DPLL.
приемная частота при этом конечно "дышит" туда-сюда, но проскальзываний позволяет избежать. я такое делал.
TU-104
Цитата(krux @ Apr 30 2016, 14:38) *
а что там сложного?
на передающей стороне на частоте, которую хотим передать, крутится счетчик-часы, его значение пишется в заголовках RTP.
на приемной стороне из заголовков RTP счетчик вынимается, по дельте за длинный промежуток определяется уход тактовой на N тактов на приемной частоте. приемная частота корректируется при помощи коэффициентов для DPLL.
приемная частота при этом конечно "дышит" туда-сюда, но проскальзываний позволяет избежать. я такое делал.

Ну если так, то вроде ничего сложного.
Просто думал, может, щас подскажут какие-то другие варианты... Например, измерить частоту(как в соседней ветке меряют), пусть с точностью +-1Гц, а на той стороне выставить эту базовую частоту и "гулять" в районе 2Гц. Как вариант.
Corner
Немного лучший метод используется в протоколах синхронизации для сетей с фиксированной архитектурой. Получатель копирует счетчик, когда тот меняется и возвращает отправителю. Отправитель меняет скорость счета, подгоняя фазу. Алгоритм чем-то похож на ФАПЧ с обратной связью. Время интегрирования тоже надо большое. Как минимум, больше максимальной задержки в сети. В пользовательских сетях работает не лучше варианта с одним счетчиком и может пойти в разнос.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.