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

1) Допустимо ли значение в LTR212_Recv(...) size=6008=751*2*4 DWORD ?
2) Допустимо ли значение в LTR114_Recv(...) size=1000=125*8 DWORD ?
3) Какие значения оптимальны для производительности потоков получения данных этих модулей?

Предполагается, что в LTR212 будут использоваться 4 канала в 4-канальном режиме повышенной точности (частота оцифровки 150.15Гц), а в LTR114 будут использоваться 8 каналов с частотой оцифровки 25Гц (FreqDivider=2, Interval=158).
Для указанных значений size ожидаем получение данных в потоках сбора данных за 5 сек.

1,2 - сами по себе значения допустимы.
3 - С производительностью могут быть проблемы, если размер слишком маленький, т.е. соответствуют блоку отсчетов за время, равное единицам, может десяткам мс. Для ваших времен в общем на производительность это влиять особо не должно и размер можно выбирать исходя из логики программы, какими блоками будете обрабатывать данные. Но если Вы принимаете блоками по 5 с нужно учитывать, что такая задержка у Вас будет в случае запроса завершения сбора (т.к. до завершения приема блока Вы из Recv не выйдете).

Не очень понял почему получились такие цифры. Если FreqDevicder = 2, то частота АЦП = 4 КГц.  Количество измерений на кадр, чтобы получить частоту кадра 25 Гц, - 4000/25 = 160. Каналов у Вас 8 (LChQnt ). Т.е. interval = 160 - 8 = 152.
Для времени в 5 с при этом нужно делать size = 125 * FrameLength, т.к. интервал в LTR114 используется для измерения внутренних параметров и они тоже передаются и будет в Recv(), просто на выходе ProcessData их не будет, да и сами отсчеты как и в LTR212 передаются за 2 слова.

1) FreqDivider=2, Interval=158 - хотели, чтобы оцифровка производилась почти одновременно, несмотря на мультиплексирование.
А ограничить в Recv() объем 125 настройками не получиться никак? (Не принимать данные за Interval, чтобы ограничить массивы).
Параметр SpecialFeatures никак не поможет?
2) Сбор данных организую в отдельных потоках для каждого модуля, как Вы и рекомендовали, а главному потоку как раз 5сек должно хватить для дополнительной обработки.
3) Еще такой вопрос. В примерах от LCard для LTR114 и LTR212 (объем данных принимал по 1 сек) обнаружилось, что астрономическое время сразу после
приема очередной порции данных отличается от ожидаемого интервала на 1мс или менее. Поэтому возникла мысль "астрономические" временные метки рассчитывать по этому астрономическому времени с шагом (назад) по 40мс для полученных за 1сек данных, временные метки DWORD вообще не использовать.
Сюрпризы, известные Вам, нас не ожидают?