ＰＣ上のProcessingでリアルタイムグラフプログラムは2時間で出来てしまったのですが、なぜ簡単なのかというとＰＣの場合は、WIN10でBlueTooth SPPの設定してあるからです。やり方はこちらです。つまり、普通のUSBシリアル通信のプログラムでBlueToothＳＰＰ用ＣＯＭ番号に指定するだけでＯＫです。しかし、スマホの場合は、ProcessingのBlueToothライブラリーは、公式版は無くて、KETAIというＩＯＴ用ライブラリーしかありません。（私が知る限りですが）この3年間でKETAIでBlueTooth受信プログラムをいろいろ作ってきたのですが、ｃｍ級ＧＮＳＳのＲＴＫシステムの場合は、200msec周期なのでノントラブルだったのですが、パワーメーターの8msecの波形データを漏れなく受信するには、KETAIライブラリーの速度が厳しくなって、いろいろ破綻してきます。
ごちゃごちゃしてきたので、備忘録としてメモしておきます。
●Processing android mode プログラムデバッグ環境
Processing IDEを中心のデバッグしていきます。
PCにスマホをつないで、IDEでコンパイルするとスマホに自動転送してアプリとして実行してくれます。M5StackのArduinoIDEコンパイル時間より５倍くらい速いので便利です。
さらに、スマホの実行結果は、print命令で、IDEの下部のコンソールに表示されるので、デバッグに非常に便利です。
スマホのBlueToothで受信したデータをデバッグしていくので、決まった時系列データをスマホへBlueTooth経由で入力しなればなりません。ローラ台で踏みながらデバッグできませんので、ペダリングデータをシミュレータを作って捏造します。シミュレータで使うM5StickCが3個で、ロードバイク左右クランクに2個M5StickCを取り付けてあるので、M5StickCが合計5個体制まで膨れあがってますが、安いわりに高機能なので、いろいろ使えていいです。中華品なので、時々異常動作（ＰＣに接続するとカーソルが暴走する）などＵＳＢシリアル関係で不具合が結構ありますが、ご愛嬌というところで納得してます。
下の写真がシミュレータシステムです。これらは、数ｍ離れていてもいいので、部屋の隅っこにおいておいて、ＰＣとスマホのデバッグは、家のどこでもBlueToothが届く範囲内で自由にできます。晩酌しながら、デバッグ作業してます。
■1ｓｔＳＴＥＰ：BlueTooth送信データ生成シミュレーションシステム作成
リアルタイムの評価なので実際と同じ無線システム（ＥＳＰ－ＮＯＷ）で無線通信してます。ESP-NOWは、1MBPSと無線としては高速なので、2020年からは、Xbeeは、出番を失ってます。
Ａ：左右クランクの正弦波発生用M5Stick2個
Ｂ：パワータップのＡＮＴからのパワー値とＡＮＴハートレートセンサの心拍値
siml ANT+でデータを捏造してます。
Ｃ：母艦M5Stickから1秒間隔で上死点信号を左右クランクのm5Stickへ送信します。
M5Stickの外付けBlueToohtモジュールＲＮ－４２からスマホへデータを送って、デバッグします。
■2ndＳＴＥＰ:スマホ側は、Processingアンドロイドモードで、ＰＣからプログラムを書き換えながらデバッグします。スマホのログは、スマホの内部メモリーにログして、GoogleDriveへスマホからＣＳＶファイルを共有します。GoogleDriveからＰＣのＥＸＣＥＬでＣＳＶファイルを開いてデータを分析してデバッグします。
●今までのスマホBlueTooth受信プログラム開発の事例
①2018年にスマホをサイコン化した時は、周期が4～6msecで受信していたので、あちこちでエラーがでて破綻してしまって失敗でした。今から考えると、Ｘｂｅｅのデータ落ちとBTのデータ落ちが重なってとんでもないことになっていたと思います。素人プログラムでのＢＴは、速度対応がダメです。プロのＢＴは、4msecでもデータ落ちしてませんでした。(BlueTermでログできた）
➁ＧＮＳＳ ＲＴＫ MovingBasecモードのスマホモニターは首尾よくできました。
これは、データの周期が200msecだったので、KETAI BlueTooothライブラリが余裕で受信できたので、データ落ちなどトラブルが発生しない点が良かったと思います。
●パワーメーター２０２０でのBT受信状況
周期が8msecになっていますので、２０１８年よりは遅くなってます。これは、ESP-NOWで、2か所と同時通信しているので、1か所だけなら4msecでＯＫでした。
しかし、プログラムを作ってみるとBlueToothからの受信データがばらばらで安定して受信できませんでした。スマホでログをとってみると、なんと、1回の受信バイト数が3バイトから390バイトまでばらばらと入ってきます。KETAIライブラリでは、デリミター区切りで
読み込んでくれないので、ばらばらのままユーザーが整理しないといけません。
●ばらばらなBT受信を整理するための方策
方策１：今までASCIIデータで扱ってきたのをバイナリーデータにして、送信バイト数を固定フォーマットにしました。
＝＞受信バイト数がばらばらなので、少なくとも送信データ数とフォーマットを固定しないと整理がつかなくて、発散してしまうので、送信データを以下のフォーマットに決めました。
●データ受信ログをみながら考える
①最初にヘッダーを探す動作
受信データの12番目からヘッダの’Ｂ’が始まっているので、この12番をj0として基準番号として記憶する。
基準番号からj０+29までが1データセットなので、これがそろったら、整数に変換して
グラフとログに回す。
➁最大データ数は388バイトもある
最大388バイトもあると30バイト1セットが１２個もあるので、12個を変換しないといけませんが、リアルタイム性がどうなるかが課題となります。
●以後
これらのデータをまとめて、リングバッファ関数を作って、メインから呼び出しながらデータをリアルタイムグラフにおとしていきます。どこまでリアルタイムになるか実際の表示速度と検証しないといけません。
