Форум arduino.ua

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

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

Вообще говоря, 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 будет все время относительно небольшим.

https://groupgets.com/manufacturers/flir

Direction Finidng может только указать направление. При наличии антенной решетки, расположенной на одной линии - в плоскости. При использовании двухмерной решетки - в пространстве. Однако расстояние до объекта будет неизвестным, и его можно только приближенно получить через RSSI. Для того, чтобы точно обнаружить местоположение объекта, нужно будет провести триангуляцию.

Что касается следования за человеком, то да, Direction Finding можно использовать, как вектор направления, а обход препятствий можно реализовать через другие датчики - ультразвук, IR, LIDAR, и пр. По сути это будут готовые входные данные для алгоритма поиска A*, где цель может свободно перемещаться.

Batu, так ИИ достаточно много? ;-)

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

Вместо этого предлагается управлять светодиодом, синхронизировав его с часами, которые идут независимо от delay(). Таким образом каждый раз loop() будет иметь возможность оценить значение таймера и принять решение, как переключить светодиод. Например, если таймер меньше значения X, то светодиод зажечь. Если больше - погасить. Подробнее:

https://www.arduino.cc/en/Tutorial/Buil … thoutDelay

Для воспроизведения более сложной последовательности можно запомнить время начала этой последовательности, а затем зажигать или гасить светодиод по прошествии определенного времени относительно начала. При этом сам код переключения светодиода должен выполняться при каждом цикле loop():

#define BLINKER_NOTIME -1

void()
{
    unsigned long currentms = millis();
    long long blinkerstartms;

    // ... some blinker related event happened ...

    switch (event) {
    case BLINKER_ON_EVT:
        // engage the blinker()
        blinkerstartms = currentms;
        break;

    case BLINKER_OFF_EVT:
        blinkerstartms = BLINKER_NOTIME;
        break;

    default:
        // nothing to do
    }

    if (blinkerstartms != BLINKER_NOTIME)
        blinkerstartms = blinker(blinkerstartms, currentms);
}

long long
blinker(unsigned long startms, currentms)
{
    // defined as offsets cumulative 0 + 8000 + 5000 + 8000 + 10000 + 18000
    unsigned int blinkms[] = {0, 8000, 13000, 21000, 31000, 49000};

    if (startms < 0)
        return BLINKER_NOTIME;

    // invert the blinker every time it reaches the next blinkms value
    for (i = 0; i < sizeof(blinkms)/sizeof(blinkms[0]); i++) {
        // TODO: handle the timer overflows
        if (blinkms[i] >= startms - currentms) {
            digitalWrite(LED_ADDR, i % 2 ? LOW : HIGH);
            return startms;
    }

    // we're done with the blinkms[] array - shut the blinker down
    return BLINKER_NOTIME;
}

Извините, никогда не писал для Ардуино, но идею, надеюсь, передать удалось.

Попробуйте один из модулей nRF52. Они не совместимы с Arduino, но c SoftDevice вы получите до двадцати одновременных ролей в каждом модуле. Возможно, Zephyr может поддерживать больше, пока не разбирался.

Также интересно, почему не подходит ESP32?

Игорь, подскажете, пожалуйста, это в формате тренировок IPSC / IDPA или для развлекательного тира, типа лазертаг?

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

Виктор, эти все линии заведены в кросс или это просто свободный конец кабеля?

AISLER производит платы в Германии и США и высылает по всему миру бесплатно, включая Украину (DHL, TNT, FedEx, до 4-х недель). Прототипы выпускаются в количестве кратном трем: 3, 6, 9, ...

Производство небольшой (5х5 см) двусторонней или четырехслойной платы обойдется где-то в 15 евро.

Детальнее https://aisler.net/

Для настройки антенны необходимо впаиваться в радиотракт между антенной и трансивером, и для этих целей нужен высококачественный кабель малого диаметра, до 2 мм. Один из вариантов - это RG178. Еще один вариант - Molex Temp-Flex.

На днях я поехал на местный радиобазар в надежде купить что-нибудь подходящее. Однако, к моему сожалению, того, чего нужно, там нет и в помине. Наиболее близкий вариант - это RG-174 (сопротивление 50 Ом, толщина 2.8 мм). Хоть он и не подходит для моих целей, я все же купил для тестов метр кабеля Cabletech RG-174 (10 гривень). Мне объяснили, что его часто ставят на WIFI или GSM. Кроме того, для интереса взял метр какого-то неизвестного коаксиального кабеля без изоляции или, как его называют, "провод в экране" (цена 5 грн), а также разъемы SMA (по 25 грн за штуку).

Разъемы, скажу сразу, пришлось выкинуть и купить другие. Те, что на базаре, просто не работают. При сборке я стабильно получаю короткое замыкание. Собрали три штуки - все выкинули. Еще один остался на память, чтобы знать, как выглядит и больше не покупать:

Пришлось отдельно заехать в "Радиомаг" и купить другие разъемы, на этот раз по 15 грн, но они оказались намного лучше. Собрал вот таких два кабеля, каждый по 1 м:

Итак, имеем два кабеля: кабель А и кабель Б.

Первый тест: кабель подключается к порту VNA, на другом конце устанавливается терминатор 50 Ом. При такой схеме включения коэффициент стоячей волны для идеального кабеля, рассчитанного на импеданс 50 Ом, должен быть равен единице, поскольку он определяется качеством согласования нагрузки и линии связи. По общему признанию, если кабель возбуждает стоячую волну с КСВ больше 1.22, то его использовать нежелательно. На графиках ниже отображено фактическое состояние дел; красный график - КСВ, синий график - импеданс.

Очевидно, что кабель Б имеет явно меньший КСВ и, следовательно, вносит меньше искажений. Кабель А при этом достаточно сносно работает до частоты 1.5 ГГц, но при этом бросается в глаза явное смещение импеданса с повышением частоты. Видимо, кабель А имеет слишком большую индуктивную составляющую.

Следующий тест проверяет то, насколько качественно собраны эти два кабеля. Геометрическая форма влияет не только на импеданс, но и на фазовые задержки. Это может быть важным моментом, если используются несколько подобных кабелей одновременно, например, для нескольких антенн MIMO или Bluetooth 5.1. Для эксперимента, кабелем соединяются два порта VNA и после этого выполняется калибровка VNA. После калибровки фазовая задержка принимается равной нулю. После этого, кабель нужно подвигать, поскручивать, подергать и снова посмотреть на фазовую задержку. Идеальный кабель не меняет своей формы и новых задержек вносить не будет.

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

И последний тест, самый очевидный - это вносимые потери. Для этого кабель подключается к двум портам VNA и оценивается уровень сигнала после прохождения через кабель. Потери отображаются на графике. Для сравнения, неплохой кабель будет иметь это значение порядка 80 дБ на 100 метров длины, хороший - около 60 Дб на 100 метров. Оба моих кабеля длиной один метр:

Похоже, что оба кабеля и разъемы очень невысокого качества. Что касается импеданса и вносимых помех (КСВ), кабель Б имеет явно более стабильную характеристику, однако при этом он хуже сделан физически: после скручивания он создает явно выраженную фазовую задержку. Также, для частот больших 500МГц я бы воздержался от использования кабеля Б длиннее одного метра.

В свою очередь по сравнению с Б кабель А вносит намного меньшие затухания на высокой частоте. Нужно, тем не менее, отметить, что это аж 1.5 Дб на метр на частоте 2.4 ГГц. Все-таки, кабель больше подходит для частот до 1 ГГц, где он ведет себя и стабильнее, и вносит не такие высокие потери.

Кабели, что шли в комплекте расширенной поставки, похоже, тоже не так уж и плохи, тем более за эти деньги. На моем приборе коэффициент стоячей волны не превышал 1.15, а контрольный замер показал и того меньше: