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

"Снять погрешность", в рамках одного крейта Вы можете программно уже сейчас, включив внутреннюю секундную метку синхронизации и выравнивая все принятые отсчёты относительно меток на верхнем программном уровне, поскольку частоты меток и частоты следования отсчётов АЦП известны и кратны друг другу, а в LTR метки ставятся в очередь на передачу  одновременно отсчётами от остальных модулей АЦП.

В п. 4.6.5.1 РЭ,  - аналогично, -  секундные метки идут не с точностью до секунды, а с периодом 1 секунда для разметки всего потока от всех модулей, что позволяет получить точность синхронизации каждого отсчёта АЦП - до 1 периода АЦП.. И сейчас Вы можете сделать то же самое, только в метках не будет записано время Unix Time.

Если часы ПК не синхронизированы с секундными метками от LTR-EU, то на вернем программном уровне нужно организовывать инерционную систему отслеживания фазы (захвата частоты) секундных меток от LTR-EU по отношению к часам ПК, и относительно этой восстановленной (накопленной) фазы восстановить все остальные временные интервалы  между отсчётами.. Но будет значительно проще, если использовать внешний сервер единого времени (СЕВ), от которого засинхронизировать и часы ПК, и все крейты LTR-EU, подав на них секундные (PPS) импульсы от СЕВ, по которым крейты будут высылать секундные метки, тогда просто все отсчёты должны быть выравнены на верхнем уровне по некой абсолютной задержке относительно "времени рождения" секундных меток.

Во всех описанных выше случаях для выравнивания отчётов по времени необходимо использовать небольшую буферизацию (задержку) данных на количество отсчётов, соответствующую их максимальному разбросу по задержкам приёма (как я это  объяснял с самого начала темы: http://www.lcard.ru/forums/viewtopic.ph … 019#p61019 ) для того, чтобы уже из этого буфера устроить выдачу данных точно по восстановленным временны'м признакам синхронизации.

Если "восстанавливать ритмичность" отсчётов только от одного модуля LTR, то можно обойтись вообще  без секундных меток, поскольку исходная частота отсчётов известна, и, применяя на программном уровне Real-Time системы инерционный захват этой частоты и выравнивающий буфер, можно добиться выравнивания "не ритмичности" (10+-2) мс соседних отсчётов на порядки. Допустим, при большом времени захвата (тысячи периодов отсчётов) можно вполне рассчитывать на выравнивание времени выдачи соседних отсчётов в 100 раз:  (10+-0,02) мс. При этом, как в классических системах захвата частоты (ФАПЧ), хорошо бы формировать признак захвата частоты, который должен перейти в "не захват", если в системе начнутся неожиданные большие задержки приёма отсчётов.   

Под пример  http://www.lcard.ru/node/803 у нас есть специальная прошивка FPGA для LTR-EU, которая принимает протокол IRIG от СЕВ по входу SYNC LTR-EU, и вставляет в каждую секундную метку поля времени, принятые от СЕВ. Таким образом, при применении СЕВ, можно привязать к абсолютному времени СЕВ все отсчёты АЦП от всех крейтов LTR и модулей LTR с точностью до периода АЦП! А, применяя захват частоты и выравнивающий буфер (как это я объяснил выше), можно кардинально уменьшить "не ритмичность" соседних отсчётов.

Отредактировано Гарманов Александр (08.12.2016 08:48:31)

Извините, не могу понять Ваше предложение.

Положим, имею один крейт и в нем один многоканальный модуль.

По LTR***_Recv() получаю очередную порцию измерений  по каждому каналу модуля. Системной ф-цией ftime() сразу после LTR***_Recv() могу "привязать" результаты  к текущему времени ПК с точностью до миллисекунды и отдать результаты другим программам проекта, работающим в реальном времени. Другие программы будут использовать текущий результат по своему усмотрению ( расчеты, вывод на экран, анализ аварий, постоянная запись, мнемосхемы с программами управления и т.д.).

Но стало понятно, что период поступления измерений плавает в диапазоне -+2мс. Т.е. привязка результата к текущему времени ПК (вместо получения результата вместе с внутренним временем крейта ) будет с этой ошибкой -+2мс.

Как мне могут помочь подмешанные в поток данных "секундные" метки чтобы устранить ошибку -+2мс каждого отсчета?

Читайте  http://www.lcard.ru/download/ltr.pdf, п.4.7. и руководство программиста, где описаны метки синхронизации. Пока не поймёте принцип синхронизации в LTR, дело не двинется. В своём исправленном предыдущем посте основные идеи синхронизации вашей системы я Вам излагаю. Успехов!

Отредактировано Гарманов Александр (08.12.2016 08:42:52)

Следую Вашей рекомендации, перечитываю п. 4.7 РЭ и Ваш пост #26.

В наших приложениях есть не очень быстрые измерения с частотой сбора 50Гц от всех модулей в крейте.

Буферировать данные не представляется возможным: обработка данных проходит в реальном времени их возникновения.

Ваше предложение по уточнению времени очередной порции данных  реализуемо:

- если очередная порция пришла через время <=20мс от предыдущей порции - присвоить ей время поступления данных в ПК;

- если очередная порция пришла через время > 20 мс от предыдущей порции - присвоить ей время поступления данных в ПК минус время возникшей задержки от 20-ти мс.

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

Для этого можно предусмотреть API-функцию занесения в крейт точного времени из host-ПК.

М.б. в будущем разработать модуль получения точного времени через GPS.

Тогда крейтовая система LTR была бы поставщиком измеренных данных с привязкой к реальному времени их сбора . В т.ч. при получении данных по длинным сетям через Internet.

Это непонятно, поскольку, если "в реальном времени", тогда важна задержка относительно входа АЦП. И, как я объяснял в http://www.lcard.ru/forums/viewtopic.ph … 021#p61021 , абсолютная задержка относительно входов LTR27 - уже не менее 12 мс, не считая времени задержки буферизации-передачи данных во всём интерфейсе. Таким образом, выравнивающий буфер (на несколько миллисекунд) добавит только малую часть от уже имеющейся абсолютной задержки (относительно входа LTR27).

Я полагаю, что, если будет заказ, то сделаем это.

Ровно ЭТО и сделано в http://www.lcard.ru/node/803. С точностью до миллисекунды и с периодом 1 с. Тем самым, каждый отсчёт на верхнем программном уровне привязывается с относительно метки с точностью до периода преобразования АЦП, поскольку изначальный период следования отсчётов известен с большой точностью.

Тоже самое Вы можете сделать уже сейчас и со штатной прошивкой крейта и внешним блоком GPS, от которого засинхронизируете часы ПК, и с которого секундный импульс (pps)  подадите на вход SYNC крейтов. - Это ровно то же самое, что в http://www.lcard.ru/node/803, только в формате метки не будет значения времени, но это не помешает решить ту же задачу, если исходить из того, что абсолютное время задержки интерфейса не превышает период 1 с секундного импульса.

Другая задача - это воспроизвести на верхнем программном уровне изначальный период следования отсчётов. Как решить эту задачу, я уже предлагал выше. Но если же Вы хотите, чтобы отсчёты от крейта физически принимались (на верхнем программном уровне) с их изначальным периодом следования, то требуется внедрять поверх Ethernet какой-либо протокол реального времени. Об этом тоже уже писал выше. Я уже стал повторяться, и кажется, по третьему разу... 

Что касается вариантов заказных работ, то я вижу возможность в добавлении в LTR-EU для метки "Старт" периодичного режима, например, с периодом 0,1 мс, разбивающий период "Секундной" метки на 10000 интервалов. Это позволит точнее и удобнее на верхнем программном уровне привязывать принимающиеся отсчёты к шкале времени уже по двум меткам. Эта работа потребует модификации прошивки FPGA и поддержи в библиотеке верхнего уровня. Замечу, что данная работа проще, чем модифицировать ПО Blackfin.

У Вас интересное предложение, будем осмысливать.

Или же, если найти точный внешний генератор прямоугольного сигнала 10кГц и подать его на разъем метки "Старт" крейта, то дорабатывать ПО крейта и API модулей не понадобится?..

Жаль что LTR-43 не программируется на бесконечную генерацию меандра заданной частоты. А 1 канал LTR-34 вроде бы можно под данную нужду использовать?!

Вы можете любой  из двух каналов меток (или оба канала) использовать с внешней синхронизацией.  Это штатная пользовательская функция. Только сигнал должен быть c TTL-уровнями:  http://www.lcard.ru/lexicon/ttl_in_out

Вероятно, это ещё одна тема для заказа, чтобы ввести эту функцию.

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

По видимому имелось ввиду использование одного аналогового выхода ЦАП для генерации меантра с уровнями напряжения, соответствующими TTL, и этот меандр завести на один из входов SYNC для генерации метки от внешнего условия.

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

Подключать выход LTR34 ко входам синхронизации крейта можно только через ограничительную цепь, например, на основе резистора и стабилитрона.

Также с программной точки зрения нужно учесть, что режим работы (автогенератор, потоковый) настраиваются на все каналы и данные передаются общим потоком. Так что нужно смотреть насколько это совместимо с способом работы с другими каналами LTR34

Спасибо за критические комментарии, использовать LTR34 для выдачи меток "Старт" - не лучшее предложение.

{рекламный контекст удалён}

Тестируется такое решение:
В ПК с ОС реального времени (QNX6) установлен интерфейс с дискретными выводами ТТL-уровня.

В принципе, дискретный сигнал можно формировать с помощью последовательного или параллельного интерфейса любого ПК.

Один дискретный вывод подключен к сигналу DIGIN1 каждого крейта.
После старта ltrd и программ обслуживания модулей крейта запускается нить выдачи дискретных импульсов ( с высоким приоритетом).

Сперва однократно в "глухом" цикле производится ожидание смены секунды. В момент смены секунды настраивается и запускается таймер ОС реального времени.
Время до первого срабатывания таймера настраивается с компенсацией "проскакивания" при смене секунды ( случайное значение от 0 до 200 мкс). Последующие срабатывания таймера настраиваются на период 500мкс. При каждом срабатывании таймера производится выдача дискретного сигнала в "1" и сразу в "0". Время выдачи высокого уровня "1" составляет 4 мкс.

При приеме данных каждый модуль принимает значение метки "Старт" и по числу импульсов определяет время реального измерения как число микросекунд текущих ЧЧ:ММ:СС.

Тесты показывают, что задержки от реального измерения до доставки данных в ПК могут составить 500...3500мкс.
Т.о. точность определения реального времени измерения может составить до 500мкс.

Можно настроить ticksize часов реального времени ОС на величину 100мкс и выдавать импульсы через 100мкс.  При этом точность определения реального времени измерения - до 100мкс. Но растут накладные расходы на функционирование ОС  примерно на 15% от доступных ресурсов ПК.

Выбор зависит от требований прикладной задачи...

Спасибо за полезные советы.

В посте #42 приведены данные тестирования модулей LTR27. Для них в массив tmark[] при приеме счетчиков метки "Старт" помещаются одинаковые значения для каждого канала ( видимо потому, что каналы работают параллельно ).

Для модуля LTR114 в массив tmark[] поступают разные значения счетчика метки "Старт" потому что каналы работают последовательно?

А при 4-х проводной схеме подключения (8 каналов ) элементы массива tmark[0] и [1] - для первого канала, [2] и [3] для второго канала и т.д. ? (приходят попарно одинаковые значения ).

И еще вопрос: для LTR27 задержка , рассчитанная по меткам "Старт", от момента измерения до поступления данных в ПК cоставляет до 1/5 периода измерения ( при периоде 10мс задержка до 2 мс ).

Почему для LTR114 таким же образом рассчитанная задержка составляет около одного периода измерения? (  при периоде 10мс задержка до 10-12 мс )! Как это можно объяснить? Спасибо.

В LTR114 в любом режиме один отсчет передается в виде двух слов, соответственно всегда на один отсчет два элемента в tmark.
Да, модуль LTR114 производит измерения последовательно, соответственно и время поступления каждого отсчета отличается и отличается значение метки (LTR27 выдает все слова в интерфейс одновременно друг за другом, поэтому с большой вероятностью метка времени у них будет одинакова, если только прям не совпадет момент увеличения счетчика метки с моментом передачи кадра LTR27).
В этой связи для LTR114, так как Вы принимаете по кадру, не совсем понятно, Вы при этом ориентируетесь на метку первого слова или последнего в кадре?
В остальном эти задержки измеряемые метками в передачи данных крейтом и явно не зависят от модуля, единственное что разве что сам поток данных разный, из-за того что, как было сказано, в одном случае выдаются отсчеты вместе а в другом распределены во времени и объединять для передачи крейт может несколько по разному...

Вас понял так, что на один канал LTR114 всегда приходится 2 элемента в tmark с одинаковым значением счетчика.

Т.к. я за один вызов LTR114_Recv() получаю отсчеты по всем активным каналам, то буду считывать все метки tmark[2][число каналов] и для каждого канала принимать свое значение счетчика "Старт".

Осталась такая проблема:один раз за ( примерно ) каждые 30 cекунд с LTR114 происходит очень большая разница между реальным временем по tmark и временем поступления данных в ПК (примерно 300-500мс).

Вроде все требования по отмене периодической автокалибровки выполнил:

conf.Interval = 0 ,
conf.SyncMode = LTR114_SYNCMODE_INTERNAL, перед
LTR114_SetADC(&conf);

далее однократно вызываю
LTR114_Calibrate(&conf);

потом LTR114_Start(&conf);

после приема порции данных вызываю
LTR114_ProcessData(&conf, recv_data, proc_data, &size,
LTR114_CORRECTION_MODE_INIT, LTR114_PROCF_VALUE);

В чем еще может быть причина редкой периодической "длинной" задержки LTR114?

Может ли быть причиной отсутствие вызова LTR114_GetConfig(); перед LTR114_SetADC(); ?

Спасибо.

Непредвиденной автокалибровки не происходит.
Извините.