[[email protected] 0]

Приветствую.

Задача не оригинальная: есть система сбора данных с датчиков на компьютер, где необходимо эти данные синхронизировать.

Распределенные датчики цифруют сигнал на некоторой известной скорости, например, 1000 sps (с поправкой на точность своих кварцев, пусть +-50ppm).

Контроллер сбора последовательно опрашивает датчики по RS-485, забирая из них пакеты оцифрованных данных без потерь в буфер. Пакеты от датчиков содержат в т.ч. свои идентификаторы порядковый номер первой оцифровки в этом пакете. Контроллер может периодически выдавать широковещательную команду на все датчики, по которой они могут сбрасывать номер последней оцифровки. У контроллера есть часы реального времени, отметки которого в момент синхронизации можно периодически подмешивать в общий поток данных.

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

Есть целый ряд очевидных проблем:

- скорости датчиков не совпадают из-за разных кварцев, и даже скорость одного датчика плывет со временем;

- часы реального времени в контроллере имеют дискретность несколько мс;

- команда синхронизации приходит на датчики практически синхронно, но реагируют они на нее с некоторой задержкой;

- даже если все работает абсолютно синхронно, за 1 с от одного датчика может прилетать как 1000 оцифровок, так и попеременно то 999, то 1001.

- частота оцифровки датчиков может не совпадать, а отличаться, скажем, раза в полтора. 

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

 

[Plain 168]

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

[Lmx2315 2]

Самый важный вопрос надо решить,  это раздать метку синхронизации по клиентам за время менее чем дискрет отсчёта их измерения.

[iosifk 3]

1 час назад, [email protected] сказал:

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

Что-то подобное есть в синхронизации потоков E3.

https://ru.wikipedia.org/wiki/Плезиохронная_цифровая_иерархия

Это когда несколько потоков Е1 собираются в Е3. Там В Е3 встраиваются биты, указывающие на величину рассогласования генераторов... 

[[email protected] 0]

33 minutes ago, Plain said:

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

А можно чуть подробнее? Отмерять по RTC каждую миллисекунду, и слать по 1000 запросов на каждый датчик каждую секунду? Как-то слишком грубо, и через 115200 вряд ли это прокачаю. Или просто вас не понял.

2 minutes ago, Lmx2315 said:

Самый важный вопрос надо решить,  это раздать метку синхронизации по клиентам за время менее чем дискрет отсчёта их измерения.

Команда синхронизации широковещательная на все датчики, длительность на 115200 около 0.5 мс, вроде подходит под критерий?

 

Мне задача видется, как сведение двух (или даже N) разнесенных цифровых микрофонов. Они же по-любому шлют поток оцифровок асинхронно? Если что, не пинайте, я в общем-то не в теме.

Как мне кажется, похожие задачи решаются в системах с на порядки большим темпом сбора. И разнесенные датчики могли бы быть на безпроводке и через маршрутизаторы...

[Lmx2315 2]

3 минуты назад, [email protected] сказал:

Команда синхронизации широковещательная на все датчики, длительность на 115200 около 0.5 мс, вроде подходит под критерий?

За время менее одного отсчёта надо разослать синхрокоманду и применить её к сигналу запуска DMA АЦП и сбросить по ней внутренние часы датчика. Повторную команду синхронизации надо слать за время меньшее чем по расчётам накопятся ошибки разсинхронизации в датчиках.

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

[[email protected] 0]

8 minutes ago, iosifk said:

Что-то подобное есть в синхронизации потоков E3.

https://ru.wikipedia.org/wiki/Плезиохронная_цифровая_иерархия

Пошел читать

[iosifk 3]

1 минуту назад, [email protected] сказал:

Пошел читать

Если найдете, то книгу БС Гольдштейна.. https://www.litres.ru/b-goldshteyn/ob-avtore/ 

А вот какую точно, уже не помню...

[[email protected] 0]

2 minutes ago, Lmx2315 said:

За время менее одного отсчёта надо разослать синхрокоманду и применить её к сигналу запуска DMA АЦП и сбросить по ней внутренние часы датчика. Повторную команду синхронизации надо слать за время меньшее чем по расчётам накопятся ошибки разсинхронизации в датчиках.

Синхронизировать два датчика таким образом я думаю, что смогу. Хотя и не хочется - пусть бы АЦП+DMA разных датчиков работали на своих "родных" частотах, с разбегом по фазе вплоть до одного цикла оцифровки. Пусть за период между синхронизациями датчики разбегутся еще на 1 цикл. Меня вполне устраивает итоговый разбег в 1-2 (да может и 3) оцифровки, как писал в начале.

У меня другие непонятки: пусть есть всего один датчик, но при опросе его буфера за 1 с там может быть как 1000, так и 999, и 1001 оцифровка. При идеальном совпадении часов/синхронизации набега не будет, т.е. за 100 c будет суммарно вычитано от 99`999 до 10`001. Проблема в том, что я не знаю, как должен действовать алгоритм на ПК, когда в него поступает неодинаковое количество оцифровок за одинаковый период времени. Можно выкидывать "лишние" и додумывать "нехватающие" оцифровки, но это как-то совсем криво.

6 minutes ago, Lmx2315 said:

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

Здесь я не понял. Тактовые частоты разных датчиков в моем случае не могут совпадать.

[Plain 168]

2 часа назад, [email protected] сказал:

чуть подробнее?

1 час назад, [email protected] сказал:

не знаю, как должен действовать алгоритм на ПК, когда в него поступает неодинаковое количество оцифровок за одинаковый период времени ... пусть бы АЦП+DMA разных датчиков работали на своих "родных" частотах

Ну т.е. взаимно — сперва спросите у автора того неизвестного алгоритма, а то задача изначально слегка неточна. Если это дискретизация, а не сбор данных, то каждому ведомому требуется ФАПЧ, восстанавливающая в его местности частоту и фазу ведущего, и разумеется, вышеозвученные несинхронизируемые датчики изначально не годятся для такой задачи.