Не изчетох всичко че съм от тел но има лесен начин без много хардурер. Тайм сървъра казва след 100 ms ще бъде 12:00:000001 и след това подаваш синхро импулс. Без особенни грижи от там насетне по този импулс можеш да се свериш. Зависи от проца, но може импулса изцало хардуерно да накара някой кепчър да изчете таймер който го клочиш да речем с 100 ns. Ако е 16 битов имаш цяла вечност да влезеш да провериш текуща стойност и да се свериш преди да е извъртял още 16 бита.
Всичко това ще изисква един сериен канал и един цифров сигнал който може да е всякакъв, но ако имаш разстояния най-добре диференциален.
Може и само с импулс но тогава вече имаш допускания, например че се е сверявал всеки път, че не е много изостанал.... въпреки че и там има решения но започват да става безсмислено.

ТоНи, идеята която съм описал в предишните постове е подобна на твоята.

Zdrav,
с предложената от теб идея възможно ли е при използване на УАРТ на 115200 bps и да кажем 4 устройства директно свързани към PC-тo (през RS232) след преизчисления да се постигне грешка под 1uS между таимстампите на устройствата?

Според мен това е непосилна задача за програмистите под Windows или Linux. (Поне на тези около мен - точните времена са им голям проблем и в повечето случаи нямат решение.) Та в тази връзка - микросекунда и Windows или Linux нещо не ми се връзват. Ограничението е в ОС-а, а не в PC хардуера. (Може и да не съм прав разбира се...)

Може ли да обясниш по-подробно идеята си?

stefan63, мисля че само с един таймер с два инпут кепчара ще си свърша работа.

miro_atc, CRS-a по документ изглежда учудващо добър. Идеята ти е добра, но не съм сигурен дали ми се мисли в тази посока. Доста преработване на код ще трябва да правя за да порта това, което ми трябва.

ike, евентите са вътрешни състояния на радиа. Една част от тях ще са закачени към кепчър, а други (за съжаление) на прекъсване ... Опитвам се да реша проблема с наличен хардуер и поради тази причина идеята на миро с CRS-a не е подходяща за случая. Въпроса по-скоро ми беше принципен.

Емо, чини ми се, че пак си решил да онождош дявола в полет. Нема лошо, но казват, че се случвало веднъж на 100 години. Аз не разбрах изначално, що ти требе да цепиш микросекундата?

И аз не знам какво е това радио дето изкарва сигнал с фронт под микросекунда, че да се налагат такива мерения ама човека си знае.

Помисли и върху вариант като допълнителен хардуер, т.е. в случай че не измислиш чисто софтуерно решение може да сложиш едно STM-че като интерфейс и като източник на клок за твоята система.

Значи чисто теоретично за синхронизация ти трябват две неща. Първо трябва да знаеш разликата в часовниците и второ тяхното бягане/изоставяне.
Примерно като се ползва NTP с едно сверяване виждаш колко се разминават двата часовника към момента на сверяването. Но ако часовника дето сверяваш си избързва или изостава ти не знаеш с колко и скоро след сверяването си пак с грешка. Затова на практика се правят сверявания през някакъв интервал и се трупа статистика, първо за да подобриш самото сверяване и второ за да разбереш с колко точно избързваш/изоставаш.
Конкретно с цифри при сверяване с NTP точността ти зависи от round trip-a, който обикновено е под 100mS и с голяма доза вероятност (ако закъсненията в двете посоки са ти долу-горе еднакви) се приема че точността е под 10mS. С натрупване на статистика се подобрява, но не безкрайно. Виж за изоставянето статистиката колкото повече трупаш толкова по-точно става (стига да нямаш други фактори като температура и т.н.).

В крайна сметка при NTP твърдят че слизат под 1mS разминаване и много добро изравняване на скоростите, така че веднъж като свериш дълго време след това имаш точно време.
В твоя случай, за да постигнеш 1uS ти трябва много бърз път, но което е още по-лошо ако си стъпил на стандартни кварцове много бързо след сверяването твоят часовник ще е мръднал с повече от 1uS нанякъде. Ако тръгнеш да правиш статистиките и да смяташ избързването/изоставането ще стане сложно, а ако не го направиш пък все едно нищо не си направил. Хубавото на STM-a е че прави и двете. т.е. хем ти синхронизира часовниците като показания, хем ти коригира клока да не бяга.

PIF, при скорост 1Mbps, бит по радиото (зависи и от модулацията де) се предава за 1uS. Кое е чак толкова странното в случая? (за щастие в моя случай скоростта не е чак мегабит )

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

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


Стига да има кой да чете.

Колкото повече чета толкова по неясно ми става.
1 мегабит не се предава толкова лесно. Така или иначе трябва да направиш рикавър на клока в приемната страна и след това да приемаш. Зависи и от типа модулация. Ару-тата в приемната страна трябва да се стабилизират. Ако си QAM или QPSK или BPSK или някоя от другите цифвови модулации ще мине време докато ПЛЛ-а ти сработи. Та какво точно ще чакаш не ми е ясно. Да дойде единица в стрийм от нули. Или някой предавател да се събуди и приемника да хване предавателя и тогава да изкара нещо на изхода или ... сложно ми се види. Не логването с точност 1 микросекунда а концепцията като цяло. Някой иска да направи нещо ама не си е написал домашното и стреля в тъмното. Ха на бас, че тая микросекунда е мениджерска а не инженерна.

Идеята на Zdrav доколкото разбирам е стандартното NTP, има го описано...

Само че през USB може да е голям проблем. Нагледал съм се на всякакви хардуерни и софтуерни решения. Когато искаш да предаваш първо в зависимост на типа на ендпоинта и как се управлява фифото при някои пращането се стартира с потвърждение след като си натъпкал пакета, при други още в началото се гледа дали е четен/нечетен фрейма и се програмира пращането да почне на следващия фрейм. При всички случаи обаче след като устройството е решило да праща, хоста трябва да му полира ендпоинта и там са също едни буйни алгоритми дето зависят от това колко устройства има с колко ендпоинта отворени всеки, дали са ACK-нали или NAC-нали последния фрейм и т.н.
Въобще единичен пинг дето на теория може да стане за 1-2 фрейма, на практика отиват 6-7 до 10-на фрейма (ms).

По-добре да се стъпи на SOF пакета който хоста броудкаства до всички едновременно. Само трябва да се внимава всички устройства да са на един бъс, понеже при компютрите често различните портове са пръснати на няколко бъса. Така от страна на хоста няма нужда от специален софтуер, те пакетите си текат постоянно. От страна на устройствата трябва да се пусне SOF интеръпта и да се премести възможно най в началото на USB интеръпта. Това може да е проблем, особено ако устройството си позволява да забранява интеръпти или има по-високо приоритетни такива. Не знам конкретната ситуация, но целта е да няма голямо закъснение от възникването SOF интеръпта до неговата обработка.
Отделно трябва едно таймерче, което ще брои локалното време и по него ще се свалят таймстамповете. Пуска се таймерчерчето да върви и в SOF се следи за брояча на фреймовете, който е 11-битов. Някои устройства имат повече от 11 бита, но трябва да се гледат само младшите 11 щото само те идват от SOF пакета. И така когато 11-те бита превъртят си нулираш таймерчето.
Дотук тъй като всички устройства би трябвало да получават по едно и също време SOF би трябвало долу-горе в едно и също време да си нулират таймстамповете и да са "почти" синхронни. Евентуално заради закъснения на обработката на SOF интеръпта и заради разлика в клоците те няма да са съвсем синхронни. Затова може да се добави следното - преди да нулираш таймстампа го запомняш и после нулираш. Ако да кажем таймстампа ти е на 1MHz (1uS резолюция) то при превъртане стойността дето си запомнил трябва да е 2048000.
Но тя няма да е толкова а ще е с някаква грешка. Устройството може просто да праща стойността на компютъра и там да я обработваш грешките. Всъщност имаш две грешки - едната е различното закъснение при обработката на SOF. Това ще го хванеш по това че един път запомнената стойност е по-малка, друг път по-голяма, изместването спрямо средната стойност ти е грешката в офсета на таймстамповете. А пък ако средната стойност не е 2048000 то значи клока на таймстамповете ти не е "точно" 1MHz, т.е. освен офсет имаш и грешка на "усилване"... С малко статистика и двете грешки може да ги изчистиш в компютъра. И за цялото упражнение трябва просто веднъж на две секунди устройството да праща един таймстамп.
Сега ако нямаш 32-битов таймер (или не може да сглобиш) може да го направиш и с 16-битов. Само че тогава трябва да го нулираш не веднъж на 2 секунди, а максимум на около 60mS. Да кажем на всеки 32ms (превъртане на младшите 5 бита от фрейма). Ако приемеш че за 32mS няма как да имаш повече от +/-128 uS грешка то от контролния таймстамп вадиш 32000 и получаваш един байт за пращане към компютъра. За една секунда ще трябва да пратиш 30-на байта. Не е кой знае какво.

Не усетих кога се е обърнало на радио, но там повечето смислени идеи за мрежи си имат концепция за синхронизиране на времето. Не знам дали гонят 1мкс, или повече, или по-малко, но за деленето на ефира по време си трябва синхронизация винаги.
Разбира се че си трябва рековъри на клока, но то и по етернет е така, и по CAN имаш preamble. Прецизните GPS-и вадят фазата на L1 носещата за допълнителна точност отгоре на времето.
За CAN има една идея за Time-triggered network - само че тя работи само ако можеш да изключиш ретрансмита и да можеш да си сигурен кога е излязъл подадения пакет. Същото е за етернет - но понеже там няма толкова директен контрол се налага хардуера да предлага слагането на таймстампа точно в момента на пращане (когато е сигурен че е спечелил арбитрацията на канала).
Като цяло може да се погледне отдолу нагоре - кой RF чип дава таймстампи на приетите фреймове и да се види как да се ползва - както споменах по моите знания това е базата/важното.
Може и наобратно - кой от популярните безжични протоколи (TDMA?) дели най-прецизно по време и да се види какво предлага. Тука въпросът е по-скоро към спецовете в безжичните мрежи.
http://www.cs.wustl.edu/~jain/cse574-06/ftp/time_sync/index.html
http://www.ece.uah.edu/~jovanov/papers/C2005_Cox_synch.pdf
http://www.simonduquennoy.net/papers/elsts16microsecond.pdf
Само че пак - вирелес решението е малко специфично и дано пасва на приложението? Ако можеш да толерираш известни периоди на липса на комуникация щото сега точно щраква контактора на телфера ще стане. При индустриалните не върви - тя сихнронизацията ще преживее примерно 100мс без нови данни, но машината ще задълбае кофти ако няма задания за повече от 1 цикъл (1мс или по-малко).

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

Синхронен процес с асинхронна комуникация не става. Празни приказки тука можем да си приказваме с години.

какъв ти е бюджета?
1us е ни риба, ни рак.

аз също мисля, че най-лесно ще стане с 1588, но ще ти трябват няколко хилки.
с RMII PHY се достига лесно 100ns, за надолу техниката е друга. по принцип има PHY, които работят с тайм-стампи директно, но почти съм сигурен, че не могат да работят сами без МАС.
ако мислиш, че ти трябва помощ, пиши

Мисля че всички се подвеждате по заглавието на темата: "Синхронизация на устройства", а всъщност задачата по-скоро е синхронизация на данните събрани от тези устройства. Едва ли на emilvtc му трябва до няколко us или дори ms да получи данните със синхронизирани таймщампи.
Може и да бъркам, но нещо ми подсказва, че тези данни се събират и обработката им не е толкова спешна(вероятно търпи поне секунда максимално време за реакция), а не управляват процес, който иска <1us латентност/време за отговор.

Но все пак това ще каже автора на темата.