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

pvvx · 31 Дек 2016

sasasa написал(а):
Какие библиотеки должны быт включены(#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 · 31 Дек 2016

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

pvvx · 31 Дек 2016

Взял пример 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 · 31 Дек 2016

sasasa · 31 Дек 2016

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

pvvx · 31 Дек 2016

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

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

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

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

pvvx · 31 Дек 2016

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

sasasa · 2 Янв 2017

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 · 2 Янв 2017

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

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

sasasa · 2 Янв 2017

pvvx написал(а):
Сдвиг с чем?

MAC_AP - TSF_STA = 1320 +-50

pvvx · 2 Янв 2017

sasasa написал(а):
MAC_AP - TSF_STA = 1230 +-50

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

sasasa · 2 Янв 2017

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

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

sasasa · 2 Янв 2017

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

pvvx · 2 Янв 2017

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

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

sasasa · 2 Янв 2017

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

pvvx · 2 Янв 2017

sasasa написал(а):
Тут поменял местами модули - тот который быт 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 · 2 Янв 2017

Добрый день и с Новым Годом!!
--------------------------------------
Хочу рассказать, выражаясь образно,
как смотреть гланды можно гораздо проще,
если не решать эту задачу через зад.
---------------------------
немного теории.
----------------------------
Синхронизация часов двух 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 · 2 Янв 2017

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

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

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

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

pvvx · 2 Янв 2017

nikolz написал(а):
Добрый день и с Новым Годом!!

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 · 3 Янв 2017

pvvx написал(а):
C Новым Годом!

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

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

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

Member

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

Вложения

Member

Member

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

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

Member

Вложения

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

Member

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

Member

Member

Вложения

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

Member

Вложения

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

Well-known member

Member

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

Well-known member