Введение.
Представим, что у нас есть несколько датчиков и актуаторов на беспроводных интерфейсах, ZigBee или "радиоудлинитель" UART пока не важно, и какая-то управлялка к ним. Несколько это менее 10, расстояния до 10 метров. Датчики умные, с мозгами.

По команде от управлялки актуатор начинает производить механическую развертку в какой-то сканирующей системе, а датчики начинают собирать данные, и отдавать их по некоторому протоколу. Временное разрешение при сборе данных устанавливается протоколом, но не выше, например, 50 мс. У датчиков есть достаточный буфер для данных, и вообще все всё успевают.

Задача.
Хочется, чтобы результаты с датчиков были привязаны друг к другу и к процессу движения механической развертки не хуже, чем с точностью до единиц мс. Ну, пусть 10 мс. Продолжительность измерения считаем достаточно малой, чтобы не требовать перепривязки по ходу.

Иными словами, надо засинхронизировать несколько событий с точностью 10 мс по беспроводному каналу.
Я вижу такие подходы:
1 заимплементить что-то вроде NTP на уровне протокола, перепривязываться перед началом измерений.
2 предусмотреть отдельный канал синхронизации, выдавать по нему временные метки. Например, в начале и в конце измерения.

Кто что скажет?

Также интересно, имеет ли смысл пытаться скомпенсировать дрейф частоты процессорного кварца введением поправок? Или обещанная ошибка в десятки ppm не будет стабильна во времени, а наоборот будет гулять от и до в допустимом температурном диапазоне?

Решал подобную задачу как раз с применением датчиков с беспроводным интерфейсом ZigBee. Удалось достичь точности ~1 ms. Дрейф частоты кварцев необходимо учитывать. У меня дрейф компенсировался в алгоритме синхронизации, без специальных ухищрений.

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

Сообщение отредактировал Le Fou - Apr 1 2013, 13:59

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

Да в общем и без исходников понятно, спасибо

Это вы для красного словца, или и правда начали с кварцев 50 ppm и перешли на 5 ppm?

позже точно укажу какие использовали кварцы, цифр не помню :-)

насчет порядка в точности кварцев я погорячился, сорри :-)
мы использовали следующие кварцы/генераторы: PRQC8.00CR5010X000, NX3225SA-16.000000MHZ-T1.
похоже в новой ревизии большую роль сыграло ПО :-)

попробуйте вот это или нечто подобное
http://www.soel.ru/rubrics/?id=472505

Спасибо за ссылку

Синхронизация датчиков между собой решается путем рассылки широковещательных сообщений - если используемый протокол это позволяет. Погрешности/задержки будут определяться задержкой в канале связи.
Изготавливаем системы похожие на описанную ТС - датчики с радиоинтерфейсом на CC1101, управляются программой с ПК, в ПК подключается самодельный адаптер радиоканал-USB. Практически погрешность синхронизации датчиков с ПК определяется неопределенностью времени от передачи данных в UART (вызов функции типа write) до физической передачи по USB. В самих датчиках время обработки принятого пакета (и соответственно погрешность синхронизации датчиков между собой) меньше 1 мс.

Сообщение отредактировал ecomp42 - Apr 6 2013, 12:41