Форум: Техническая поддержка

Добрый день
Имеется программа, написанная на основе примера для C#. С ее помощью я хочу снимать данные с частотой 30кГц на канал. Всего 2 канала.
Данные снимаю, как по инструкции: задаю время таймаута и получаю данные в буфер. И затем по отсчетам формирую выходные данные
Но, сравнивая с LGraph2, я получаю более зашумленную форму сигнала. Амплитуда совпадает, форма издалека похожа, но в LGraph2 у меня есть повторяемость от измерения к измерению, а в моей проге нет.
Построил АЧХ для снятых сигналов. На сигнале со своей проги вижу всплески на 50 Гц в частности. На LGraph2 все чисто

У меня 2 варианта:
1) я неправильно снимаю данные с LCard L502
2) в LGraph2 на выходе есть какие-то частотные фильтры.

Какие подскажете решения? На почту я высылал АЧХ и класс взаимодействия с LCard на C#.
Спасибо.

В LGraph2 фильтров нет. Он показывает данные, поступающие с платы.

Значит у меня проблема в коде со съемом данных...

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

Все же хотелось бы также иметь скрин из X502Studio с теми же параметрами - там сразу строиться спектр и сразу будет понятно, какая картина в действительности на входе модуля.

По присланному коду, время отсчетов должно браться исходя из настроенной частоты на канал, а не исходя из времени приема данных деленных деленного на их количество, т.к. на последние параметры влияют задержки передачи, реакции программы и т.п., из-за чего эти времена еще и будут плавать, в то время как в самом модуле все измерения выполняются со строго определенной аппаратной частотой.
Также не совсем корректно, что нет проверки на четность количества принятых данных, т.к. если за таймаут будет вычитано нечетное число, то может произойти перепутывание номеров каналов. Несколько также смущает, что lock используется только при сохранении данных в очередь, но не используется при извлечении.

- Когда я вам графики выслал, немного поторопился. На верхнем графике была только часть сигнала, чтобы было понятна его форма. У сигнала нет четко выраженных гармоник, и это нормально. Выслал картинку из XStudio. То, что она показывает, так и должно быть
- по времени и lock, исправлю, спасибо за замечание

Вопросы:
- каким образом влияет изменение параметров таймаута и размера буфера на данные? RECV_BUF_SIZE, RECV_TOUT
Какое время таймаута считается оптимальным?

По скрину из Studio не совсем понятно, за какое время строился спектр (в Файл -> Настройки приложения можно выбрать время блока для обработки). На временном графике отображается только 10 мс, при таком времени 50 Гц на спектре в любом случае не увидеть. Чтобы увидеть 50 Гц на спектре, нужно хотя бы несколько периодов сигнала, например периодов 10) т.е. время блока 200 мс поставить. Можно также двойным нажатием на график выбрать интервалы по осям, чтобы увеличить часть, хотя в принципе максимальную частоту она и в параметрах отобразит, если она будет.
Т.е. я правильно понимаю, что Вы каким-то образом генерируете сигнал без явно выраженной частоты при этом с достаточно значительным размахом (около +/- 1В), при этом даже на Вашем спектре 50 Гц хоть и выражена на спектре, но по амплитуде значительно меньше этих явных колебаний, и на временном представлении это в любом случае не увидеть?

По поводу таймаутов, то логика такая. Модуль после запуска постоянно выполняет измерения с заданной частотой и передает их в ПК, где они помещаются в буфер типа очереди (FIFO), откуда уже они вычитываются с помощью Recv(). Данные всегда добавляются в конец очереди, а вычитываются из начала (самые старые пришедшие данные). По Stop останавливается сбор и буфер очищается.
Recv ожидает, пока не произойдет хотя бы одно из событий - в буфере накопится запрошенное число данных или истечет заданный таймаут. В результате чего из буфера будет вычитано, либо запрашиваемое число отсчетов, либо меньше, если на момент завершения функции их пришло меньше.
Ну само время чтения блока на ОС общего назначения желательно, чтобы было хотя бы не меньше 10 мс, чтобы не получилось, что возможные задержки Windows и дополнительная нагрузка из-за частых вызовов не привели бы к тому, что мы читали бы данные слишком медленно, с верхней стороны уже скорее вопрос к требуемому времени обновления данных в приложении и времени реакции самого приложения. Но в любом случае, если прием сделан корректно и не случится переполнения буфера (но в этом случае Recv вернет ошибку), то данные должны быть прочитаны одни и те же вне зависимости от времени и размера блока на прием.

К использованию Recv обычно есть два подхода:
1. Обработка блоков с фиксированным размером точек. Тут размер блока привязывается времени измеряемого исходного сигнала. В этом случае исходя из частоты сбора и выбранного времени блока выбирается RECV_SIZE, а tout ставится значительно больше времени блока (например на 2-3 секунды), и служит только для обработки нештатных ситуаций. В этом случае при корректной работе Recv всегда возвращает столько же данных, сколько запрошено (меньшее число можно считать ошибкой). Тут удобно, что если RECV_SIZE кратен числу каналов, то Вы всегда принимаете и обрабатываете данные из целого числа кадров. В общем если нет приема с цифровых линий, то этот способ проще использовать.
2. Обработка блоков по времени приема. Тут уже кол-во точек в блоке может быть разное из-за задержек передачи и идет обработка всех точек, что приняли за заданный интервал времени на ПК. Таймаут ставится исходя из времени прием, а RECV_SIZE ставится заведомо больше и уже смотрится по возвращаемому значению функции, сколько реально пришло данных. Но тут нужно учитывать, что их может прийти не кратно числу разрешенных каналов, и это нужно обрабатывать (либо учитывая, при обработке, либо склеивая неполные куски кадра с конца предыдущего и начала нового Recv()). В случае, если нужны данные с цифровых линий, то этот способ обычно приходится использовать, т.к. в одном потоке объединяются два и явно размер исходных отсчетов определить уже сложнее.