Здравствуйте,

Есть такая задачка:
8-канальный 24-битный АЦП выдает данные 1000 сэмплов в секунду.
То есть трафик полезных передаваемых данных: 8 каналов * 24 бита * 1000 сэмплов = 192 Килобита в секунду (плюс еще мелочь вроде текущего времени)

Нужно передавать этот поток в канал Ethernet. Супернадежность не нужна, потеря фрейма не страшна. По всем критериям UDP подходит.
генерировать фреймы проблемы не вижу, проблема как это сделать так, чтобы с принимающей стороны это было просто принимать и обрабатывать.

Может быть, есть более-менее стандартные (популярные) методики для передачи подобной информации, например, какие-нибудь АЦП модуль с Езернетом, и на них известен формат фрейма?
Или, может быть, несложно сделать так чтобы со стороны принимающего компьютера это выглядело как удаленный виртуальный COM-порт (с уникальным IP и port) ?

Какие подводные камни могут быть? возможно ли, чтобы несколько приемников(компьютеров) принимали эти UDP дэйтаграммы (вроде бы да) ?

например, нашел у lcard.ru похожие устройства с UDP.

Не подходит. На первом же коммутаторе два пакета UDP вполне себе могут "поменяться местами", то есть отправленный позже пакет придёт раньше. Думаю, что для АЦП данных это критично.

Я однозначно в каждый UDP пакет буду вставлять время первого сэмпла в начало (опять же вопрос что вставлять, пока что склоняюсь к 4-байтовому числу формата time_t плюс 2-байтовый номер миллисекунды).

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

Вот только как будете разруливать ситуацию, когда скажем пакет "поздний" придет, а "ранний" потеряется... Ждать? Не ждать, так тогда как?

Ну да, ну да, согласен. Это вечная проблема (наряду с переводом времени назад).

Ограничил (себе) задачу, буду просто на экран график в онлайне выводить.
Для надежной передачи есть файлы с данными и по FTP доступны, так что объявил этот UDP поток онлайн интерфейсом для тестирования-наладки.
В-общем, в таком виде все просто: храню историю последних 10 секунд, если точка есть- засвечиваю на графике, если нет- то ее не видно.
Похоже, по сложности реализации конструкция выходного дня получается, искать чужой формат фрейма расхотелось, быстрей свое самому написать в билдере

Добрый день!
Скажите, у вас всё-таки получилось организовать передачу данных с АЦП по Ethernet или нет?

Тоже задавался этим вопросом
сделал так

Ну, вроде бы да
у меня 8 каналов 24-битных АЦП, 1 килосемпл. то есть поток данных 24 килобайта в секунду.
Сделал на UDP, каждые полсекунды новая пачка пакетов. Длина пакета- 2400 байт данных плюс заголовок, позволяющий контролировать целостность данных (номер пакета, время первого отсчета и тд).
Работает.
В контроллере нужно иметь буфер пакетов, позволяющий "пережить без потерь" время, когда линия занята (зависит от загрузки Езернета).

Трудности были и со стороны компьютера- стандартный путь использования Матлаба для приема UDP не подошел, пакеты иногда терялись. Написал свое под C++Билдером и проблема ушла.

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

я так понимаешь, что Вы запустились

Доброго времени суток!

Я вот столкнулся с такой задачей:
На двухканальный АЦП подаются синфазная и квадратурная компоненты сигнала.
Сигнал с частатой f<1МГц.
Необходимо полученный после АЦП поток данных отправить по Ethernet на комп.

Подскажите, на чём лучше выполнить формирование и осуществить отправку E-кадров,
и может будут какие-то рекомендации в по-поводу того, какой АЦП лучше использовать?

Разделите задачу на независимые части, вроде "черных ящиков" с входом и выходом. Чем стандартнее черный ящик- тем проще его решить.
например, в Вашем случае:
1. Входные аналоговые цепи (выход: данные, пригодные для АЦП)
2. сбор данных с АЦП (выход: данные в буфере микроконтроллера)
3. Фрагментирование потока данных (выход: данные в виде, пригодном для подачи в TCP/IP модуль)
4. передача пакета данных (выход: данные в линии Езернет)
5. Прием сырых данных (выход: данные в буфере приемника (компьютера))
6. Обработка (выход: обработанные данные в буфере компьютера)
7. Использование (выход: данные переданы по назначению (отображены, сохранены, учтены и пр.))

Понятно, что каждый этот кубик можно еще подробнее разделить. И так до того уровня, на котором не будет разночтений и недомолвок. В конце концов все должно быть определено и понятно: тут ставим диод, а тут нужен 30-дюймовый дисплей. Уровень детализации должен быть достаточным для понимания и прогнозирования ресурсов, которые будут потрачены (время, люди, материалы).

Ну и на конкретный вопрос (по одному такому "черному ящику", а не по задаче целиком) сильно больше вероятность получить конкретный ответ.


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

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

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