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

[pvvx]

Какие библиотеки должны быт включены(#include...) в начале скетча?

--
Arduino 1.6.8 , Из Аrduino.cc
ESP8266 из Github http://arduino.esp8266.com/stable/package_esp8266com_index.json, скопирована в Arduino/ hardware,
сейчас добавлен SDK 1.5.4 в ESP8266com/ES{8266/tools/SDK
всё вроде работает ну только не то что из libnet80211.a, хотя я из неё ничего больше кроме get_tsf_station() не пробовал.

Т.е. у вас одновременно две версии Arduino под ESP8266? Одна в Arduino/hardware, вторая в C:\Users\_Имя_пользователя_\AppData\Local\Arduino15\packages?
И какая из них работает в реале вы не знаете?
Это "ничего" - у многих стоит 3 варианта (третий в C:\Users\_Имя_пользователя_\AppData\Roaming) и они тоже не знают что и как
Сча попробую что-нибудь пропатчить и испытать на варианте из GitHub - esp8266/Arduino: ESP8266 core for Arduino ...

 

[sasasa]

Нет, Я думаю что однав.
Arduino15/packages/ESP8266/hardware, я оставил только 2.3.0
В AppData/Roaming из Ардуина ничего нет.

 

[pvvx]

Взял пример WiFiСlient. Вставил в начало:

extern "C" uint64_t get_mac_time(void); // step 1 us
#define get_tsf_ap() get_mac_time()
extern "C" uint64_t get_tsf_station(void); // step 1 us

В последнюю строчку в void loop():

uint64_t tsf = get_tsf_station();
  Serial.print((uint32_t)tsf,DEC);  Serial.print("+"); Serial.println((uint32_t)(tsf>>32),DEC);

Сменил либу C:\Users\_Имя_\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.3.0\tools\sdk\lib\libnet80211.a
Сменил имя и пароль WiFi.
Странслировал:

Connecting to **********
...
WiFi connected
IP address:
192.168.1.225
connecting to data.sparkfun.com
Requesting URL: /input/....................?private_key=....................&value=1
HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,DELETE
Access-Control-Allow-Headers: X-Requested-With, Phant-Private-Key
Content-Type: text/plain
Date: Fri, 30 Dec 2016 22:57:43 GMT
Connection: close
Transfer-Encoding: chunked
Set-Cookie: SERVERID=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

13
0 stream not found

0


closing connection
1569688828+67 <---- работает
connecting to data.sparkfun.com
Requesting URL: /input/....................?private_key=....................&value=2
HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,DELETE
Access-Control-Allow-Headers: X-Requested-With, Phant-Private-Key
Content-Type: text/plain
Date: Fri, 30 Dec 2016 22:57:49 GMT
Connection: close
Transfer-Encoding: chunked
Set-Cookie: SERVERID=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

13
0 stream not found

0


closing connection
1575986785+67 <---- работает

Пропатченная либа для текущей версии на GitHub - esp8266/Arduino: ESP8266 core for Arduino

 

[sasasa]

 

[sasasa]

Работает! Ради интереса переслал UDP пакетики - посмотреть сколько времени они в пути. Получился интересный результат, который элементарно откорректировать - время прихода пакета (get_mac_time()) раньше чем время послания (get_tsf_station()) почти на 11000мкс -это несмотря на то что пересылка пакета ~3500мкс. Т.е по неизвестной причине часики STA спешат на почти 15000мкс. Синхронность пока не проверял - это на завтра.
Но там, я думаю, всё будет в порядки. Интересно сколько Ардуин внесёт свои поправки?
Потом буду учится "Си", чтобы написать в нормальном виде

 

[pvvx]

Ради интереса переслал UDP пакетики - посмотреть сколько времени они в пути. Получился интересный результат, который элементарно откорректировать - время прихода пакета (get_mac_time()) раньше чем время послания (get_tsf_station()) почти на 11000мкс -это несмотря на то что пересылка пакета ~3500мкс. Т.е по неизвестной причине часики STA спешат на почти 15000мкс.

Я AP на ESP не проверял - к ней мало доверия. Неизвестно как, когда и какое значение считанное со своего аппаратного счетчика она отправляет. Надо ковырять. Если совсем криво будет - запатчим

Синхронность пока не проверял - это на завтра.

На Arduino не стал бы рассчитывать... По тому и просил - пробуйте, если что, то тоже запатчим

 

[pvvx]

В Arduino ESP, в режиме station, значение принятого счетчика TSF скачет (более 200 us) при входе в WiFi-sleep: Modem. Этот режим там стоит по умолчанию. Первые секунды, до включения перехода station в WiFi-sleep, вроде всё нормально – расхождения несколько us. Отключайте WiFi-sleep в None.

 

[sasasa]

C Новым Годом!
У меня такая картинка. В среднем сдвиг по времени 1320мкс, который скачет в пределах 45мкс.
Измерялся нажимая кнопку, которая соединена с gpio2, дальше прерывание.

void GetTime(){ //for STA
  sta_tsf_time = get_tsf_station();
}

void GetMacTime() {// for AP
  ap_mac_time = get_mac_time();
}

wifi_set_sleep_type(NONE_SLEEP_T);
attachInterrupt(inPin, GetTime, FALLING);

 

[pvvx]

У меня такая картинка. В среднем сдвиг по времени 1320мкс, который скачет в пределах 45мкс.

Сдвиг с чем? mac_time - это просто счетчик с момента старта (инициализации WiFi) модуля. А tsf_station - это счетчик принятый с внешней AP. Они всегда разные...
Попробуйте ещё включить 160 MHz и выключить вывод log - system_set_os_print(0).
Должны быть меньше расхождения, т.е. биения
Исходник get_tsf_station() для понимания процесса.

 

[sasasa]

Сдвиг с чем?

MAC_AP - TSF_STA = 1320 +-50

 

[pvvx]

MAC_AP - TSF_STA = 1230 +-50

Это текущее значение TSF на AP и принятое от модуля в режиме station?
Т.е. это время передачи пакета + джиттер обоих модулей с прерываниями по I/O?
Джиттер прерываний по I/O менее 100+ us на ESP не будет. ПО wifi постоянно отрабатывая делает запреты прерываний на 100+ us.
Это испытание уже произведено тут: Синхронизация часов.
Как итог выходит, что get_tsf_station() дает значение точнее, чем может получить модуль по внешнему проводу.

 

[sasasa]

Это текущее значение TSF на AP и принятое от модуля в режиме station?
Т.е. это время передачи пакета + джиттер обоих модулей с прерываниями по I/O?

Да.
AP на 160Мгц, STA на 80 (на 160 зависала), system_set_os_print(0).
Такой же результат.
Сейчас не понимаю - Ардуино ИДЕ всё портит или сама ЕСПка

 

[sasasa]

И тут картинка рутер+2sta. 2 модуля с идентичным кодом. Как видно, то один из них постоянно тормозит по сравнению с другим.
Разброс около 100мкс, как и ожидал.. Сейчас получается так, что если я синхронизирую между собой сенсор_AP+сенсор _STA, то получаю на половину меньше ошибку, чем в варианте с база_AP + 2 сенсора_STA.
Есть какие то реальные пути уменьшения времени срабатывания прерывания по входу GPIO? Ставить рядом Ардуинку на прерывания?

 

[pvvx]

И тут картинка рутер+2sta. 2 модуля с идентичным кодом. Как видно, то один из них постоянно тормозит по сравнению с другим.

Может на это влияет очередность передачи данных по WiFi.
Программы и как что происходит нет и судить не о чем.

 

[sasasa]

Тут поменял местами модули - тот который быт AP (тормоз) наSTA, и STA на АP.
в графике разница времени MAC_AP и TSF_STA. По любому время на АP на спешит столько же как и было раньше. По любому время на АП на спешит столько же как и было раньше. Но скачки стали больше. Странно, что первые 2 замера на много меньше чем остальные.

 

[pvvx]

Тут поменял местами модули - тот который быт AP (тормоз) наSTA, и STA на АP.
в графике разница времени MAC_AP и TSF_STA. По любому время на АP на спешит столько же как и было раньше. По любому время на АП на спешит столько же как и было раньше. Но скачки стали больше. Странно, что первые 2 замера на много меньше чем остальные.

У меня от ASUS RT-N56U два модуля ESP показали одинаковые результаты, хотя модули разные: DevKit с ESP-12 и модуль ESP-01.
Счетчик может расходиться если кривые кварцы или в esp_init_data_default.bin указаны автоподстройки (байт 112 не равен нулю и т.д):

Вообще, если 112 не равен нулю, то у satation ESP сносит мозги до перезагрузок по protected или отваливания на веки от AP до перезагрузки со всеми версиями SDK.
Для полной победы надо переписать всю SDK - выкинуть все вставки Espressif из тянутого ими кода из открытых источников... Их программеры загубили более менее чип, а счас губят ESP-32S

 

[nikolz]

Добрый день и с Новым Годом!!
--------------------------------------
Хочу рассказать, выражаясь образно,
как смотреть гланды можно гораздо проще,
если не решать эту задачу через зад.
---------------------------
немного теории.
----------------------------
Синхронизация часов двух ESP сводится к привязке их счетчиков времени к некоторой общей базе.
Проще говоря, надо, чтобы показания счетчиков были скорректированы на некоторую константу так, чтобы их значения были одинаковые в момент коррекции.
Участник данной темы pvvx предложил для этой цели использовать значение TSF, которое существует в глубине недокументированного кода оборудования WIFI. (Назовем это - Вариант 1)
------
В результате , занявшись своим любимым делом -взломом чужого софта и патчем SDK недокументированными заплатками,
он породил некоторую временную поделку,
которая не будет работать на новых SDK.
---------------------------------
Но самое удивительное,
что синхронизацию часов с тем же результатом можно сделать в рамках документированных функций SDK,
ничего не взламывая.
--------------------------
Что бы понять как это делать,
давайте сначала разберем в чем суть TSF и с чем его едят.
--------------------------------
Объясняю без несущественных деталей.
-----------------------
В беспроводных сетях есть необходимость синхронизировать работу сети для решения проблем коллизий.
Это делается с помощью рассылаемых AP периодически всем с интервалом 100 мс специального пакета,
в котором AP передает значение своего счетчика времени. это значение и есть TSF.
--------------------
Все станции принимают эти пакеты и сохраняют у себя значение TSF,
чтобы относительно него отсчитывать единое время в сети,
корректируя начальное значение своего счетчика времени.
--------------------------------
Но в задаче данного топика необходимо синхронизировать две ESP.
Поэтому мы может сделать совершенно тоже самое, если с некоторым интервалом будет посылать с одной ESP на другую показание счетчика системного времени этой ESP.
Принимающая eSP запоминает это значение как базу. (Назовем это Вариант 2)
-----------------------------------
Давайте сравним Вариант 1 и 2.
------------------------------
1) существенная разница в том,
что во втором варианте не надо ничего взламывать и патчить,
все можно делать в рамках существующей документации и SDK.
---------------------
2) Во втором варианте мы может использовать любой протокол в том числе и ESP-now и любое железо, например NRF.
------------------
3) Во-втором варианте мы может использовать обе ESP в режимах станций.
---------------------------
4) Счетчик TSF имеет разрядность 64 бита, а системное время , получаемое документированной функцией system_get_time() 32 бита.
Но 32 бита достаточно для интервала 1 час, что вполне достаточно.
--------------------------------------
Таким образом, оба варианта идентичны для синхронизации часов ESP.
Причем второй вариант применим для любого SDK, любого протокола и любых аппаратных средств без взлома чужого софта.
-----------------------
Ошибка синхронизации, вызванная случайными помехами не устраняется этими методами.
--------------------
Для этого надо использовать алгоритмические методы синхронизации. Но взламывать SDK для этого не надо.
Но это уже другая тема.

 

[sasasa]

1)
второй вариант применим для любого SDK, любого протокола и любых аппаратных средств без взлома чужого софта.

Это конечно плюс.

2) Во втором варианте мы может использовать любой протокол в том числе и ESP-now

Про ESP-NOW незнаю, но по UDP задержка при пересылке пакета получилась с расхождением 1300-4200мкс.
--
nRF24 (808-828мкс) хороший вариант, но тогда и можно без ЕСПки обойтись. SI4432 дал ещё меньше расхождение по передаче пакета 1010-1013мкс, но эта уже другая тема.

 

[pvvx]

Добрый день и с Новым Годом!!

C Новым Годом!
Очнулись?
Уже соню раз сказано, что передача счетчика пользователем (упакованного в пакет) будет задержана на непроизвольное время в отсылающем контроллере - читайте стандарт WiFi!
Для совсем тупиков Nikolz ещё раз повторяю - WiFi не два провода между двумя устройствами, а на нем существует арбитраж. Иначе в сети будут сплошные коллизии. Это касается и ESP-Now На beacon это не распространяется, т.к. это и есть пакет распределения арбитража между устройствами и пропустивший его - теряет сеть. Передача NSF прописана в стандарте и работает на всех WiFi устройствах. Не получив его и его счетчик, модуль не знает когда ему выходить на передачу.
То, что вы писали в качестве теста на скорость передачи после старта модуля - есть обычная глушилка WiFi. Вам про это и тогда говорилось, но увы - читать вы не научились.
А так спасибо за ваше предложение получить синхронизацию с джиттером в 100 ms при следовании beacon-ов c установками по умолчанию Нас это не устраивает. У нас тут уже стадия уточнения к десятке us, учитывая кривое китай-ПО в ESP от Espressif. Мы пока пытаемся обойтись без математики с фильтрами и эмуляции ФАПЧ. Как было показано и измерено - джиттер у get_tsf_station() у нас +-1us, но из-за кривого-закрытого ПО от Espressif мы не можем использовать прерывания и опрос счетчика через уже реализованную функцию с точностью менее +-50us. Даже если соединить модули проводом - кривизна ПО Espressif не дает нам большей точности.
Так што Nikolz– вам остается открыть тему: “Методы Nikolz для синхронизации WiFi сети с предельной точностью до +-0.1 секунды” и распинаться там Возможно, такая тема кому-то будет интересна с точки зрения как забить прошивку лишним кодом и данными. Пока у нас всё укладывается в объемы до сотни байт кода вместе с данными. Надеюсь, что вы свой метод уложите в десять байт…

 

[nikolz]

C Новым Годом!

Все, что Вы написали - это известно и бездоказательно, так как нет никаких числовых данных.
-------------------------------
Проблема не в том,
что вы используете TSF,
а в том, что Вы ковыряете чужой софт,
делаете кухонные поделки, а потом ругаете тех,
кто дал Вам возможность заняться этими поделками.
(Не плюй в корытце, пригодится воды напиться)
------------------------
Относительно задержки в канале передачи.
Проблема решается использова6нием дифференциальной схемы синхронизации.
Т е использование базового ESP совместно с двумя сенсорными.
в результате задержка в канале передачи не влияет на синхронизацию.
====================
Самое забавное, что Вы не знаете потенциальной точности реализуемой модели.
т е опять по старинке - "метод ползучего эмпиризма.
Хотя в стандарте указана потенциальная погрешность метода 25 мкс.
---------------------------
Относительно метода (Вашего и моего)
Это один и тот же метод.
Метод базовой станции.
У нас с Вами различные алгоритмы реализации этого метода.
Но Вы все равно не можете отличить метод от алгоритма. Бывает...