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

[Valentinych]

Извините, коротко не получится, даже тезисно. Впереди многА букАвок...

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

Трасса представляет собой треугольный маршрут со сторонами 180*180*40 метров, и размечается на ровной, горизонтальной, открытой площадке. По условиям безопасности запрещено находится внутри трассы и на расстоянии менее ~120 метров от ее оси всем, кроме участников гонки (4 экипажа) и судьи на старте. Все остальные судьи, обслуживающие соревнования (10 человек), по правилам должны находиться на линии безопасности, проходящей на расстоянии =>120 метров от оси трассы. Зрители должны находиться за линией безопасности.
Можно считать линию безопасности, параллельную оси трассы, базовым ориентиром для размещения стартового оборудования.

Все электронные девайсы системы должны быть расположены на оси трассы и на линии безопасности:
1) Основной модуль системы (хронометраж, подсчет кругов, подсчет допущенных ошибок) располагается в точке пересечения условного продолжения линии основания треугольного маршрута трассы с линией безопасности (расстояние по прямой => 120 метров). Будем считать его модулем "А".
На этот модуль должна собираться информация от остальных судейских модулей обслуживающих гонки (в том числе и мониторинг аккумуляторов). Модуль должен обеспечивать работу старта, и выполнять все основные вычисления (время, круги, ошибки) в автоматическом режиме, и передавать эту информацию на компьютер секретаря соревнований для дублирующего вычисления времени (точность вычисления не хуже 0,01 сек, лучше - 1 мс), и сохранения итогов соревнований в базе данных, реализуемой на Excel и VBA формах. При этом компьютер секретаря старта не входит в комплект стартового оборудования, которое должно являться полностью автономной и функционально независимой системой. Но связь между модулем "А" и компьютером секретаря осуществляется так же, как и с остальными модулями системы.
Органы управления модулем "А" - четыре кнопки судей - счетчиков кругов. Кнопки нажимаются судьями в момент пресечения линии старт-финиш после завершения очередного круга гонки, с отсечкой текущего времени гонки.
Учитывая широкий круг задач, которые должен решать модуль "А", предполагается, что он будет организован на обычном WIFI-роутере с системой OpenWRT. Это даст возможность сохранять довольно большой объем логов системы для возможного последующего анализа или "разбора полетов" в спорных ситуациях.
Модуль располагается на штанге высотой 2-3 метра от земли, имеет выносные пульты с кнопками управления.

2) Модуль судьи на старте (модуль "В") представляет собой пульт в виде стартового флага (пластиковая труба длиной ~500 мм). Располагается в районе линии старта (у основания треугольной трассы).
Модуль функционально минималистичен: из органов управления - всего 1 "многорежимная" кнопка, и (возможно) несколько светодиодов (или OLED дисплей), индицирующих текущий режим системы. Кнопка при длительном нажатии и удержании передает на модуль "А" сигнал, "обнуляющий" систему перед очередной гонкой. При коротком нажатии кнопки (последовательно, после "обнуления") передаются команды соответствующие регламенту соревнований: подготовка, рабочее время, и раздельный старт для каждого участника. Как вариант - исключить использование этой кнопки при старте гонки, заменив ее на датчик-акселерометр, который будет выдавать сигнал старта для участников при взмахе флагом.
Модуль находится в руках у судьи, т.е. на высоте 0,5..2,0 метра над землей (в зависимости от того, поднят он, или опущен).

3) Следующие два модуля в паре представляют собой подсистему контроля правильности прохождения участниками гонки дальней точки дистанции (вершины треугольной трассы). Модуль "С" судей располагается на линии безопасности, в точке ее пересечения траверсом дальней точки трассы (расстояние от модуля "А" 180 метров). Этот модуль управляет работой четырехцветного светофора (модуль "D"), расположенного в вершине треугольника трассы, и сигнализирующего участником о прохождении траверса дальней точки. Расстояние между модулями "C" и "D" =>120метров.
В принципе, это отдельная задача уже решена, правда, на другом радиоканале, тоже 2,4 ГГц. Но для корректной работы системы в целом, необходимо сигнал на включение светофора учитывать при подсчете ошибок прохождения трассы. Поэтому сигналы модуля "С" так же должны приниматься и обрабатываться модулем "А".
Органы управления модуля "С" - четыре кнопки (для каждого из судей-наблюдателей).
Органы, которыми управляет модуль "D" - светофор на светодиодных матрицах (4 матрицы по 172 сверхярких светодиода типа "Пиранья" красного, синего, зеленого и желтого цветов).
Высота этих модулей, установленных на треногах ~ 1,8 метра над землей.

Таким образом, модули "А", "В", "С" и "D" образуют прямоугольник размерами ~120 *~180 метров. Диагональ прямоугольника (прямая между точками "А" и "D") - максимальное расстояние, на котором необходимо обеспечить надежную и скоростную связь (в идеале пинг не больше единиц-десятков миллисекунд).

4), 5), 6), 7) Модули "Е", "F", "G", "H". Как и модуль "В" судьи на старте, располагаются на линии старта (в районе основания треугольника трассы). Представляют собой "одноместные" семисегментные индикаторы увеличенного размера (высота цифры ~150 мм).
Кроме того, каждый из этих модулей (E, F, G, H) должен быть оснащен кнопкой фиксации ошибок на старте (фальстарт), и передавать сигнал о таких ошибках в модуль "А".
Модули управляются сигналами от модулей "А" и "В". Располагаются на стойках высотой 0,5...0,8 метра над землей.

8),9),10) Три одинаковых модуля (модули "I", "K", "L") с четырьмя кнопками каждый, конструктивно и функционально аналогичны модулю "С". Так же служат для фиксации ошибок прохождения трассы судьями - наблюдателями в других точках трассы. Располагаются вдольа линии безопасности, с двух сторон от модуля "А", на расстоянии до 180 метров от модуля "А", на стойках высотой ~1,8 метра над землей.

11) Модуль "M" (бонусный) - управление информационным табло. Команды получает от модуля "А". Расположен в зоне выхода на гоночную трассу, вблизи (несколько метров) от модуля "А", на высоте 2,0-2,5 метра над землей.
Конструктивно табло размером примерно 2,0 * 0,2 метра будет выполнено на полноцветных светодиодных лентах с пиксельной адресацией (WS2813, 60 пикселей на метр).

Большинство модулей (кроме "А" и "М") питаются от автономных источников (LiPo аккумуляторы напряжением 7,2-14,4 вольт емкостью 2,0...3,5 А/час), поэтому должны постоянно мониторить состояние своих батарей, и передавать данные об уровне из разряда на модуль "А".
Модули "А" и "М" расположены в районе стартового кемпинга, и могут быть запитаны от дизель-генератора, который, как правило, имеется на всех соревнованиях. На крайний случай, предусматривается резервное батарейной питание (автомобильные аккумуляторы).
Применение проводных каналов связи между модулями не допускается. Исключение составляют выносные кнопочные пульты для судей-наблюдателей, которые в дальнейшем так же планируется заменить на "беспроводку".

Необходимо, чтобы все модули системы были помещены в корпуса, обеспечивающие защиту класса IP65, и могли работать в диапазоне температур от -10 С до +40 С, под прямыми солнечными лучами и не очень интенсивного дождя.
Время автономной работы системы от одного свежезаряженного комплекта аккумуляторов - не менее 10 часов.

Уфф... Кажется все...
Если что-то забыл, или описал невнятно, спрашивайте отвечу подробнее.

 

[Valentinych]

В топике описана задача, которую предстоит решить. При этом (повторюсь) сам проект не коммерческий (скорее - благотворительный), а его бюджет более чем скромный. В первую очередь это касается систем связи.
На данный момент имеется около двух десятков ESP-07 и -12, пара NodeMCU (разных релизов), десяток NRF24 (с PCB антенной) и пара "умощненных". Первоначально смотрел в их сторону, но потом как-то съехал на ESP, но ничего не мешает вернуться обратно.
Опыта работы с вифи устройствами нет. Вааще.. Программирую с трудом, и только на ассемблере (предпочитаю АВР).
Опыт конструирования и изготовления РЭА есть, и не малый - почти полвека в основном только этим и занимаюсь. Производственная база для механических работ, и соответствующие навыки имеются. Печатки - только промышленным образом, ЛУТ'ом переболел еще в детстве, хотя этой технологией владею в совершенстве. Платы могу разводить в разных CAD'ах, но для "хоббийных" поделок предпочитаю ДипТрейс и "лейку". Работаю в SolidWorks, и в других автоматизированных проектировщиках. Есть некоторый опыт (пока не очень большой) расчетов в программе ELCUT.
Блин, прямо резюме получается. Мо-быть кто-то и работу старому перцу предложит?

Для скептиков и пессимистов: задача БУДЕТ решена, невзирая на любой скепсис и сомнения (а их, как я понимаю, будет много). По этому прошу не тратить время (свое и мое) на разговоры о том, почему не надо заниматься подобной разработкой.
Но все дельные мысли, советы, рекомендации, и разумно-аргументированная критика будут приняты с благодарностью.
"Хотелки" буду описывать по мере пробуждения интереса к проекту со стороны участников сообщества (конечно, если такой интерес возникнет).
Пока готов к первоначальным обсуждениям задумки как таковой. Свои мысли и наработки по этой теме, безусловно уже имеются.

 

[Jury_78]

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

 

[Valentinych]

Вы правы только отчасти. Жесткие требования реал-тайм нужны лишь в одном месте - при передаче сигнала на запуск секундомеров от модуля "В" к модулю "А". И только в момент старта. Здесь необходимо обеспечить задержки не более 0,01 сек.
Дальнейшие отсечки времени и подсчет кругов проводятся по нажатию кнопок пультов, связанных с модулем "А" по проводам, т.к. судьи - счетчики кругов находятся непосредственно рядом с этим модулем (не более 2,5-3,0 метров).
Задержка передачи команды от модуля "С" к модулю "D" может достигать даже 0,05-0,1 сек.
Все остальные команды и сигналы, передаваемые по каналам связи системы не участвуют в хронометраже, и могут иметь существенные задержки (до сотен миллисекунд, и даже более) - это не скажется на общей стабильности работы системы и ее точности.

 

[pvvx]

Невидно никаких сложностей и вопросов по описанию. Задачи только в изготовлении – механические.

Мелкие проблемы видны всего в выборе модулей WiFi, для обеспечения точности синхронизации. Практика и обсуждаемые темы на форуме по синхронизации устройств WiFi к единому времени показали, что необходимо использовать счетчик TSF, передаваемый в каждом beacon от единой базовой станции, выполняющей роль AP. Достигаемая точность такой привязки стремиться к 1 мкс, т.к. каждый блок приемо-передатчика WiFi имеет аппаратный счетчик на 64 бита с дискретом в 1 мкс. Его значение и передается AP и принимается со всеми предусмотренными в стандарте коррекциями каждым участником сети, синхронизируясь с AP каждый beacon (102.4 мс). Доступ к данному счетчику зависит от программной реализации модуля WiFi. Точность привязки – от использованного оборудования. В вашем случае, с указанными расстояниями и с учетом, что эфир не зашумлен в "ближней зоне", автоматическая точность привязки по времени будет стремиться к +-5 мкс в самом драйвере и писать что-то своё не требуется.
Но, ESP8266 не имеет стандартных средств для получения текущего значения счетчика TSF и ограничен по другим вопросам синхронизации из-за своего базового закрытого ПО. Закрытый SDK от Espressif не позволяет получить время внешнего события точнее пары секунд – таковы там процедуры, запрещающие прерывания на данные периоды при разных событиях на WiFi.

По тому требуется только выбор оборудования для вашего проекта...

 

[Valentinych]

@pvvx, какие Вы видите варианты выбора аппаратных средств для достижения требуемых параметров системы?
Целесообразнее ли использовать NRF24, или RLT8710? Какие преимущества и недостатки у этих модулей?

Если я правильно понял, то проблема RTS на счетчике TSF касается только ESP. Но у меня это может быть реализовано в роутере, насколько я понимаю. Или нет?

 

[pvvx]

@pvvx, какие Вы видите варианты выбора аппаратных средств для достижения требуемых параметров системы?
Целесообразнее ли использовать NRF24, или RLT7810? Какие преимущества и недостатки у этих модулей?

Если я правильно понял, то проблема RTS на счетчике TSF касается только ESP. Но у меня это может быть реализовано в роутере, насколько я понимаю. Или нет?

А в роутере у вас есть доступ к данному счетчику, да ещё с учетом временем отработки процедуры передачи значения этого счетчика?
Это реализуется специально только в специализированном оборудовании. Если у вас нет исходных кодов драйвера или процедур для доступа к внутренностям, то ничего и не сделать. На те-же RTL доступ есть за счет того, что "надыбаны" все заголовки к регистрам WiFi, процедурам и структурам драйвера. Иначе NDA.
На ESP я это тоже прорыл и где-то указывал примеры кода для доступа к TSF. Но там другие проблемы - запреты драйвером WiFi прерываний на длительные сроки, что приводит к невозможности точной синхронизации с внешним событием. Одно ядро процессора не разорвать на две задачи одновременно, а система приоритетов прерываний или задач в SDK от Espressif не используется.
Т.е. точные часики то есть, но использовать их вы не можете...
Все другие методы не впишутся в требуемые параметры для вашего проекта (точность синхронизации -+ 10 мс). Только для решения задач создания всяких ФАПЧ, фильтрации и прочего придется написать толпу кода, если использовать что-то типа NTP. Но у вас открытая площадка и проще вместо этого хлама поставить GPS на каждое устройство которому необходима синхронизация.

 

[Valentinych]

Я вообще не вижу острой необходимости общей синхронизации всех девайсов системы (или не понимаю ее значения)... Грубо говоря, если все секундомеры реализовать внутри роутера (а так и планируется), то из удаленных команд принципиальной по времени поступления будет только одна - команда на запуск конкретного секундомера. Этой же командой включаются индикаторы-светофоры, разрешающие старт тому, или иному экипажу (модули "Е", "F", "G", "H").
Промежуточные отсчеты времени, счет пройденных кругов и останов секундомеров должен осуществляться "по проводам", от кнопок, которые будут подключены непосредственно к мозгам роутера.
Все остальные команды и события, передаваемые "по воздуху", а это фиксация ошибок прохождения трассы и мониторинг батареек питания, не влияют на измерение времени, и даже значительные временнЫе задержки ни на что не повлияют. Они просто должны быть зафиксированы, и учтены при окончательном подсчете результатов гонки.
Может быть Вы несколько преувеличиваете значение системной синхронизации в этой задаче?

 

[Jury_78]

Вы правы только отчасти. Жесткие требования реал-тайм нужны лишь в одном месте - при передаче сигнала на запуск секундомеров от модуля "В" к модулю "А". И только в момент старта. Здесь необходимо обеспечить задержки не более 0,01 сек.

Вы же хотите для "А" wifi роутер, а там скорей всего linux система, а это совсем не система реального времени. Я тут вижу только контроллер.

 

[Valentinych]

Тем не менее, в любом девайсе на линуксе есть программный секундомер, который работает с точность не хуже 0,01 сек. Что мешает запустить четыре секундомера одновременно? Мне же не нужна привязка к реальному текущему времени, хотя и эта опция в линукс-устройствах так же присутствует.
Или я опять чего-то не понимаю?

В конце концов, если сильно "припрет", то не сложно в модуль к роутеру присоседить еще и тиньку или мегу. Исключительно для измерения времени гонки. Готовое решение уже реализовано в аналогичной разработке без wi-fi. Но оно надо?
Меня в первую очередь интересует связь на базе wi-fi модулей. Давайте лучше поговорим об этом.

 

[Jury_78]

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

 

[Юрий Ботов]

Просто мысли:
- приходилось видеть системы больших стадионов, так вот, там система синхронизации всегда выделена отдельно и стоит реально больших денег. Я не предлагаю идти по пути удорожания... но подумайте о отдельной системе синхронизации для всего этого. Возможно это окажется проще чем пытаться засинхронизироваться неизвестно от чего. Я бы поставил маломощный передатчик на разрешенный диапазон (433 например) с непрерывным излучением и фазовой манипуляцией в момент "тика". Можно придумать что то еще.
- поскольку участники стартуют не одновременно, грех не автоматизировать контроль фальстарта: на участника крепится катафот (уголковый отражатель) который сбоку подсвечивается лазером(модулированным для устранения статической помехи), если катафот вышел из луча до стартового "тика" - фальшстарт. Пересечение катафотом луча - круг. Катафоты у разных участников можно клеить на разной высоте - чтобы автоматически их идентифицировать. Есть проблема - одновременное пересечение 2-мя участниками линии старта (будут заслонять друг дружку) - предусмотреть ручную фиксацию факта судьей.
- где спорт, там ставки, где ставки - там желание сорвать куш любыми средствами. Так, какая нибудь сволочь обязательно припрется с глушилкой и включит ее в момент, когда почувствует что его ставленник проигрывает. "Судейская система сломалась - повторяем/аннулируем заезд..." Недаром тут народ за провода ратует. А по уму в такой ситуации надо резервировать все каналы связи, разными системами, на разных частотах...

 

[Jury_78]

Я бы поставил маломощный передатчик на разрешенный диапазон (433 например) с непрерывным излучением и фазовой манипуляцией в момент "тика".

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

 

[Valentinych]

@Юрий Ботов, все мы любим фантазировать... Но что и Вы страдаете этим недугом - не ожидал.
Хорошо конечно, катафоты, лазерные лучи, и т.д. Но все это малоприменимо в условиях тех гонок, которые я пытаюсь автоматизировать. Так же, как маловероятно, что за этим спортом стоят высокие ставки на тотализаторе. И уж совсем не вероятно, что условный лихоимец припрется на старты с глушилкой, которая "забьет" работу системы. (Забегая вперед скажу, что так как современная аппаратура радиоуправления, которая используется спортсменами, работает как раз в диапазоне 2,4 ГГц, такой человек долго не проживет - его моментально вычислят, и закопают прямо на полянке, где проходят соревнования.)
Но это моя вина. Не подумал, что нужно сразу озвучить, о каких именно гонках идет речь, как именно происходит старт, и что из себя представляет "гоночный болид". Исправляюсь.

Речь идет об автоматизации старта соревнований радиоуправляемых гоночных авиа моделей класса F3D.
Модель (в разных подклассах) может стартовать как с земли, так и выпускаться из рук. И так как по базе модель летит на высоте от трех метров и выше, да еще со скоростью порой превышающей 350 км/час, зафиксировать лазерным лучом момент, когда она пересекает вертикальную плоскость над линией старт-финиш невозможно.
Именно это и вызвало мою иронию на Ваше рационализаторское предложение.
А так как некоторым моделям необходимо "разбежаться" перед взлетом, то и наличие каких-либо проводов на старте не допустимо. Что касается соединения проводами модулей - прикиньте, сколько для этого нужно кабелей, и какова будет надежность всей этой "паутины".
Одним словом - только "по воздуху", и только в диапазоне 2,4 ГГц, который разрешен для систем радиоуправления. На все остальное - табу.

А вот @Jury_78 верно понял основную задачу - дистанционно "по воздуху" запустить четыре электронных секундомера. Все остальное при измерении времени гонки делается обычными методами, не требующими синхронизации.

 

[Jury_78]

только в диапазоне 2,4 ГГц

Думаю, что этот диапазон ограничен по числу каналов, а у Вас радиоуправление работает в этом диапазоне, плюс мобильные телефоны с wifi и BT. Может выбрать другую частоту, есть же и другие разрешенные диапазоны, например 27МГц, может еще 433/443МГц.

 

[Юрий Ботов]

Но что и Вы страдаете этим недугом - не ожидал.

Я всего лишь человек

Именно это и вызвало мою иронию на Ваше рационализаторское предложение.

мне по описанию и по форме трассы показалось что речь идет о авто/мото. Сейчас во многих регионах расцвет этих направлений - "лучше на трассе чем на улице..."

 

[Юрий Ботов]

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

 

[sharikov]

Одним словом - только "по воздуху", и только в диапазоне 2,4 ГГц, который разрешен для систем радиоуправления. На все остальное - табу.

А вот @Jury_78 верно понял основную задачу - дистанционно "по воздуху" запустить четыре электронных секундомера..

Задержки в канале wifi непредсказуемы особенно если учесть что в том же диапазоне на вашей площадке работает 100500 систем радиоуправления.
Прохождение данных в любом радиоканале не гарантировано (помехи, шум и так далее).
Если вам нужно запускать секундомеры с надежностью 100.0% - только провод!

Заранее предусматривайте работу системы при непрохождении команд между любыми узлами. Иначе вас закопают прямо на площадке.

 

[Valentinych]

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

Современные цифровые системы радиоуправления, применяемые в моделизме работают именно на таких принципах (в т.ч. используются и последовательности Баркера). При этом по одному радиоканалу может передаваться одновременно до 20 пропорциональных команд управления бортовым оборудованием модели, а в одном и том же частотном диапазоне может одновременно беспроблемно работать несколько десятков комплектов ОДИНАКОВОЙ аппаратуры.
И что главное - реальные задержки отработки по каждому из N низкочастотных пропорциональных каналов не превышают единиц миллисекунд.
Существуют и системы двустороннего обмена - в этом случае на модель передается пакет кодированной информации о мгновенном положении двух двух-координатных джойстиков (это четыре пропорциональных канала управления), о положении дополнительных 4-6 пропорциональных каналов и плюс к этому еще до десятка каналов, работающих в релейном режиме (включено/выключено), но потенциально так же пропорциональных, а с борта модели обратно передается пакет телеметрической информации от ряда датчиков, отслеживающих как положение модели в пространстве, так и состояние самых важных агрегатных узлов.
Самое интересное при этом то, что каналы связи нашей аппаратуры построены на модулях, аналогичных модулям wifi как по частотному диапазону работы (2,4 ГГц), так и по выходной мощности трансивера (не более 100 мВт), например на NRF24. Про ESP такого сказать не могу (не знаю), но думаю, это все из одной оперы.
Совместимость аппаратуры, работающей в одном частотном окне обеспечивается тем, что каждый комплект аппаратуры работает (излучает) не на одной фиксированной частоте, а "прыгает" по всему частотному диапазону, размазывая спектр излучения (системы "спред спектрум" в разных вариантах). К сожалению, мне не известен доступный для повторения алгоритм такого управления радиоканалом, но насколько я знаю, протокол 802.11 как раз и использует эту технологию.

Напомню, что современные модели могут летать на скоростях свыше 350 км/час, т.е. 1 метр модель пролетает примерно за 10 миллисекунд. Нужно объяснять, что может произойти с моделью, летящей с такой скоростью на высоте 3 метра, если вдруг возникнет задержка в канале управления допустим на 50 мс?

 

[Valentinych]

Все другие методы не впишутся в требуемые параметры для вашего проекта (точность синхронизации -+ 10 мс).
... Но у вас открытая площадка и проще вместо этого хлама поставить GPS на каждое устройство которому необходима синхронизация.

Меня вполне устроит точность синхронизации +/- 0,01 сек.
По правилам FAI замер времени гонки должен выполняться с точность не хуже 0,01 сек. Затем результаты округляются до 0,1 сек по правилам арифметики, после чего начисляется штрафное время: при одной допущенной ошибке округленное до десятых долей секунды время увеличивается на 10%, после чего результат округляется до целых секунд, которые численно приравниваются к очкам. Экипаж, набравший наименьшее число очков во всех турах, становится победителем.
Так что учитывая требования правил, можно было бы смириться с рассинхроном вплоть до 0,05-0,1 сек, но для тренировок все же хочется иметь возможность измерять время поточнее.

Можно немного подробнее про GPS? Насколько это реализуемо в моих условиях и при моих требованиях?

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