Pdelay_Req報文格式定義
如下圖15所示為IEEE802.1AS定義的報文格式定義:
圖15 Pdelay_Req報文格式定義
上圖中header與SYNCMessage頭信息定義(IEEE802.1AS)中一致,該報文共占用54個字節(jié),除了header信息外沒有其他Payload信息。
Pdelay_Resp報文格式定義
圖16 Pdelay_Resp報文格式定義
上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致,該報文共占用54個字節(jié), 圖中兩個變量解釋如下:
requestReceiptTimestamp:該值是Pdelay_Req報文發(fā)送時刻的s與ns部分;
requestingPortIdentity:該值應(yīng)與Pdelay_Req報文中的sourcePortIdentity字段一致;
Pdelay_Resp_Follow_Up報文格式定義
圖17 Pdelay_Resp_Follow_up報文格式定義
上圖中header與SYNC Message頭信息定義(IEEE802.1AS)中一致,該報文共占用54個字節(jié), 圖中兩個變量解釋如下:
responseOriginTimestamp:發(fā)送Pdelay_Resp報文時刻的s部分與ns部分;
requestingPortIdentity:該值應(yīng)與Pdelay_Req報文中的sourcePortIdentity字段一致;
除了解上述Path延時測量相關(guān)報文格式以外,AUTOSAR定義的Path延時時間測量機制還需要注意如下幾個關(guān)鍵點:
EthTsync模塊通過Pdelay_Req,Pdelay_Resp,Pdelay_Resp_Follow_Up報文來進行延遲測量;
Pdelay_Res超時發(fā)出接收節(jié)點將會中止本次延時測量,接收節(jié)點默認(rèn)使用上次延時測量的結(jié)果;
主從時鐘節(jié)點均需要周期性發(fā)送Pdelay_Req報文來進行彼此的Path延時時間測量,發(fā)送報文周期可通過EthTSynGlobalTimeTxPdelayReqPeriod來控制;
Pdelay_Resp_Follow_Up報文的發(fā)送時間可以通過參數(shù)EthTSynGlobalTimeTxFollowUpOffset配置;
上述五類報文的目標(biāo)MAC地址均統(tǒng)一為01-80-C2-00-00-0E, 源MAC地址為各自報文發(fā)送的端口地址;
上述五類報文的EtherType統(tǒng)一為88-F7;
聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。
舉報投訴
相關(guān)推薦
的定位,是許多物聯(lián)網(wǎng)應(yīng)用的基礎(chǔ),這篇blog將向大家簡單的介紹如何使用python腳本在dragonboard 410c上解析GPS報文數(shù)據(jù)。 首先我們需要了解GPS報文格式,這里我們介紹
發(fā)表于 09-28 11:54
。假設(shè)報文格式如下圖所示,整個報文包包含4個字,每個bit組合均代表不同的涵義。下面我們根據(jù)該報文格式進行報文合成和報文解析。
發(fā)表于 08-26 20:33
TCP(Transmission ControProtocol)傳輸控制協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層協(xié)議。TCP報文是TCP層傳輸?shù)臄?shù)據(jù)單元,也稱為報文段。
發(fā)表于 12-08 11:11
?3.2w次閱讀
本文檔的主要內(nèi)容詳細(xì)介紹的是TCP IP相關(guān)知識的詳細(xì)資料說明免費下載。主要內(nèi)容包括了:TCP報文格式,TCP通信過程,ICMP協(xié)議。
發(fā)表于 12-05 11:19
?19次下載
本章將介紹目前常見的幾種動態(tài)路由協(xié)議(包括RIP、OSPF、IS-IS和BGP)的一些基礎(chǔ)知識,所采用的路由算法工作原理,主要路由消息及報文格式。其中最重要的是使用這些路由協(xié)議的基本網(wǎng)絡(luò)結(jié)構(gòu),路由表基本生成原理,以及不同路由消息報文
發(fā)表于 05-27 08:00
?15次下載
報文聚類是報文格式推斷的基礎(chǔ),現(xiàn)有的報文聚類方法大多以報文的全局相似性為聚類的標(biāo)準(zhǔn),這類聚類方法的準(zhǔn)確率往往不高,進而影響后續(xù)報文格式提取的
發(fā)表于 04-25 11:45
?3次下載
在上一篇文章,直接在本地搭建了服務(wù)器和客戶端,簡單的實踐了MQTT的用法。而這一篇來解析MQTT的報文格式。MQTT的報文字段很精簡。但是解析起來還是有些復(fù)雜的。 解析報文最好的工具是采用
發(fā)表于 05-13 14:06
?5073次閱讀
PLC以通訊方式控制變頻器正反轉(zhuǎn)為例進行說明;在通訊參數(shù)都設(shè)置好之后,需要先斷一下電,這樣設(shè)置的參數(shù)才會生效,下面就是PLC要發(fā)送報文給變頻器了。
發(fā)表于 02-03 09:09
?2498次閱讀
請求行以方法字段開始,后面分別是URL字段和HTTP協(xié)議版本字段,并以CRLF結(jié)尾。SP是分隔符。除了在最后的CRLF序列中CF和LF是必需的之外,其他都可以不要。有關(guān)通用信息頭,請求頭和實體頭方面的具體內(nèi)容可以參照相關(guān)文件。
發(fā)表于 05-06 15:56
?3646次閱讀
//CANopen是位于CAN總線之上的應(yīng)用層協(xié)議。CAN報文由7個不同的位域組成,CANopen主要是規(guī)定了其中的仲裁域和數(shù)據(jù)域的使用情況。01CANopen報文格式CANopen的報文格式為
發(fā)表于 08-10 09:21
?2908次閱讀
Version版本 4Bit :ip報文中,用來表示該協(xié)議采用的是那一個版本的ip,相同版本的ip才能進行通信。一般此處的值為4,表示ipv4。
發(fā)表于 12-13 09:43
?2025次閱讀
支持點對點和多點通信,可以實現(xiàn)控制器之間的通信。 Modbus報文是Modbus協(xié)議中的基本通信單位。Modbus報文包含一個頭部和數(shù)據(jù)部分。頭部包含了從站地址、功能碼和數(shù)據(jù)長度等信息,數(shù)據(jù)部分包含了請求或響應(yīng)數(shù)據(jù)。 ? 1. 地址碼(Address Code):指定通信
發(fā)表于 01-09 16:45
?5331次閱讀
在標(biāo)準(zhǔn)格式中,報文的起始位稱為幀起始(SOF),然后是由11位標(biāo)識符和遠(yuǎn)程發(fā)送請求位(RTR)組成的仲裁場。RTR位標(biāo)明是數(shù)據(jù)幀還是請求幀,在請求幀中沒有數(shù)據(jù)字節(jié)。
發(fā)表于 04-11 10:07
?6899次閱讀
怎么樣的。表1是一幀正常標(biāo)準(zhǔn)數(shù)據(jù)幀的報文組成。表1標(biāo)準(zhǔn)數(shù)據(jù)幀報文格式組成圖1標(biāo)準(zhǔn)數(shù)據(jù)幀格式CAN總線是一種基于廣播的通訊方式,為了保證總線上的每一個正常節(jié)點都能正
發(fā)表于 04-12 08:25
?1416次閱讀
支持點對點和多點通信,可以實現(xiàn)控制器之間的通信。 Modbus報文是Modbus協(xié)議中的基本通信單位。Modbus報文包含一個頭部和數(shù)據(jù)部分。頭部包含了從站地址、功能碼和數(shù)據(jù)長度等信息,數(shù)據(jù)部分包含了請求或響應(yīng)數(shù)據(jù)。 1. 地址碼(Address Code):指定通信對象
發(fā)表于 04-16 15:16
?2163次閱讀
評論