Господа, Мы уже запаслись Попкорном и Колой следя за вышей перепалкой ! Еще =АК= пригласите и я сам ящик бухла выкачу )))) А по теме "РЕАЛЬНО" , без понтов можно ? Просто у меня схожая тема тоже нарисовалась.
Для Arduino, полное решение c получением микросекундного 64-х битного счетчика TSF от AP на любой station дано выше, в теме "Синхронизация часов". Далее запасаемся попкорном и ждем решения для Mesh сетей, где это сильно сложнее и является основной проблемой в таких протоколах.
Ищем поставщика попкорна и:
Гуру nikolz нам (и сему миру) покажет и расскажет как произвести синхронизацию в радио-сетях организованных по типу Mesh, без специально введенных маяков.
Имеющиеся решения синхронизации в продвинутых сетях по типу Mesh, куда и входит ESP-NOW (но у него нет вообще никакой синхронизации - ещё не дорос), пока используют такие решения:
Выделяют временные паузы для маяков, во время которых передача другим запрещена. Далее распределяют по приоритету, последовательность передач маяков между ведущими устройствами. Другие устройства при этом должны молчать на данном канале и ждать... Это составляет ненормированную паузу для передачи в сети.
В отличии от этого, система синхронизации с миллисекундной точностью изначально встроена в 802.11, путем фиксации времени выдачи маяка от AP - beacon содержащего 64-х битный микросекундный счетчик времени с поправкой, учитывающей время передачи пакета и прочие аппаратные особенности конкретной реализации AP. Смысл поправок - чтобы приемные устройства могли получить точность привязки к 1 us. Все участники сети при этом знают время следующего beacon и на промежуток его приема должны молчать в эфире...
Господин @svs2007m, извиняюсь за =AK=, т.к. он не сможет присоединиться, т.к. не умеет переводить сложные вещи на простой язык и не обладает заученной базой по протоколам WiFi.
Возможно, спустя время необходимое для заучивания всех лейбочек и статей по данному поводу он присоединиться и обвинит всех присутствующих в безграмотности в маркетинго-технических терминах, образовавшихся после создания основных протоколов WiFi. Я вот их не знаю, т.к. не готовлю пиар-статьи и мне совершенно пофиг как и что там названо, т.к. считаю, что важнее знать методу и алгоритмы решения, какой битик править и когда, а не их современные пиар-названия образовавшиеся апосля и на основе уже давно решенных вопросов и приготовленных устройств, и давно полученной начальной прибыли.
Леммингов то должен кто-то вести в пропасть? Иначе не получим минимальной стоимости...
Ищем поставщика попкорна и:
Гуру nikolz нам (и сему миру) покажет и расскажет как произвести синхронизацию в радио-сетях организованных по типу Mesh, без специально введенных маяков.
Имеющиеся решения синхронизации в продвинутых сетях по типу Mesh, куда и входит ESP-NOW (но у него нет вообще никакой синхронизации - ещё не дорос), пока используют такие решения:
Выделяют временные паузы для маяков, во время которых передача другим запрещена. Далее распределяют по приоритету, последовательность передач маяков между ведущими устройствами. Другие устройства при этом должны молчать на данном канале и ждать... Это составляет ненормированную паузу для передачи в сети.
В отличии от этого, система синхронизации с миллисекундной точностью изначально встроена в 802.11, путем фиксации времени выдачи маяка от AP - beacon содержащего 64-х битный микросекундный счетчик времени с поправкой, учитывающей время передачи пакета и прочие аппаратные особенности конкретной реализации AP. Смысл поправок - чтобы приемные устройства могли получить точность привязки к 1 us. Все участники сети при этом знают время следующего beacon и на промежуток его приема должны молчать в эфире...
Гуру pvvx сейчас развешает лапшу на уши всем желающим.
Расскажет как он на генераторах тактовой частоты в ESP с нестабильностью от 30ppm достигает погрешности измерения времени 1 мкс
-----------------------------
Он возможно просветит всех чем отличается синхронизация по времени от пересылки числа импульсов из счетчика маяка в счетчик ESP.
---------------------
Фишка в том, что измерить время с погрешностью 1 мкс невозможно на кварцах с погрешность 30ppm, но pvvx этого не знает и продолжает делать открытия в этой области.
Ждемс, выступления.
pvvx, прежде чем начнете опять хвалить ваши костыли ответьте на простой вопрос
с какой погрешностью можно измерить интервал времени в 1000 секунд с помощью кварцевого генератора номиналом 1 Мггц с нестабильностью 30-50 ppm в диапазоне температур от -10 до 40 и счетчика импульсов.
задача в данной теме не сводится лишь к решению вопроса одновременного пуска двух ESP
а требует решения более сложной задачи - точного измерения относительно длительного интервала (для примера 1000 сек)
---------------------
Чтобы решить проблему одновременности достаточно синхронизировать одну ESP от другой, либо две от третьей.
При этом стабильность времени зависит от стабильности времени роутера.
Когда роутером становится ESP, то проблема измерения времени еще больше усложняется и
решение задачи одновременности (синхронизации начала счета ) ничего не решает.
-----------------------
Наглядным примером являются системы для измерения времени в спортивных соревнованиях.
И если бы pvvx действительно решил проблему измерения времени с погрешностью 1 мкс в спортивных системах,
то получил бы нобелевскую премию.
Г-да, давайте сосредоточимся на обсуждении технических вопросов и методов их решения, а не на личностях участников форума. Не хотелось бы прекращать это увлекательное обсуждение.
Г-да, давайте сосредоточимся на обсуждении технических вопросов и методов их решения, а не на личностях участников форума. Не хотелось бы прекращать это увлекательное обсуждение.
продолжаю.
В чем суть моего эксперимента.
Так как у меня нет атомных часов, то я придумал следующий способ проверки достижимой точности измерения.
Берем две нестабильные системы и измеряем разность времени этих систем.
Так как нестабильность в них не коррелирована , то возникающие отклонения позволяют оценить максимально возможную ошибку измерения.
Эта оценка будет больше чем, если бы одна из систем была высокостабильной, так как ошибки систем временами будут складываться.
В результате я получил оценку максимальной ошибки без использования атомных часов.
Меня данный результат удовлетворил.
Посмотрел что продают по цене от 50 до 200 тыс руб. там погрешность от 10 мс до 1 мс, что вполне достигается с внешним чипом с термокомпенсацией. При этом нестабильность генератора с 30 ppm уменьшается до 3 ppm.
-----------
далее..
применение ESP для данной задачи не оптимально.
Задачу надо решать на BLE +генератор с термокомпенсацией+датчики для обнаружения старта стопа.
-------------------
Посмотрел что есть.
аналогом я бы взял систему для марафона - это браслет на ногу (80 евро). Т е в такой системе всего два чипа
Один на спортсмене, второй- у судьи. Синхронизация вообще не требуется.
еще бы добавил лазерную ленточку.
------------------
Г-да, давайте сосредоточимся на обсуждении технических вопросов и методов их решения, а не на личностях участников форума. Не хотелось бы прекращать это увлекательное обсуждение.
Для этого старт и финиш располагаем в зоне видимости одной AP, организованной на нормальном WiFi оборудовании (типа от Cisco ). Там наверняка стоит не стекло, а нормальный кварц и ПО не написано бездарно на Arduino школьниками. Если предполагается многочасовая эстафета или точность измерения к 6-ти (десятичным) знакам, тогда, возможно, роутер поместить в термостат, для организации стабильного хода его часов (кварца) с заранее вычисленной поправкой в стационаре…
На “старте”, в зоне данной AP, приемник(и) делает(ют) соединение с ней. Ждем события фиксирующего “старт” и по этому сигналу считываем значение счетчика TSF, запоминаем и неспешно передаем его на базу… Далее творим что угодно. На финише производим аналогичные действия – соединяемся с AP и по финишному сигналу фиксируем значение счетчика TSF, запоминаем и передаем его на базу… На базе (возможно и на самом приемнике) вычисляем разницу (“финишный TSF” минус “стартовый TFS”) и получаем время в пути в us c точностью до +-5 us, т.к. ПО (дрова WiFi и прочее) приемника на ESP8266 писали школьники и не смогли правильно распределить атомарные операции (операции с запретом прерываний) для получения минимальной задержки (джиттера) у маскируемых аппаратных прерываний, а NMI у ESP не вызывается по изменению на пинах и прочих аппаратных интерфейсов кроме таймера ( или “сикретно”).
На этом тема сверх-бюджетной WiFi синхронизации с вычислением на множественных устройствах времени событий с точностью +-5us можно закрывать, но требуется “поводырь леммингов”. Он должен раскрасить имеющееся решение, поставить свой (с) и произвести пиар среди первой группы леммингов. Если поток леммингов пойдет, то найдутся более пиар-активные поводыри… Далее, возможно, сработает рынок (китайцы) и наводнят али готовыми устройствами по 100 рупь..
Оставшиеся вопросы – механические и прочие датчики “старта” и “финиша”.
Точность интервала ограничена кварцем AP и расхождением стекляшки на ESP8266.
Данный график https://esp8266.ru/forum/attachments/snimok1135-gif.3013/ и показывает расхождение кварца AP и стекла ESP8266 на периоде 12500 beаcon (12500*0.1024 сек) с применением того-же патча и процедур, что впихнул в Arduino.
Ещё раз - График показывает не синхронизацию и не время с AP, а уход стекла ESP от кварца AP.
Синхронизация итогового 64-х битного счетчика времени, с использованием аппаратного таймера TSF на ESP8266 дает погрешность в +-5us и прочие отклонения из-за джиттера процедур с запретом прерываний и это уже программная часть. Имеющаяся аппаратная часть позволяет и более точную синхронизацию в случае стабилизации кварца ESP8266. Но большая точность никому не нужна, т.к. вы всё равно не сможете реализовать в Arduino синхронность (привязку) считывания TSF к внешнему событию.
Точность интервала ограничена кварцем AP и расхождением стекляшки на ESP8266.
Данный график https://esp8266.ru/forum/attachments/snimok1135-gif.3013/ и показывает расхождение кварца AP и стекла ESP8266 на периоде 12500 beаcon (12500*0.1024 сек) с применением того-же патча и процедур, что впихнул в Arduino.
Ещё раз - График показывает не синхронизацию и не время с AP, а уход стекла ESP от кварца AP.
Синхронизация итогового 64-х битного счетчика времени, с использованием аппаратного таймера TSF на ESP8266 дает погрешность в +-5us и прочие отклонения из-за джиттера процедур с запретом прерываний и это уже программная часть. Имеющаяся аппаратная часть позволяет и более точную синхронизацию в случае стабилизации кварца ESP8266. Но большая точность никому не нужна, т.к. вы всё равно не сможете реализовать в Arduino синхронность (привязку) считывания TSF к внешнему событию.
Ну наконец-то Вы признали что В вашей схеме не решается точность измерения времени, а практически лишь трансляция счетчика AP на станции и там изменение этого счетчика внутренним генератором за 100 мс.
Теперь давайте уберем все станции и попробуйте ответить на вопрос
с какой точностью Вы измерите на AP интервал в 1000 секунд.
Если как вы указываете 5 мкс, то это соответствует 5*10-6/1000 т е долговременной стабильности генератора AP на уровне 10-9.
Вопрос простой -сколько стоит генератор обеспечивающий такую стабильность Если не ошибаюсь, то это на уровне 0.005 ppm.
Я ничего не упустил?
Сколько стоит такой чудо генератор?
Ну наконец-то Вы признали что В вашей схеме не решается точность измерения времени, а практически лишь трансляция счетчика AP на станции и там изменение этого счетчика внутренним генератором за 100 мс.
Теперь давайте уберем все станции и попробуйте ответить на вопрос
с какой точностью Вы измерите на AP интервал в 1000 секунд.
C +-5us.
Или точность источника звука (орущего niкolz) в 1.5 см с помощью 3-х ESP8266 и роутера
И какое ещё признание и чего? Того, что и не говорил, но вы мне навязываете?
Если как вы указываете 5 мкс, то это соответствует 5*10-6/1000 т е долговременной стабильности генератора AP на уровне 10-9.
Вопрос простой -сколько стоит генератор обеспечивающий такую стабильность Если не ошибаюсь, то это на уровне 0.005 ppm.
Я ничего не упустил?
Сколько стоит такой чудо генератор?
Весь комплект до 1 т.р.
Вас сложно вылечить - надо начинать с нуля, что уже невозможно.
Точность синхронизации с помощью TSF ограничена на уровне +-1us в базе. Синхронизация канала происходит каждый beacon = по умолчанию 102.4 мс.
Уход дешевого стекла/кварца за 100 мс сосчитать сможете или надо платное обучение? Назовем это максимальный джиттер канала связи.
Это максимальный уход аппаратного счетчика в us в приемнике. Далее, каждый beacon, происходит следующая коррекция TSF (синхронизация с 1 us). Имея источник точного времени (пусть секундный импульс с GPS) и обычный, не халявно-разгильдяйский модуль (не Arduino и не ESP) WiFi и AP без особых проблем, по прерыванию от источника времени считывается TSF и к нему привязывается время источника. Затем это передается. Т.к. вся сеть имеет счетчик TSF с максимальным уходом в джиттер канала связи, то имеем максимальный уход времени от внешнего источника в джиттер канала связи.
Более подробно о том, как формируется timestamp в beacon описано тут Способ и система для точной тактовой синхронизации посредством взаимодействия между уровнями и подуровнями связи для систем связи
Для реализации требуется выданный вам патч, который осуществляет энто: "Способ дополнительно включает в себя предоставление принятого кадра синхронизации на более высокий уровень связи в приемнике, причем кадр синхронизации поступает на упомянутый более высокий уровень связи во время поступления, указывающее локальное время приемника, в которое кадр синхронизации поступил на упомянутый более высокий уровень. Способ дополнительно включает в себя временную синхронизацию приемника с передатчиком посредством определения разности между упомянутой временной отметкой и упомянутым временем приема и подстройки локального времени приемника упомянутой разностью, чтобы синхронизировать по времени приемник с передатчиком."
Т.е. обеспечивает базовое API для синхронизации по TSF.
@pvvx, я правильно понимаю, что вы предлагаете не замерять время с помощью esp, а просто запоминать по внешнему прерыванию (кнопке) текущее значение счетчик TSF и потом передавать его, хоть сразу, хоть по запросу? При чём любое число esp в одной сети всегда будут иметь одно значение счетчика TSF, независимо от ухода своего кварца\стекла с погрешностью не более +-5us. Данные со всех esp можно собирать как во время самого этапа соревнования, так и сразу после него без спешки, провести вычисления времени и передать на устройство отображения. Так?
1. При передаче beacon (c его timestamp) все остальные устройства молчат, что обеспечивает точную доставку без помех. Это является стандартом в 802.11.
2. Beacon передается на самой низкой частоте модуляции, что обеспечивает более уверенный его прием.
3. Beacon имеет фиксированную структуру пакета и длинющий начальный синхро, чтобы никто не пропустил и смог лучше синхронизоваться и подстроить частоту передатчика.
4. Timestamp в beacon корректируется каждый раз при передаче и при формировании пакета программно вносится необходимая поправка, чтобы приемное устройство получило точное время по приему этого пакета. Так-же коррекция стоит и в процедуре приема beacon. Она необходима из-за разности аппаратных особенностей – задержек в обработке драйвера приемника и вычисления времени окна для приема следующего beacon (когда незя включать передатчик).
Это псё уже сделано за вас в каждом 802.11 устройстве. У ESP8266 не хватает API, производящего фиксацию локального времени приема beacon и счетчика TSF из него.
Переданный вам патч обеспечивает эту недоделку.
По прерыванию приема beacon в ворованных дровах ESP8266 вызывает функцию cnx_update_bss_more(struct ieee80211_scanparams), вызов которой перехватывает патч.
Время этого вызова фиксируется со встроенным аппаратным 64-х битным счетчиком MAC_TIMER64BIT_COUNT идущем с шагом в 1 us. Получаем локальное время приема TSF: recv_tsf_time и запоминаем переданное значение TSF: recv_tsf. Это происходит каждый beacon, каждые 0.1024 сек.
Если вам надо узнать время на AP, то считываем 64-х битный аппаратный счетчик и вычитаем из него время приема. Разницу складываем с последним значением TSF от AP.
Для получения более точной и абсолютной синхронизации уже сами сможете написать софт с ФАПЧ или прикрутить какой аппаратный костыль...
@pvvx, я правильно понимаю, что вы предлагаете не замерять время с помощью esp, а просто запоминать по внешнему прерыванию (кнопке) текущее значение счетчик TSF и потом передавать его, хоть сразу, хоть по запросу? При чём любое число esp в одной сети всегда будут иметь одно значение счетчика TSF, независимо от ухода своего кварца\стекла с погрешностью не более +-5us. Данные со всех esp можно собирать как во время самого этапа соревнования, так и сразу после него без спешки, провести вычисления времени и передать на устройство отображения. Так?
Так, но счетчик timestamp (TSF) есть счетчик у AP, который обычно тактируется её кварцем. Но в случае если вы используете его для передачи внешнего timestamp, то максимальный уход будет ограничен данной синхронизацией - следованием beаcon и расхождением за данный период кварца приемника.
При этом PLL приемника частенько подстраивают по синхро-преамбуле beacon
Вот где-то в данном алго и зарыта собака в ESP8266, что его мозги сносит навеки (выход только путем сброса питания или пином ресет) и он орет как резанный, глуша все окружающие WiFi.
Да, ущё - более продвинутые (проф.) WiFi могут корректировать значение TSF с внешними источниками типа NTP, но более точными (GPS и т.д.).
Всё это необходимо для точности сетки частот и прочей синхронизации в сети. Очень актуально для роуминга в распределенных сетях....
Так, но счетчик timestamp (TSF) есть счетчик у AP, который обычно тактируется её кварцем. Но в случае если вы используете его для передачи внешнего timestamp, то максимальный уход будет ограничен данной синхронизацией - следованием beаcon и расхождением за данный период кварца приемника.
Олично. Я понимаю, что TSF - это счётчик AP. Таким образом вместо задачи по синхронизации кучи esp на произвольном отрезки времени, мы пришли к довольно простой задаче запоминания последнего счётчика TSF от единственной AP на произвольном числе esp + времени после него до события по внешнему сигналу. Задача приема TSF фактически решена предложенным вами патчем и осуществляется каждые 0.1024 сек. За время 0.1024 сек рассинхронизация внутренних часов разных esp не превысит +-5мкс.
Вопрос: в качестве эталонной AP может выступать, допустим смартфон в режиме точки доступа? Или не стоит надеяться на точность его кварца?
