アンドロイド センサーの値を取得 エンコーダー

ロータリーエンコーダの動作確認ができました。
写真がぼやけていますが、
２９５１７
というのが、エンコーダの値です。

初期値を３００００にして、
マイナス方向にパルスが発生しているという
ことになります。

実際には、マイコンがタブレットに、データ送信するごとに
エンコーダの値を、３００００にして、次に送信するまでの
変化量で、タブレット側には、表示させようと思います。

こうすることで、マイコン側の桁あふれなどに対応できると
思います。

本番は、１回転で１０００パルスのロータリーエンコーダで、
位相係数モードというので使うと、１回転で４０００パルスに
なります。
例えば１秒ごとにデータを取得する場合。

１秒間に７回転くらいまでなら、桁あふれが起きないだろうなと

以前のデータで、１回転で、２２７．６ｍｍの移動量として
計算した場合、１５９３．２ｍｍ　

１秒で約１．５ｍの移動量。

もしそれでもオーバーフローするようなら、
初期値を３００００ではなく２００００に
すれば、プラス方向への桁あふれに余裕が持てることになるので
そのようにするつもりです。値の範囲は０〜６５５３５かな。
（１６ビット　２の１６乗）

アンドロイド センサーの値を取得 電圧の変化

電圧が０Ｖから５Ｖまでの変化を
０Ｖ＝０
５Ｖ＝１０２３
とみなして、ボリウムで、電圧を変化させて
その値を連続的に読み取る。

２箇所同時に読み取る。

テスト完了です。

もう１つ、エンコーダといって、パルス数を取得して
例えば、移動距離がわかる。というようなセンサーが
あるのですが、次は、エンコーダの値を取得する部分を
テストする予定です。

アンドロイド 定期的にデータ送信

定期的にタブレットからマイコンに対して、データ要求のコードを
送信する。という仕組みが作れました。

今現在、スレッドを使って、socket通信を行っていますが
単に、スレッドの中で、インターバルをおくだけで
いいのかどうかを、今日中には試したいと思います。
（試せました）

スレッド自体は、ループしていて、

＞Thread.sleep(REPEAT_INTERVAL);

このあたりがキーワードになるかなと思っています。
REPEAT_INTERVALの値は前もって、このように定義すると
//繰り返し間隔（ミリ秒）
private final int REPEAT_INTERVAL = 3000;

３秒間処理が停止されます。

スレッドというのは、ちょっとニュアンス違うかもしれませんが

会社の中にＡさんとＢさんがいて、ＡさんとＢさんは別々の仕事を
している。会社としてみた場合は、２つの仕事が同時に進んでいて
連携もできるし、通常は別々の動きをしている。
というような例え方ができるかもしれません。

プログラムとしては１つでも、処理が通常は同時並行的に処理できる。

スレッドの処理が止まっても別処理は普通に動作している。
ので、スレッドで、３秒のタイマーを用意して、３秒ごとに
マイコンにデータ要求をする。というのが動作確認できました。

本番は１秒ごとくらいにデータ要求ができればいいなと思っています。

次は、アンドロイド側からのデータ要求に応じて、
センサーの値を返す仕組みを作ります。

擬似的にセンサーの役割をするボリウム（ボリューム　可変抵抗器）を
調達してきます。

アンドロイド 画面非表示の必要なし

アンドロイドのbluetooth通信で、
最初のsocketのconnectに時間がかかったと
いうことで、通信自体は、最初から最後まで
基本的につなぎっぱなしにしようと思い、

最初の画面で通信を確立して、その画面は
閉じない。という方法を取ろうと思います。

画面が切り替わったとき、もしかして
一瞬でも、後ろの画面（最初の画面）が
表示されるのかなと思い、図のように、
３画面で、順に遷移するプログラムでテスト
した結果、最初の画面は開いたままで、
２画面目、３画面目に切り替えたとき、

後ろの画面が表示されないことを確認しました。

＞// インテントへのインスタンス生成
＞Intent intent = new Intent(this, BtEcho03ThirdActivity.class);
＞
＞//　インテントに値をセット
＞//intent.putExtra("KuiNo", wtextV.getText().toString());
＞// サブ画面の呼び出し
＞
＞startActivity(intent);
＞finish(); //自画面終了

アクティビティをスタートさせてから
自分の画面を閉じるという順番です。

最初思っていた、画面を非表示にする必要はなさそうです。

アンドロイド 画面を非表示にできるのか？

タブレットと、マイコンが無線でデータ通信できだしたので、

次は、マイコン側は、センサーの情報を、送信する仕組み

タブレット側は、マイコンから送られてきた情報を編集および
保存する仕組みを作っていきます。

タブレット側で、通信開始の際に、コネクトといって、
相手側と繋ぐ命令のところで数秒かかるので、やはり
一度繋いだら、プログラム終了までは、つなぎっぱなしに
したほうが良いだろうなと思います

アンドロイドのプログラムでは、画面のことをアクティビティと
呼んだりしますが、今の自分の考えでは、１画面だけは、閉じずに
ずっと開きっぱなしで、できれば、別画面が表示されるときは
非表示（隠す）ということができないかな？　と思っています。

アンドロイド bluetooth通信の悩みごと解決

アンドロイドのbluetoothでソケット通信で
一度closeしたあと、次にconnectするときに
エラーとなってしまっていた件はなんとか
メドが立ちました。

今回使用したbluetoothモジュールは、
初回起動、connect、closeのときに
bluetoothモジュール自体がメッセージを
出力します。

マイコン側のプログラムで、
受信したコードをそのまま送信するように
テストプログラムを作成していたのですが、

アンドロイド側が、closeしたときに、
当然bluetoothモジュールがメッセージを出力
するので、それを、マイコンが受信して、
そのコードを、アンドロイド側に送信しようと
しても、もう、closeされている。

という感じで、エラーの原因になっていたのだと思います。

テストで、マイコン側は、受信だけして、アンドロイド側に
送信しないようなプログラムに変更して、

マイコンは、動きっぱなしで、アンドロイド側のプログラムを
何回も起動、終了を繰り返したところ、
毎回正常に接続できました。


実際のプログラムでは、bluetoothモジュールの
メッセージに出てこないコードを使用して、
ハンドシェイクの、通信を行うようにしようと思います。

全体の進捗を進めることも大切

今、通信のところで、少し手間取っていますが
ここでモタモタすると、よくないので

質問を投げかけたカタチで、

全体を仕上げていく方向にチカラをいれます。

本当の意味での工作作業。

穴を開けたり、箱に組み付けたり。
といったことも進めておけば、前には進みます。


今まで、いろいろ失敗した中で、わからない部分に
ずっと注目しすぎて、全体が止まる。ということが
ありました。

気にはなっていますが、できるところは前に進めて
全体の進捗を進めることも大事なことだと思っています。

アンドロイドでの質問がしたいのですが．．．

アンドロイドのプログラムで、自分でも難しいこと
やっているかなと思いながら。。。
誰かに質問したいけど、誰に質問すればいいのかが
わからないです。

それとも、難しく考えすぎているのかな？

画面が切り替わっても、通信はずっと動いていないと
いけないな？とか。

そうなれば、後ろで動いている通信のデータを
リアルタイムで、表の画面に表示できたりするんだろうかなど。


いろんなサンプルは、１つの画面の中で完結しているのですが、
実際には、いろいろ画面が切り替わるので、その都度
通信が切れたら、再接続に時間がかかりすぎるような感じに
なるので、やはり、プログラムが動いているときは、ずっと
通信は、動きっぱなしのほうがいいかな？

問題ありだけど、アンドロイドとマイコンが無線でつながりました。

アンドロイド端末と、マイコンが、Bluetoothの無線でつながり
双方向通信ができるようになりました。

ただし、まだ問題があります。

１画面だけで、完結するプログラムではないので、
通信を切ったときの再接続がうまくいきません。

最初、接続するのに、どうしても時間がかかるので
たぶん、画面とは別で、通信を、ずっと動かす。
という方式にするだろうと思いますが、

たぶん、画面間での、リアルタイムの情報通信も
可能じゃないのかなと思いながら、サンプルを
探すようになると思います。

マイコン側、テストのための前準備

マイコンに有線で、"A"が送信されたら、
マイコン側のＬＥＤを点灯させる。という
プログラムを作成して、マイコンに送られて
くるコードを識別していることと、
マイコン側に、コード（データ）が到達していると
いう確認ができるように。

この２点を確認できました。