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

есть задача такая, нужно передать асинхронный поток 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.

Сообщение отредактировал Волощенко - Dec 22 2006, 10:36

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