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

[sasasa]

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

Нет не согласен, потому что именно из-за нестабильности передачи-приёма (даже без эфира и помех) невозможно измерение без синхронизации. Если у вас есть конкретное решение в целом, то готов выслушать.
Вы не ответили - Сколько (в мкс) по вашим замерам (хотя бы расчётам) флуктуация интервала передача-приём? Пусть даже без помех.

 

[pvvx]

Что то я совсем не понимаю. Получается, что если две ЕСПки запустить как AP-STA, одной из них сделать connect to AP, то они сами будут себя синхронизировать и мне только остаётся посылать сигнал сенсора и не надо ничего думать о синхронизации? И только по таймкодам пакетов вычислить разность? Что то не верится что так просто..

Именно так просто, но на ESP не считать TSF у Station и у него нет аппаратного таймера для него - используется простой таймер-будильник (отсчет до события) для вычисления следующего беакона, всё это повязано со sleep отключениями таймеров и CPU, как итог - никакой точности - китайцы....
AP передает свой счетчик каждый beacon всем Station и вся сеть работает синхронно. При чем любая, хоть BT, не говоря уже о ESP-now - арбитраж времени передач всё равно производится и задержка (и биения) зависит от него (это для гуру - nikolz , который постоянно путает два выделенных провода c WiFi и прочими радио-коммуникациями).

 

[KomX]

@nikolz, Вы не горячитесь... Скажите лучше, что покажет преложенный Вами метод в случае: 1-й сенсор срабатывает в момент времени t1 и через 15 мксек в момент времени t2=t1+15 срабатывает 2-й сенсор.

 

[pvvx]

Вы можете доказать наличие нестабильности передачи по WIFI и ее величину?

Можем. Она описана в стандарте

Иначе разговор не о чем.

Скорее всего - таков участник разговора. Не хочет прочесть стандарты или популярные изложения системы работы WiFi. Вместо этого он пишет отправку и прием пакетов в произвольное время, без соблюдения любых стандартов, а ПО на модуле ESP8266 это допускает.

Вы измерили время исполнения задач в ОС и свалили это на WIFI.

WiFi обслуживается по прерываниям и никто их не запрещал. Рекомендованные промежутки на бездействие системы для обслуживания дополнительных задач WiFi, описанные производителем ПО драйвера WiFi соблюдены. Но в закрытой части системы производителя ПО присутствуют баги с режимами sleep и плохо организована система окна приема управляющих пакетов. Из-за этого имеем пропуски и коллизии... атак-же неверную работу стека TCP-IP из-за увеличения промежутка времени таймеров обслуживания LwIP производителем закрытого ПО в десятки (ошибка - в сотни) раз ради цифры экономии питания, т.е. ради галочки до нерабочего состояния...

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

Сколько раз?
Нам не с чем сравнивать. Приводилось не менее десятка примеров с замерами, а вот от вас - нуль. Нехорошо выходит
Примеры задач тоже приведены - нечего ерзать и уводить, покрывая ваших любимых китайцев из Espressif. Ну не смогли они и не могут дать исходники от WiFi т.к. они тянуты у других.

 

[Сергей_Ф]

@pvvx а если обе ЕСП друг к другу перекрестно подсоединить? И пересылать свой TSF от softAP для синхронизации?

 

[KomX]

@pvvx
Вы совершенно правы, говоря, что нам не с чем сравнивать. Здесь обсуждается что угодно, только не синхронизирующий маркер для 2-х сенсоров. Моё предложение - это UDP пакет на широковещательный адрес, который будет обработан одновременно обоими сенсорами.

 

[sasasa]

Именно так просто, но на ESP не считать TSF у Station и у него нет аппаратного таймера для него

Может быть всё-таки проще в этом случае отказатся от ЕСпки и использовать что то другое? например RTL8710.
Как у RTL8710 с TSF синхронизацией? Тоже такая кривая как у ЕСПки?
--
Попробовал запустить ESP-NOW и ничего не получилось. Ардуино ИДЕ ругается во всю. Не могу понять как запустить. Там наверное какие то дополнительные библиотеки надо добавить?

 

[pvvx]

Может быть всё-таки проще в этом случае отказатся от ЕСпки и использовать что то другое? например RTL8710.
Как у RTL8710 с TSF синхронизацией? Тоже такая кривая как у ЕСПки?

Почти. Но получить доступ к TSF можно даже по заголовкам процедур. Такой уровень закрыт только у Espressif. Разница и все недовольства в том, что закрыв WiFi Espressif прилепило к нем 90% других библиотек, и вы не имеете возможности поменять даже простые настройки по умолчанию или загрузку системы, но обязаны включить весь их хлам в 1 мега-байт Flash и перепатчивать большинство процедур для привода системы в порядок. Так-же не дан код соответствующий сертификационным испытаниям. Такое безобразие наблюдается исключительно у Espressif
В RTL проблем с обратным реверсом нет - на ARM перевод асм в СИ производится автоматически - существует большой выбор ПО для этого действа с конфигураторами, шаблонами и т.д... а так-же и средств отладки, с помощью которых очень быстро вылечивается любая проблемма.
Из-за тактирования RTOS в 1 ms, если не примете доп. меры то это и будет джиттер приема-отправки сообщений. Режимы пониженного питания для WiFi и системы там другие - за промежуток между беаконами отключается всё, кроме некоторых аппаратных прерываний и набираются события, затем скопом отрабатываются в период (окно) приема beaсоn - там ресурсы позволяют такой метод. Да и вариантов пониженного потребления там несколько... Описал самый экономный - естественно в данном режиме первый пинг будет к времени следования beacon - до 100 c + ms.
Каждое устройство-драйвер в SDK к RTL871x имеет несколько состояний (sleep, активно, отключено, ..):

Спойлер: Пример лога "AT" опроса состояния драйверов

# ATSI
Dev UART0, state = ACT
Dev UART1, state = WACT
Dev UART2, state = WACT
Dev SPI0, state = WACT
Dev SPI1, state = WACT
Dev SPI2, state = WACT
Dev SPI0_MCS, state = UNDEF
Dev I2C0, state = WACT
Dev I2C1, state = WACT
Dev I2C2, state = WACT
Dev I2C3, state = WACT
Dev I2S0, state = WACT
Dev I2S1, state = WACT
Dev PCM0, state = WACT
Dev PCM1, state = WACT
Dev ADC0, state = WACT
Dev DAC0, state = WACT
Dev DAC1, state = WACT
Dev SDIOD, state = WACT
Dev SDIOH, state = WACT
Dev USBOTG, state = UNDEF
Dev MII, state = WACT
Dev WL_LED, state = UNDEF
Dev WL_ANT0, state = UNDEF
Dev WL_ANT1, state = UNDEF
Dev WL_BTCOEX, state = UNDEF
Dev WL_BTCMD, state = UNDEF
Dev NFC, state = UNDEF
Dev PWM0, state = WACT
Dev PWM1, state = WACT
Dev PWM2, state = WACT
Dev PWM3, state = WACT
Dev ETE0, state = WACT
Dev ETE1, state = WACT
Dev ETE2, state = WACT
Dev ETE3, state = WACT
Dev EGTIM, state = WACT
Dev SPI_FLASH, state = UNDEF
Dev SDR, state = UNDEF
Dev JTAG, state = UNDEF
Dev TRACE, state = UNDEF
Dev LOG_UART, state = ACT
Dev LOG_UART_IR, state = UNDEF
Dev SIC, state = UNDEF
Dev EEPROM, state = UNDEF
Dev DEBUG, state = UNDEF

Попробовал запустить ESP-NOW и ничего не получилось. Ардуино ИДЕ ругается во всю. Не могу понять как запустить. Там наверное какие то дополнительные библиотеки надо добавить?

Не знаю - не пробовал на ESP. И как-то неохота - данная система состряпана Espressif...

 

[sasasa]

Но получить доступ к TSF можно даже по заголовкам процедур.

Так и до конца не понял - стоит мучить ЕСПку или нет? Если нет TSF на STA, то не вижу смысла зацикливаться на ESP8266. На ЕСПке тогда мануально придётся синхронизировать а РТЛ на железе всё сделает. А то как бы можно , но трудно..
Ещё вопрос/уточнение поTSF - это уже синхронные таймеры всех девайсов в сети или индивидуальные таймеры по которым делают синхронизацию? Если 2-й вариант, то где искать регистр синхронного времени?

 

[pvvx]

Так и до конца не понял - стоит мучить ЕСПку или нет? Если нет TSF на STA, то не вижу смысла зацикливаться на ESP8266. На ЕСПке тогда мануально придётся синхронизировать а РТЛ на железе всё сделает. А то как бы можно , но трудно..
Ещё вопрос/уточнение поTSF - это уже синхронные таймеры всех девайсов в сети или индивидуальные таймеры по которым делают синхронизацию? Если 2-й вариант, то где искать регистр синхронного времени?

Ну откройте любое описание... пересказывать с переложением на кухонный язык сложно.
Кароче - AP передает каждые n ms пакет becaon. При его передаче в него вставляется счетчик TSF на этапе перед самой физической отсылкой в эфир. Вставляется с коррекцией на время передачи пакета (смотрите исходники хоть открытого WiFi или драйверов Realteк для линуха - других нет ).
Пакет летит и прилетает на Station. Время полета ограничено спецификацией WiFi - в пределе какие-то сотни метров и проницаемости среды, зависящей от гравитационного потенциала, "константы" для данного уголка вселенной.
По получении пакета на Station, TSF из него, опять с поправкой на оборудование, записывается в счетчик считающий с шагом в 1 us. Всё.
Т.е. каждые 102.4 ms происходит новая установка таймера на 1 us в 64 бита (600 лет). Этим и производится вся синхронизация. Итог джиттера = расхождения таймера за 100 ms.

Пример - таймер спешит, его расхождение от эталона AP будет типа этого графика:

 

[KomX]

Пошукал я это TSF в сети. Нашёл вот такой любопытный документ. Даже моего "глубокого" знания английского хватило на то, чтобы понять, что TSF - это не наш путь.
"Clocks move only forward" - будет принято передаваемое время или не будет принято зависит от того спешат или отстают часы приёмника.
Самый спешащий узел никогда не будет синхронизирован. Мало того, сам будет навязывать свою синхронизацию.

 

[pvvx]

Пошукал я это TSF в сети. Нашёл вот такой любопытный документ. Даже моего "глубокого" знания английского хватило на то, чтобы понять, что TSF - это не наш путь.
"Clocks move only forward" - будет принято передаваемое время или не будет принято зависит от того спешат или отстают часы приёмника.

Док http://web.cse.ohio-state.edu/~lai/788-Au03/2-scalibility.pdf не открывается. Ваше описание ошибочно. Если beacon не принят - считайте связи по WiFi с данной станцией вообще нет.
Через Сингапур (VPN) открывается http://web.cse.ohio-state.edu/~lai/788-Au03/2-scalibility.pdf
Там нет того, про что вы пишите. Даны графики замеров в большой и зашумленной сети - для описанных тут задач эти значения устраивают и модифицированный алгоритм не требуется.
Пропуск приема нескольких подряд beacon станцией = разрыву связи и новому соединению. Даже если она в режиме DTIM (спит с пропусками n beacon-ов)

 

[KomX]

Док http://web.cse.ohio-state.edu/~lai/788-Au03/2-scalibility.pdf не открывается. Ваше описание ошибочно. Если beacon не принят - считайте связи по WiFi с данной станцией вообще нет.
Через Сингапур (VPN) открывается http://web.cse.ohio-state.edu/~lai/788-Au03/2-scalibility.pdf
Там нет того, про что вы пишите. Даны графики замеров в большой и зашумленной сети - для описанных тут задач эти значения устраивают и модифицированный алгоритм не требуется.

Первые 6 страниц.

 

[pvvx]

Первые 6 страниц.

Читал досконально ещё вчера... Это реклама "усовершенствования" и не для простых систем c одной AP и десятком ST.
Для получения тех графиков надо поставить станцию на геликоптер и гонять им на пределе слышимости AP У нас тут стационар и 100 метров с направленной антенной.

 

[sasasa]

ше описание ошибочно

А что будет после 5минут если мой clock быстрее? ж...? Что то я опять не понимаю.

 

[pvvx]

Посмотреть вложение 2897

Про константу добавки на приемнике не забыли? Её и ставят в среднее отклонение...
Данный таймер нужен для начала открытия окна приема следующего beacon и если у вас время идет быстрее - то всё будет ок - приемник немного подождет Отправка Beacon-а с AP имеет право запаздывать, из-за нерадивых членов застолья...
Схема дана для репиттеров... Обычно усовершенствованный алго и гонят для всяких p2p. Там кавардак с тем, кто является AP. Кароче не наш случай.
Любую синхронную работу устройств можно убить динамитом.
Если правильно вписать стандартную схему с TSF в ESP8266, с отключениями всяких WiFi-sleep, то десяток us получите. Расстояние AP- ST даст только фиксированную константу отклонения.

 

[pvvx]

Трепаться можете -это видно.

Какая яркая самокритика? Взрослеете?
----------
В SDK 1.5.4 у меня, после сборки проекта на ESP8266 адрес расположения последнего принятого (!) ST-TSF получается такой:

//===============================================================================
// get_tsf_station()
//-------------------------------------------------------------------------------
extern os_timer_t sta_con_timer;
uint64 ICACHE_FLASH_ATTR get_tsf_station(void)
{
    uint64 * pq = &((uint64 *)&sta_con_timer)[-0x69];
    return *pq;
}

Далее копаете как он туда попадает, патчите - включаете туда фиксацию значения на момент приема 64-битного mac таймера.
Далее, когда требуется счетчик, то берете текущее значение 64-битного mac таймера и вычитаете записанное + значение принятого TSF.

 

[nikolz]

Какая яркая самокритика? Взрослеете?
----------
В SDK 1.5.2 у меня, после сборки проекта на ESP8266 адрес расположения последнего принятого (!) ST-TSF получается такой:

//===============================================================================
// get_tsf_station()
//-------------------------------------------------------------------------------
extern os_timer_t sta_con_timer;
uint64 ICACHE_FLASH_ATTR get_tsf_station(void)
{
    uint64 * pq = &((uint64 *)&sta_con_timer)[-0x69];
    return *pq;
}

Далее копаете как он туда попадает, патчите - включаете туда фиксацию значения на момент приема 64-битного mac таймера.
Далее, когда требуется счетчик, то берете текущее значение 64-битного mac таймера и вычитаете записанное + значение принятого TSF.

Покажите где в стандарте вы нашли нестабильность WIFI на расстоянии 100 метров.
А то ля-ля да ля-ля.

 

[pvvx]

опять ля-ля

Неа - тру-ля-ля.

Если правильно вписать ...

Угу - ваши нерадивые не смогли.

все если и если ...

На любой лом найдётся свой приём...

 

[pvvx]

Покажите где в стандарте вы нашли нестабильность WIFI на расстоянии 100 метров.
А то ля-ля да ля-ля.

Вам всё покажи да покажи = Купи слоника? Купите - покажу.