好看的言情小说,小说改编的网页游戏,我欲封天耳根小说零

概述：文章第一部分先公布結論，第二部分是1M PHY吞吐率的實測過程與理論分析，第三部分是2M PHY的實測數據，第四部分是實操部分，喜歡BLE的朋友可以按照此部分的說明自己動手進行測試。

一、結論

使用INGCHIPS SDK中測試吞吐率的例程peripheral_throughput和central_throughput，使用兩個開發板進行測試。

1M phy吞吐率≥93KBps；

2M phy吞吐率≥152KBps。

二、1MPHY

01 實測

為了最小化包頭、包尾、校驗等無法避免的數據開銷，每一包數據MTU設置為247。除去3bytes的ATT Header，則實際的ATT payload為244。在central端連接參數使用默認值的情況下：

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來說，由主設備統計的吞吐率為：687104bps。 ? ??

使用藍盒（ellisys）抓包：

一包間隔為62.5ms(即50*1.25ms)，觀察其中的數據包發現，一個間隔有23包數據發出去。實際發出的有效數據=23x244bytes=23x244x8bits=44896bits。吞吐率=44896/0.0625=718336bps. 比串口統計的略大，仔細觀察Ellisys窗口，發現每個連接間隔發滿時，都有一次retry。在連接間隔的末尾，從設備沒有回復主設備連接包，主設備進行了一次重傳。

也就是一個連接間隔實際只發了22包。

吞吐率=22x244x8/0.0625=687104，與串口的統計對應上了。

想要提升吞吐率，從上面的分析可以看到，有兩個可以調整的地方，一個是每次重傳的那一包，一個是連接間隔中空閑的6.116ms。

6.116ms足夠傳2包數據（具體傳送一包的時長，參照下面的理論分析部分）。

調整連接間隔

.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，基本一致。參數設置為

.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，

基本上已經達到極限。

02 理論分析

BLE連接數據包分解如下：

當ATT payload設置為244，傳輸一包數據需額外傳輸的bytes數為：

1（preamble）+4（access address）+2（LL Header）+4（L2CAP Header）+3（ATT Header）+3（CRC）=17（因為不加密，所以沒有MIC）。

一包總的數據長度為17+244=261bytes=261x8bits=2088bits。

對于1Mphy來說，傳輸1bit時間為1us，傳輸一包數據就需要2088us，即2.088ms。

數據傳輸還有另外兩個無法避免的時間開銷：1）傳輸完一個數據包后，需要另一個設備回一個空包來保持數據傳輸；2）數據包之間需要有一個空閑時間來讓協議棧完成數據處理，這個時間即T_IFS，150us。

空包的長度為1（preamble）+4（Access Address）+2（PDU）+3（crc）=10Bytes=80bits。

也就是說傳輸一個空包時間為80us，加上兩個T_IFS，總共380us。

也就是說，傳輸244Bytes數據，實際花費的總時間=2088us+380us=2468us=2.468ms. 如果可以保持不間斷地發送，吞吐率=244/0.002468=98865Bytes≈98KBps。但是實際必然無法達到這個速度，就是由于上面說的，每一個連接間隔無法全部用于發送數據，即便讓連接間隔是2.468ms的整數倍，協議棧也會留出一些空隙用于內部業務處理，對于Ingchips來說，這個間隙大約在4-6ms。因此實測的93KBps已接近理論吞吐量的極限。根據上面的分析，合理猜測如果把連接間隔無限拉長，可以最小化每個連接間隔空隙4-6ms的影響。但實際上，協議棧總需要時間來處理自己的事務，如果把連接間隔設的過長，且全部用于發送數據，協議棧就會在一定時間停止發送，且此連接間隔剩下的時間也不再用于發送數據，因此數據速率還會下降。

三、2MPHY

01 Ellisys抓包2M PHY 方法

如下圖所示，勾選2M PHY

02 實測

在連接間隔設為60，152kBps以上。

具體過程不再贅述。

四、實操

01 環境準備

硬件：

INGCHIPS開發板兩套，可以咨詢INGCHIPS代理商購買（上面的膠棒天線需要自備）。

Micro USB線兩條。

軟件：

INGCHIPS SDK，下載最新版本。

串口調試工具，比如SSCOM。

02 測試過程

說明：

關于INGCHIPS SDK的下載和安裝、開發軟件環境的配置、例程的編譯和固件下載等具體問題，桃芯官網提供了豐富的由淺入深的開發資料，前期搭建環境過程中可以參照。

http://www.ingchips.cn/intro/25.html

https://ingchips.github.io/docs/application-notes/
過程中遇到問題也可以咨詢桃芯科技的代理商或原廠支持。

SDK安裝好后，在兩塊開發板分別下載SDK提供的專門用于吞吐量測試的主從例程。