Синхронизация часов.

sasasa · 23 Дек 2016

Нашёл такую картинку. Видно что мне нужные 5мкс не предел для WiFi WL8 синхронизации. Это обнадёживает

sasasa · 24 Дек 2016

KomX написал(а):
Так как код обработки UDP пакета у Вас будет одинаков, то и время периферийного устройства будет сохранятся в один и тот же момент (от возникающих аппаратных прерываний

Попробовал просто Ping с мобилки на ЕСПку. Результат разочаровал 8.21-26.1мс. Я думаю что UDP не будет быстрее, там кажется пакет ещё длиннее, и тем более оочень уж большой разброс по времени

Сергей_Ф · 24 Дек 2016

@sasasa Вы точно не путаете мс и мкс? У ping мс прыгают в диапазоне десятков мс!!! Как тут может быть точность в микро? Забудьте про wifi. Лучше nrf мучайте, если на 100 м добьют.

sasasa · 24 Дек 2016

Точно мс. Не знаю откуда микросекунды. Тут результат от двух разных программ. На разных ЕСПках такой же результат. Мерил с расстояния 3-х метров

pvvx · 24 Дек 2016

Сергей_Ф написал(а):
@sasasa Вы точно не путаете мс и мкс? У ping мс прыгают в диапазоне десятков мс!!! Как тут может быть точность в микро? Забудьте про wifi. Лучше nrf мучайте, если на 100 м добьют.

Пинг для ESP8266 не более 1ms, если это не Arduino. В Arduino циклический "опрос" в свободное время в цикле Loop() и прием у вас бьет с его исполнением. Приходящий пакет на WiFi обрабатывается по прерыванию и сразу обслуживается в LwIP, но у вас это не используется.
Во вторых никто не синхронизирует время без программного аналога ФАПЧ с обратной связью. Точность у таких устройств зависит от времени затраченного на процесс синхронизации - не один пакет туда-сюда, а много, с коррекциями и постоянно - температура не мешает.

Предел синхронизации = точности источника тактирования. Если это кварц, то значит где-то 10^6. Если постараетесь, то выловите и джиттер PLL и джиттер прерываний у ESP8266 связанный с разными частотами тактирования шин и CPU... Но это уже за пределами температурных отклонений кварца

У вас "стационар", а не динамика, как у GPS. Ей иногда сложнее...

sasasa · 24 Дек 2016

pvvx написал(а):
если это не Arduino

Это именно Ардуино и картинки выше наглядно показывает время ответа, но записано в loop() всего чтение UDP пакета и больше ничего. Пока до 1мс как до луны, Хотя и 1мс мне многовато. Хотя бы стабильные 0.2мс получить с разбросом не более 0.05мс.
Проверил несколько чипов. Но если лооп тормозит ответ пинга, то может быть UDP быстрее приходит?
Мне не нужно точное время а только синхронизацию/сброс 2-х таймеров на разных ЕСПках.

Сергей_Ф · 24 Дек 2016

@sasasa предположим Вы получили 5 мкс, дальше что? Как Вы на 100 м "стрелять" будете? Через роутер? Там Ваши 5 мкс превратятся в "тыкву".

sasasa · 24 Дек 2016

Сергей_Ф написал(а):
Как Вы на 100 м "стрелять" будете? Через роутер?

Сам не пробовал, но по отзывам в интернете что с наружной антенной ЕСПка 100м без проблем потянет

pvvx написал(а):
Приходящий пакет на WiFi обрабатывается по прерыванию и сразу обслуживается в LwIP, но у вас это не используется.

Что такое LwIP, и как его использовать?

pvvx написал(а):
не один пакет туда-сюда, а много, с коррекциями и постоянно

На данный момент планируется сигнал синхронизации с частотой 1Гц.
--
Можете что то посоветовать по этому поводу? Где, что, посмотреть, почитать.

pvvx · 24 Дек 2016

Код:

>ping atesp8266 -n 20

Обмен пакетами с atesp8266 [192.168.3.1] с 32 байтами данных:
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255
Ответ от 192.168.3.1: число байт=32 время<1мс TTL=255

Статистика Ping для 192.168.3.1:
    Пакетов: отправлено = 20, получено = 20, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

Не Arduino. Но так никто синхронизацию (только по приему) не делает...
Wireshark говорит 0.000515..0.000656 сек между передачей и приемом пакета ping (ICMP). Это через самый дешевый USB-свисток "Wi-Pi"

pvvx · 24 Дек 2016

Сергей_Ф написал(а):
@sasasa предположим Вы получили 5 мкс, дальше что? Как Вы на 100 м "стрелять" будете? Через роутер? Там Ваши 5 мкс превратятся в "тыкву".

Посылки данных обычно сопровождаются штампом таймера и неважно когда они придут... У вас видео по инет работает или плавают кадры?
-----------
@sasasa
Всё проходил совместно с появлением и литературы не читал. Посоветовать нечего.
Поиск по инет дает ерунду: http://wircom.ua/content/20/network_time_pro.pdf
Сетевые решения построения пакетной сети распределения сигналов единого точного времени ...

Вот это вам пойдет Протокол точного времени — Википедия

http://www.belden.com/pdfs/Techpprs/Precision_Clock_Synchronization_WP.pdf
Полу-Авто-перевод: Установка дрейфа осцилляторов ограничивает точность синхронизации в существующих прототипах. Кварцевый - частота 50 МГц (± 50 частей на миллион) дает разрешение 20 нс. Таким образом, система может установить только диапазон дрейфа ± 20 нс в секунду. Если вы теперь посмотрите на относительный дрейф между локальными часами и мастера в течение двух следующих друг за другом телеграмм синхронизации, вскоре становится ясно, что краткосрочная стабильность осцилляторов оказывает решающее влияние на точность синхронизации в переходном состоянии.

Т.е. всё примерно как и прописывал - ограничение в стабильности кварца на ESP

Счетчик тактов CPU в ESP8266 есть и работает на 160 MHz.

IEEE 1588 Precision Time Protocol (PTP) : Результат показан на графике. Смещение часов в пределах -50нс до 50нс.

sasasa · 25 Дек 2016

ОК. Сначала попробую почистить loop() и потом посмотреть какой пинг будет. Ясно что синхронизация не будет по одному сигналу, но пока у меня так сильно Ping плавает и нечего дальше думать. Спасибо!

pvvx · 25 Дек 2016

nikolz написал(а):
А почему бы не использовать SNTP и механизм синхронизации времени как в винде ?

А потому, что он для точности в +-1 сек (SNTP).
NTP точнее.
А если прочитаете начало темы и основной вопрос, то поймете что поддержка каких-то стандартных протоколов в данной задаче не требуется, а требуется реализация примерно аналогичного алгоритма от PTP, но упрощенного для достижения точности в миллисекунды, а не нано. 6-ть десятичных знаков, а не 9-ть

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

Лично для Гуру Nikolz: Как раз такое применение и показывает, что требуются исходники WiFi драйвера для реализации более точных синхронизаций, чего от китай-Espressif не дождетесь и аналогичные задачи будут реализовывать на чипах другой фирмы, благо они дешевле...

Сергей_Ф · 25 Дек 2016

@pvvx 5 мкс ТС хотел. Не милли, а микро. И Вы не объяснили ему, что на Arduino IDE он этого не получит, пока не перейдёт на чистый С.

pvvx · 25 Дек 2016

Сергей_Ф написал(а):
@pvvx 5 мкс ТС хотел. Не милли, а микро. И Вы не объяснили ему, что на Arduino IDE он этого не получит, пока не перейдёт на чистый С.

Arduino поддерживает и чистый СИ и C++. Проблема в используемых библиотеках писаных кое-как, для галочки "портировщиками"...
Вписываете #include ... и получаете доступ ко всему, чему только возможно в SDK.

Надо глянуть - может вообще драйвер WiFi вставляет сам таймштамп в us (он аппаратный в блоке PHY ESP8266) и тогда делать вообще почти нечего, кроме пары формул хоть на бэйсике. Если нет, то вписать вставку счетчика тактов CPU - он в 6.3 наносекунд.

pvvx · 25 Дек 2016

nikolz написал(а):
В качестве примера синхронизации времени компьютера с помощью SNTP привожу результаты синхронизации своего компа для исследования запаздывания данных с биржи:

По оси Х -время в секундах от момента включения компа,
по Y - ошибка в секундах локальных часов компа относительно атомных часов.
Наглядно видно что ошибка составляет примерно 40 мс и является систематической (это время пинга до сервер точного времени).
Если ее учесть , то погрешность в пределах 5 mc, которую можно снижать.
-------------------------------
Т е SNTP позволяет получить синхронизацию в предела ms для секунд минут часов дней и лет.

Нет. Для SNTP прямая зависимость от удаленности сервера и всей сети. Это +-20 секунд

Возьмите стандартный канал пользователя - NAT + WiFi + GSM + спутник + вокруг шарика + кривой сервер в ШША + ... Итого и в 60 сек нет гарантий. Норма 120 сек в ожидании заплутавшего пакета только в TCP на сегодня

pvvx · 25 Дек 2016

nikolz написал(а):
Я не теорию рассказываю, а результат работы привел.
---------------------------
Можете экспериментально доказать ? Нет!
---------------------------
Ну и не надо трындеть.

Без проблем - давайте ваш личный эксп

Найду вам сервер для SNTP за тридевятъ земель

И не надо путать SNTP и NTP. Дуплекс и просто прием метки от источника в локальной сети

У меня точнее уже просто пинг c ESP8266 и показан - расхождение +-50 us

По причине беакона в 100 ms ...
Интересно - какое отношение имеет SNTP к задаче в топике?

Вы получили точность синхронизации на Arduino в ESP8266 в заданные 5 мкс?

sasasa · 25 Дек 2016

pvvx написал(а):
Надо глянуть - может вообще драйвер WiFi вставляет сам таймштамп в us (он аппаратный в блоке PHY ESP8266) и тогда делать вообще почти нечего, кроме пары формул хоть на бэйсике. Если нет, то вписать вставку счетчика тактов CPU - он в 6.3 наносекунд.

И как это всё написать? Есть идеи?
--
!

Сейчас появилась идея сделать всё наоборот - не посылать синхроимпульсы с "базы" на сенсор, а с сенсорного блока на базу и там делать все вычисления. Т.е. делать синхронизацию базы по сенсора. В результате ЕСПке на сенсоре не надо ничего вычислять а только посылать импульсы, скажем 1Гц. Обратная связь не нужна. Импульс срабатывания сенсора посылается в промежутке между синхроимпульсом. Кажется идеальный вариант - никто никому не мешает, процессор не нагружен и вся работа только по 2-м прерываниям. Кажется я ничего не упустил.

nikolz написал(а):
На каком интервале Вам нужна синхронизация и с какой погрешностью?

Надо чтобы в течении всего дня любая пара импульсов полученных с обоих сенсоров была с погрешностью не более 5мкс.
Максимальный интервал между импульсами обоих сенсоров 2секунды.
Каждая следующая пара импульсов приходит не раньше чем через 10секунд после предыдущего.

pvvx · 25 Дек 2016

sasasa написал(а):
И как это всё написать? Есть идеи?

Как считать счетчик тактов CPU или 64-х битный mactime?

Код:

/* MAC_TIMER64BIT_COUNT: 0x3ff21048
* Step: 1us * wDev_MacTim1Arm() */
#define MAC_TIMER64BIT_COUNT_ADDR 0x3ff21048
uint64 ICACHE_FLASH_ATTR get_mac_time(void)
{
    union {
        volatile uint32 dw[2];
        uint64 dd;
    }ux;
    volatile uint32 * ptr = (volatile uint32 *)MAC_TIMER64BIT_COUNT_ADDR;
    ux.dw[0] = ptr[0];
    ux.dw[1] = ptr[1];
    if(ux.dw[1] != ptr[1]) {
        ux.dw[0] = ptr[0];
        ux.dw[1] = ptr[1];
    }
    return ux.dd;
}

Step: 1us phy_get_mactime(), system_get_time()
uint32 system_relative_time(void) {
return *((uint32*)0x3FF20C00);
}
#define system_get_time() (*((volatile unsigned int *)(0x3FF20C00)))
extern "C" unsigned xthal_get_ccount(void)
#define system_get_cpu_clk_count() xthal_get_ccount()

! Сейчас появилась идея сделать всё наоборот - не посылать синхроимпульсы с "базы" на сенсор, а с сенсорного блока на базу и там делать все вычисления. Т.е. делать синхронизацию базы по сенсора. В результате ЕСПке на сенсоре не надо ничего вычислять а только посылать импульсы, скажем 1Гц. Обратная связь не нужна. Импульс срабатывания сенсора посылается в промежутке между синхроимпульсом. Кажется идеальный вариант - никто никому не мешает, процессор не нагружен и вся работа только по 2-м прерываниям. Кажется я ничего не упустил.

Но надо знать отклонения (на сколько спешат или отстают часы устройств).
Без обратной связи быстро точность не получить...
Выходит как-бы кольцо в котором два генератора передают отклонения друг другу и в итоге синхронизируются на одну частоту с метками. Это задача отличается от синхронизации к внешнему источнику - всяким NTP или PTP. Она проще. В/к этом/у же кольце/у и привязаны данные с датчиков и съем из него для совмещения с другими происходит асинхронно с фильтрацией и аппроксимацией данных...

Да, обязательно отключите все sleep режимы у WiFi, иначе пинг будет несколько десятков ms.

sasasa · 25 Дек 2016

pvvx написал(а):
Но надо знать отклонения (на сколько спешат или отстают часы устройств).
Без обратной связи быстро точность не получить...

Я думаю что не надо. По полученным сигналам база сможет вычислить работу генераторов импульса сенсорных блоков. Сигналы с экстремальным отклонением будет удалены. Уже после несколько минут нестабильность задержки пакетов на столько снизится путём усреднения, что не повлияет на результат. А сигнал срабатывания самого сенсора будет вычисляться по отношении к генератору синхросигналов сенсорного блока. Я не вижу необходимости в обратной связи. Это при условии что время передачи/приёма пакетов не плавает в таких экстремальных пределах как сейчас у меня. Хотя бы в 200мкс уложится, не время отклика а разница задержек.

pvvx · 25 Дек 2016

Та я привык делать всё до нормального уровня, если это рабочий вариант, а не игрушка... Если вам хватит точности простыми путями - то пробуйте...

Синхронизация часов.

Member

Member

Moderator

Member

Активный участник сообщества

Member

Moderator

Member

Активный участник сообщества

Активный участник сообщества

Member

Активный участник сообщества

Moderator

Активный участник сообщества

Активный участник сообщества

Активный участник сообщества

Member

Активный участник сообщества

Member

Активный участник сообщества