BlueTooth Low Energy v4.2を使ってみる。nRF52832

nRF52832 と、BLE v4.2 の最大の魅力は、パケットサイズを大きくとれること
ＵＡＲＴで相互通信
nRF52832 には、ＣＰＵを介さないで周辺回路を制御するＰＰＩという機能がある。ＰＰＩでＡＤＣを動かす
ＰＰＩでＡＤＣを動かし、ＧＰＩＯの制御を追加。 ２０１７．１１．９　プロジェクトソース追加
ＳＤＫ１４．０では、周辺回路のクロックソースが、デフォルトで内臓ＲＣ発振になっている！　２０１７．１１．１２
１パケット２４４バイトで、インターバルを５０ｍｓで通信してみる ２０１７．１１．１９
ＰＰＩで内臓ＡＤＣを動かし、ＢＬＥでデータを送信する。 ２０１７．１２．８


　ＢＬＥ( BlueTooth Low Energy )は、低消費電力を売りものにした通信規格であるため、従来のＢｌｕｅＴｏｏｔｈほどのデータ通信の速度を出せず、用途によっては　「もう少し早ければ」という壁にさえぎられることがありました。スペック的には、７．５ｍｓの通信インターバルで、２０バイトが最高の速度なので、１３３ｘ２０で、１秒間で、２６６０バイトが限界でした。（　実際に、この速度を出すのは不可能です。というのは、これはエラーなく通信できた場合のみです。）

　このような速度の限界を突破できる規格が、ｖ４．２で、２０１４年１２月に発表されました。パケットサイズが約１０倍となり、無線キャリアで送信できる速度も１Ｍｂｐｓから、最大２Ｍｂｐｓになったようです。チップメーカーからこの規格のＩＣが出てきたのは、最近のことで、評価基板付き、日本国内技適認証付きでは、２０１７年４月ごろです。（　ノルディックの、nRF52832 を使った　太陽誘電のＢＬＥモジュール　）

　ノルディックからは、ｎＲＦ５２　ＤＫという評価基板が、先に入手できていましたが、これには、日本の技適の認証はありません。あくまでもテスト用です。この評価基板は、ＤｉｇｉＫｅｙなどから入手でき、値段もそれほど高くないので、nRF52832 関連の開発をするなら、１枚あるといろいろと役に立ちます。ノルディックのＳＤＫ（　最新は、Ｖ１４．０　）に同梱されているサンプルソフトは、この nRF52 DK で、修正なしに動作するようになっています。
　以下は、nRF52 DK



　nRF52 DK は、押しボタンや、ＬＥＤなど、サンプルソフトをそのまま動作可能ですが、別の部品を接続するには不便なので、次のような評価基板を用意しました。太陽誘電株式会社のＢＬＥ評価基板です。nRF52 DK よりかなり高価（約２倍）ですが、それなりの使い勝手があります。

　上側の　Ｐ　のラベルを貼ったのが、ＥＢＳＨＪＮＺＸＺで、Ｃ　のラベルを貼ったのが、ＥＢＳＨＣＮＺＸＺです。違いは、ＢＬＥモジュールの大きさと、外部で使えるピンの数です。いづれもＦＴＤＩの、ＦＴ２３２ＲＱを介して、ＵＳＢ経由で、ＰＣのＣＯＭポートでＵＡＲＴ送受信できます。ＵＡＲＴに接続しているnRF52832 のピンは、nRF52 DK と同じになっているので、サンプルソフトの、ble_app_uart と、ble_app_uart_c を使って、相互にＵＡＲＴで無線送受信可能です。（　１文字単位に送るわけではなく、ＬＦコード[0x0A]で区切られたパケット単位　）



nRF52832 と、BLE v4.2 の最大の魅力は、パケットサイズを大きくとれること

　このパケットサイズを大きくすることを、ＤＬＥと呼んでいますが、ＢＬＥｖ４．１までは、２３バイトでしたが、ＢＬＥ　ｖ４．２では、これが、最大２４７バイトになって、ユーザーが扱えるパケットサイズは、最大２４４バイトになり、実に１２倍まで１パケットで送れます。
　この「最大」ということがミソで、１００バイトにしたいなら、その設定にすることができます。ble_app_uart という名のサンプルソフトの、main.c には、nrf_ble_gatt_att_mtu_periph_set(nrf_ble_gatt_t * p_gatt, mtusize)　関数があって、この関数で、最大パケットサイズを設定できます。使いたいペーロードの最大サイズを１００バイトにしたいなら、mtusize = １０３と設定します。

　ＳＤＫ１４．０（ nRF5_SDK_14.0.0_3bcc1f7 ）の、examples フォルダには、ble_central と、ble_peripheral のフォルダがあり、これらのフォルダには、それぞれ、セントラル側のサンプルソフトと、ペリフェラル側のサンプルソフトがまとめられており、その中に、UART で相互通信可能な、ble_app_uart_c と、ble_app_uart があります。この２個のサンプルソフトを使って、上の写真で紹介した、太陽誘電の評価基板、ＥＢＳＨＪＮＺＸＺ　と、ＥＢＳＨＣＮＺＸＺ　で、相互にＵＡＲＴで無線通信させることができます。なぜ最初にＵＡＲＴのサンプルソフトを使うのかというと、どちらの基板にも、ＵＡＲＴとして設定されるポートがＦＴＤＩと接続されていて、容易にＰＣのターミナルソフトで動作確認ができるからです。

ＵＡＲＴで相互通信
　サンプルソフトの、ble_app_uart_c と、ble_app_uart を、それぞれ、KEIL （ ここで使ったのは、やや古いバージョンのＩＤＥで、ｖ５．１２ ）でコンパイルしますが、ble_app_uart_c のソースは、すこし改造します。改造といっても、エコーバック機能を止めるだけです。

　以下は、ble_app_uart_c の、main.c の、８７行です。オリジナルでは、１と設定されているので、これを０に変更します。


　ペリフェラルの改造は、デフォルトでは、ペイロードサイズが、６１バイト（設定値としては６４）なので、これを、１２８バイトまで送れるようにします。設定は、１３１となります。変更箇所は、main.c の、void gatt_init(void) 関数内で、以下です。


　この設定で、１２８バイトまで１パケットで送れます。

　その他、動作中のメモリや、チップの周辺回路のレジスタの値を読めるように、モニタを実装します。モニタを実装すると、常時ＣＰＵが動作するため、スリープにはならないので、モニタには、終了コマンドを入れて、スリープできる機能も入れておきます。

　こちらが、ペリフェラルのソース一式です。→　ble_app_uart_TAIYO.lzh　ファイル一式 ble_app_uart_TAIYO.lzh
　解凍して、ble_app_uart_TAIYO　フォルダを、nRF5_SDK_14.0.0_3bcc1f7\examples\ble_peripheral\　フォルダに置きます。

　以下は、テラタームでのスクリーンショットです。

　ペリフェラル側、ＥＢＳＨＪＮＺＸＺに、解凍した、nrf52832_xxaa.hex　を書いてリセットスタートすると、
UART Start!00
とターミナルに表示されるので、ここで、コントロールＣを入力すると、
nRF52832 BLE SoC 2017.10.8-1
NRF52832-Bug>
　と表示され、コマンドを入力して、メモリの表示などができます。


nRF52832 には、ＣＰＵを介さないで周辺回路を制御するＰＰＩという機能がある。ＰＰＩでＡＤＣを動かす

　nRF52832 には、いわゆるＤＭＡとシーケンサを組み合わせたような機構が、各周辺回路に個別に実装されていて、無線の対応で割り込みサービスが遅れて正確なタイミング設定ができない問題を解消してくれます。この機構を、「ＰＰＩ」と呼びます。ＰＰＩとは、Programmable peripheral interconnect　のことで、ＣＰＵ動作から独立した、簡単なハードウエアシーケンサです。ハードウエアで制御するため、時間間隔などは正確にタイマーに追従します。
　なぜこのような機能を入れたのかは、最優先のＢＬＥの制御によって、ユーザーに渡される割り込みのタイミングが大きくずれてしまうので、そのずれを解消するためと推測されます。実際、nRF51822 では、タイマー割込みを使っても、１ｍｓ程度のジッターが発生してしまい、正確さが要求される用途には使えませんでした。

　時間を正確に決められるといっても、繰り返し動作のような使い方で重宝するのですが、ＡＤコンバーターを正確なインターバルで動作させる、正確なインターバルでＳＰＩを動作させる、正確なインターバルでＧＰＩＯを操作する、などが可能になります。また、これらの周辺回路操作を複数個、同じタイマーのカウント数の違いで、個別に操作タイミングを設定できたりします。

　ＳＤＫ１４．０には、nRF52832 の、ＰＰＩ機能を使ったサンプルが、
nRF5_SDK_14.0.0_3bcc1f7\examples\peripheral　フォルダに、いくつか用意されていて、
　その中の、saadc というフォルダにある、ＡＤコンバーターをＰＰＩで制御するサンプルを使ってみます。そのままでも動作しますが、ＡＤコンバーターのサンプリングを、１秒に１０００回として、２個用意された読み取りバッファーを、２００回のサンプル単位に、バッファーの先頭部分をＵＡＲＴでヘキサで出すように改造してみます。オリジナルでは、デバッグ用にヘキサでＵＡＲＴで出すようになっていますが、このあたりは、別途にＵＡＲＴ出力を実装します。そのために、peripheral\uart フォルダにある、ＵＡＲＴのサンプルを、saadc　サンプルに移植します。

　主な変更点は以下
  1. uart 機能を追加。サンプルソフトの　uart から必要な部分をコピーして移植。
  2. ４ビットのデータをヘキサ文字に変換して、ＵＡＲＴで出力する関数。uint8_t tohexcode(uint8_t d) を追加。
  3. nrf_drv_timer_ms_to_ticks(&m_timer, 400); を、nrf_drv_timer_us_to_ticks(&m_timer, 1000); に変更。400ms から、1ms に。
  4. #define SAMPLES_IN_BUFFER 5　を、#define SAMPLES_IN_BUFFER 200 に変更。サンプル数は、２００回。
  5. void timer_handler(nrf_timer_event_t event_type, void * p_context)　関数内で、ポートに、Ｌｏｗパルスを出す。
  6. void saadc_callback(nrf_drv_saadc_evt_t const * p_event)　関数内に、バッファーの先頭のデータをヘキサでＵＡＲＴで出す処理を追加。
  7. NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN0);　を、NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1); にして、P0.03 (AN1) の電圧を変換します。
　これらの変更をしたプロジェクトファイル一式です。→　 saadc_modify.lzh
　解凍して、saadc_modify　フォルダを、nRF5_SDK_14.0.0_3bcc1f7\examples\peripheral\　フォルダに置きます。

　以下は、ボリュームで適当な電圧を作って　P0.03 ピンに入力し、ターミナルに、ＵＡＲＴで変換結果を表示させたものです。ＡＤコンバーターは、１０ビットで動作しているので、ボリュームを回すと、０付近　〜　０ｘ３ＦＦ付近の値に変化します。



ＰＰＩでＡＤＣを動かし、ＧＰＩＯの制御を追加。

　さて、ＳＤＫ１４．０のサンプルソフトでは、周辺回路の単体動作を、ＰＰＩで制御させる例はあるのですが、複数の周辺回路を、関連付けて動作させる例が見当たらないようです。この要求は、内蔵ＡＤＣでは、変換を始める前に、ポートをＬｏｗ，Ｈｉｇｈさせるとか、外部のＩＣにタイミングを通知するのに必要になることがあります。また、ＳＰＩや、Ｉ２Ｃも、ＰＰＩで制御できますが、外部に接続した、複数の異なるシリアルデバイスを、関連付けて制御したい、ってこともあると思われます。
　この要求を満たすには、ＰＰＩの制御がどのように行われるのか、分析しないと判りませんが、とりあえず、内臓ＡＤＣを、ＰＰＩで制御し、関連付けたポートに、Ｌｏｗ，Ｈｉｇｈを出すものを作成してみました。saadc のサンプルを元に、ＧＰＩＯを追加するには、いくつかファイルとか、インクルードパスとか、を追加し、sdk_config.h への #define 文の追加が必要になってきて、一筋縄には動作しませんでした。

　以下はその備忘録です。
　手順
  1. ＧＰＩＯに関するソースパス、nRF5_SDK_14.0.0_3bcc1f7\components\drivers_nrf\gpiote　を、インクルードパスに追加。
  2. nRF_Drivers ソース欄に、nRF5_SDK_14.0.0_3bcc1f7\components\drivers_nrf\gpiote の、nrf_drv_gpiote.c　を追加。
    このとき、nrf_drv_gpiote.c　には、どんな関数があるか一通りながめておく。
  3. ＳＤＫ１４．０の、ペリフェラルのサンプル、nRF5_SDK_14.0.0_3bcc1f7\examples\peripheral\gpiote　の、main.c で、ＧＰＩＯの使い方を確認する。このサンプルは、ＧＰＩＯを、ＰＰＩで制御するサンプルなので、使い方が判る。
  4. saadc に、ＧＰＩＯのサンプルを、同じタイマーで動作するように、改造しながら、移植する。
　・・・　と、こんな具合なのですが、４番目で、どう移植するのかに、一番時間がかかりました。
　以上の手順をふまえ、saadc のサンプルに、gpiote のサンプルを、同じタイマーを使って、ＰＰＩ制御して、ＡＤコンバーターが動作する前に、ポート　P0.28 に、Ｌｏｗ　のパルスを出すようにしたものです。ＡＤコンバーターサンプリングインターバルは、１ｍｓと短くして、ＡＤＣの結果のバッファーも、２００個を２面用意し、片方に変換データが書かれているときには、もう一方のバッファーから読み出せるようにしています。

　また、この bitcraft ＵＲＬのあちこちで使っている、モニタ機能を入れ、ＵＡＲＴ経由でメモリの内容の表示や変更ができるようにしています。
　ＳＡＡＤＣとＧＰＩＯをＰＰＩで制御したプロジェクトファイル一式です。→　 saadc_modify_gpio_mon.lzh 　このソースでは、ＢＬＥは使っていません。
　解凍してできるフォルダ、saadc_modify_gpio_mon　を、nRF5_SDK_14.0.0_3bcc1f7\examples\peripheral　フォルダ以下にコピーすると、
nRF5_SDK_14.0.0_3bcc1f7\examples\peripheral\saadc_modify_gpio_mon\pca10040\blank\arm4　に、saadc_pca10040.uvprojx　という名のＫＥＩＬのプロジェクトファイルがあるので、これを、ＫＥＩＬのＩＤＥで開くと、変更、再コンパイルが可能です。

　以下は、P0.20 でトリガし（赤色）、ＡＤＣサンプリングの前の１００μ秒のＬｏｗパルス（青色）P0.28 を観測したもの。

　赤色のＬｏｗパルスは、ＡＤコンバーター２００回読み取りの結果の割り込み処理です。

ＳＤＫ１４．０ では、周辺回路のクロックソースが、デフォルトで内臓ＲＣ発振になっている！

　ＰＰＩでＧＰＩＯを操作できてるか確認のためオシロで観察していると、１ｍｓのインターバル時間が、わずかに変動しているのが判りました。オシロで確認できるほどなので、どれくらいなのか正確に測ってみることにしました。こちらの、→ ＧＰＳモジュール　AE-GYSFDMAXB　の、１ＰＰＳ出力を調査　で１秒インターバルの測定で使ったＦＰＧＡ（ＡＲＴＹ）で測定すると、約±１％のジッターがあるのが判りました。つまり、０．９９ｍｓ　〜　１．０１ｍｓの間で常にランダムに変動しているのです。ＰＰＩは、ハードウエアによる制御なので、カウンタに正確に追従しているはずなのに、このジッターは何なのか、調査してみました。その結果、ノルディックのデベロッパーゾーンにその回答がありました。→NORDIC DEVELOPER ZONEで、PWM frequency accuracy で検索。

先ほどの、プロジェクトソース saadc_modify_gpio_mon.lzh の、mai.n.c の、以下の部分の、コメントとしているところは、ジッターをほとんど無しにする設定です。この設定は、ノルディックのメーリングリストＱ＆Ａで見つけたものです。→PWM frequency accuracy


NRF_CLOCK->TASKS_HFCLKSTART = 1; と、その次の行のコメントを外すと、正確な１ｍｓになりました。

１パケット２４４バイトで、インターバルを５０ｍｓで通信してみる

　通信のテストに行う構成は、以下です。ＰＣには、２４４バイトの文字列( 最後の２バイトは、CR と LF コード)を任意のインターバルでＵＡＲＴで送信するソフトと、ＵＡＲＴで受信するターミナルソフトを用意。

　このテストに使った、プロジェクトファイル一式です。→　 ble_app_uart_pkt244_7_5ms.lzh 　起動後、ソフトデバイスを起動する前にモニタが走り、NRF52832-Bug>t (enter) で、デフォルトのＭＴＵサイズ、２４７を確認でき、NRF52832-Bug>t92 (enter) で、ＭＴＵサイズを、１４６に設定できます。NRF52832-Bug>q (enter) で、モニタが終了し、ソフトデバイスの設定を行い、アドバタイジングを始め、再びモニタが走ります。セントラルと接続できると、再び、NRF52832-Bug>q (enter) でモニタを終了すると、ＵＡＲＴで受信したデータをセントラルに送れます。
　セントラル側は、こちら →　 ble_app_uart_c_mtumax247_7_5to75ms.lzh

　BLE v4.2 で、ＳＤＫ１４．０のＵＡＲＴサンプルソフトを使うと、パケットサイズ（ＵＡＲＴ等で実際に送れる１パケットのペイロードサイズ）を最大２４４バイトにはできますが、実際にこれを行うと、以下のようになります。コネクションインターバルは、７．５ｍｓと、最短時間としています。
青：ＵＡＲＴで２４４バイト受信後、２４４バイトを送信する、ble_nus_string_send　関数を呼び出す前後で、ポートをＬｏｗにした信号
赤：ble_evt_handler　のイベント通知で、p_ble_evt->header.evt_id　が、BLE_GATTS_EVT_HVN_TX_COMPLETE　の時、Ｌｏｗパルスをポートに出した信号

カーソルは、送信したあと、送信完了の通知がくるまで、約３０ｍｓであるのを示しています。
また、青のＬｏｗパルスのインターバルが、約５０ｍｓになっており、５０ｍｓインターバルで送信していることを示しています。

　青、赤信号とも、約７．５ｍｓインターバルで、急激にすこし電圧が下がっていますが、これは、ＢＬＥモジュールの電源供給ラインに２０オームの抵抗を直列に挿入して、無線が動作しているときの電流増加が判るようにしたものです。信号を拡大すると、送信と、受信操作の区別も判ります。
　送信完了のイベント通知、BLE_GATTS_EVT_HVN_TX_COMPLETEが来るまで、この電圧低下の波形が何回かあり、カーソル位置の例では、５回となっています。そのうち最初の３回は、Ｌｏｗになっている（ 正確には、何回か短くＬｏｗ，Ｈｉｇｈと変化 ）期間が長く、そのあとかなり短いＬｏｗ、そして、BLE_GATTS_EVT_HVN_TX_COMPLETE　のイベント通知のときの、短い波形となっています。

この波形を見る限り、２４４バイトが、１パケットで送られているようには見えません。ソフトデバイスでは、送信相手がデータを正常に受け取れなかった場合、再送信を行うようになっていますが、このテストでは、送信相手をごく近くに置いているため、（約８ｃｍ）電波品質の悪さが再送信につながっているとは思えません。

そこで、パケットサイズを、もう少し短くして同じようなテストをしてみました。ペイロードは、１４３バイトです。（ＭＴＵ設定は、１４６）


この波形を見ても、１４３バイトが、１パケットで送られているようには見えません。図では、３パケットすべてが２回で送られています。　

　パケットサイズを、最大２４４バイトにできるはずなのですが、何等かの理由で、１４３バイトでも１回で送られていないようです。


いろいろ設定値を変え１パケット１４３バイトで、通信してみた

　そこで、いろいろ設定値を変え、sdk_config.h での設定値、#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247　のところを、小さくしていき、１４６という設定だと、１４３バイトのペイロードを１回で送られることが判りました。
　以下は、sdk_config.h での設定値を、#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 146 とし、main.c の void gatt_init(void)関数　で、nrf_ble_gatt_att_mtu_periph_set(&m_gatt, 146);としたものです。


　この図では、４パケットの送信で、すべて１回で送信しているのが判ります。BLE_GATTS_EVT_HVN_TX_COMPLETE　の通知も、１回の送信のあと、次のコネクションインターバルの時に発生しています。
　そして、この図から推定されることとして、送信インターバルを、もっと短く、２５ｍｓでも連続で送れるように思われます。

ＰＰＩで内臓ＡＤＣを動かし、ＢＬＥでデータを送信する。

　これを行う前に、まず、ＵＡＲＴで受信したデータをＢＬＥで送るプロジェクトに、ＰＰＩを使って、ＡＤＣを駆動する機能を追加します。ＢＬＥで送信するプロジェクトは、いろいろ設定値を変え１パケット１４３バイトで、通信してみたを使い、それに、ＰＰＩでＡＤＣを操作する機能を追加します。→ＰＰＩでＡＤＣを動かし、ＧＰＩＯの制御を追加。
　ここで、ＰＰＩでＡＤＣを操作する部分をＢＩＯＳとして分離し、ＡＤＣ以外のデータ取得方法になったとき、変更しやすいようにします。名称は、hal_ppi_adc.c などと、ハードウエア寄りのモジュール名とします。

　全体の構成としては、モニタを実装してＰＰＩで読み取ったＡＤＣのデータを表示したり、ヘキサコードなどに変換して、ＢＬＥで送ったりできるようにします。ノルディックのサンプルソフトは、送受信双方を、ble_app_uart, ble_app_uart_c として、ノルディックのＵＡＲＴのＵＵＩＤを使います。

　追加した関数。ＰＰＩでのＡＤＣ読み取りバッファーは、１００サンプルに変更しています。また、コネクションインターバルを、１０ｍｓとしています。
  1. hal_ppi_adc.c　ＰＰＩを使って、ＡＤＣで電圧を読み取る。ハードウエアレイヤー
  2. hal_send_timer.c　１０ｍｓのタイマーを動作させ、割り込み処理関数を登録。ハードウエアレイヤー
  3. app_ble_send_data.c　上記の、割り込み関数の実行部と、ＡＤＣで読んだデータをＢＬＥで送信する。アプリケーションレイヤー
  4. dbgmon.c　テスト用のモニタ
　上記ファイルを追加したもの。パケットサイズは、１３１バイトとなっています。→ ble_app_uart_pkt131_adc100ms_10ms.lzh
　ＢＬＥで送信するとき、ＡＤＣで読んだ１０ビットデータのＭＳＢ６ビットは不要なので、バイト列に詰めて、パケットサイズを小さくしています。また、ペリフェラルでは、ＵＡＲＴのデータはＢＬＥで送信しません。

送信側で、上記のようにパックした１００サンプル（１２５バイトになる）に、ヘッダーのＳＴＸ，４バイトのシーケンス番号、１２５バイトのパックデータ、ＬＦ　として送信するので、受信側が出力するＵＡＲＴデータを、ターミナルで内容を確認することはできません。

　送信側（ペリフェラル）の動作と操作は以下のように進みます。
  1. nRF52832 BLE SoC pkt131 2017.12.8-1
    NRF52832-Bug>00 とＵＡＲＴで通知がくるので、ctrl-C を入力すると、
  2. NRF52832-Bug> とモニタのプロンプトが出るので、ここで、q (enter) とターミナルから入力します。（この時点でアドバタイジングを開始）
    すると、UART Start!00 とターミナルに通知がくるので、再び、ctrl-C を入力すると、
  3. nRF52832 BLE SoC pkt131 2017.12.8-1
    NRF52832-Bug>00　と再び同じ通知がくるので、ctrl-C を入力すると、
  4. NRF52832-Bug> とモニタのプロンプトが出て、ＡＤＣで読み取ったデータを、セントラルに送信する操作ができるようになります。
  5. セントラル側とのコネクションができても、何も通知しませんが、送信操作で確認します。
ＡＤＣで読んだ１００サンプルのデータを送信する。
NRF52832-Bug>a1 (enter) で、１００サンプルデータを送信します。送り終わると以下のように結果が出ます。
TX complete time = 10 ms
NRF52832-Bug>

ＡＤＣで読んだ１００サンプルのデータを指定回数送信する。指定回数は、ヘキサで指示します

上の例は、ペリフェラルと、セントラルの距離が約８０ｃｍですが、操作しているノートパソコンのＷｉＦｉでファイル転送している場合は以下のようになります。ＷｉＦｉでのデータ転送レートは、１秒で約１０ＭＢ。負荷としては中程度です。

　この結果から、近くでＷｉＦｉがそこそこ動作している場合は、ソフトデバイスでの再送信回数が増加し、ＢＬＥの電波が妨害されているのが判ります。

ＡＤＣで読んだ１００サンプルのデータを指定回数だけ、app_ble_send_data.c　の、app_send_timer_event_handler　で送信する。















準備中


ホームに戻る


inserted by FC2 system