Можно ли оцифрованные данные 16 бит 2 МГц передать по витой паре на 100 метров (и более)

если можно - в какую сторону смотреть,
хотелось бы чтобы передатчик не был слишком навороченным

Ethernet

Зачем? аля-485й вполне справится (только надо драйвер и приемник взять с соответствующим быстродействием). Тем более, что эзернет надо 100 (потому как 2*16=32МБит/с) и много другого надо воротить.

USB 2.0

интересно, это как это 485 справится, и нужно ли кодирование информации, как в Ethernet

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

А вообще, для корректного ответа на Ваш вопрос очень мало информации. Что есть источник информации, что есть приемник - например, эти данные хотелось бы получить.

И репитер через каждые 5 метров
USB - это офисный настольный интерфейс, также как и RS-232

А есть драйвера RS-485 на 32Mbit ? Да чтоб 100 метров.

На 20 точно есть. У AD. Надо у других глянуть.

На крайний случай можно 2 потока организовать. Наверняка ж обычная витуха CAT5 ляжет, пар аж 4 штуки.

ИМХО асинхронный протокол при таком битрейте не подойдет. Это же нужно чтобы разбег тактовых частот был не хуже 0,2-0,5%. Даже при тактовой 64МГц требования к долговременной стабильности и джиттеру уже весьма нехилые получаются. Так что либо нужно синхру гнать параллельно, либо использовать самосинхронизирующиеся протоколы типа Манчестера. Что всяко ближе к Ethernet, чем к RS485

нашел LTC1688 100Mbps RS485

если кодировать 4b5b (или каким другим самосинхр. кодом), можно ли передать на 100-200 метров по витой паре кат. 6?

USB не годится принципиально.
RS-485 может и пройдёт, но поизвращаться придётся.
Всякие LVDS-ы по дальности тоже сомнительно, и с кодированием придётся возиться.
Так что Ethernet было бы правильно по моему.

Если цель - передать 16 бит параллельно со стробом записи, то проще всего манчестер. На концах - простенькие плиски и оконечники. Я такое делал на советской логике. Пара десятков корпусов 533/1533 серии. Частота была 10 МГц.
Хотя "проще" - понятие растяжимое.
Кому-то проще поставить немеряный Virtex, насовать туда IP-корок и наслаждаться...

У всех 485-ых передатчиков скорость передачи завязана с длиной линии. У LTC1688 написано 100 мбод на 30 метрах. По 485 стандарту 30 мбод идёт до 10 метров. А далее по убывающей. Сколько мбод останется на 100-200 метрах... Надо проверять. Зависит ещё от сопротивления самого кабеля. На длинных кабелях при стандартных терминальных резисторах 100 ом может не хватать напряжения для срабатывания приёмника. Придётся увеличивать резистор и уменьшать скорость передачи. Но в LTC1688 есть 4 передатчика и если использовать 2 или 3 из них, то 32 мбод сделать на 200 метров проблем не будет.

говорю, UTP 6, а кодирование какое-нибудь нужно?

Кодирование... Дык неизвестно откуда идут данные и в каком формате и ещё много чего неизвестно. 485-ый представляет из себя просто помехозащищённую передачу сигналов на большие расстояния. А по сути это простейшее соединение двух устройств одним (несколькими) сигнальным проводом. Что на вход передатчика подаёте, то на выходе приёмника и получаете. Один в один, только с задержкой распостранения сигнала по линии. Поэтому кодирование и разделение своего сигнала на несколько параллельных сигналов для 485-ого это уже совсем другая тема.

данные идут с датчика, оцифрованный аналоговый сигнал 16 битным АЦП с частотой дискретизации 2 МГц

А что произойдет, если половина всех принятых данных будет содержать ошибки?
Это приемлемо? А если четверть? И вообще, о каком допустимом BER идет речь?

Нужна ли контрольная сумма при передаче или информация для восстановления? Если да, то всё придётся делать через ПЛИС. Если же искажения (очень редкие) не смертельны, а искажения возможны всегда (!) при передаче данных, то всё будет проще.

ошибок не должно быть

Тогда сочувствую

Самое смешное, что эзернет тоже не так просто реализовать. По одной простой причине - надо накапливать данные с АЦП для сборки в пакеты. Потом - разгребать. И если будет ошибка, то грохнется весь пакет (т.е. много измерений), а не одно измерение. А насчет "ошибок не должно быть" это автор темы погорячился. А если помеха влетает на вход АЦП? Чем такой вариант отличается от порчи бита в потоке?

Биты разные бывают.
Когда я интересовался помехоустойчивым кодированием (писал диплом в 2000 году), то встречал коды, в которых разные биты имеют разный вес (как раз наш случай). То есть, порча старшего бита - это катастрофа, поэтому он максимально защищён, а младший - всё равно содержит один шум, его потеря ничего не значит.

Да нет. Потом фильтровать надо данные (FIR)

Скажите уже, что за сигнал передаёте? Что на входе АЦП? Тогда может и совет полезный услышите.

Высоконадёжная передача данных даже на 100 метров - это тема докторской диссертации если не сложнее. Вы готовы в это окунуться?

Задача заменить передачу аналогового сигнала (30 - 300 кГц) по коаксиалу, на передачу оцифрованного сигнала

Так бы сразу и сказали. Для передачи того же звука вполне допускается выпадение одного сэмпла из допустим тысячи. Вообще, по 485 каналу можно передать сигнал с нехудшим качеством чем по коаксиалу. Проще всего ввести в канал дополнительную информацию по восстановлению. БЧХ или что покруче. MrYuran походу знает про это, может что посоветует. Делать такой большой поток данных легче всего в плисине, либо в черезмерно мощном проце. Можно расчитывать, что при этом ошибок вообще не будет если рядом молния не шваркнет или других искровых разрядов по близости нет.

Хотя наверно можно сперва поискать какие-нить готовые решения в сети или в продаже.

Эзернет
если все требования переписать в один список, то эзернет, предложенный кем-то в первом ответе, будет в самый раз. и лучше гигабитный, для возможности повтора испорченных пакетов.
а "разжевав" кодирование будет видно что это копия tcp
очередной вЕлик

тогда еще вопросик:

если эзернет точка-точка, можно ли на одном конце не использовать трансформатор?

Если сам сигнал от 30 до 300 кГц, а оцифровывается 2 МГц, то целесообразно предварительно слегка припаковать. Если ставится ПЛМ, то очень легко реализуется например вычисление разницы между предыдущим и последующим. Думаю что необходимая скорость передачи потока уменьшится на порядок.

Я и USB2 протягивал с ретрансляцией 5 раз по 15 метров и питанием с одной стороны. Получал скорость до 23 Мбайт.
Если питание с двух сторон можно сделать, то по 20 метров ретрансляторы будут работать.

вопрос по Ethernet

а можно ли посылать пакеты например по 20 байт, и есть ли какие либо ограничения на размер пакета
и чем они обоснованы

имеется ввиду пакет чистых данных с АЦП без дополнительных данных и без использования протоколов

Нельзя. Минимальная длинна пакета - 64 байта + 8 байт преамбулы (55,55,55,55,55,55,55,5D). В собственно пакет входят 6 байт адреса приемника, 6 байт адреса источника, 2 байта - тип пакета (его еще надо правильно выбрать, дабы не помешать другим, поищите по форуму, это обсуждалось), и в конце - контрольная сумма. Остальное можете забить своими данными.

связь точка-точка

с одной стороны FPGA отсылает данные через внешний PHY, а с другой стороны FPGA принимает данные через внешний PHY

никому мешать я не собираюсь :-)

Аааа, ну если так, то хватит только преамбулы. Дальше - сколько хотите байт можете передавать.

не понял, а зачем преамбула?

я так понимаю PHY (LAN8700) сам определяет начало и конец передачи данных, а также и у приема

По преамбуле происходит начальная синхронизация. Сам ниббл D (вместо 5) говорит о начале собственно пакета. Без этого жить не будет.

а нибблы J K T R тогда зачем?

О, пардон, Вы про сотку... Ну байт 0x5D Вам все равно надо передать. А дальше - сколько хотите.

опять же не понял, этот байт кому нужен
я так понял для PHY он не нужен, или я не прав?

и сколько хотите - это хоть 1 байт?

Нужен. Без него не будет работать.



Можно и один.

последний вопрос:

а где про это прочитать можно?

В описании MAC-уровня (IEEE802.3) Вы такого не прочитаете. 8 байт преамбулы и все. А это - собственный опыт.

Может попробовать по оптике ?
Берете оборудование для передачи видеосигнала по оптоволокну
(например, Teleste) и получаете готовое решение.
Оно передает полосу до 6,5 МГц, частота оцифровки у разных девайсов разная,
ну минимум по Котельникову должно быть где-то 13 МГц.

Правда, путь АЦП -> оптика -> ЦАП -> АЦП смотрится не очень привлекательно.

Но тогда можно свой девайс сделать типа АЦП -> оптика -> цифровой сигнал на прибор.

Забыл упомянуть, что в передатчиках видео по оптоволокну оцифровка обычно 8 или 10 битная. Но теоретически можно взять двухканальное оборудование, разбить диапазон измерений на две части и получить в итоге 16-20 битную оцифровку.

примерное задание но сигнал 4мбит хотел передавать по витой на 200м, в результате отказался и поставил сдел все на оптике оконечка http://www.infineon.com