電源部分の作成とテスト

俗に言う、車のバッテリーから電源供給するために
電源部分の作成とテストを行いました。

１２Ｖバッテリーといっても、実際の電圧は１４．４Ｖ
くらいあるので、三端子レギュレータで、１２Ｖと
５Ｖをつくります。

１２Ｖ側の三端子レギュレータは
低損失三端子レギュレーター　［１２Ｖ１Ａ］　ＬＭ２９４０ＣＴ−１２

５Ｖ側の三端子レギュレータは
三端子レギュレーター　［５Ｖ１Ａ］　ＮＪＭ７８０５ＦＡ（５個入）

いずれも、秋月電子さんで購入して、テストしました。

１２Ｖの三端子レギュレータは、入力電圧が、１２Ｖより０．６Ｖ高ければ
ＯＫということだったので、助かりました。

実際には、重機に搭載されているバッテリーを使いますが、
バッテリーから直接の電圧だと、ちょっと問題があるなと思っていて
いいものがあるかどうかを探していました。

１Ａまで流せれば、今回は問題ありません。

数日停止していました

数日間、家のほうの仕事をしていて、本来の
コンピュータ関連の作業ができていませんでしたが
月曜日、集中して、エクセルのプログラムを作って
いました。

ある程度、カタチになってきたと思います。

次はアンドロイドも思い出すこと。

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

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

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

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

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

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

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

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

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

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

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

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

２箇所同時に読み取る。

テスト完了です。

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

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

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

今現在、スレッドを使って、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"が送信されたら、
マイコン側のＬＥＤを点灯させる。という
プログラムを作成して、マイコンに送られて
くるコードを識別していることと、
マイコン側に、コード（データ）が到達していると
いう確認ができるように。

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

苦手意識を克服したいんだけどなあ

時期的なものもあるのかも知れませんが、
自分が「まずいなあ」と思えるときというのは

やらないといけないことが、徐々にたまってきて
どうしようと思っている間に、もっとたまってくる。

このパターンなのかなと思えます。

気持ちを切り替えるのって、
ときどき難しいなと思えます。

まず、マイコン側通信のプログラム確認完了

有線（ＲＳ−２３２Ｃ）での
パソコンとマイコンの間に通信は
できることを確認しました。

マイコン側、プログラムで、一番基本の
データ受信、データ送信のプログラムの
テストが完了。

次は、マイコン側にブルートゥースモジュールを
つけて、無線で通信ができることを、確認することに
なります。

間接的にお客様のチカラも借りる

まだ、自分では持っていないんですが
複数のお客様のところで、Windows7を
少しずつ使わせてもらう機会があり、
操作にもだいぶなれてきましたし、

ある意味で、プログラムのWin7での動作確認も
させてもらえています。

間接的にお客様のチカラも借りることが
後々、助けになってくるだろうなと思っています。

マイコン側の開発環境確認

かなりてこずってしまったですが
マイコン側の開発環境の確認が
ようやくできました。

緑色のＬＥＤが１つ点灯しているので
プログラムが作成できて、正常に
動いたという証拠になります。

まあ、これは初歩の初歩なので、これからです。

以前に作っていたサンプルで、動作しなかったので、
おかしな？と思って、それで時間がかかったんですが
要するに、使ったサンプルが、動作しない未完成のものを
使ってしまったというだけのようで、もう少し別のサンプルを
試すべきでした。

まあ、開発環境のインストール、およびプログラムの作成
コンパイル方法、プログラムの書き込み。
すべて今回セットアップしたもので、確認できたので、
ＯＫとします。

実感

ここにきて、アンドロイド、i-pad関連で
こんなことできないかな？という問い泡ｓが
立て続けにきました。

実作業ではなく、問い合わせでではありますが、

なんとなく、ニュースと連動して、皆さんの関心が

パソコンから、スマホ、もしくはタブレットに
移ってきているなというのを実感しています。

現時点での、自分の方向性は間違っていないなというのを
感じました。

まだ、実績がありませんが、必ず、お役に立てるものを
提供します。そう思っています。

バタバタ

今日は、なんやかんやバタバタしてました。

基板の配置について

３つの基板を、２５０×２００×１００の箱の中に
配置するのに、どうしようかなと思っています。




一応、同じ面に配置しても収まるのですが、
あと、端子台が、１６端子×２つつけようとしています。

箱の中に、プラ板を置き、それをベースにしようと
思っているのですが、
端子台を浮かすために、５０ｍｍほどベースを浮かす
必要があります。

面積節約を考えて、ベースの表面、裏面に両方基板を
配置しても問題ないだろうか？　そんなことを考え中です。




写真の中の、３つの基板の、左の１つが、電源基板になるんですが

基板をベースの両面に配置する場合、私としては、電源基板を、
裏面に配置して、箱のふたを開けたときに、マイコンの基板と
Bluetoothの基板がすぐ見えるようにしたいところですが、

マイコンや、Bluetoothの下に電源を持っていったら、もしかして
熱の問題が出てくるかもしれないなと思い、だとしたら、
表面に電源、裏面にマイコン基板とBluetoothの基板ということに
したほうがいいだろうか？

箱は固定するかどうかは、使う側しだいですが、写真の箱の
寸法の書いてある面に、スイッチとかＬＥＤがつくので、
普通に考えれば、ベースの表面が上、ベースの裏面が下に
なります。

結論を近いうちに出します。

テスターと、ルーペのおかげ

Bluetoothモジュールを動くように、
ハンダ付けして、テストしました。

ハンダ付けは上手ではないので時間は
かかりましたが、何とか動作確認まで
できました。

最初、TeraTermでの表示が変わっていたので
ビックリしました。バージョンが３まであがって
いました。

それでコマンドを受け付けないので、何か仕様変更
されたかなと思い、ネットからマニュアルを探して
内容を見たりしました。

結局、１箇所ハンダ付け不良があったので、
表示はするけど、コマンドを受け付けない。
ということになってしまってました。

電源を入れる前に、一通りチェックしたんですけど
見落としがありました。

テスターと、ルーペのおかげです。

本当は、ブルートゥースモジュールの小さな基板は
表裏逆なんですけど（たぶん）ここのハンダ付けが
一番苦労するところで、ハンダ不良も、ここに１箇所
ありました。

間隔が普通の基板の間隔より狭く、なおかつ、ハンダの付く
面積が少ないんです、下手なことしてると、半田付けの部分が
はがれ、はがれたら、修復がたぶんできない。

いまどき、手配線も珍しいかもしれませんが、
手配線の場合、モノがコンパクトすぎても、ちょっと困ると
言うのが正直な気持ちです。