При асинхронна комуникация не можеш да синронизация на клокове с голяма прецизност след като имаш много несигурни елементи по пътя. Нито УСБ нито едърнет могат да ти синхронизират клокове под микросекунда. Имаш драйвер, шина, операционна система, прекъсвания, и още куп неизвестни. Ако по пътя на мрежата имаш и някой суич - забрави. За милисекунда е трудно да се говори а не за микросекунда. Ще имаш 1 микросекунда резолюция и 100 микросекунди джитър. Защо ти е тая резолюция тогава. Нито УСБ-то нито едърнета стават за синхронни процеси, където е необходимо еднакви клокове. Затова и във видеото и аудиото където има големи стриймове от даани не могат да се ползват. Позва се файъруайър. Нещо което е синхронно.
На Миро пледоарията за регистри и каунтъри звучи както урока за краставицата на Иванчо. Дето Суецкия канал бил продълговат и приличал на краставица и краставицата имала 98% вода.
Първо размигай светодиод през усб с 1 килохерц, закачи осцилоскопа и виж колко ти е джитъра и тогава казвай как ще постигнеш точност с 3 порядъка по-голяма.
За такива времена си трябва синхронна топология. Каква ще е няма значение. Не е нито УСБ нито едърнет.

С риск да те засегна, но май не четеш и водиш разговор със самия себе си.

В първия пост по темата пише:


Къде прочете някъде в темата, някой да е казал, че ще се управлява нещо макар и светодиод?

Когато събираш данни кой ти е вързал ръцете временно да буферираш няколко семпъла при устройствата. Нали всеки от тях вече има поставен таймстамп - знаеш момента когато е регистриран. После остава данните да се съберат от всички устройства и да се подравнят по една обща времева база.
Каква ще е комуникацията която ги прехвърля, синхронна или асинхронна, не е от значение.

аз не рабирам добре заданието на Емо. от там май и идва изобилието на идеи, пречупени през вижданията на изказалите се.

по принцип рядко съм съгласен с Пифа, но в случая е прав - трябва някаква синхронна медия, за да се синхронизират по клок и фаза различни нодове.
каква ще е медията - няма значение, стига да е синхронна. теоретично може и с асинхронна, но трябва времето за разпространение (или по-скоро джитера му) да е поне с един порядък по-добър от таргета. но такова работещо животно не съм виждал, така че съм скептичен малко.

понеже Емо говори за тайстампване на 8 събития на нещо, което е на под метър разстояние, може би един процесор с 8 таймера, които имат възможност за копиране на free running брояч в отделен регистър при кепване е подходящо решение. пускаш всички броячи едновременно и с един клок и получаваш сихронизация. само дето не се сещам за такъв чип. може би софт процесор, сглобен с 8 подходящи таймера в FPGA? или направо чисто FPGA решение.

Ако се усвоява бюджет - вероятно да. Отивате на FPGA, софт кор, 1588 и прочие
Ако трябва да се реши задачата - всъщност от доста време има MCU-та с по няколко кептчъра към един таймер. LPC15xx например има 8x32 bit кептчър-а към един SCTimer, а в едно MCU има два такива таймера и две по-малки, пак 32 bit, техни братчета.

Но Емо явно разполага с устройства, които има под ръка и иска да използва техните таймери. Остава му само да синхронизира получените резултати. Таймерите нека си ходят както искат един спрямо друг. Ако се направи статистика на разминаването им и се съберат данните с таймщампите може като последваща обработка да се "синхронизират" пост фактум самите данни.
Щом тези данни не влизат в някакъв контрол лууп примерно или някакво управление, никой не поставя условие за получаване на готовите синхронизирани данни след тази "синхронизация" с гарантирана латентност под 1 us на самата операция по събирането и "синхронизацията". Важното е събраните данни спрямо общата времева база да не са с повече от 1 us грешка.

Но ако човек иска може и да си поиграе със синхронните медии стига да има кой да му плаща за това забавление.

Здрав,
няма какво да ме засегнеш. Проблема не е в комуникацията а в сверяването на часовниците. Никой не може да ти гарантира колко време ще отнеме на реда код който си написа на ПЦ-то да излезе през УСБ драйвера и да стигне до устройствата. Или през мрежата. Всеки път това време ще е различно и порядъка на разликите е в стотин микросекунди. Дори да нямаш синхронизация от мастъра - то тогава всеки от процесорите ще си тича със свое собственно време. Може да имаш друг клок който да ти генерира ивенти на определено време и ПЦ-то да преизчислява таймстамповете по 8 независими и разсинхронизирани часовника. Но пак ти трябва еталонно време което не може да мине нито през УСБ нито през едърнет. И колкото и да е странно може да мине по RS. Но за целта трябва да има мастър клок. Който не може да е в ПЦ-то. ПЦ-то не е направено за измервателно устройство. То е направено секретарката да си пише на уърд или Пешо да си чертае платки. Може и Миро да си компилира кода. Както с трактор не можеш да отидеш на формула 1 така и с болид не можеш да изореш нива. Всяко нещо си има предназначение. Персоналния компютър не е от нещата служещи за точно измерване на време.

Мислех си че просто не четеш.
Сега вече си мисля, че не вдяваш за какво се пише в темата.

На Емо едва ли му е нужно да има еталонно време. Трябва му просто тези 8 или колко са там, потока от данни, относително един спрямо друг да са синхронизирани. Не вярвам получените данни да ги праща в Гринуич.
За времева база ще ползва клок на MCU, което си комуникира с всички устройства и събира данните от тях преди да ги прати към PC.

Абе и чисто ломуникационно е възможно, но ако има външен строб е най-лесно, това е синхронната медия, а протокола е само инфото. Не виждам проблем, ако изключим думата РС, аз бих сложил един концентратор за всички гадини който да ги сверява по този четод, пък той може да е относително сверен към РС то. Доколкото разбирам важмо е и 8те да кепчват синхронно, а не толкова колко е реалното време.

Дедо, кво прави почивните дни? Нещо да не те е напекло слънцето

Знам че ти бориш повечко памети и си свикнал със source synchronious, но при мрежите това понятие е оксиморон. Няма такива, или по-точно малкото такива дето са направили грешката (jtag примерно) на практика се ползват като асинхронни (надявам се знаеш защо).

Тони,
точно така е. Трябва ти един строб по който да ти се сверяват часовниците. Но за да намалиш джитъра ползваш ПЛЛ. А какъв е после транспорта няма никакво значение. Просто за синхронизация не можеш да ползваш нестабилни транспорти като едърнет и усб.

Здрав,
аз не чета а ти не мислиш. Аз съм 100% сигурен, че тази 1 микросекунда изобщо не му трябва. Тук обаче обсъждаме хипотетичен проект в който тази 1 микросекунда му трябва.
Ще се опитам да ти го обясня с думи пък и тогава ако не го схванеш - ще ти го нарисувам с картинки. Да приемем, че ти сверяваш часовника на всеки 2 милисекунди. Ако за тези 2 милисекунди единия процесор избързва с 2 микросекунди а другия изостава с 2 микросекунди. Какво ще се случи с данните ако имаш 2 събития - едното 5 микросекунди преди сверяване и едното 5 микросекунди след сверяване. Сега си изчисли 2-те стойности ако в единия случай едното се е случило на избързващия а другото на изоставащия часовник а после обратното.
Сега разгледай същия този период но ако събитията са с 500 милисекунди разлика.
А сега разгледай случая в който ти сверяваш на 1 милисекунда но точноста ти на сверяване е 20 микросекунди.
В колко от описаните случаи ще имаш точно измерване на 2-те времена едно спрямо друго с точност 1 микросекунда?
За да не си блъскаш главата ще ти помогна - само в рамките на тази 1 милисекунда в която имаш сверяване и то в първата 1/4 от времето когато дрифта на часовниците не е минал 1 микросекунда - желаната разделителна способност.
Ако искаш да измериш примерно 3 секунди с точност до 1 микросекунда - пак нямаш шанс. В единия случай имаш буфер с определена дължина в която можеш да мериш - като на осцилоскопа екрана в другия случай имаш логер който записва постоянно и ти имаш всичките данни за цялото време. Не само онзи отрязък от време в който си синхронизиран и мериш. Когато синхронизираш не мериш.

Точно така. Както още в началото писах - става въпрос само за логване. Нещо повече - не е необходимо устройствата да са синхронизирани с компютъра, са само помежду си.
Лога от всички тях се пише във файл и се обработва със закъснение.

Относно бюджета - то с пари всеки може
(е, не всеки може дори и с пари)

Както казах - не мога евентите да ги кепчвам с един проц с много кепчари към един таймер.
Евентите са вътрешни за устройствата (SoC MCU+трансивър) и дори не са изведени на вън на пинове, но вътрешно са на прекъсване или на кепчър. Отделно трябва лесно да се променя и броя на устройствата - 1..8 примерно в зависимост от случая.
Конкретиката в случая не е важна. Въпроса беше по-скоро принципен и мисля, че коректно съм го задал.

Та много такива устройства (1..8 примерно) на разстояние 10-20см едно от друго трябва да логват, като таимстампите (а не таймерите) им трябва да са синхронизирани в рамките на микросекунда.

Варианта до който стигнах с ваша помощ (както вече го описах) е всяко устройство през УСБ да е закачено към РС-то.
Отделно устройствата са свързани и помежду си с 1 кабел за синхронизация.

Едно от устройствата се набеждава за "синхро-мастер" и то започва да генерира сигнал (хардуерно с къмпеар примерно) на всяка секунда, клочено от собствения си кристален осцилатор (без PLL, за да няма фазов джитер).
Всички останали "четат" този синхронизиращ сигнал с инпут кепчерите си и кепчват собствените си таймери на всеки положителен фронт на синхроимпулсите примерно. По този начин те могат да си измерят собственият си клок спрямо този на мастер-а и да изчислят грешката за периода на две последователни кепчвания.

Когато се появи евент - устройството кепчва таймера си и коригира кепчнатото с процент от грешката си, който зависи от отстоянието на кепчването спрямо последния синхронизиращ импулс. Например ако синхронизацията е на 1сек (1000000uS), а евента е кепчнат на 500000us след това, ако грешката е +50us, то таймстампата ще е мин:сек:500000-50*(500000/1000000) = мин:сек:499975 uS
горе-долу до тук стигнах.

Целта е с минимално усилия и финанси да се реши задачката и мисля, че не е невъзможно. Всички устройства ще са еднакви (HW и SW) и ще могат да се навържат N такива устройства работещи едновременно.

И защо ти е кабелът? Толкова ли ти е голям проблем да прихванеш SOF-a ?

А за корекциите, не си измисляй като Pif чисълца. Освен ако не работиш с RC-та но дълбоко се съмнявам (най-малко USB-то ти няма да бачка). Та в най-лошия случай си с кварц под 100ppm демек няма как да имаш 1uS/S грешка. Демек или трябва да си вдигнеш резолюцията, или да си преосмислиш корекцията

Вместо кепчър понякога се ползва "ресет на таймера по фронт", или на по-нормалните процесори има "зареждане със стойност" (ресет но не със нула ами произволна фаза). Това работи добре ако гарантираш добър и безшумен сигнал. Което пак може да иска нещо диференциално вместо проста жица, но ти си знаеш.

Миро, защо числата ти се струват нереални? (може и аз да греша де)

Ако кварца е примерно 1MHz с начална грешка 20ppm (нека изключим температурната грешка за момента), то честотата му ще е 1MHz +/- 20ppm = 999980 до 1000020 Hz.

Това ще рече, че за секунда ще имам +/- 20 импулса. Т.е. 20 импулса грешка.
Ако клок-мастера се случи да е с +20ppm, а другото устройство да е -20ppm, то за една секунда грешката между двете ще е 40 импулса.

Гичо, с ресет на таймера няма да стане. Така ще загубя грешката, която ми трябва за да направя корекцията на таймстампата.

ако е...

ако сложиш 1MHz с 200ppm ще е 10 пъти по-голяма даже

Но с толкова калпави клоци няма да ти бачка usb-то, не знам за радиото... затова ти казах дай реални стойности вместо да си ги изсмукваме от пръстите

При USB нормално се гони 50ppm @48МHz, демек грешка под 1uS/S. Айде тва май беше само за otg, за чист девайс не помня но ако целта ти не е изрично да тестваш с кофти клоци не виждам защо ще си го причиняваш. От друга страна ако имаш до 1uS грешка няма как да коригираш щото ти от дискретизацията имаш вече грешка от същия порядък.

Радиата ще са с 20ppm кварцове (такива използваме и в момента за тях). Трансивъра си "донастройва" честотата на синтезатора, така че няма проблем с тези ppm-и.

Това са реални числа.