У кого есть мысли о синхронизации?

Batu · 2020-12-02 13:02:59

Необходимо синхронизировать несколько устройств находящихся на расстоянии 100 метров. Пробовал передатчиком на частоте 300мгц непредсказуемая задержка 170 мксек. Есть что-то более простое? Передается код устройства и код операции. Т.е. два байта. Дело не только в задержке, а в непредсказуемости. Т.е. ее не получается учесть.

Mishka · 2020-12-02 18:29:13

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

Batu · 2020-12-02 19:03:40

Mishka пише:

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

Два типа устройств. До 16 штук каждого типа. Точность какая возможна. Ибо светодиодами не всегда удобно. Не вопрос же в задержке, но хотя бы предсказуемая что б можно было вычислить и учесть. Если есть реальный вариант, то готов оплатить лучшее экспериментальное подтверждение. Передать надо 3-4 байта. Это что б с запасом. Синхронизация по первому байту. Т.е. сама скорость не принципиальна. Передатчик (он же синхронизатор) один.

Остання редакція Batu (2020-12-02 19:07:27)

Mishka · 2020-12-03 03:09:58

Вообще говоря, 170 мкс - это уже неплохой результат.

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

Например, устройство TX генерирует некоторый пакет, состоящий из преамбулы и четырех битов 0101. Его получают три устройства А, В и С. Они могут выполнять команды, которые синхронизированы по переднему фронту. При этом А и В работают на одной и той же частоте, но со смещением фаз генератора частоты, а С работает на частоте в два раза большей, чем у А и В. Из диаграммы видно, что время получения радио пакета будет плюс минус одинаковое. А вот время сборки пакета и вызов прерывания у С занимает времени меньше, чем у А или В:

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

Например, такой подход реализован в протоколе RBS - Reference Broadcast Synchronization. Один из узлов рассылает специальный пакет, затем каждый узел отмечает время его получения и после этого все узлы неспешно обмениваются этим значением времени, чтобы настроить свои часы относительно друг друга. Протокол можно несколько подправить для данной задачи и вместо того, чтобы обмениваться собственно временем, можно обменяться задержкой от момента получения пакета до момента, когда требуется выполнить некий код синхронно на всех устройствах. Самая большая задержка из всех устройств будет определять задержку на остальных, более быстрых устройствах. Если время реакции суть не так важно, то можно вообще иметь постоянную задержку, достаточно большую, чтобы любое устройство успело обработать все, что необходимо, и синхронно со всеми начать выполнять нужный код после того, как был получен нужный пакет.

В случае, когда нет возможности получить прецизионный штамп времени, предлагаю пойти другим путем. Идея в том, что если ни отправитель, ни получатель не имеют возможности точно сказать, сколько понадобится времени на формирование, отправку и получение пакета, то снимая статистику можно все равно приблизительно вычислить разницу между часами отправителя и конкретного получателя. Она будет равна минимальной разнице во времени среди всех полученных пакетов. Задержка, которую при этом должен иметь получатель, чтобы синхронно с остальными получателями выполнить какое-то действие, должна быть максимальной разницей среди всех получателей.

Например, отправитель высылает пакеты и добавляет в них свое время (на уровне приложения). Пакеты уходят c такими значениями:

X = 120 140 160 180 200

В свою очередь получатели А и В имеют задержку +75 мкс (время опережает Х) и -45 мкс (время отстает от Х) и по факту принимают пакеты в такое время:

A = 204 221 243 260 276
B = 71  92  116 134 151

Разница, соответственно, составляет:

A - X = 84 81 83 80 76,       da = min(A - X) =  76
B - X = -49 -48 -44 -46 -49,  db = max(B - X) = -44

При этом da и db посчитаны почти правильно. Это значит, что в тот момент, когда отправитель Х высылал свои пакеты, время на А и В на самом деле было почти таким:

A* = X + da = 196 216 236 256 276
B* = X + db =  76  96 116 136 156

Далее, максимальная задержка составила:

dx = max(abs([A - X] - da), abs([B - X] - db)) = max(8, 5) = 8

Это значит, что, после того, как и А, и В обменяются этим значением задержки в 8 мкс, если бы они снова получили эти же самые пакеты от Х, они должны были бы совершить синхронное действие в следующие моменты времени:

X =                 120 140 160 180 200
A** = X + da + dx = 204 224 244 264 284
B** = X + db + dx = 84  104 124 144 164

Математически это разница между часами А и В относительно Х:

A** - B** = X + da + dx - (X + db + dx) = da - db

Выполняя алгоритм в потоке, синхронизация будет становится точнее и точнее. Однако нужно отметить, что если таймер на А или Б будет систематически отставать или спешить, ошибка может начать накапливаться и dx начнет расти. Одним из решений можно предложить время от времени синхронизировать таймеры между собой. Еще одно решение - регулярно сбрасывать da и db, а вернее учитывать при их расчете только N последних значений. Тогда окно dx будет все время относительно небольшим.

Mishka · 2020-12-03 03:14:16

Кстати, если подходит, dx можно не синхронизировать, а иметь изначально с запасом. Например для случая выше поставить MAX_DX = 20. Но все равно вычислять его, чтобы понимать, когда требуемая задержка выросла до критически большой и текущее значение MAX_DX не подходит для того, чтобы все узлы работали синхронно.

Batu · 2020-12-03 09:28:38

Mishka пише:

Кстати, если подходит, dx можно не синхронизировать, а иметь изначально с запасом.

Запас ничего не меняет. Устройства не могут обмениваться между собой. контроллер STM 20Мгц.
Нужно конкретное предложение по приемнику и передатчику что б принять один байт, сравнить с собственным номером и выдать 1 на пин. Что б на всех устройствах максимально синхронно запустить другие устройства.

vvr · 2020-12-03 11:04:15

уж не камеры ли включать собираетесь или вспышки ?

MikeM · 2020-12-03 11:33:53

При появлении первых признаков поступления сигнала (любого!) приёмник формирует сигнал прерывания, время поступления которого контроллер запоминает по собственному таймеру (синхронизация с другими устройствами не нужна). Далее следует сколь угодно продолжительная обработка сигнала. Если сигнал идентифицирован как такой, по которому нужно что-то делать, то нужно вспомнить "начальный момент " и отсчить от него нужный интервал. Если чувствительность приёмников сделать одинаковой то рассинхронизация будет в пределах времени реакции на прерывание.
Приёмник для обнаружения сигнала должен быть сугубо аналоговым. В противном случае идея убивается напрочь.
Приёмник для выделения информации из сигнала может быть любой.

Остання редакція MikeM (2020-12-03 11:40:22)

Batu · 2020-12-03 11:41:14

MikeM пише:

При появлении первых признаков поступления сигнала (любого!) приёмник формирует сигнал прерывания, время поступления которого контроллер запоминает по собственному таймеру (синхронизация с другими устройствами не нужна). Далее следует сколь угодно продолжительная обработка сигнала. Если сигнал идентифицирован как такой, по которому нужно что-то делать, то нужно вспомнить "начальный момент " и отсчить от него нужный интервал. Если чувствительность приёмников сделать одинаковой то рассинхронизация будет в пределах времени реакции на прерывание.

Достойный результат. Можешь модели подходящих передатчиков/ приемников купить или свмим делать?

MikeM · 2020-12-03 11:48:34

В ближайшие несколько дней не могу - занят очень и очень. Потом можно будет посмотреть.

Batu · 2020-12-03 12:25:03

ок

MikeM · 2020-12-03 12:34:45

А какие передатчики и приёмники использовались?

Batu · 2020-12-03 13:23:14

MikeM пише:

А какие передатчики и приёмники использовались?

http://www.kosmodrom.com.ua/el.php?name=SYN115-433MHZ

Mishka · 2020-12-03 14:00:13

Batu пише:

Mishka пише:
Кстати, если подходит, dx можно не синхронизировать, а иметь изначально с запасом.
Запас ничего не меняет. Устройства не могут обмениваться между собой. контроллер STM 20Мгц.
Нужно конкретное предложение по приемнику и передатчику что б принять один байт, сравнить с собственным номером и выдать 1 на пин. Что б на всех устройствах максимально синхронно запустить другие устройства.

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

Радиомодуль может быть произвольный, потому что почти все современные устройства являются мультипротокольными и формируют пакеты программно. Для связи на 100 метров достаточно использовать модули 2.4ГГц. Тот же популярный nRF24 должен подойти прекрасно. Любые другие, включая 865 МГц или 433 МГц - тоже.

Остання редакція Mishka (2020-12-03 14:01:36)

Форум arduino.ua

#1 2020-12-02 13:02:59

У кого есть мысли о синхронизации?

#2 2020-12-02 18:29:13

Re: У кого есть мысли о синхронизации?

#3 2020-12-02 19:03:40

Re: У кого есть мысли о синхронизации?

#4 2020-12-03 03:09:58

Re: У кого есть мысли о синхронизации?

#5 2020-12-03 03:14:16

Re: У кого есть мысли о синхронизации?

#6 2020-12-03 09:28:38

Re: У кого есть мысли о синхронизации?

#7 2020-12-03 11:04:15

Re: У кого есть мысли о синхронизации?

#8 2020-12-03 11:33:53

Re: У кого есть мысли о синхронизации?

#9 2020-12-03 11:41:14

Re: У кого есть мысли о синхронизации?

#10 2020-12-03 11:48:34

Re: У кого есть мысли о синхронизации?

#11 2020-12-03 12:25:03

Re: У кого есть мысли о синхронизации?

#12 2020-12-03 12:34:45

Re: У кого есть мысли о синхронизации?

#13 2020-12-03 13:23:14

Re: У кого есть мысли о синхронизации?

#14 2020-12-03 14:00:13

Re: У кого есть мысли о синхронизации?

Швидке повідомлення

Підвал форуму