Ruslan1 17 2 ноября, 2013 Опубликовано 2 ноября, 2013 · Жалоба Здравствуйте, Есть такая задачка: 8-канальный 24-битный АЦП выдает данные 1000 сэмплов в секунду. То есть трафик полезных передаваемых данных: 8 каналов * 24 бита * 1000 сэмплов = 192 Килобита в секунду (плюс еще мелочь вроде текущего времени) Нужно передавать этот поток в канал Ethernet. Супернадежность не нужна, потеря фрейма не страшна. По всем критериям UDP подходит. генерировать фреймы проблемы не вижу, проблема как это сделать так, чтобы с принимающей стороны это было просто принимать и обрабатывать. Может быть, есть более-менее стандартные (популярные) методики для передачи подобной информации, например, какие-нибудь АЦП модуль с Езернетом, и на них известен формат фрейма? Или, может быть, несложно сделать так чтобы со стороны принимающего компьютера это выглядело как удаленный виртуальный COM-порт (с уникальным IP и port) ? Какие подводные камни могут быть? возможно ли, чтобы несколько приемников(компьютеров) принимали эти UDP дэйтаграммы (вроде бы да) ? например, нашел у lcard.ru похожие устройства с UDP. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gerber 8 2 ноября, 2013 Опубликовано 2 ноября, 2013 · Жалоба Супернадежность не нужна, потеря фрейма не страшна. По всем критериям UDP подходит. Не подходит. На первом же коммутаторе два пакета UDP вполне себе могут "поменяться местами", то есть отправленный позже пакет придёт раньше. Думаю, что для АЦП данных это критично. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 2 ноября, 2013 Опубликовано 2 ноября, 2013 · Жалоба Не подходит. На первом же коммутаторе два пакета UDP вполне себе могут "поменяться местами", то есть отправленный позже пакет придёт раньше. Думаю, что для АЦП данных это критично. Я однозначно в каждый UDP пакет буду вставлять время первого сэмпла в начало (опять же вопрос что вставлять, пока что склоняюсь к 4-байтовому числу формата time_t плюс 2-байтовый номер миллисекунды). Спасибо за замечание, это означает что нужно писать свой приемник, который будет не просто вставлять пакеты в итоговый файл один-за-другим, а делать это строго согласно заголовку с временем (то есть возможна вставка). Получается, что просто глупый приемник потока в файл (как с последовательным портом) не подходит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 2 ноября, 2013 Опубликовано 2 ноября, 2013 · Жалоба Спасибо за замечание, это означает что нужно писать свой приемник, который будет не просто вставлять пакеты в итоговый файл один-за-другим, а делать это строго согласно заголовку с временем (то есть возможна вставка). Получается, что просто глупый приемник потока в файл (как с последовательным портом) не подходит. Вот только как будете разруливать ситуацию, когда скажем пакет "поздний" придет, а "ранний" потеряется... Ждать? Не ждать, так тогда как? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 2 ноября, 2013 Опубликовано 2 ноября, 2013 · Жалоба Вот только как будете разруливать ситуацию, когда скажем пакет "поздний" придет, а "ранний" потеряется... Ждать? Не ждать, так тогда как? Ну да, ну да, согласен. Это вечная проблема (наряду с переводом времени назад). Ограничил (себе) задачу, буду просто на экран график в онлайне выводить. Для надежной передачи есть файлы с данными и по FTP доступны, так что объявил этот UDP поток онлайн интерфейсом для тестирования-наладки. В-общем, в таком виде все просто: храню историю последних 10 секунд, если точка есть- засвечиваю на графике, если нет- то ее не видно. Похоже, по сложности реализации конструкция выходного дня получается, искать чужой формат фрейма расхотелось, быстрей свое самому написать в билдере :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
reijn 0 16 мая, 2014 Опубликовано 16 мая, 2014 · Жалоба Добрый день! Скажите, у вас всё-таки получилось организовать передачу данных с АЦП по Ethernet или нет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
megajohn 8 16 мая, 2014 Опубликовано 16 мая, 2014 · Жалоба Скажите, у вас всё-таки получилось организовать передачу данных с АЦП по Ethernet или нет? Тоже задавался этим вопросом сделал так Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 17 мая, 2014 Опубликовано 17 мая, 2014 · Жалоба Скажите, у вас всё-таки получилось организовать передачу данных с АЦП по Ethernet или нет? Ну, вроде бы да :) у меня 8 каналов 24-битных АЦП, 1 килосемпл. то есть поток данных 24 килобайта в секунду. Сделал на UDP, каждые полсекунды новая пачка пакетов. Длина пакета- 2400 байт данных плюс заголовок, позволяющий контролировать целостность данных (номер пакета, время первого отсчета и тд). Работает. В контроллере нужно иметь буфер пакетов, позволяющий "пережить без потерь" время, когда линия занята (зависит от загрузки Езернета). Трудности были и со стороны компьютера- стандартный путь использования Матлаба для приема UDP не подошел, пакеты иногда терялись. Написал свое под C++Билдером и проблема ушла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 17 мая, 2014 Опубликовано 17 мая, 2014 · Жалоба ..нужно иметь буфер пакетов, позволяющий "пережить без потерь" время, когда линия занята... вот именно этот критерий отбрасывания и надо было заюзать...а не время для перестановки UDP пакетов как писали выше. потому как постановка задачи уже отвечает на вопрос что делать если пакеты меняются местами. а ничего - отбрасывать :) я так понимаешь, что Вы запустились :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
reijn 0 17 мая, 2014 Опубликовано 17 мая, 2014 · Жалоба Доброго времени суток! Я вот столкнулся с такой задачей: На двухканальный АЦП подаются синфазная и квадратурная компоненты сигнала. Сигнал с частатой f<1МГц. Необходимо полученный после АЦП поток данных отправить по Ethernet на комп. Подскажите, на чём лучше выполнить формирование и осуществить отправку E-кадров, и может будут какие-то рекомендации в по-поводу того, какой АЦП лучше использовать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 18 мая, 2014 Опубликовано 18 мая, 2014 · Жалоба Доброго времени суток! Я вот столкнулся с такой задачей: На двухканальный АЦП подаются синфазная и квадратурная компоненты сигнала. Сигнал с частатой f<1МГц. Необходимо полученный после АЦП поток данных отправить по Ethernet на комп. Подскажите, на чём лучше выполнить формирование и осуществить отправку E-кадров, и может будут какие-то рекомендации в по-поводу того, какой АЦП лучше использовать? Разделите задачу на независимые части, вроде "черных ящиков" с входом и выходом. Чем стандартнее черный ящик- тем проще его решить. например, в Вашем случае: 1. Входные аналоговые цепи (выход: данные, пригодные для АЦП) 2. сбор данных с АЦП (выход: данные в буфере микроконтроллера) 3. Фрагментирование потока данных (выход: данные в виде, пригодном для подачи в TCP/IP модуль) 4. передача пакета данных (выход: данные в линии Езернет) 5. Прием сырых данных (выход: данные в буфере приемника (компьютера)) 6. Обработка (выход: обработанные данные в буфере компьютера) 7. Использование (выход: данные переданы по назначению (отображены, сохранены, учтены и пр.)) Понятно, что каждый этот кубик можно еще подробнее разделить. И так до того уровня, на котором не будет разночтений и недомолвок. В конце концов все должно быть определено и понятно: тут ставим диод, а тут нужен 30-дюймовый дисплей. Уровень детализации должен быть достаточным для понимания и прогнозирования ресурсов, которые будут потрачены (время, люди, материалы). Ну и на конкретный вопрос (по одному такому "черному ящику", а не по задаче целиком) сильно больше вероятность получить конкретный ответ. вот именно этот критерий отбрасывания и надо было заюзать...а не время для перестановки UDP пакетов как писали выше. потому как постановка задачи уже отвечает на вопрос что делать если пакеты меняются местами. а ничего - отбрасывать :) я так понимаешь, что Вы запустились :) На данный момент у меня UDP поток используется для тестовых целей, из него нужно вычленить небитую последовательность длиной до нескольких минут для матобработки. Для этого достаточно просто иметь информацию о целостности данных, а для этого каждый пакет снабжен заголовком. Если вдруг что-то побилось- то просто начинаю сбор в компьютере со следующего пакета (то есть эксперимент просто немного удлиняется по времени). Но по текущему опыту- в локалке проблем не видел, вероятность потери крайне низкая (единицы пакетов в десятки минут). Изменение порядка следования UDP пакетов не видел. И, скорее всего, потери связаны не с каналом передачи а с обработкой пакетов в компьютере. Сейчас не мешает, позже буду вылизывать :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 19 мая, 2014 Опубликовано 19 мая, 2014 · Жалоба ...скорее всего, потери связаны не с каналом передачи а с обработкой пакетов в компьютере... это пока локалка. исправная локалка я бы добавил. достаточно какого нить странного свитча, или там хромую карточку, или ышо чаво нить и проблемы обеспечены. если Вы закладывались на такие форс-мажоры, то даже не почуствуете (т.к. это не типичное поведение и не так часто). а посмотреть и прочуствовать - да фигня вопрос. выставите в инет девайс и попробуйте поработать с ним удалённо, даже из своего города. т.е. несколько хопов чтоб было по пути следования. желательно не сильно простаивающих :) можно конечно же и локалку нагрузить. есть соответствующий софт и методы... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
