概述:文章第一部分先公布結(jié)論,第二部分是1M PHY吞吐率的實測過程與理論分析,第三部分是2M PHY的實測數(shù)據(jù),第四部分是實操部分,喜歡BLE的朋友可以按照此部分的說明自己動手進(jìn)行測試。
一、結(jié)論
使用INGCHIPS SDK中測試吞吐率的例程peripheral_throughput和central_throughput,使用兩個開發(fā)板進(jìn)行測試。
1M phy吞吐率≥93KBps;
2M phy吞吐率≥152KBps。
二、1MPHY
01 實測
為了最小化包頭、包尾、校驗等無法避免的數(shù)據(jù)開銷,每一包數(shù)據(jù)MTU設(shè)置為247。 除去3bytes的ATT Header,則實際的ATT payload為244。 在central端連接參數(shù)使用默認(rèn)值的情況下:
static initiating_phy_config_t phy_configs[] = { { .phy = PHY_1M, .conn_param = { .scan_int = 200, .scan_win = 180, .interval_min = 50, .interval_max = 50, .latency = 0, .supervision_timeout = 600, .min_ce_len = 90, .max_ce_len = 90 } } };
對于1M phy來說,由主設(shè)備統(tǒng)計的吞吐率為:687104bps。 ? ??
使用藍(lán)盒(ellisys)抓包:
一包間隔為62.5ms(即50*1.25ms),觀察其中的數(shù)據(jù)包發(fā)現(xiàn),一個間隔有23包數(shù)據(jù)發(fā)出去。 實際發(fā)出的有效數(shù)據(jù)=23x244bytes=23x244x8bits=44896bits。 吞吐率=44896/0.0625=718336bps. 比串口統(tǒng)計的略大,仔細(xì)觀察Ellisys窗口,發(fā)現(xiàn)每個連接間隔發(fā)滿時,都有一次retry。在連接間隔的末尾,從設(shè)備沒有回復(fù)主設(shè)備連接包,主設(shè)備進(jìn)行了一次重傳。
也就是一個連接間隔實際只發(fā)了22包。
吞吐率=22x244x8/0.0625=687104,與串口的統(tǒng)計對應(yīng)上了。
想要提升吞吐率,從上面的分析可以看到,有兩個可以調(diào)整的地方,一個是每次重傳的那一包,一個是連接間隔中空閑的6.116ms。
6.116ms足夠傳2包數(shù)據(jù)(具體傳送一包的時長,參照下面的理論分析部分)。
調(diào)整連接間隔
.interval_min = 51,
.interval_max = 51,
可以看到,每個連接間隔變成了63.75ms,比剛才多傳了一包,24包(由于依然有一個retry包,有效包23包),連接間隔中浪費的時間4.89ms,比剛才的6.116ms少,本次吞吐率理論上比上次高。
23x244x8/0.06375=704205
串口顯示基本上兩次718336,一次673440, (718336x2+673440)/3=703370,基本一致。 參數(shù)設(shè)置為
.conn_param = { .scan_int = 200, .scan_win = 180, .interval_min = 100, .interval_max = 100, .latency = 0, .supervision_timeout = 600, .min_ce_len = 200, .max_ce_len = 200 }
每個連接間隔125ms,傳輸有效包48包。
48x244x8/0.125=749568bps=93696Bps≈93KBps,
此時連接間隔的空閑時間為4.447ms,
基本上已經(jīng)達(dá)到極限。
02 理論分析
BLE連接數(shù)據(jù)包分解如下:
當(dāng)ATT payload設(shè)置為244,傳輸一包數(shù)據(jù)需額外傳輸?shù)腷ytes數(shù)為:
1(preamble)+4(access address)+2(LL Header)+4(L2CAP Header)+3(ATT Header)+3(CRC)=17(因為不加密,所以沒有MIC)。
一包總的數(shù)據(jù)長度為17+244=261bytes=261x8bits=2088bits。
對于1Mphy來說,傳輸1bit時間為1us,傳輸一包數(shù)據(jù)就需要2088us,即2.088ms。
數(shù)據(jù)傳輸還有另外兩個無法避免的時間開銷:1)傳輸完一個數(shù)據(jù)包后,需要另一個設(shè)備回一個空包來保持?jǐn)?shù)據(jù)傳輸;2)數(shù)據(jù)包之間需要有一個空閑時間來讓協(xié)議棧完成數(shù)據(jù)處理,這個時間即T_IFS,150us。
空包的長度為1(preamble)+4(Access Address)+2(PDU)+3(crc)=10Bytes=80bits。
也就是說傳輸一個空包時間為80us,加上兩個T_IFS,總共380us。
也就是說,傳輸244Bytes數(shù)據(jù),實際花費的總時間=2088us+380us=2468us=2.468ms. 如果可以保持不間斷地發(fā)送,吞吐率=244/0.002468=98865Bytes≈98KBps。 但是實際必然無法達(dá)到這個速度,就是由于上面說的,每一個連接間隔無法全部用于發(fā)送數(shù)據(jù),即便讓連接間隔是2.468ms的整數(shù)倍,協(xié)議棧也會留出一些空隙用于內(nèi)部業(yè)務(wù)處理,對于Ingchips來說,這個間隙大約在4-6ms。 因此實測的93KBps已接近理論吞吐量的極限。 根據(jù)上面的分析,合理猜測如果把連接間隔無限拉長,可以最小化每個連接間隔空隙4-6ms的影響。但實際上,協(xié)議棧總需要時間來處理自己的事務(wù),如果把連接間隔設(shè)的過長,且全部用于發(fā)送數(shù)據(jù),協(xié)議棧就會在一定時間停止發(fā)送,且此連接間隔剩下的時間也不再用于發(fā)送數(shù)據(jù),因此數(shù)據(jù)速率還會下降。
三、2MPHY
01 Ellisys抓包2M PHY 方法
如下圖所示,勾選2M PHY
02 實測
在連接間隔設(shè)為60,152kBps以上。
具體過程不再贅述。
四、實操
01 環(huán)境準(zhǔn)備
硬件:
INGCHIPS開發(fā)板兩套,可以咨詢INGCHIPS代理商購買(上面的膠棒天線需要自備)。
Micro USB線兩條。
軟件:
串口調(diào)試工具,比如SSCOM。
02 測試過程
說明:
關(guān)于INGCHIPS SDK的下載和安裝、開發(fā)軟件環(huán)境的配置、例程的編譯和固件下載等具體問題,桃芯官網(wǎng)提供了豐富的由淺入深的開發(fā)資料,前期搭建環(huán)境過程中可以參照。
http://www.ingchips.cn/intro/25.html
https://ingchips.github.io/docs/application-notes/
過程中遇到問題也可以咨詢桃芯科技的代理商或原廠支持。
SDK安裝好后,在兩塊開發(fā)板分別下載SDK提供的專門用于吞吐量測試的主從例程。
連接主設(shè)備的串口,主設(shè)備上電會有打印,有相關(guān)調(diào)試指令的說明。
主設(shè)備掃描到從設(shè)備后,會自動進(jìn)行連接。
之后發(fā)送測試指令(start m->s表示主設(shè)備發(fā),從設(shè)備收),主設(shè)備的串口就會1秒鐘發(fā)送一次實時吞吐率測試結(jié)果。
可以參照第二部分中,調(diào)整連接參數(shù)的配置,觀察吞吐率的變化。如果有條件,也可以用Ellisys實時抓取連接過程,觀察空中包的發(fā)送情況。 注意:測試時把兩套開發(fā)板放在靠近的位置上,保證二者有穩(wěn)定的信號連接,信號不穩(wěn)或者太差會影響吞吐率,信號強度對吞吐率的影響歡迎小伙伴們自行測試。
-
芯片
+關(guān)注
關(guān)注
455文章
50812瀏覽量
423573 -
吞吐量
+關(guān)注
關(guān)注
0文章
47瀏覽量
12330 -
PHY
+關(guān)注
關(guān)注
2文章
303瀏覽量
51741 -
BLE
+關(guān)注
關(guān)注
12文章
660瀏覽量
59406 -
SDK
+關(guān)注
關(guān)注
3文章
1036瀏覽量
45935
發(fā)布評論請先 登錄
相關(guān)推薦
評論