Кстати можно попробовать установить шаг для потока ввода равным размеру одного кадра (данные АЦП + DIN), чтобы уменьшить возможную задержку внутри контроллера модуля E502

На счет шага - у меня так и сделано:

X502_SetStreamBufSize(m_dev, X502_STREAM_CH_IN, (m_channels + m_bin_size) * 80);
X502_SetStreamStep(m_dev, X502_STREAM_CH_IN, m_channels + m_bin_size);

на счет бита с периодом 500 мсек - это вы правы, я просто ошибся - конечно 15-й.. по фронту этого бита внешнее устройство запускает внешний таймер... На логику не обращайте внимания, она тут чисто от реальной программы, а мне вот что не совсем ясно - я меняю состояние 0-го бита на выходе и тут же запускаю чтение входов. На разъеме АЦП выход 0-го бита соединен со входным 8-м битом, а 15-й (не 4-й конечно) с 0-м входным... так почему же сигнал на 0-м бите читается раньше чем на 8-м на вот эти пресловутые 7 мсек? Где засада - в моем коде или в стеке USB? я пробовал уменьшать размер входного буфера - а ни фига, данные начинают идти с перерывами.. но с той же начальной задержкой

вот вариант с размером буфера в 250 отсчетов: https://yadi.sk/i/41kg9Uod3P5oGu
а вот - с размером буфера 125 отсчетов: https://yadi.sk/i/3nQm4Njf3P5oRW

на счет компьютера и ОС - ArchLinux, Сore-I5 2.6 GHz... все шустрое, программа работает как сервис, т.е. с рутовым приоритетом.

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

а-а, точно, этого я в приведенном тексте не указал. там после adc_size = 0 должен идти вызов внешней функции. Но в этой функции ничего особенного нет - используются массивы m_inputs, m_status, из них данные собираются в список и потом пишутся в файл с формате Comtrade (в отдельном потоке с низким приоритетом)

могу эту функцию привести.. но там много разных вызовов других функций. Здесь основная конва:

//цифровая обработка аналоговых данных
    double* adc_data = app->adc->ret_data;
    for(int n = 0; n < app->adc->m_channels; n++)
    {
        app->rza_data->m_prc[n]->update(adc_data[n]);
    }
    emit rzaUpdate();
// обработка цифровых данных
    app->logic->run();
// сохранение входных данных 
    appendSourceData(adc_data);

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

Просто получается что этот выход формируется у Вас каким то сложным способом и при этом Вы спрашиваете почему он отстает?

в смысле - какой выход?

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

на нулевой бит выводится то, что я прочитал с нулевого бита.. а задержка возникает между нулевым битом на входе и 7-м, куда прямо на разъеме АЦП запаян выход 0-го бита.. т.е. разъем выглядит так

входы     выходы
0 <---+   +----  0
1        |    |       1           
...       |    |      ...
7 <------- +       7
....      |           ...
15      + -------15

Обнаружил еще одну шнягу - задержка растет с течением времени...

В контексте ранее заданного вопроса о синхронной диаграмме ввода-вывода E-502:
Эта диаграмма приведена в новой редакции руководства http://www.lcard.ru/download/e-502_users_guide.pdf , п.3.3.8.

Ну по коду это не очень понятно. Но если предположить, что так, то в общем ничего удивительного. Если у Вас задержка передачи данных по каналу ввода и вывода допустим по 3.5 мс, то и получается, что изменение на 0-м входе Вы увидите через 3.5 мс после самого момента времени (при этом модуль постоянно собирает данные за эти 3.5 мс данные находятся в процессе передачи от модуля в программу), после вывода проходит еще 3.5 мс пока данные дойдут до модуля и будут выставлены.

В общем для ОС общего назначения, которой является Linux, это по мне выглядит скорее хорошим результатом. Приоритет потока в Linux если я не ошибаюсь напрямую не зависит от пользователя, который его запустил.

И сам процессор и частота его работы к задержкам ввода вывода имеет малое отношение.

Если нужна жесткая обратная связь, т.е. чтобы на основании данных на входе изменять значения на выходах за строго заданный интервал времени (да еще если он в мс), то это в любом случае нужно использовать сигнальный процессор или ПК с ОСРВ (хотя для последнего не знаю насколько USB для этого подходит, обычно тогда используют L-502).

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

Если бы я не успевал обрабатывать кадры, то на приеме аналоговых данных у меня бы развалился спектр сигналов, поскольку с каждого кадра аналоговые данные пишутся в скользящий буфер и от него берется ДПФ. На практике такого не происходит, да и функции обмена с е502 ошибок не возвращают.  В варианте чтения/записи цифровых данных в асинхронном режиме и отдельном потоке все работало, но такой вариант нас не устраивало из-за больших и непрогнозируемых задержек.. по измерениям там было где-то порядка 30-60 мсек,но это и понятно- асинхронное чтение да еще в отдельном потоке с меньшим приоритетом...

Нарушение входного сигнала будет только если переполнится буфер обмена между модулем и ПК