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

[pvvx]

значит слабо.
Стандарты надо сначала изучить а потом уж на них ссылаться.

Абсолютно верно. Начните, а то надоело вам это напоминать.
Вы уже посчитали (?) - не успеваем попасть в "таймслот"? У вас другой гравитационный потенциал?

 

[pvvx]

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

"после 5минут" не бывает. Обновления TSF каждый beacon - по умолчанию это каждые 102.4 мс (0.1 сек).

 

[pvvx]

Предлагаю сделать такой эксперимент.
Помещаете две ESP на место первого и второго сенсоров.
ESP1 соединяете с ESP2 проводом.
На ESP1 формируете последовательность импульсов для ESP2
На ESP2 по фронту импульса посылаете пакет по UDP для ESP1
На ESP1 измеряете время запаздывание пакета относительно фронта импульса.
В результате получится задержка и нестабильность передачи пакетов по WI-FI.

В каком режиме должен быть включен модуль (подробнее можно)? По умолчанию у двух ESP8266 - пинг до 100 ms.
Время запаздывания вывода фронта у GPIO: 26 MHz частота тактирования шины и аппаратного драйвера GPIO, и 2 таких такта при обращении через разные регистры - SET/CLR. Уже не малая задержка.
Фронт определять через прерывание изменения GPIO?
Садитесь - Два. Читайте доки на ESP - уже еле вписываемся

 

[sasasa]

Если правильно вписать стандартную схему с TSF в ESP8266,..

Короче опять ничего не понял. Не совсем успеваю следить за вашими мыслями. Недавно писали что для AP TSF всё уже встроено на железном уровне и остаётся только подсчитать срабатывание сенсора относительно TSF. Но тут я читаю, что всё же надо писать код для ЕСпки чтобы всё заработало. Наверное я не всё понимаю, потому и не понятно - выкинуть ЕСПку и взять RTL или же нет.
--
ESP-NOW быстрее чем UDP? На сколько?

 

[pvvx]

Короче опять ничего не понял. Не совсем успеваю следить за вашими мыслями. Недавно писали что для AP TSF всё уже встроено на железном уровне и остаётся только подсчитать срабатывание сенсора относительно TSF. Но тут я читаю, что всё же надо писать код для ЕСпки чтобы всё заработало. Наверное я не всё понимаю, потому и не понятно - выкинуть ЕСПку и взять RTL или же нет.

SoftAP на ESP имеет счетчик TSF и передает его.
Station на ESP принимает TSF от любой AP, но не имеет своего счетчика и полной поддержки - надо патчить.
Любая полноценная AP имеет более менее стабильный TSF.
Приемники, выполняющие роль station из дешевых = как повезет.
Для RTL871x тоже нужны коррекции SDK, чтобы успешно работал station TSF и есть дополнительные сложности для незнакомых с RTOS.
----
Стоял вопрос – возможно ли сделать синхронизацию в указанные в первом посту пределы...
Ответ есть – возможно, и даны варианты. Делать готовое решение с доставкой до вас никто не будет.

Или ждите реализации кем-то по местному описанию для Arduino или уж как нибудь сами…

Nikolz вам готовый пример не даст – у него это не принято (не было за всё время тут).

 

[sasasa]

Ответ есть – возможно, и даны варианты..

Попробую разобраться. Спасибо за дискуссию!
Вопросы по ходу наверное ещё будут.

 

[pvvx]

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

Уже много раз отвечено - читайте описание работы WiFi. Постоянства не будет. Тут уже не зубоскалить надо...

 

[pvvx]

Тогда может просветите, что у Вас будет не постоянно, если не учитывать СВЧ печь и ураган на Гаити?

Передача при наличии даже пары устройств в сети не происходит по вашим писаниям. Они не могут выходить на передачу когда захочет Nikolz. У модулей такого уровня банально не хватает нескольких антенн для дуплексной работы и разнесения каналов по диапазону. И это только верх проблем...
Это понимает даже ребенок 5-ти летнего возраста

 

[pvvx]

Т е Вы конкретно не знаете, поэтому пишите то, что и 5-ти летнему ребенку в Вашем садике известно.
Я не знал, что Вы в садике,
спасибо за банальные рассуждения.

Пожалуйста.

 

[sasasa]

В каких единицах считает TSF и с какого времени?? Как перевести время TSF на понятное время ЧЧ:ММ:СС. По GPS ничего не получается
У меня путаница что есть что:
get_tsf_station() - принятое от AP время
get_mac_time() - это как бы время моего AP, но почему оно на столько отличется от TSF?
И что такое system_relative_time()?
--
И что там перескочило где жёлтым помечено? Как то вдруг число больше на много стало.
Печатаю вот таким способом. Может быть где-то ошибся?

 

[Сергей_Ф]

@sasasa если 7857 спереди отбросить - то ничего не перескочило. Похоже что то лишнее вклинилось.
Хотя непонятно, что за 7857 такое?

 

[sasasa]

Печатаю вот таким способом. Может быть где-то ошибся?

Нашёл ошибку - нолики теряются
Написал Print по другому.
Может быть и проще можно выводить на экран uint64?
Немного удивляет, что оочень часто последние цифры 84

Спойлер: Print

void Print(uint64_t value)
{
    const int NUM_DIGITS    = log10(value) + 1;
    char sz[NUM_DIGITS + 1];
    sz[NUM_DIGITS] =  0;
    for ( size_t i = NUM_DIGITS; i--; value /= 10)
    {
        sz[i] = '0' + (value % 10);
    }
    Serial.print(sz);
}

 

[pvvx]

sasasa - вот кусок кода в SDK, который копирует принятый TSF от AP:

Примерный исходник тут: freebsd/ieee80211_sta.c at master · freebsd/freebsd · GitHub
Там вставляете патч... как описывал ранее...
Готовый код отдам только при пожертвовании Nikolz на данный сайт

Немного удивляет, что оочень часто последние цифры 84

А может ваша AP всегда передает beacon при данном счете в её TSF? Вы же читаете просто последнее принятое значение от неё.

 

[sasasa]

И вот что получается, если отключить AP(рутер) во время работы STA

 

[pvvx]

И вот что получается, если отключить AP(рутер) во время работы STA

Ну это не из-за чтения счетчиков...

В каких единицах считает TSF и с какого времени??

TSF считается в us. 0.000001 секундах. как и остальные приведенные счетчики. В текущее московское время оно не переводится. Начальный счет для своей подсети выбирает AP (роутер).
На ESP у AP счетчик TSF стартует при инициализации с нуля. Показывает время работы модуля.

 

[sasasa]

Зависает именно при обращении к get_tsf_station();
Но почему на столько отличается значение TSF и MAC? Как они связаны и что вообще за цыфра в TSF? В каких единицах она и с какой даты? не по каким меркам я не смог её перевести на понятное время.

 

[pvvx]

Зависает именно при обращении к get_tsf_station();
Но почему на столько отличается значение TSF и MAC? Как они связаны и что вообще за цыфра в TSF? В каких единицах она и с какой даты? не по каким меркам я не смог её перевести на понятное время.

Вот такой счетчик TSF у роутера ASUS после старта: beacon.fixed.timestamp == 0x00000000000AF13A - это первый beacon после перезагрузки, смог плюнуть спустя 0.717114 секунды после инициализации WiFi.
До перезагрузки был beacon.fixed.timestamp == 0x00000161038D314B - это 17 с половиной дней работы...
TSF у вас, если правильно сделано, считывается с AP роутера. А mac - c AP модуля

get_tsf_station() - считывает счетчик переданный AP роутером, к которому соединен ESP модуль.
get_mac_time() - считывает аппаратный счетчик ESP модуля - он же будет передаваться подключенным к SoftAP ESP другим модулям в качестве станций.

 

[sasasa]

get_tsf_station() - считывает счетчик переданный AP роутером, к которому соединен ESP модуль.
get_mac_time() - считывает аппаратный счетчик ESP модуля - он же будет передаваться подключенным к SoftAP ESP другим модулям в качестве станций.

Ну я так и понял. Но где же время/счётчик, который синхронизируется с принятым TSF. MAC не меняется.
И разве время рутера не должно быть +- реально? Тут если перевести, скажем сейчас последнее что вижу с ESP STA TSF 5808129626, в минуты, то получается 5808129626/1000000=5808секунд /60=97минут. Как это может быт время принятое с рутера, который в глобальной сети?
...какая то каша получается.
Может быть это тот случай, когда время рутера впереди времени STA и из-за этого STA не синхронизируется? Но опять же вопрос - почему тогда принятое время тикает вперёд?

 

[pvvx]

Измерил Джиттер при выводе в UART.
Желтый - конец RF сигнала передачи Beacon с AP роутера (прием на антенну с детектором). Красный - вывод TX ESP8266 - относительно него синхронизация.

Длина передачи beacon плавает и она идет на пониженном битрэйте - таков стандарт передачи данных в WiFi.
Надо учесть и UART.
Похоже, что UART имеет минимальный джиттер при загрузке в него байта на отправку в 1/230400(baud)/8 = 0.000001 сек относительно CPU. Но может и больше...
Во всяком случае хвост передачи в основном дрожит +-1 us. На картинке - это выловленный максимум.
Вывод в UART стоит при записи TSF из принятого и распарсенного пакета beacon в закрытой либе SDK, включенного путем её патча - вызова пользовательской процедуры на фиксацию прихода нового TSF на station ESP от внешней AP.
Получается, что с фильтром будем иметь синхронизацию до +-1 us.

 

[pvvx]

Ну я так и понял. Но где же время/счётчик, который синхронизируется с принятым TSF. MAC не меняется.
И разве время рутера не должно быть +- реально? Тут если перевести, скажем сейчас последнее что вижу с ESP STA TSF 5808129626, в минуты, то получается 5808129626/1000000=5808секунд /60=97минут. Как это может быт время принятое с рутера, который в глобальной сети?
...какая то каша получается.

Пишите правильнее вывод 64-бит и уточните адрес принятого значения TSF в своей версии SDK.
Попросите Nicolz дать вам пример
Все входные и выходные точки даны, даже замерено время запаздывания после приема до момента записи счетчика (расстояние от антенны до модуля 1.5 метра). Дальше вписываете указанную процедуру - фиксацию времени по аппаратному mac_time приема нового значения TSF... Это и как получить правильный счетчик в любой момент тоже уже описано ранее...
Надеюсь, что +-1 us вам хватит. Если надо более - пишите дуплекс и фильтры.
Предоставление всего готового для Arduino IDE ESP оценивается от 1 т.р. переведенной на сайт Nicolz Он описывал, что великий бизнесмен - с него не убудет

Может быть это тот случай, когда время рутера впереди времени STA и из-за этого STA не синхронизируется? Но опять же вопрос - почему тогда принятое время тикает вперёд?

Забудьте о "тот случай" - сколько раз говорить -> никто не сравнивает, а просто берет новое значение, тем более это делаете вы, своим кодом. Там где сравнивают - это не ваш случай. Вам приведен код asm из либы ESP и исходник из FreeBSD, могу дать из Линухов - нет там ни у кого, сравнений. Эти сравнения приведены в рекламе дополнительного метода синхронизации...