Организация передачи потока данных АЦП через Ethernet (UDP) - как не изобретать велосипед?, Как наиболее стандартно это сделать? Опции

[Ruslan1]

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

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

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

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

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

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

[gerber]

Супернадежность не нужна, потеря фрейма не страшна. По всем критериям UDP подходит.

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

[Ruslan1]

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

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

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

[iosifk]

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

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

[Ruslan1]

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

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

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

[reijn]

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

[Ruslan1]

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

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

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

[kolobok0]

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

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

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