доброго дня уважаемым.

есть задача такая, нужно передать асинхронный поток 9600 через 64-х килобитный тракт.
выглядет это так:
на одной стороне нужно засемплировать, ну скажкм uart, вложить семплы в один из таймслотов E1 а на другой стороне востановить.

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

ЗЫ:
сам я вижу решение - мерять счетчиком частоту импульсов с одной стороны и гнать это все на другую сторону..
тока чемороя много.
може кто знает проще решение

Так поток содержит стартстопные посылки (как в UART) или это непрерывный поток бит ???

Если старт-стопный метод передачи, то можно принимать по одному байту, передавать
на другую сторону в каком нибудь простеньком протоколе (позволяющем отличать
наличие значимых байт данных), а на другой стороне отдавать в формате стартстопной
посылки на скорости 9600+1e-4 (т.е. на максимально допустимой).
При этом выравнивание скоростей происходит за счет растяжки стоповых битов.

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

При этом возникает вопрос - какие у Вас заданы максимально допустимые дрожания
выходного сигнала ?

Методов передачи существует множество, но наиболее простые (наложение, SIP) дают
значительные дрожания, поэтому если требования по дрожаниям строгие (<15 % от тактового
интервала) приходиться на выходе ставить ФАПЧ (обычно цифровую ДАПФ) для подавления дрожаний, это уже посложнее будет.


При строгих требованиях к дрожаниям просто не получается.

Попробуйте для начала условия в которых задача решена должна быть описать. Иначе не понятно совсем
В общем случае (плезиохронный поток вошел-вышел-забрали канальный интервал)такое решается не просто. Почитайте, например, о классической железке FALC56 там как-раз джентельменский набор для УСПЕШНОГО решения подобных задач в РАЗНООБРАЗНЫХ условиях - Фреймер, HDLC контроллер....В каких-то очень частных случаях можно и какую-нибудь приблуду изобретать.

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

Для начала, начните с начала Кроме 9600 UART имеем 2 входых потока 2Mbit и два выходных потока 2Mbit. Частоты и фазы в общем случае отличаются. Ну джиттер, слипы само собой имеют место быть.
Задача синхронизироваься и держать цикловую (и сверхцикловую?) синхронизацию, выделить в потоках указанный таймслот вынуть-вставить битики.
Ну а уж как пустые биты/фреймы передавать уже дело если и не десятое, то уж не первое. Если организуется битовый поток, то волшебное слово называется HDLC протокол, если сможете байтовый организовать, то SLIP протокол.

описывается задача примерно так:
есть асинхронный поток С1-ФЛ-БИ генерируемый устройством, которое нельзя не то что в схеме увидеть а даже на приборную его панель нельзя взглянуть.
есть плата в составе пиз!"№;тенного монстра коммутатора Е1. на плате есть пару микрух которые физику на С1 обеспечивают и альтера. на альтеру заходит Е1 2.048Мбит в один из таймслотов которого мне нужно положить сампленые отсчеты.
с другой стороны их (отсчеты) нужно извлечь и в С1 запихать.


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

извиняюсь за мат..
но других слов нет


случай, я бы сказал, исключительно частный

ЗЫ:
одна из функций этой платы (уже слава богу реализованых) - передача по Е1 телеграфных каналов (50-75 бод)
)))))))))))))))


не знаю. с телефонией недавно работаю


но не на столько стобы совсем уж ) .. сделано это давно


эт кому как. не сильно я се представляю как это делается и с какой стороны глюков ждать

Интересно, откуда такое начало про 2 входных потока и 2 выходных? У автора про это ни слова. Кроме того, так как он уже говорит про "вложить семплы в один из таймслотов E1 а на другой стороне востановить" - значит у него есть железяка, которая берет байтики с локальной шины или какого-то внутреннего линка и засовывает их в E1, обеспечивая всю необходимую синхрнизацию. А слово HDLC я вообще-то тоже знаю - только зачем человека пугать?

А как Вы собираетесь физически подключаться? Параллельно Или предполагаете, что на железку
приходит 2Mbit и терминиируется в 9600? Слишком шикарно, для реальных систем.

Похоже именно этого у него и нет - была-бы и вопроса не было. Есть похоже есть какая-то "радиолюбительская" конструкция сделанная по первому наитию.

А чего пугать-то - возьмет фреймер и будет HDLC контроллер "в подарок".


Если думаете, что словосочетание "пару микрух" объяснило с чем имеем дело, то Вы ошибаетесь .
Одно понятно, что "заходит" скорее всего не E1, а что-то типа TDM - прием+передача+клок+фреймселест. Да?

Насколько я понял его последнее объяснение - непосредственно с E1 он не работает. И вообще, он вроде бы с самого начала писал про один слот E1, а не про E1. Про то как он в него будет что-то запихивать - он ничего не писал. А использовать штатный HDLC контроллер фреймера ради 9600 - тоже слишком жирно. Скорее всего он и так используется, но для других целей.

Короче - пока имеем в качестве описания "пару микрух", "Altera" и "E1", причем "E1" скорее всего имеет косвенное отношение к делу.

вобщем Е1 действительно имеет косвенное отношение к делу.
ко мне на плату приходит локальный линк который потом мапится в групповой Е1.

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

Прочитайте книгу "Синхронизация в телекоммуникационных системах" С.М. Сухмана, А.В. Бернова, Б.В. Шевкопляса.
http://www.zelax.ru/support/library
В частности, главу 4 - Проскальзывания синхронизации

хорошая глава =) читал

Не знаю, подойдет ли это Вам, но у нас эта проблема была решена в "железе", именно для 9600 в 64кбит.
Цепочка схем такая: RS-232, Mega128, преобразователь 8 параллельных бит в ST-BUS (последовательный поток) на MT8920, фреймер МТ9075, тракт ИКМ, ну а потом все тоже, только в обратном порядке. Основная задача всего изделия - это ИКМ30, а RS-232 как дополнительная функция для дистанционного мониторинга по RS-232.
Суть такова. На двух Mega128 к основному был добавлен еще такой алгоритм для обработки потоков от RS232 (благо соотношение скоростей 9600 и 64кбит это позволяло). Поступившие в Mega128 входные 8 бит делились на две тетрады, каждая из которых помечалась-слаживалась с 4-битным признаком первой и второй тетрады, затем они, как два байта, последовательно вставлялись в поток в соседние фреймы. Когда информации нет, то во фрейм передавался байт с признаком об ее отсутствии. Противоположная Mega128, опрашивает выделенный тайм-слот из фрейма, все это разворачивает, выделяет байт и сразу передает его в RS-232. Вот и все.
То есть синхронизировать ничего не потребовалось. Таким же образом передавали и на скорости 19200. Все это работает уже почти три года в составе ИКМ30.
Если у Вас иное схемное обрамление, то, возможно, придется применить CPLD. Удачи.

к Partisan спасибо за ссылку на книгу и на zelax.

Делал так.
На приёмной и передающей стороне ставится Fifo для выравнивания скоростей и передаваётся информацию о скорости на удалённую сторону. Там восстанавливается скорость и в С1.
Р.С. ГБшники приносили свою аппаратуру со стыком С1 - всё работало. Очень удивились.

а как информацию о скорости передавали??
в пакете каком то с признаком??

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



крутттаааа
гы..

В таймслоте один за одним передаются пакеты (m бит): заголовок, биты С1 (n бит), 1 бит для выравнивания скорости, 1 бит признака наличия бита выравнивания (можно 3 штуки и принимать решение мажоритарно).

На входе С1:

Пишем в FIFO из С1.

По уровню FIFO на входе принимаем решение: передавать или нет дополнительный бит.

Скорость передачи С1 в канале 64 кбит/с - ( n/m )*64 кбит/с или ( (n+1)/m )*64 кбит/с

На входе в FIFO пишем с v=9600 кбит/с - читаем с V=(n/m)*64 (< 9600),

если указатель FIFO идёт вверх - читаем с V=( (n+1)/m )*64 (> 9600),

если вниз- читаем с V=( (n)/m )*64 (< 9600).



На выходе С1:

Пишем в FIFO из ТДМ.
Читаем из FIFO и запуливаем в стык С1.

Скорость вычитывания из FIFO регулируем джиттером.
Если указатель FIFO идёт вверх - увеличиваем скорость вычитки 9600 + x ppm,
если вниз- уменьшаем скорость вычитки 9600 - x ppm.

П.С. Размер подстройки должен перекрыть возможные отклонения частот и скорости С1 от номиналов.

Можно попробовать пойти наиболее простым путем. На входе сдвиговый регистр, работающий синхронно с E1 на частоте 64кГц. Передаем полученные данные по выбранному таймслоту.
На обратной стороне в простейшем случае опять через сдвиговый регистр на частоте 64кГц прямо так и выдаем. В этом случае на выходе получается сильный джиттер. Но может быть и так работать будет.
Если нет, то можно сделать простейшую фапч и выровнять полученный поток, пересинхронизовать его на более высокой частоте, таким образом можно уменьшить выходной джиттер. Даже FIFO не понадобится.
Что делать в такой схеме со слипами даже не знаю.
Чтобы правильно обрабатывать слипы, по видимому нужно будет делать какой-то интелектуальный обмен с многократным дублированием посылок и их восстановлением на другой стороне.

Решал похожую задачу, скорость до 115к. Укладывал в 2 слота ( при мах. скорости). Все остальные Решал похожую задачу, скорость до 115к. Укладывал в 2 слота ( при мах. скорости). Все остальные ложились в один слот. Железка работала в составе изделия Т-130. Сигналы для функционирования - подсветка канала, клок(2м), выдавала Т-130. Задача сводилась в приеме RS-232 (тупо использовал Atmel89, 20 ног, 2 кБайт) выделения байта и укладка в тайм слот. Для этого использовал свой протокол передачи, если не изменяет память принцип следующий. на синхронный поток 64 кБит ложиться асинхронный в тот самый момент времени когда готов байт передачи (т.е даже в середине подсветки слота). Данные передается в формате: старт бит, 8 бит данные, бит парити, стоп бит. Стоп бит использовался двояко: 1 – идут данные, 0 – управление. Управление необходимо для согласования скоростей приема-передачи и сигнала ошибок канала (бит парити). Естественно в один тайм слот вся информация не ложиться для этого использовал программку управления в Atmelе, которая сшивала, разбивала и выделяла информационный байт из слота. Также в памяти Atmelа находился 15 байтный буфер (2 буфера) приема и передачи. В качестве железки сопряжения с Т-130 использовалcя Xilinx на 20К.

Есть серия рекомендаций ITU X50, X51, которая предлагает решение Вашей проблемы.

А куда/откуда и через что идёт(ут) этот(эти) E1?
Если цепочка длинная с кучей девайсов в цепи (та же ТФОП), то велика вероятность того, что не все её участки синхронизируются от единого источника частоты на уровне E1. Следовательно в некоторых узлах возможны "проскальзывание кадров E1", что приводит к выпадению или дублированию отдельных байтиков в 64кБит-ном потоке.
Т.е. очень желательно чтобы протокол передачи данных по этому 64кБитному потоку был с максимальной избыточностью!