BLE Data Rate 專題討論 (2)
BLE Data Rate 專題討論 (2)
接下來我們來探討 BLE Solutions 的速度限制, 現在幾乎所有的晶片製造商都有出 BLE Single Mode Solutions 了, 列舉幾個我知道的如下:
TI / CSR / Nordic / Dialog / ST Micro / Cypress / Atmel / Microchip / Broadcom / Renesas / Realtek (瑞昱) / AMICCOM (笙科) / ...
細節大家 Google 一下就有, 在找 Solution 的朋友都可以多加比較參考, 之後我會做一下簡易的比較跟判斷要使用哪個方案的建議和教學
回到 BLE Data Rate, 上一篇提到影響 BLE Data Rate 第二個原因是不同 BLE Solution 本身的限制, 所以我們這邊就挑幾個來研究比較一下
基本上第一版的 BLE 晶片 (CSR / TI / Nordic) 都是 BLE 4.0, 實際速度大概都是 50kbps 左右而已, 而到了今年各家都出了 BLE 4.1 / 4.2 版本的晶片後, 加上都改用 Cortex-M 當作 MCU, 整個速度其實都提升了不少, 可以到 100kbps 以上 (但通常是限定跟自己家的晶片做通訊才可以達到高速)
我們先來看看 TI CC254x, 由很多網路資料可以推敲出實際使用 CC254x 的速度, 下面是 TI 論壇 CC2540 速度評估, 大約是 5.9KB/s 也就是約 48kbps 而已, 說真的有點慢, 然後一個 Connection Interval 就是送 4 packets
http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput
之後 TI 有給個 overlap processing 的機制, 原本的機制一個 connection interval 最多就是填滿 4 個 tx buffer, 然後就算資料還有, 也沒辦法再填入, 而 overlapping 就是可以做到在同一個 connection interval 繼續填充 buffer 的功能, 所以一個 connection interval 就可以送出 as many as possible 的封包了, 所以速度可以提升, 根據說法是原本一個 connection interval 4 包可以變成 14 16 包, 所以速度提升 4 倍, 但這邊沒特別講到 connection interval 設定多少, 也沒講最終速度是多少, 但或許有機會可以到接近 200kbps, 部過這個前提就是 Receiver 端也要可以做 overlap processing 能夠在一個 connection interval 收這麼多 notifications, 不然也是遺失掉而已
http://processors.wiki.ti.com/index.php/OverlappedProcessing
註: 因為網路有些人會想說一個 connection interval 最多送 4 包 packets 是 BLE SPEC 限制, 這邊製個例子其實就證明沒這回事, 特別再次說明沒這個限制, 只是剛好第一代的 BLE 晶片都恰巧是做到 4 罷了 (Nordic 的舊版 BLE 也是 4)
接下來看看 TI 新版的 BLE 晶片 CC2640, 下面有一篇 CC2640 速度探討的文件, 直接講重點, 他的速度可以到 300kbps, 基本上 CC2640 目前 Protocol 是還沒升級到 4.2 的部份 (官網寫說未來可以透過韌體升級達到升級 4.2), 而他只有 4.1 就可以到 300kbps 原因是因為他可以做到兩點:
http://processors.wiki.ti.com/index.php/CC2640_BLE_Throughput
要把 ATT_MTU 升到 255 bytes 必須要跟 peer 做 ATT_MTU 的交換, 也得收端支援才可以 (所以要是 CC2640 才能夠確保, 其他收端則不確定), 關於交換的 Procedure 可以參考下面文件的 5.5.2
下面這段值得一看, 簡單來說就是 L2CAP Size 本來就可以很大, 然後是 LL 這層來做 fragmentation & recombination, 這是 BLE Protocol 可以做到的 (然後回想一下上一章說的, 未來 BLE 4.2 之後 LL 也可以支援更大的 Payload, 這時候就不用做 fragmentation & recombination 了), 這文件後續是講如何交換 ATT_MTU, 就不再詳述
註: 由上面討論可以知道 CC2640 目前韌體只到 Bluetooth 4.1, 所以還沒有 Bluetooth 4.2 的 LL Payload 加大功能, 也就是跟 Bluetooth 4.0 是相同的, 但他藉由加大 ATT Payload (ATT_MTU) 就達到了 300kbps, 所以可以間接的證明我們在 BLE Data Rate 專題討論 (1) 去探討的 BLE 4.0/4.1 最高速 236.7 kbps 不能說他錯, 但他是限制在 ATT Payload 只有 20 bytes 的情況去評估的, 但這並非是 BLE 4.0/4.1 的限制, 假如我們再提升 ATT Payload size 的話, 速度可以更快的
因此重新結論一下 BLE 4.0/4.1 最高速並不是 236.7 kbps, 但假如我們限制 ATT Payload 20 bytes 的情況下, 那的確就是 236.7kbps
接下來我剛好有看到 Cypress 這顆 PSoC4BLE, 官方有提供速度數據, 最高速大概是 270kbps, 那他一樣是做到了 ATT_MTU 的設定改變, 他可以設定 23-512 bytes, 而實測後最高速度就是約 270kbps, 這部分一樣要有對應可以接受高 ATT_MTU 或是設定高 ATT_MTU 的 Receiver, 不然速度也會上不去
http://www.cypress.com/blog/100-projects-100-days/project-024-ble-throughput-pushing-limits
最後討論一下 Nordic, 也算是 BLE Solution 的先鋒之一 (CSR 也是, 但 CSR 老實說資料比較少一點, 所以就不在這邊討論, 但以穩定性來說 CSR 相信可以排前三名)
下面兩篇是探討 Nordic 速度的討論, 我這邊擷取一下重點:
https://devzone.nordicsemi.com/question/3440/how-do-i-calculate-throughput-for-a-ble-link/
https://devzone.nordicsemi.com/question/30611/data-rate-measurment/?answer=30753#post-id-30753
基本上就是每個 connection interval 可以送 6 包 20 bytes 的 notifications, 然後可以到最低的 connection interval 7.5ms, 所以根據公式計算速度可以到 128kbps
目前的 Nordic MEFW 似乎還沒支援改 ATT_MTU 的功能
做一個本單元的結論, 這邊我們只看了三種 solutions, 就發現速度各有不同, 用來提升速度的方式也各有不同, 而且有的還會標註想達到這麼高速, peer 一定得用同樣 solution 搭配同樣的設定才行, 這也印證了第一章提到的, 不同的解決方案, 速度不同, 選的時候要特別注意
另外這一篇也解決了我們在第一篇討論關於 ATT_MTU 的疑問, 看起來 ATT_MTU 是可以很大的, 每一個 L2CAP packet 也可以很大, 讓 LL 去切跟組就好, 所以 20 bytes notification 並非是一個最大值, 而是 ATT_MTU 預設值 23 下, notification 資料的最大值而已, 透過提升 ATT_MTU 以及 L2CAP packet size, 也可以提升 BLE application data rate
TI / CSR / Nordic / Dialog / ST Micro / Cypress / Atmel / Microchip / Broadcom / Renesas / Realtek (瑞昱) / AMICCOM (笙科) / ...
細節大家 Google 一下就有, 在找 Solution 的朋友都可以多加比較參考, 之後我會做一下簡易的比較跟判斷要使用哪個方案的建議和教學
回到 BLE Data Rate, 上一篇提到影響 BLE Data Rate 第二個原因是不同 BLE Solution 本身的限制, 所以我們這邊就挑幾個來研究比較一下
基本上第一版的 BLE 晶片 (CSR / TI / Nordic) 都是 BLE 4.0, 實際速度大概都是 50kbps 左右而已, 而到了今年各家都出了 BLE 4.1 / 4.2 版本的晶片後, 加上都改用 Cortex-M 當作 MCU, 整個速度其實都提升了不少, 可以到 100kbps 以上 (但通常是限定跟自己家的晶片做通訊才可以達到高速)
我們先來看看 TI CC254x, 由很多網路資料可以推敲出實際使用 CC254x 的速度, 下面是 TI 論壇 CC2540 速度評估, 大約是 5.9KB/s 也就是約 48kbps 而已, 說真的有點慢, 然後一個 Connection Interval 就是送 4 packets
http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput
之後 TI 有給個 overlap processing 的機制, 原本的機制一個 connection interval 最多就是填滿 4 個 tx buffer, 然後就算資料還有, 也沒辦法再填入, 而 overlapping 就是可以做到在同一個 connection interval 繼續填充 buffer 的功能, 所以一個 connection interval 就可以送出 as many as possible 的封包了, 所以速度可以提升, 根據說法是原本一個 connection interval 4 包可以變成 14 16 包, 所以速度提升 4 倍, 但這邊沒特別講到 connection interval 設定多少, 也沒講最終速度是多少, 但或許有機會可以到接近 200kbps, 部過這個前提就是 Receiver 端也要可以做 overlap processing 能夠在一個 connection interval 收這麼多 notifications, 不然也是遺失掉而已
http://processors.wiki.ti.com/index.php/OverlappedProcessing
註: 因為網路有些人會想說一個 connection interval 最多送 4 包 packets 是 BLE SPEC 限制, 這邊製個例子其實就證明沒這回事, 特別再次說明沒這個限制, 只是剛好第一代的 BLE 晶片都恰巧是做到 4 罷了 (Nordic 的舊版 BLE 也是 4)
接下來看看 TI 新版的 BLE 晶片 CC2640, 下面有一篇 CC2640 速度探討的文件, 直接講重點, 他的速度可以到 300kbps, 基本上 CC2640 目前 Protocol 是還沒升級到 4.2 的部份 (官網寫說未來可以透過韌體升級達到升級 4.2), 而他只有 4.1 就可以到 300kbps 原因是因為他可以做到兩點:
- 雖然 MAX NUM_PDU 設定是 6, 但是可以打完就補, 所以一個 Connection Interval 可以打 as many as possible 的 PDU 數量
- ATT MTU 可以設定 255, 所以 L2CAP PDU 可以到 255 bytes, 其中 Payload 可以是 248 bytes, 也就是說一個 Notification 可以帶 248 bytes (之前都是預設的 ATT_MTU 23 bytes, notification 只能帶 20 bytes)
http://processors.wiki.ti.com/index.php/CC2640_BLE_Throughput
要把 ATT_MTU 升到 255 bytes 必須要跟 peer 做 ATT_MTU 的交換, 也得收端支援才可以 (所以要是 CC2640 才能夠確保, 其他收端則不確定), 關於交換的 Procedure 可以參考下面文件的 5.5.2
下面這段值得一看, 簡單來說就是 L2CAP Size 本來就可以很大, 然後是 LL 這層來做 fragmentation & recombination, 這是 BLE Protocol 可以做到的 (然後回想一下上一章說的, 未來 BLE 4.2 之後 LL 也可以支援更大的 Payload, 這時候就不用做 fragmentation & recombination 了), 這文件後續是講如何交換 ATT_MTU, 就不再詳述
註: 由上面討論可以知道 CC2640 目前韌體只到 Bluetooth 4.1, 所以還沒有 Bluetooth 4.2 的 LL Payload 加大功能, 也就是跟 Bluetooth 4.0 是相同的, 但他藉由加大 ATT Payload (ATT_MTU) 就達到了 300kbps, 所以可以間接的證明我們在 BLE Data Rate 專題討論 (1) 去探討的 BLE 4.0/4.1 最高速 236.7 kbps 不能說他錯, 但他是限制在 ATT Payload 只有 20 bytes 的情況去評估的, 但這並非是 BLE 4.0/4.1 的限制, 假如我們再提升 ATT Payload size 的話, 速度可以更快的
因此重新結論一下 BLE 4.0/4.1 最高速並不是 236.7 kbps, 但假如我們限制 ATT Payload 20 bytes 的情況下, 那的確就是 236.7kbps
接下來我剛好有看到 Cypress 這顆 PSoC4BLE, 官方有提供速度數據, 最高速大概是 270kbps, 那他一樣是做到了 ATT_MTU 的設定改變, 他可以設定 23-512 bytes, 而實測後最高速度就是約 270kbps, 這部分一樣要有對應可以接受高 ATT_MTU 或是設定高 ATT_MTU 的 Receiver, 不然速度也會上不去
http://www.cypress.com/blog/100-projects-100-days/project-024-ble-throughput-pushing-limits
最後討論一下 Nordic, 也算是 BLE Solution 的先鋒之一 (CSR 也是, 但 CSR 老實說資料比較少一點, 所以就不在這邊討論, 但以穩定性來說 CSR 相信可以排前三名)
下面兩篇是探討 Nordic 速度的討論, 我這邊擷取一下重點:
https://devzone.nordicsemi.com/question/3440/how-do-i-calculate-throughput-for-a-ble-link/
https://devzone.nordicsemi.com/question/30611/data-rate-measurment/?answer=30753#post-id-30753
基本上就是每個 connection interval 可以送 6 包 20 bytes 的 notifications, 然後可以到最低的 connection interval 7.5ms, 所以根據公式計算速度可以到 128kbps
目前的 Nordic MEFW 似乎還沒支援改 ATT_MTU 的功能
做一個本單元的結論, 這邊我們只看了三種 solutions, 就發現速度各有不同, 用來提升速度的方式也各有不同, 而且有的還會標註想達到這麼高速, peer 一定得用同樣 solution 搭配同樣的設定才行, 這也印證了第一章提到的, 不同的解決方案, 速度不同, 選的時候要特別注意
另外這一篇也解決了我們在第一篇討論關於 ATT_MTU 的疑問, 看起來 ATT_MTU 是可以很大的, 每一個 L2CAP packet 也可以很大, 讓 LL 去切跟組就好, 所以 20 bytes notification 並非是一個最大值, 而是 ATT_MTU 預設值 23 下, notification 資料的最大值而已, 透過提升 ATT_MTU 以及 L2CAP packet size, 也可以提升 BLE application data rate
浙公网安备 33010602011771号