Нужна помощь Система хронометража прохождения гоночной трассы

[pvvx]

Меня вполне устроит точность синхронизации +/- 0,01 сек.

Я из реалий и указал +-10 мс.
Дело не в точности хода счетчиков, а во времени фиксации значений с них и внешнего события. В системе не реального времени внешнее событие регистрируется по прерыванию, но система может отложить его обработку на неопределенный срок, если в ней нет обслуживания приоритетов исполнения аппаратных прерываний и приортитетов у исполняемых задач. ESP8266 не имеет даже простейшей RTOS и во время работы драйвера WiFi системные прерывания и обработка WiFi выставленны на уровень выше пользовательских. Т.е. вам придется вклиниваться в закрытый код и глубоко копать, да тестировать, подбирая некий алгоритм, чтобы справиться с системой. Тогда вы получите возможность обработки внешних событий с джиттером примерно до 180 us. Это не точно, т.к. зависит от версии SDK, но так вышло при замерах и неком эксперименте. Если не будете предусматривать массу условий, а возьмете например Arduino IDE - то получите неопределенные задержки (дыры в исполнении пользовательского кода) примерно до 0.7..0.9 сек.

Можно немного подробнее про GPS?

Практически все модули GPS имеют аппаратный выход (вывод или он конфигурируется) на котором выводится синхро сигнал - импульс 1 раз в сек с малым джиттером. Его качество и частота зависит от модели, но обычно один импульс в 1 сек (это мои данные, на основе перебора разных моделей с 2000-го года - возможно кому-то чаще попадались другие варианты).
А время вы можете считать по их протоколу через UART.
Что нужна синхронизация - это исходит из вашего описания. Но насколько качественная и как её реализовывать - это вам решать. "Мопед не мой, я всего разместил объяву..."
------
Опишу подробнее, а то вдрух:

Возьмем для простоты черный ящик.

К нему идет провод от кнопки. Далее как минимум два варианта:

1) Вы нажимаете кнопку, срабатывает прерывание по изменению на I/O. Проц переключается, но еcли разрешены вложенные или приоритетные прерывания, то в этот момент, к примеру, срабатывает прерывание приема блока по WiFi с блоком смены ключа шифрования.

Представляете сколько вам придется сделать тестов, чтобы, к примеру, словить это или аналогичное событие, чтобы потом с уверенностью говорить, что "у меня всё на ESP8266 работает", как это любят делать все Ардуинщики? По этому спорить или слушать их мнение бесполезно.
Далее система меняет ключ шифрования пусть за 0.5 сек, т.к. процедур и уровней вложения там немеряно… Потом происходит возврат в ваш код и там считывается число из часов. Но с момента нажатия уже прошло 0.5 сек.

2) Примерно то-же самое – система обрабатывает какую-то длинную задачу и запретила прерывания. Кнопка нажата – реакции нет. Система отработала и разрешила прерывание – сработала ваша процедура распознавания нажатия и фиксации его к таймеру. Но реальное нажатие кнопки было уже давно


Выходит только с RTOS или вклинивание и разруливание аппаратными средствами на том SoC самому, включая изучение уровней приоритетов системы или даже их сдвиг, с переключением на своё управление системой вас спасет. Никакая Arduino или SDK с закрытым кодом в таком случае не поможет…

 

[nich]

Хотел бы еще раз уточнить у автора всю схему.
В точке B располагается старт, в точке A "мозг системы", задача: как можно быстрее и точнее передать время старта, правильно я понимаю?
Помимо работы с железом, я вижу реализацию на программном уровне, например так: при подключении устройства к серверу, синхронизируется время (отдельными командами, не торопясь), далее девайсы работают в одном ритме.
В момент старта, на сервер передается время старта, поэтому скорость прохождения сигнала не столь важна, для зрителей (судей, операторов) задержка реакции системы в 0,1-0,3 сек не будет видна, а в логах будет известно точное время.
Механизм синхронизации времени, на мой взгляд не сложно реализовать (заранее оговорюсь, что вся сложность зависит от точности, 0,01 сек - это бесконечность).
Логично, что чем меньше в цепи элементов, тем быстрее передастся сигнал, но в данной ситуации присутствует несколько звеньев работающих не на RTOS системах, поэтому гарантировать скорость (время работы) не могут.

PS Все вышесказанное исходя из своего опыта работы. Являюсь разработчиком системы электронного судейства в соревнованиях по автомобильному дрифту. Достаточно плотно работаю с устройствами, которые через WiFi соединяются с сервером реалтайм, подводных камней достаточно много, шишек набили столько же. Могу поделится опытом и посодействовать разработке (на общественных началах).

 

[pvvx]

Механизм синхронизации времени, на мой взгляд не сложно реализовать (заранее оговорюсь, что вся сложность зависит от точности, 0,01 сек - это бесконечность).

Вы уже использовали штатные счетчики WiFi TSF (Timing Synchronization Function) в реальных проектах? Я пока - нет. Только в тестах, да вокруг да около. Хотелось бы узнать реальность их применения - итоговые практические результаты эксплуатации, зависимости от применяемых WiFi устройств и т.д....
Для страждущих, тема синхронизации к +-5 us (микросекунд) на ESP8266 и типа обсуждалась тут:
https://esp8266.ru/forum/threads/sinxronizacija-chasov.1951/page-10#post-28358
Все проблемы расхождений возникают от невозможности привязки-синхронизации внешнего события к значению счетчиков в ESP8266 (отсутствие RTOS и неприспособленность системы для таких действий). На RTL871x немного другая проблема и вопрос вроде как решается проще... но теряем энерго-эфективные режимы, т.к. в них производится отключение блока WiFi между beacon-ами и соответственно аппаратного счетчика TSF...
График расхождения часов в мкс на основе TSF на ESP при работе в связке с роутером ASUS от эталонного генератора https://esp8266.ru/forum/attachments/snimok1135-gif.3013/ (без фильтрации задержек-джиттеров прерывания от внешнего события возникающих в самой процедуре прерывания и считывания-вычисления текущего счетчика TSF).
Т.е. это уже расхождения кварцев систем от температуры.

 

[nich]

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

 

[pvvx]

При наличии чистого эфира это наверно хватит, да и задача у вас позволяет. Вам достаточно просто считать значение TSF приходящее от роутера на станции каждый beacon, не прибегая ни к каким дополнительным алгоритмам и передавать его в связке к событиям на базу. Вам даже всё равно – включены или нет всякие энерго-эконимичные режимы, т.к. если устройства не спят (DTIM=1) и следование beacon стоит стандартное – 0.10024 сек, то и счетчик возобновляется в них каждые 102.4 ms. Без этого связь WiFi вообще не работает - это определяет арбитраж кто и когда из участников сети выходит в эфир... Неоределенности участников уже в несколько мс порушат всю связь и вызовут дополнительное потребление у устройств находящихся в спящих режимах(!). ESP8266 по этому не лучший вариант - она не имеет сертификации у альянса WiFi и является кривой игрушкой. (Участие ESP8266 в сети приводит к увеличению потребления у других устройств - в вашем смарте быстрее сядет акб, а если на ESP ещё включена своя SoftAP - то ещё быстрее... Зато сам ESP - дешевый...
И как когда-то выразился представитель Espressif – исходные коды не дадут, т.к. там у них эксклюзивные алгоритмы обработки WiFi
Если это всё перенести на Arduino IDE, то выходит, что пользовательский код с рекомендуемыми задержками отдачи системе времени на обработку, описанные горе специалистами, вызывает сдвиги в следовании beacon и увеличение окна активности на его прием у других участников сети, тем самым выжирает у них батарейку. В случае с SoftAP ESP8266, с эксклюзивным алгоритмом от Espressif , вообще не рассматривает других участников сети и она работает асинхронно, приводя к увеличению коллизий в эфире и прочим бедам (как вредитель в огороде). Зато стоит дешево )

Но часто требуется постоянная синхронизация, c большей точностью …

 

[pvvx]

Это всё к тому, что ESP8266 не рекомендуется использовать в сетях WiFi, где существует не один участник. На оф. страницах форумов и сайтов Espressif вы найдете рекомендации использования ESP8266 в связке с выделенным роутером на каждый модуль и отсутствие рядом работающих других устройств WiFi. В других случаях никакие ошибки или недочеты они не принимают

Это всё влияет на выбор компонентов системы:

Но применение синхронизации времени не обеспечивает отсутствия задержек при подаче визуальных команд, допустим, при включении стартового светофора - время (или скорость) передачи команды от модуля к модулю "по воздуху" будет зависеть от быстродействия Wi-Fi, а это, как я понял вещь в себе... Какие реально могут быть задержки в таких системах? В граммах... И можно ли считать их "системными", т.е. постоянными по величине?

Определяется именно частотой следования beacon, т.е. арбитражем от AP. Если устройство не активно, то оно проснется только в момент окна приема beacon. От этого первый "пинг" обычно всегда имеет задержку-джиттер-синхронизацию к сети в эти 100 мс, если DTIM=1, а если более, пропуск N beacon, то соответсвенно. Это в случае, если у устройства со Station включен какой режим экономии энергии (у ESP8266 и других модулей для IoT он обычно включен по умолчанию). А далее полная зависимость от арбитража AP, т.е. от участников банкета. Если участники кривые - такие как ESP, то и поведение всей структуры аналогичное. Так-же в окно времени передачи beacon никто не может передавать. Если вы попали с запросом передачи на такой момент, то и будет задержка отсылки пакета...
Кроме LPS режимов есть ещё параметры для IPS - описывать не хочу - WiFi mode IPS/LPS TDMA/DTIM
В итоге, в граммах, задержки в передаче имеют множественные зависимости от выбора компонентов и режимов работы всей структуры. Перевести в граммы не выйдет. Нормальная реальная WiFi система при правильной организации и без глушилки в эфире (находящегося рядом ESP8266 с зажатым RESET в момент активности передатчика или включенного путем плавном подъема питания , да и вообще работающего в округе) справиться с задачей к среднему максимуму задержек до 50 ms, но не забываем моменты смены ключей шифрования и других сетевых переключений и свойств протоколов (TCP - ожидания ACK)...

 

[Valentinych]

Всем доброго времени! В данный момент нахожусь на соревнованиях, пишу с мобилы.
Завтра вернусь домой, отвечу подробнее.
Благодарю nich за предложенную помощь, и с удовольствием ей воспользуюсь.

 

[Valentinych]

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

...система обрабатывает какую-то длинную задачу и запретила прерывания. Кнопка нажата – реакции нет. Система отработала и разрешила прерывание – сработала ваша процедура распознавания нажатия и фиксации его к таймеру. Но реальное нажатие кнопки было уже давно.

@pvvx, Вы абсолютно правы. Но с одной оговоркой: Вы не учитываете "заторможенность" смены событий в обсуждаемой задаче, и практически полное отсутствие в ней циклично выполняемых "пользовательских" действий. Оценить загрузку wi-fi модулей собственными "внутренними" задачами я не могу...

Ниже постараюсь восполнить пробелы в части постановки задачи в целом.

Хотел бы еще раз уточнить у автора всю схему.
В точке B располагается старт, в точке A "мозг системы", задача: как можно быстрее и точнее передать время старта, правильно я понимаю?

@nich, именно так. Хотя я для себя формулирую этот момент чуть иначе, т.к. задача двойственная. Сейчас сформулирую верменнЫе задачи системы корректнее.

Все, что описано в топике - это абрис задачи, приукрашенный "хотелками" разработчика и будущих потребителей (спортсменов). В реальности задача несколько проще.
Далее пошагово опишу процессы, которые должны происходить и фиксироваться системой.
При этом сразу буду вставлять собственные мыслишки и идейки, которые смогут (?) облегчить достижение поставленной задачи в целом.
Сразу нужно заметить, что наши гонки очень не продолжительные по времени - если строго формально трактовать международные правила, то гонка для каждого экипажа должна заканчиваться не позднее, чем через 200 секунд после его старта, т.е. с учетом трехсекундной задержки старта четвертого экипажа, гонку можно считать завершенной через 203 секунды с момента подачи команды, разрешающей старт первому экипажу.
Реально гонка может продолжаться и больше, но это уже никак не сказывается на ее результатах - худший результат в гонке все равно будет равен 200 очкам (секундам).
Исходя из этого следует рассчитывать и оценивать "кратковременную" стабильность RTOS системы, определяемую выбегом частоты кварцев задающих генераторов. Разумеется, "долговременная" нестабильность за счет возможных температурных градиентов окружающей среды при этом может достигать довольно больших значений, но прикидочные расчеты показывают, что они все равно будут укладываться в допустимую точность измерения времени гонки +/- 0,1 секунды.

Теперь немного о регламенте гонки, в части замеров времени.
1) Перед началом каждой гонки начальник старта нажатием и удержанием на 5-7 секунд кнопки на модуле "В" "обнуляет" систему от предыдущих данных, подготавливая ее к выполнению определенного алгоритма действия.
В это же время может проводиться мониторинг батарей питания всех модулей со сбором информации
в модуле "А".
2) Сразу после этого, коротким нажатием той же кнопки (без удержания), запускается интервал "минута на запуск и прогрев двигателей". В течение этого интервала все четыре индикатора на линии старта (модули "E", "F", "G", "H") ведут обратный отсчет времени - сначала в десятках секунд (от 6 до 1), затем в единицах секунд (от 9 до 0). При этом единицы секунд на 2, 3 и 4 индикаторе начинают "запаздывать" на одной секунде для каждого экипажа, т.е. команда "Старт" для второго экипажа происходит с задержкой в 1 секунду, для второго экипажа - еще на одну секунду, и т. д.
Отсчет этого времени можно было бы полностью передать "мозгам" этих четырех модулей, если бы не необходимость передачи команды о старте каждого экипажа на "базу" (в модуль "А"). Поэтому видится целесообразным "листать" цифирьки на секторных индикаторах с модуля "В" начальника старта, передавая одновременно команду и в секторные модули, и в модуль "базы". Маленький плюс при этом в том, что расстояние связи между модулем нач. старта, и секторными модулями сокращается до минимума, и не превышает 5-10 метров. Думаю, это позволит обойтись в секторных модулях простенькими wi-fi-"свистками" типа esp-07 или аналогичными, с PSB-антеннами "на борту", и при этом получить довольно скоростную связь в этом сегменте системы. Хотя никто не мешает к тем же esp-07 подключить и внешнюю штыревую антенну, разместив ее внутри герметичного пластикового корпуса индикатора.
Модуль "В" может иметь внешнюю антенну с небольшим коэффициентом усиления (3-6 дБм), что обеспечит устойчивую связь и с модулем "А", удаленным от него на ~120 метров.
Второй вариант работы системы (точнее - первый, прописанный в правилах) - это подача команды "Старт" для каждого экипажа по истечению 60 секунд на запуск начальником старта при взмахе флагом (модулем "В"). При этом команда может подаваться как коротким нажатием на ту же кнопку, так и по сигналу с датчика-акселерометра при взмахе флагом.

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

У меня была мысль в момент рестарта системы перед каждой гонкой, наряду с мониторингом батарей питания, передавать на базу еще и "текущее" время модуля "В", который требует синхронизации с базой. Для этого можно просто прочитать состояние счетчика времени работы модуля esp (видимо, это как раз и есть счетчик TSF?), и отправить его значение на базу, где уже сравнить с "текущим" временем базы, и программно "уровнять" их. При этом не требуется гонять команду синхронизации туда-обратно, значит, примерно в два раза сокращается и суммарное время вероятной ошибки синхронизации. Положительным здесь мне видится и то, что такая процедура не требует вмешательство в работу модуля и "рихтования" его регистров, что тоже, как я понимаю, требует аппаратных и временнЫх затрат.
Все остальные модули системы (фиксация ошибок прохождения трассы и подсистема управления светофором на дальней точке трассы) не требуют синхронизации, так как не влияют на точность измерения времени гонки.

2) После старта система некоторое время (минимум 3-5 секунд) практически ничего не делает. Первое внешнее событие наступает, когда первая модель долетает до траверса дальней точки трассы. В этот момент подается команда на включение одного из фонарей светофора (с модуля "С" на модуль "D"). Здесь так же время задержки должно быть не более 0,01-0,05 сек. Одновременно сигнал об этом событии принимается модулем "А", для того, чтобы оценить, достигла ли модель точки разворота. Но время передачи этой команды на модуль "А" может достигать 3-4 секунд, главное, чтобы эта команда "достигла" модуля "А" до того момента, когда будет подана команда о завершении круга (эта команда подается в модуль "А" по проводам от пультов судей - счетчиков кругов). В том случае, если команда от модуля "С" не поступила до завершения моделью круга, экипажу начисляется штрафное очко.

3) В ходе гонки могут фиксироваться нарушения, но при этом фиксировать момент такого нарушения не требуется, т.е. не требуется и синхронизовать оставшиеся модули с базовым. Главное, чтобы рано или поздно факт нарушения был записан в "мозги" базы, и учтен при вычислении окончательного результата гонки.
Это касается всех остальных модулей, не упомянутых в этом сообщении.

4) В процессе гонки после прохождения каждой моделью очередного круга индикаторы на линии старта (модули "E", "F", "G", "H") отображают пройденные моделью круги. После прохождения крайнего, десятого круга, на индикаторе высвечивается блинкующая в течение 30 секунд буква "F" (финиш).

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

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

 

[Valentinych]

Могу поделится опытом и посодействовать разработке (на общественных началах).

Буду очень рад этому, и отвечу на любые Ваши вопросы как в форуме, так и в личной переписке.

 

[Valentinych]

Возвращаюсь к теме после вынужденного отсутствия.
За это время проанализировал рекомендации форумчан, почитал темы форума, в которых поднимались вопросы, связанные в реал-тайм синхронизацией и быстродействием канала передачи данных и поковырялся в интернете, пытаясь найти готовое решение, которое можно было бы применить для реализации моей задумки.
В итоге пришел к выводу, что в поставленной задаче целесообразнее использовать не wi-fi модули ESP8266, а обычные RF модули, например - NRF24хх, которые даже при использовании в качестве управляющего контроллера дуины (и ее стандартных, медленных библиотек) обеспечивают скорость пинга между двумя модулями не хуже 1-2 мс. Такой точности мне вполне достаточно.
За прошедшее время сформулировал основные требования к системе, и алгоритм работы в случае ее построения на модулях NRF24. При этом постарался оптимизировать связи и маршруты передачи данных между составляющими блоками системы, а так же распределил порядок и очередность внутрисистемного администрирования между двумя ключевыми блоками.
На приведенном ниже рисунке показана гоночная трасса и места расположения всех блоков системы.


Время цикла работы системы определяется длительностью одной гонки:
1) Перед каждой гонкой по нажатию и удержанию на ~5 секунд кнопки, распложенной на пульте блока "В" начальника старта (маршала), который находится в центре трассы, начинается рестарт системы.
2) Функция администрирования присваивается блоку "В" (маршал), который посылает команду блоку "А" на обнуление всех данные предыдущей гонки.
Затем блок "В" поверяет состояние своей батареи, и посылает запрос на мониторинг батарей питания секторных блоков "E", "F", "G", "H", которые находятся в непосредственной близости от него. После мониторинга блок "В" передает на блок "А" информацию о уровне заряда батарей питания ("высокий", "средний", "низкий") - далее эта информация будет отображаться на мониторе ПК секретаря соревнований, контролирующего ход гонки (в судейском блоке). На рисунке этот ПК не показан, но канал связи с ним от блока "А" может быть как воздушный, так и проводной - расстояние между блоком "А" и ПК обычно не превышает 10-30 метров..
3) Затем функция администрирования передается блоку "А" (база), который проводит мониторинг батарей питания блоков "C", "D", "I", "K", "L".
4) Проводится демонстрация моделей, при которой факт идентификации каждой модели судьями дальней вешки подтверждается кратковременным включением соответствующего фонаря светофора (см. п.7), после чего администрирование вновь передается блоку "В".
5) Блок "В" начинает обратный отсчет времени (команда "60 секунд на запуск и прогрев двигателей"), управляя цифрами на одноразрядных семисегментных индикаторах секторных блоков "E", "F", "G", "H", отображая сначала десятки секунд (от 6 до 1) до старта, затем единицы секунд ( от 9 до 0). Отсчет ведется раздельно для каждого сектора, с запаздыванием в одну секунду для каждого последующего сектора.
6) Окончание подготовительного времени и включение цифры "0" на индикаторе, является командой, разрешающей старт экипажу. Одновременно с командой на включение цифры "0" на секторном индикаторе, с блока "В" на блок "А" подается команда на включение секундомера для первого, второго, третьего и четвертого участников. Этот момент - единственный за все время гонки, когда требуется максимальная скорость передачи команды. Здесь время задержки не должно превышать 10 мс.
7) После старта четвертой модели, блок "В" передает функции администратора блоку "А", а сам переходит в режим Standby до следующего рестарта системы . За три секунды, разделяющие старт первой и четвертой модели в системе не происходит никаких событий, требующих фиксации.
В процессе текущей гонки блок "В" больше не используется.
8) Блок "А" начинает с периодичностью в несколько миллисекунд опрашивать блок "С", ожидая нажатия кнопок (4 кнопки на блоке "С"). Как только будет зафиксировано нажатие любой кнопки на блоке "С", блок "А" передаст на блок "D" команду на включение соответствующего фонаря (4 фонаря разного цвета на светофоре). Здесь допустимая задержка может достигать 0,01-0,1 сек.
8) Завершение первого (и последующих) круга конкретной моделью фиксируется нажатием кнопки (-ок) на блоке "А" (4 кнопки). Кнопки связаны с блоком проводами, поэтому временнЫе задержки здесь не будут превышать времени исполнения возможных прерываний микроконтроллера (в худшем случае - единицы микросекунд). После фиксации завершения моделью очередного круга, блок "А" передает команду на соответствующий секторный блок "E", "F", "G" или "H" на включение цифры, соответствующей количеству пройденных кругов (от 1 до 9).
После завершения десятого круга на 30 секунд включается блинкующий символ "F" (финиш). Задержка передачи команды от блока "А" к блокам "E", "F", "G", "H" на смену цифры на индикаторе не принципиальна, и может достигать сотен миллисекунд, на влияя на ход и результаты гонки.
После завершения периода индикации символа "F", секторный блок автоматически переходит в режим Standby.
9) Ошибки, допущенные участниками в процессе гонки, фиксируются (нажатием соответствующих кнопок) в памяти контроллеров судейских блоков ("I", "K", "L") , и хранятся до окончания гонки. После завершения гонки последним участником, блок "А" переназначает сетевые адресные номера труб (заменяя адреса блоков "E", "F", "G", "H" на адреса блоков "I", "K", "L"), опрашивает блоки "I", "K", "L", и собирает информацию об ошибках, которые затем учитываются при вычислении окончательного результата гонки.
Ошибки, допущенные участниками на старте (фальстарт, и т.д.), фиксируются начальником старта (маршалом) нажатием кнопки на соответствующем секторном блоке "E", "F", "G", "H", и считываются блоком "А" в моменты подтверждения секторным блоком получения команды на смену информации на индикаторе.
10) После завершения сбора информации об ошибках, блок "А" передает команду блокам "I", "K", "L" на обнуление регистров памяти, в которых хранилась информация об ошибках, и команду на переход в режим Standby.
11) Завершающем действием гоночного цикла является перенастройка сети в состояние, предшествующее рестарту системы, и переход блока "А" в режим ожидания рестарта системы.
Таким образом, в каждый момент гоночного цикла в сети одновременно бывает задействовано не более 7 абонентов:
а) Перед рестартом, при мониторинге батарей "первой очереди", и во время старта, в сети зарегистрировано 6 абонентов - блок "В" (администратор), блок "А" и блоки "E", "F", "G", "H".
b) Во время мониторинга батарей "второй очереди" и демонстрации моделей сеть состоит из 6 абонентов - блок "А" (администратор), и блоки "С", "D", "I", "K", "L".
с) Во время гонки в сети работает 7 абонентов - блок "А" (администратор), блоки "С", "D", "E", "F", "G", "H".
d) После окончания гонки, во время сбора информации об ошибках в сети работает только 4 абонента - блок "А" (администратор), и блоки "I", "K", "L".

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