Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: звук по диф.паре в цифровом виде
Форум разработчиков электроники ELECTRONIX.ru > Аналоговая и цифровая техника, прикладная электроника > Цифровые схемы, высокоскоростные ЦС
qalex
В общем необходимо построить такую систему, чтобы по диф.паре передавать звук в цифровом виде в обоих направления "одновременно", например человек говорит в микрофон и слышит сам себя в наушниках. Преобразовать в цифру не проблема, а вот как обработать это потом? Теоретически должнобыть похоже на I2C, т.е. master выставляет на шину адрес, slave принимает и т.д. А вот практически, какая микросхема способна справиться с этим?


Фактически диф.пару можно принять за один провод.
Саша Z
Цитата(qalex @ May 30 2007, 23:08) *
В общем необходимо построить такую систему, чтобы по диф.паре передавать звук в цифровом виде в обоих направления "одновременно", например человек говорит в микрофон и слышит сам себя в наушниках. Преобразовать в цифру не проблема, а вот как обработать это потом? Теоретически должнобыть похоже на I2C, т.е. master выставляет на шину адрес, slave принимает и т.д. А вот практически, какая микросхема способна справиться с этим?
Фактически диф.пару можно принять за один провод.


Хмм, не совсем понял, хотите дифференциальный канал ? В принципе в моем понимании это больше относится к аналоговым аспектам сигнала, обычно для лучшей помехоустойчивости, хотя наверно есть и в цифровом виде (т.е. цифровые данные передаваемые по одному каналу есть бинарная инверсия данных второго канала). Вы это имеете ввиду ?

Одновременно - вы говорите о full duplex ? То о чем вы написали ("говорит в микрофон и слышит себя в наушниках) - это один канал, т.е. идет передача со входа на выход, второго канал тут не вижу вообще.
Если вы действительно имеет ввиду просто говорить и слышать себя-же - по идее не проблема. Просто сигнал оцифруется, заводится в систему и выводится оттуда на выход (после DAC на наушник). Естественно, 100% одновременно" не получиться - всегда есть задержка, хотя на слух она может быть и не заметна.
Если вышеизложенное есть то что вам нужно, не вижу тут никакой надобности в какой-либо обработке сигнала в плане DSP - просто IN > OUT как FIFO. Не вижу тут завязки на I2C протокол..Конкретная реализация зависит от ваших намерений к реализации - можно например сделать на каком-нить простеньком FPGAе с подключенными ADC/DAC и соотв. аналоговыми фильтрами (anti-alaising по входу anti-imaging по выходу). Ежели вы принципиально хотите это прогонять через DSP систему - есть кучу недорогих DSK (development board) процессоров DSP (от тех-же TI например или Analog Devices, но тут влезают кучу аспектов программирования под DSP....этот field для меня пока еще нов, сам его сейчас только начал осваивать... smile.gif
AVL
Цитата(qalex @ May 30 2007, 23:08) *
В общем необходимо построить такую систему, чтобы по диф.паре передавать звук в цифровом виде в обоих направления "одновременно"... Теоретически должнобыть похоже на I2C...


Практически физический протокол I2C (2 двунаправленных электрически независимых сигнала с открытым коллектором) для данной задачи не подходит никак.
Среди стандартных протоколов можно применить USB, Ethernet (в режиме half duplex), они работают как раз с диф.парой и данные в обе стороны. В случае USB одна сторона будет host, другая - device. На сколько я себе представляю, сторона host достаточно сложна. С Ethernet все проще.
Также еще CAN посмотрите, тоже должен подойти.
И еще, конечно, можно сделать свой проект на ПЛИС по своему протоколу.
qalex
Спасибо за ответы. Первоночальная формулировка была не совсем понятна и правильна. Диф. пара для передачи на расстояние. Можно принять за один провод.Можно построить систему ( к примеру) так - два кодека A и Б, оба обмениваются информацией, которая по времени разделена например на 2 раздела. В первом разделе от А к Б, во втором Б-А, в разных кодах. Соответствующий кодек получает информацию, видит что началась передача и декодирует информацию . Потом наоборот. Идет постоянный обмен между ними. Это также похоже на разговор двух людей по мобильнику, кажется что одновременно, а на самом деле все квантуется с большой скоростью.
Это действительно может быть похоже на ETHERNET. Надо поисткать соответствующие аппликации.

А вот по поводу ПЛИС тоже интересно, только вот мы с ними не работали.

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

Только что посмотрел стандарт Ethernet - не подходит. Передача ведется по двум витым парам, т.е. фактически по двум проводам. А нужно по одному.
AVL
Цитата(qalex @ Jun 1 2007, 17:35) *
Только что посмотрел стандарт Ethernet - не подходит. Передача ведется по двум витым парам, т.е. фактически по двум проводам. А нужно по одному.


В случае Ethernet в режиме half-duplex можно передавать по одной дифференциальной паре.

...На каком максимальном расстоянии могут находиться ваши узлы?

P.S. если интересует, у меня есть готовый проект на ПЛИС (пишите в почту)
Alex11
Посмотрите еще на интерфейсы цифровых телефонных аппаратов. Там 2 МБит/сек скорость и попеременно отправляемые пакеты в обе стороны. Для звуковых данных достаточно, даже 2 канала двунаправленных можно протянуть. Если нужна скорость выше и полный дуплекс - то можно поглядеть на SDSL связь, но там чипы тяжелые и трудно доставаемые.
AVL
Цитата(qalex @ Jun 2 2007) *
Максимальное расстояние 100м.

Ответить на Ваше письмо нет возможности, у Вас статус 'validating' и нет контактов.
Пишу ответ здесь...

Соответственно USB не подойдет. Остаются варианты Ethernet, CAN, DSL и вариант на ПЛИС по собственному разработанному протоколу.

варианты на ПЛИС:
1) Готовый проект (обмен по одной диф.паре) у меня работает на расстояниях до 10м.
2) Также есть проект, работающий по 2-м диф.парам (полный дуплекс), и работающий на расстояниях до 400м.

То есть с учетом того, что Вам нужно до 100м, готового проекта у меня нет. Но в принципе можно рассмотреть вариант разработки проекта на ПЛИС, работающего на расстояниях до 100м в режиме полудуплекс, используя предыдущие наработки.

P.S. и все же нужно провести анализ и выбрать наиболее экономичное решение в плане денежных затрат. Если Вы планируете несколько экземпляров изделий, то дешевле построить устройство на микросхемах, использующие стандартный протокол. Если партия большая, то дешевле на ПЛИС.
hdmi
Пользователь qalex заблокирован, подтверждения не приходят на мыло. Я за него cool.gif


p.s. AVL см.приват
Oldring
Передать битики - не особая проблема. Есть другие подводные камни. Нужно не забыть про синхронизацию тактовых генераторов на обеих сторонах.
Stanislav
Цитата(qalex @ Jun 1 2007, 17:35) *
Спасибо за ответы. Первоночальная формулировка была не совсем понятна и правильна. Диф. пара для передачи на расстояние. Можно принять за один провод.Можно построить систему ( к примеру) так - два кодека A и Б, оба обмениваются информацией, которая по времени разделена например на 2 раздела. В первом разделе от А к Б, во втором Б-А, в разных кодах. Соответствующий кодек получает информацию, видит что началась передача и декодирует информацию . Потом наоборот. Идет постоянный обмен между ними. Это также похоже на разговор двух людей по мобильнику, кажется что одновременно, а на самом деле все квантуется с большой скоростью...


Посмотрите чипаки для ISDN. Может, там чего обрящете. smile.gif
Ну, и стандарты почитать не грех, чтобы понимать, о чём речь. Передача полным дуплексом по витой паре в ISDN точно есть, и кодеки для этих целей готовые имеются (какие именно - сейчас не скажу: давно этим не занимался).
zltigo
Цитата(AVL @ Jun 1 2007, 22:52) *
В случае Ethernet в режиме half-duplex можно передавать по одной дифференциальной паре.

???
Stanislav
Цитата(Oldring @ Jun 5 2007, 01:35) *
Передать битики - не особая проблема. Есть другие подводные камни. Нужно не забыть про синхронизацию тактовых генераторов на обеих сторонах.
Интересно, а как можно передать (и принять!) битики без синхронизации генераторов на обеих сторонах? Режим-то дуплексный...
Кстати, синхронизацию тактовых генераторов для этого делать вовсе не обязательно.
zltigo
Цитата(Alex11 @ Jun 2 2007, 22:59) *
Посмотрите еще на интерфейсы цифровых телефонных аппаратов. Там 2 МБит/сек скорость

Нет ISDN это 2B+D - 128Kbit+16Kkbit
И помирают производители прямо на глазах. Считай один Infinion остался, на NEC стаааренький чип тянет.
Цитата
Если нужна скорость выше и полный дуплекс - то можно поглядеть на SDSL связь, но там чипы тяжелые и трудно доставаемые.

SHDSL - вот тут тут уже и мегабиты могут быть, чипы тяжелые, но абсолютно доставаемые. В принципе легко использовать готовые модемы в разнообразнейших конструктивных исполнениях - от законченных коробочных конcтрукций до субмодулей.
AVL
Цитата(zltigo @ Jun 5 2007, 02:42) *
???


Для передачи по одной диф. паре в случае Ethernet в режиме half-duplex, как один из вариантов решения, потребуется вместо 2-х 2-х обмоточных трансформаторов поставить 2 3-х обмоточных и 2 высокоскоростных диф. ОУ в режиме повторителей. Один из трансформаторов для линии (смеситель), другой трансформатор для подавления сигнала с выхода фисивера на его вход. Повторители напряжения нужны для развязки трансформаторов (направление сигнала только в одну сторону).
zltigo
Цитата(AVL @ Jun 5 2007, 14:12) *
Для передачи...

Вы сами-то эту ..... дифсистему то городить-то пробовали?
Oldring
Цитата(Stanislav @ Jun 5 2007, 02:46) *
Интересно, а как можно передать (и принять!) битики без синхронизации генераторов на обеих сторонах? Режим-то дуплексный...
Кстати, синхронизацию тактовых генераторов для этого делать вовсе не обязательно.


См. "плезиохронность".
AVL
Цитата(zltigo @ Jun 5 2007, 15:45) *
Вы сами-то эту ..... дифсистему то городить-то пробовали?


Именно для Ethernet не делал. Делал подобное для других задач. Естественно при реализации возникнут проблемы. Но они решаемы.
Stanislav
Цитата(Oldring @ Jun 5 2007, 15:59) *
См. "плезиохронность".
Ух ты! Опять "вумные" слова.
Не соблаговолит ли Автор пояснить, каким боком эта "плезиохронность" соотносится с утверждением:
Цитата(Oldring @ Jun 5 2007, 01:35) *
Передать битики - не особая проблема. Есть другие подводные камни. Нужно не забыть про синхронизацию тактовых генераторов на обеих сторонах.
?
В частности, интересно было бы узнать трактовку понятия "плезиохронность" в свете "синхронизации тактовых генераторов", и непременного его выполнения для "передачи и приёма битиков". А также, где здесь запрятаны "подводные камни"?

Цитата(zltigo @ Jun 5 2007, 15:45) *
Вы сами-то эту ..... дифсистему то городить-то пробовали?
Сделать можно. Например, как это реализовано на коаксиале. Там система с разделением времени доступа.

Цитата(zltigo @ Jun 5 2007, 02:52) *
И помирают производители прямо на глазах. Считай один Infinion остался, на NEC стаааренький чип тянет...
Да, это, пожалуй, я не учёл... Темпоро мутанто...
hdmi
Что то я уже совсем запутался, как эти битики передать, по какому протоколу. Проблема не в диф.системе( тут есть некоторые наработки), а в кодировании сигналов, как и чем.
blackfin
Цитата(hdmi @ Jun 6 2007, 21:58) *
Что то я уже совсем запутался, как эти битики передать, по какому протоколу.

Манчестер + ВременноеУплотнение (TDM).
hdmi
Цитата(blackfin @ Jun 6 2007, 21:11) *
Манчестер + ВременноеУплотнение (TDM).


А что есмь - манчестер???
Stanislav
Цитата(hdmi @ Jun 6 2007, 21:58) *
Что то я уже совсем запутался, как эти битики передать, по какому протоколу. Проблема не в диф.системе( тут есть некоторые наработки), а в кодировании сигналов, как и чем.
Постановка задачи изначально не полна. Нужно указать все существенные требования к качеству звука и системе передачи-приёма, а также, по возможности более полно, описать все физические особенности канала.
Способов кодирования существует множество. Для речевого сигнала - это от простого A-law или Mu-law до "навороченных" вокодеров. Скорости передачи данных при этом могут варьировать от десятков килобит до сотен бит в секунду.
В простейшем случае, если расстояние не слишком велико (до сотен метров), можно сделать так: берёте два МК с УАРТ-ами на борту и подключаете их к витой паре с использованием драйверов RS-485/RS-422. К каждому МК подключаем АЦП (если качества звука высокого не нужно, можно использовать внутренний) и ЦАП (иногда достаточно ШИМ). Один из МК объявляем ведущим, второй - ведомым.
Суть протокола сводится к следующему. Ведущий МК посылает в линию текущий отсчёт сигнала, и переключается на приём. Ведомый дожидается окончания приёма, после чего переключается на передачу и "выплёвывает" в сеть свой отсчёт, вновь затем переключаясь на приём. Далее, ведущий дожидается прихода нового отсчёта с АЦП, и цикл повторяется. После каждого сеанса приёма МК выводят принятые отсчёты в ЦАП-ы.
Full-duplex в этом случае получается за счёт такого вот простейшего протокола обмена.
Обсуждать применение других способов (эхоподавление, временнОе и частотное разделение) уместно только при грамотной постановке задачи.
AVL
Цитата(Stanislav @ Jun 7 2007, 23:41) *
Суть протокола сводится к следующему. Ведущий МК посылает в линию текущий отсчёт сигнала, и переключается на приём. Ведомый дожидается окончания приёма, после чего переключается на передачу и "выплёвывает" сеть свой отсчёт, вновь затем переключаясь на приём. Далее, ведущий дожидается прихода нового отсчёта с АЦП, и цикл повторяется...
Full-duplex в этом случае получается за счёт такого вот простейшего протокола обмена.

Full-duplex в таком случае никак не получается smile.gif
То, что Вы предлагаете - это half-duplex с использованием одной диф.пары. Как раз то, что автор хочет.
Stanislav
Цитата(AVL @ Jun 8 2007, 10:31) *
Full-duplex в таком случае никак не получается smile.gif
То, что Вы предлагаете - это half-duplex с использованием одной диф.пары. Как раз то, что автор хочет.
Ну, это вопрос терминологический. smile.gif
Если разруливание идёт по каждому конкретному отсчёту, никаких очередей не создаётся, то, с моей точки зрения, режим нужно называть full duplex-ом.
el34
тут не упомянут S/PDIF протокол - он напрямую заточен для передачи звука и может работать в коаксиал или витую пару...
кодеки (cirrus, adi) есть в продаже....
для (поул)дуплекса надо будет немного поковырятся, но с дополнительными внешними устройствами думаю можно приспособить.....
AVL
Цитата(el34 @ Jun 8 2007, 12:40) *
тут не упомянут S/PDIF протокол - он напрямую заточен для передачи звука и может работать в коаксиал или витую пару...
кодеки (cirrus, adi) есть в продаже....
для (поул)дуплекса надо будет немного поковырятся, но с дополнительными внешними устройствами думаю можно приспособить.....

Нашел еще упоминания про протокол AES/EBU. Нормальной спецификации не нашел ни на протокол S/PDIF, ни на протокол AES/EBU (все надо покупать).
По информации, которую смог найти:
1) S/PDIF обеспечивает передачу в одном направлении (коаксиал, обычно до 10м). У cirrus есть как отдельные приемники и передатчики, так и трансиверы. Для соединения трансиверов используется 2 кабеля.
2) AES/EBU разрабатан для передачи на большие расстояния (до 1000м), причем информация передается в обе стороны по одному кабелю (витая пара).

Может у кого есть еще информация? или оригиналы описания стандартов S/PDIF и AES/EBU?
hdmi
Вот нашел интересный кодек от cirrus
http://www.cirrus.com/en/products/pro/detail/P1034.html.
По моему должно подойти. Или нет?
el34
hdmi>http://www.cirrus.com/en/products/pro/detail/P1034.html.
hdmi>По моему должно подойти. Или нет?

ну это смотря для чего.... как аудио кодек .... может...
а как интефейс - вряд ли...
вот тут интерфейсные лежат....
приемники и передатчики....
http://www.cirrus.com/en/products/pro/areas/PA68.html
AVL
Цитата(el34 @ Jun 9 2007, 01:22) *
вот тут интерфейсные лежат....
приемники и передатчики....
http://www.cirrus.com/en/products/pro/areas/PA68.html

Эти микросхемы не поддерживают двунаправленный обмен по одной диф.паре.
el34
AVL>Эти микросхемы не поддерживают двунаправленный обмен по одной диф.паре.

это конечно...
но , если добавить внешнее управление и использовать для передачи удвоенную частоту квантования или служебные посылки то организовать можно....
мультиплексировать напр так:
одну посылку посылаем ....
её принимаем местным(то, что он принял - выкидываем) и удаленным приемником(удаленный передатчик передает в этот момент в NUL(в никуда))...
следующую(удаленную) принимаем(ее же принимает в этот момент и удаеленный приемник(выкидываем)) а местный передатчик в это момент перенаправляем в NUL.....
если в системе будет один "мастер" то синхорнизироватся можно без проблем....
AVL
Цитата(el34 @ Jun 9 2007, 12:04) *
это конечно...
но , если добавить внешнее управление и использовать для передачи удвоенную частоту квантования или служебные посылки то организовать можно....
мультиплексировать напр так:
одну посылку посылаем ....
её принимаем местным(то, что он принял - выкидываем) и удаленным приемником(удаленный передатчик передает в этот момент в NUL(в никуда))...
следующую(удаленную) принимаем(ее же принимает в этот момент и удаеленный приемник(выкидываем)) а местный передатчик в это момент перенаправляем в NUL.....
если в системе будет один "мастер" то синхорнизироватся можно без проблем....

Для того, чтобы сделать что-то подобное этому, необходимо поставить ПЛИС + LIU. Поскольку ставим ПЛИС+LIU, то нет смысла в трансиверах S/PDIF, даже со встроенными аудио кодеками. Нет смысла, потому что на ПЛИС можно сделать весь протокол, причем не обязательно S/PDIF. Сделать так, как это удобно для данной задачи.

P.S. Как правильно написал Stanislav, постановка задачи не полна. Вопрос к hdmi, какие требования к передаче звуковой информации? (частота дискретизации, битовое разрешение, тип кодирования звуковых данных (linear PCM, A-law/u-law, ADPCM, или что-то еще)
el34
AVL>Для того, чтобы сделать что-то подобное этому, необходимо поставить ПЛИС + LIU.

ПЛИС тут совсем не нужна ....
uC конечно нужен....
и задача получается довольно простая (имхо)....
конечно же можно и кучу других способов предложить....

а вот делать на плис протокол , да фапчи, да контроль ....
совсем не тривиально....
есть уже готовые мс для этого....
AVL
Цитата(el34 @ Jun 9 2007, 12:56) *
AVL>Для того, чтобы сделать что-то подобное этому, необходимо поставить ПЛИС + LIU.

ПЛИС тут совсем не нужна ....
uC конечно нужен....
и задача получается довольно простая (имхо)....
конечно же можно и кучу других способов предложить....

Из Вашего поверхностного описания, то насколько я смог Вас понять, пришел в выводу, что эту логику можно сделать на ПЛИС. Значит я не правильно понял. Если Вам не сложно, могли бы Вы рассказать более детально алгоритм, который Вы предлагаете?

Цитата(el34 @ Jun 9 2007, 12:56) *
а вот делать на плис протокол , да фапчи, да контроль ....
совсем не тривиально....
есть уже готовые мс для этого....

Пока с готовыми микросхемами не так все просто. Возможно в продаже и есть подходящее, но пока такой информации не нашли.
hdmi
А почему кодек CS42406 не подойдет? У него двунаправленный вход. После него поставить драйвер для диф.пары. И есть также вход для 2х каналов анадогового звука и выход 6 каналов .
AVL
Цитата(hdmi @ Jun 9 2007, 18:01) *
А почему кодек CS42406 не подойдет? У него двунаправленный вход. После него поставить драйвер для диф.пары. И есть также вход для 2х каналов анадогового звука и выход 6 каналов .

Нет там такого. Этот кодек вообще не предназначен для работы на линию.
el34
AVL>Пока с готовыми микросхемами не так все просто. Возможно в продаже и есть подходящее, но пока такой информации не нашли.

я покупал в www.terraelectronica.ru

AVL>Из Вашего поверхностного описания, то насколько я смог Вас понять, пришел в выводу, что эту логику можно сделать на ПЛИС. Значит я не правильно понял. Если Вам не сложно, могли бы Вы рассказать более детально алгоритм, который Вы предлагаете?

скажу по другому:
на обоих концах линии связи стоят по 1 мс приемника и передатчика....
они работают напр. на удвоеной частоте квантования сигнала речи...
используется доступ с разделением времени...
в одном временном интервале передает передатчик ус-ва A - при этом приемник ус-ва B на приеме в следующий временной интервал наоборот...
для поддержания работы PLL микросхемы приемника, она работает на прием без пропуска циклов (принимает сигнал и удаленного и местного передатчика)...
в качестве опорного генератора мс передатчика используется выход PLL приемника...
для мультиплексирования достаточно одной мс 4х2в1 mux ну может еще чуток по мелочи....
и 485 приемопередатчик
при этом для управления использовать uC....
можно реализовать мультиплексирование/синхронизацию и без uC только с применением CPLD....


если взять пару CS8406-CS8416, то при их работе на 192kHz, при этом для речи использовать Fs= 24kHz - можно организовать до 8 временных слотов....
это позволит передавать и аудио и управление и тп и тд....
хотя вполне достаточно и удвоенной частоты работы приемника и передатчика....
AVL
Цитата(el34 @ Jun 9 2007, 21:09) *
AVL>Пока с готовыми микросхемами не так все просто. Возможно в продаже и есть подходящее, но пока такой информации не нашли.
я покупал в www.terraelectronica.ru

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

Цитата(el34 @ Jun 9 2007, 21:09) *
скажу по другому:
на обоих концах линии связи стоят по 1 мс приемника и передатчика....
они работают напр. на удвоеной частоте квантования сигнала речи...
используется доступ с разделением времени...
в одном временном интервале передает передатчик ус-ва A - при этом приемник ус-ва B на приеме в следующий временной интервал наоборот...
для поддержания работы PLL микросхемы приемника, она работает на прием без пропуска циклов (принимает сигнал и удаленного и местного передатчика)...
в качестве опорного генератора мс передатчика используется выход PLL приемника...
для мультиплексирования достаточно одной мс 4х2в1 mux ну может еще чуток по мелочи....
и 485 приемопередатчик
при этом для управления использовать uC....
можно реализовать мультиплексирование/синхронизацию и без uC только с применением CPLD....
если взять пару CS8406-CS8416, то при их работе на 192kHz, при этом для речи использовать Fs= 24kHz - можно организовать до 8 временных слотов....
это позволит передавать и аудио и управление и тп и тд....
хотя вполне достаточно и удвоенной частоты работы приемника и передатчика....

Хорошо. А вы в курсе, что задержка сигнала на кабеле длиной 100м составит от 600нс до 1мкс в зависимости от типа кабеля? А на другой длине величина задержки будет другой.
Допустим узел B у Вас засинхронизировался от узла A. Но после того, как узел B начнет передавать, сигнал от B к A вернется с задержкой фазы величиной 2 задержки распространения сигнала по кабелю. Суть проблемы уловили? то, что PLL приемника A будет вести себя немного странно wink.gif

Цитата(hdmi @ Jun 9 2007, 18:01) *
А почему кодек CS42406 не подойдет? У него двунаправленный вход. После него поставить драйвер для диф.пары. И есть также вход для 2х каналов анадогового звука и выход 6 каналов .

Что Вы под драйвером подразумеваете? LIU+framer? если да, то тогда в принципе любой кодек подойдет, необязательно CS42406.

Вам лучше написать требования к передаче звуковой информации. (частота дискретизации, битовое разрешение, тип кодирования звуковых данных (linear PCM, A-law/u-law, ADPCM, или что-то еще)
А то действительно обсуждение теряет смысл.
el34
AVL>Суть проблемы уловили? то, что PLL приемника A будет вести себя немного странно smile.gif

предложил идею....
забраковали...
считаете , что не работоспособно....
ну и лады....
пс сорри за беспокойство...
AVL
Цитата(el34 @ Jun 9 2007, 22:45) *
AVL>Суть проблемы уловили? то, что PLL приемника A будет вести себя немного странно smile.gif

предложил идею....
забраковали...
считаете , что не работоспособно....
ну и лады....
пс сорри за беспокойство...

Да не обижайтесь smile.gif Давайте лучше дальше размышлять, если Вас интересует эта тема.
el34
AVL>Да не обижайтесь Давайте лучше дальше размышлять, если Вас интересует эта тема.

разумеется , никаких обид....

особых проблем в работе плл не вижу....
ведь синхру приемник берет из информацинонной посылки....
а местный передатчик синхронен с сигналом удаленного передатчика в месте приема (он ведь синхронен с приемником т.к. берет клок из него).... и поэтому дребезга врод. быть не должно....
имхо
короче не понял я проблему....
Stanislav
Братцы, предмета для спора нет пока...
Автору темы, как я понял, нужен именно протокол дуплексного обмена. Который можно выбрать только после задания существенно необходимых условий.
Я же предложил простеёший протокол только в качестве примера того, как некую систему дуплексной передачи данных можно организовать без всяких "наворотов" типа эхоподавления, PLL, и т.д.
Предлагаю подождать, пока автор темы дозреет до состояния грамотной постановки задачи. smile.gif
AVL
Цитата(Stanislav @ Jun 9 2007, 23:49) *
Братцы, предмета для спора нет пока...
Автору темы, как я понял, нужен именно протокол дуплексного обмена. Который можно выбрать только после задания существенно необходимых условий.
Я же предложил простеёший протокол только в качестве примера того, как некую систему дуплексной передачи данных можно организовать без всяких "наворотов" типа эхоподавления, PLL, и т.д.
Предлагаю подождать, пока автор темы дозреет до состояния грамотной постановки задачи. smile.gif

Я абсолютно согласен. Предлагаю больше не вести эту тему до момента получения необходимых исходных данных от автора.
el34
AVL> Давайте лучше дальше размышлять, если Вас интересует эта тема.

Вы уж чиркните пару слов в ответ на #40.....
плз...
зародили ведь во мне сомнение и что:

AVL>Предлагаю больше не вести эту тему до момента получения необходимых исходных данных от автора.

Stanislav>Братцы, предмета для спора нет пока...

ну это ,как Вы понимаете, не проблема ! smile.gif
hdmi
В принципе не ставил вопрос о параметрах звука в качестве краеугольного. Интересовал больше алгоритм реализации и конкретные аппликации.
Вообще на hi fi претендовать не будем. Можно даже пожертвовать качеством звука для увеличения устойчивости работы системы и её удешевления. Вобщем в этих вопросах можно всегда найти компромисс. А цифры... будут.
В любом случае ( даже если тему закроют) большое спасибо!
hdmi
Полоса пропускания 50Гц-18кГц. Частота дискретизации 44,1 кГц- для звука(для микрофона можно использовать и более низкую), битовое разрешение- 16 , тип кодирования звуковых данных - linear PCM.
Краткое описание работы системы - пользователь находясь на удалении 30 м. от компьютера(к примеру) слушает музыку, говорит в микрофон и слышит сам себя.
Aryel
Цитата(hdmi @ Jun 14 2007, 22:13) *
Полоса пропускания 50Гц-18кГц. Частота дискретизации 44,1 кГц- для звука(для микрофона можно использовать и более низкую), битовое разрешение- 16 , тип кодирования звуковых данных - linear PCM.
Краткое описание работы системы - пользователь находясь на удалении 30 м. от компьютера(к примеру) слушает музыку, говорит в микрофон и слышит сам себя.

А почему вам нужен именно цифровой сигнал для обоих направлений? И потом, если речь идет о микрофоне, который, как я полагаю, моно, то вы можете сделать так. На одной стороне ставите преобразователь STEREO - PCM, например на паре CS5340+CS8406, выход CS8406 преобразуете каким-нибудь аналоговым усилителем (например EL2140) в дифференциальный и подключаете к линии. К его выходу одновременно подключаете дифф. вход аналогового усилителя для приема сигнала микрофона со второй стороны кабеля. Поскольку SPDIF имеет частоту 6 mHz, то он не будет создавать помеху для аналогового сигнала микрофона (проверено). Ну а на другой стороне кабеля соответственно вешаете
SPDIF приемник (CS8416+CS4344) и микрофонный усилитель.
Удачи.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.