開発ノート ⁽⁹¹⁾

XBeeモジュールを透過モードで使っていてどうにも使い勝手が悪いので、APIモードに挑戦することにしました。が、至近距離でのデータ送受信なのにレスポンスコードが返ってこない。どうしてだろうと色々試していたら、MCUとXBee間の通信速度を115200bpsから57600bpsにすると劇的に改善されました。透過モードの時にエラーが多かったのもこれが原因だったのかもしれません。

かわっちタイマーはバイクジムカーナ向け、タイム計測システムです。この文書はかわっちタイマーのハードウェアの設計、実装についてのメモです。 - 回路設計 - 電源５Ｖの電源はモバイルバッテリーから既に供給されているため、作成が不要です。モバイルバッテリーからRaspberryPiに入れて、PiのEXTから取り出します。Piの電源回路が弱いため本来はEXTに行くラインにバッテリーを接続したいのですが、そうすると保護回路（ポリスイッチ）をショートカットしてしまうので、電源保護に不安がのこります。ただ実際に接続してみると、ＵＳＢ接続機器が電源が原因のようにみえる動作不安定が生じている様に見えます。そこで止む得ませんので、EXTラインに直接接続する形にします（ただし未実装）。またここからＵＳＢの電源に直接配線を引っ張って電流容量を確保します。使用しているAnkerのバッテリーに過電流保護回路が付いているっぽいので、本来望ましくはないですが、保護はこれのみで妥協します。１２Ｖの回路は電源モジュールに直接配線しているだけですので回路図は割愛します。このモジュールは出力電圧可変式ですので、ＤＭＭで電圧を調整しました。よくよく考えてみると、電圧は１２Ｖ以上であればよく、１２Ｖである必要は無いのですが、システム全体の効率からは１２Ｖが良さそうなので、１２Ｖに設定しました。 - ブザーインダクタを使って昇圧する回路です。防犯ブザーで用いられているものと同じだと思います。容量と許容電流量が大きなインダクタを用いないと、音量が確保できないので、電子部品店を回って一番大きなものを購入しました。最初はデジタルトランジスタを使って試作しましたが、どうにも音量が出ないので、ダーリントントランジスタに変えたところ、満足な音量を得ることができました。音量切り替えは使用するインダクタの数を変更する回路にする予定でしたが、トランジスタへのベース電流を変化させて行う方式に変更しました。普通はボリューム抵抗を使うと思いますが、無段階切り替えよりも室内用、屋外用、バイクの側用といった切り替えの方が便利なように思いましたので、3接点スイッチを使って切り替える方式にしました。実際の使用電流量を計測してみると（普通のＤＭＭなのでパルスのへ平均が出ていると思います）、図に記載した通りの電流となり、許容可能な電流値となりました。 - 光電スイッチは１２Ｖで駆動していますので、電圧をPiの側のトレラント電圧とスレショールド電圧に合うように変圧する必要があります。動作速度を考えると、１２Ｖ入力３．３Ｖ出力のバッファＩＣを利用するのが望ましいですが、そういった製品がなかなか見あたらない、あってもパッケージの変換が必要でしたので利用は断念し、単純に抵抗分圧で電圧を変化させました。電流量が減りますので、スイッチングが若干遅延しますが、計算してみたところマイクロセコンド単位でしたし、スタートとゴールで同じ時間ずつ遅延し、電源電圧が同じである限りはばらつきが無いので、計測精度への悪影響は無いと判断しました。抵抗分圧で行う場合、スイッチングのオンオフにかかわらず電流を消費します。そこでスイッチングスピードに影響を与えない範囲で大きめの抵抗を使用しました。 - LED大電流のスイッチングが必要なので、本来はリレーやスイッチング用の素子が必要です。もっとも今回使用するＬＥＤドライバはスイッチング用のコントロールが付いていて、ＰＷＭ調光ができるぐらいの周波数にも対応します。そこで素直にこの端子を使用する事にします。ただし12V系の回路にマイコンを直接接続するのは怖いので（何かの拍子に12Vが流れると一瞬で破壊しそう）、フォトカプラを使って絶縁します。Piの出力電流には余裕が無いので、ドライブできる範囲でできるだけ大きめの抵抗を使用しました。このドライバモジュールはモジュール上の半固定抵抗で光量が調整できます。各色の輝度が同じぐらいになるように、自分の感覚と、iPhoneアプリの照度計で調整をしました。 - プッシュスイッチチャタリングの除去をソフトウェアで行うとCPU側の負担が増えるので、回路側でチャタリング波形の除去を行います。立ち上がりと立ち下がりのチャタリング両方を除去しようとすると、回路図用に抵抗2本とコンデンサ1つが必要です。スイッチがノーマリーオフなので、プルダウンしておいて、スイッチオン時以外は電流を消費させないようにしました。かなり大きめのコンデンサを用いないとチャタリングの吸収ができませんでしたので、1.5uFの積層セラミックコンデンサを使用しました。波形を見た限りではチャタリングを除去できていたように見えたのですが、Piに投げてみると、それでもチャタリングが出ました。オンの遅延を考慮せずもっとなめらかな波形になる定数を選択した方がよかったと思います。 - ハードウェアの制作 - pipiはタイプAとタイプＢがありますが、イーサネットコントローラが電力を食いそうなので、タイプAを採用予定でした。が、タイプAはUSBポートが一つしか無いので、アクセスポイント用に無線ＬＡＮ子機を挿すと、インターネットにアクセスできません。インターネットにアクスできないと、aptやnpmが使えないので、インストールで苦労します。そこで一通りの形ができあがるまではタイプBを使用する事にし、必要に応じてタイプAを使うことにしました。piはそのままでは筐体への固定ができませんので、一旦市販のケースに入れて、それからビスで固定しています。アクセスポイント化する場合には、使用する無線LANチップが限定されますので、実績のあるものを選びます。最初に別の製品を使用した際には接続不可でした。 - 基板プリント基板を起こすと制作や再製作が楽ですが、一点もののために作るのはコストが合いませんので、ユニバーサル基板で作成しました。piとの接続はスマートさを重視してフラットケーブルです。コンパクトに収めようと思うとある程度計画性をもって制作しないといけませんので、使用するユニバーサル基板のコピーを取ってから、配置のイメージを描いてみました。また個々の回路についても、できるだけコンパクトで配線が楽な配置を予め考えておいて、それから実際に実装をしました。 - 電源 モバイルバッテリーそのままです。基板上にはストリナさんの昇圧モジュールを入れます。 - 筐体 タカチの防水型ケースを使用しました。蓋がポリカーボネートですので、中身がそのまま確認できます。内部は２階建て構造で、底にユニバーサル基板、見える部分にマーカーレンズを付けたLED、pi、モバイルバッテリーを配置しています。加工はプッシュスイッチとコネクタ用の穴開けだけですが、サイズを注意しないと防水性が失われるので、リーマーで注意しながら穴を広げました。背面はVESAマウントサイズの穴を開けたので、汎用のVESAスタンドを使用できます。 - 光電スイッチ オムロンの製品を使用します（E3JK-RN12）。特に加工はありません。防水性を確保するためケーブルの先端には七星科学のNJW(http://www.nanabosi.co.jp/connector/njw.html)シリーズを接続しました。業務用っぽいですが、マルツや共立で入手できました。オムロン純正のマウント金具を介して、卓上三脚で自立させています。三脚のネジはインチサイズで使いにくいので、Eリングをはずして、ミリねじと蝶ねじ、蝶ナットに交換しました。反射板側はマウントの穴の位置が合いませんでしたので、三脚のベース部分に穴を開けて、ミリねじの蝶ねじ、蝶ナットで固定しました。抵抗3本の配置はパズル的です。設定は感度はほぼ最大、オンオフはノーマリーオフです。 - 液晶I2C規格は本来は基板上といった狭い範囲での情報伝送を想定したものですので、ケーブルでの信号伝送には向いていません。piのプルアップ抵抗が小さめなので(1kしかない)、信号線の長さの波形への悪影響は小さいと思われますが、短いにこしたことは無いでしょう。ただし液晶のドライブ回路の容量が小さいようですので、本来はpiとストリナの液晶は相性が悪いと思います。piのプルアップ抵抗値を大きくしたいのですが、基板上のチップ抵抗を変更するのは大変なので止めておきました。単にチップを外して外側の回路で抵抗を付けるのは簡単なので、液晶のトラブルが続くようであれば試してみます。 - シリアルモニターをつなげずに開発していると、接続設定に失敗すると永遠にログイン不可になりかねません。そこでもしもの時のために、シリアルピンをアクセスしやすいところに引き出しておきました。 - ブザー基板上 回路図の通り組むだけです。ブザー本体は大きいものがなかなか手に入らなかったので、秋月の大音量ブザーを分解して、自励回路部分を除いて、ブザーとケーシングを利用しました。本来防水性は無いのですが、少しでも耐久性を高めるため、筐体の下部に下向きに取り付けました。そのまま取り付けると筐体全部が振動しそうなので、スポンジゴムを介してフローティングマウントしています。 - スイッチ 普通に付けるだけですが、防水スイッチなので、ねじ込みのトルクは強めにしています。LED、ブザー、スイッチはいずれも、細めのケーブルで引っ張って、QIコネクタで基板上のピンに挿しています。回路部分は受動素子3点だけですので簡単です。 - ＲＦＩＤリーダ USB接続ですのでそのままつなげるだけですが、消費電力が多そうなので、三つ叉になっている電源供給コネクタ付きＵＳＢホストケーブルを使用しています。血走ったライダーがフルパワーでタッチするとすぐに壊れてしまいそうですので、ＦＲＰ板の裏側に配置して、ＦＲＰ板にはタッチ位置のピクトグラムを描きました。ＲＦＩＤリーダはタブレットと組み合わせて、ブーム付きのマイクスタンドに取り付けています。これは「バイクに乗車したまま、左手でクラッチを握ったまま、右手で手を伸ばして届く範囲」という制約があるためです。サウンドハウスでＫ＆Ｎのスタンドが安価で販売されていますので、これを利用しました。値段の割には、重量感があって、しっかりしています。実際に設置する際には、マイクスタンドの足にタイヤをかぶせて安定させています。カードには番号を振ってあり、固定番号と対応させたテーブルを保持しています。 - タブレット 「USB以外から充電できる」という仕様はかなり珍しく、新品での入手可能な製品が中華パッドしかなかったため、原道双撃となりました。背面にマグネットシートを貼って、マウントに磁力で固定します。強力タイプを使用したので、タブレットの重量を保持するには十分な吸着力です。 -…

XBeeのAPIモードのパケットをCでデコード。既存のライブラリがあったんですがブロッキングioだったので使い勝手が悪い。書き換えるなら最初から書いた方が早そうなので。で、今度はこれをVBAに移植。ニーズは少なそうですが公開しようかな。

Unityを始めました。独特の流儀が多いのですが、普段組み込みばかりやっていると新鮮ですね。オブジェクトのキューが組み込み型にあるという時点で感動しています。さてプログラムを作成していて、あるメソッドで値を代入したクラスのインスタンスフィールドが、他のメソッドから参照できない、というか見れるけれども初期値になっていて代入の結果が反映されていないという問題が発生しました。何じゃそりゃと悩んでいたのですが、原因は極基本的な所にありました。バグの解析の最中にその変数をStaticにすると他のメソッドからも参照できたのですが、「インスタンスフィールドなんだからstaticにしようがしまいが関係無いはずでしょ」とうんうん悩んでました。ただこれも分かってみると納得。作業としては、Unityでユーティリティアプリを作ろうとしていて、画面の描画されるオブジェクトとは関係無く一定のロジックを回したいので、HierarchyにEmpty Objectを作り、そこにC#スクリプト(Main.cs)をアタッチしてロジックを作っていました。このスクリプト（クラス）のあるメソッドでインスタンスフィールドを設定したら、Main.csの同じクラス内のインスタンスフィールドから見られないという状態になっていたのです。原因は、GUIに設定したボタンへのスクリプトのアタッチでした。UIのボタンが押されたときに簡単に処理できるように、そのボタンにもMain.csをアタッチしていました。こうするとボタンのクリックイベントからMain.csのメソッドを呼べるので簡単だろうという判断からです。が、これが間違いの始まりでした。オブジェクトにアタッチされたクラスは、それぞれのアタッチ先のオブジェクト毎にインスタンス化されるので、Empty Objectとボタンにそれぞれアタッチされたスクリプトで、別のインスタンスが生成されていることが分かりました。まだGameObjectの仕組みをあまり理解できていないのですが、概ねそんなところだと理解しています。試しに新しいプロジェクトで以下のスクリプトをEmptyとボタン２個にそれぞれアタッチしたところ、それぞれのインスタンス他それぞれStart()を実行し、自分のアタッチ先のGameObject名を出力しました。staticな変数が２個目のインスタンスでは初期化されないことも確認でき、２個目のインスタンスのstart()ではその前のインスタンスで設定された内容が表示されます。インスタンスが３つあるのでUpdateも別々に回っていて、それぞれがDebug.logを実行しています。publicにしたプロパティはインスペクター上でそれぞれ違う値を設定でき、その値が動作に反映されました。 ここで他のメソッドから参照している変数は、メソッド内のローカル変数ではなくクラスのフィールドです。インスタンスフィールドは各コンポーネントのインスタンスごとに保持され、staticフィールドはクラスに属します。同じスクリプトを複数オブジェクトにアタッチすると、通常は別のコンポーネントインスタンスとなる、という発見が本稿の要点です。

僕の本（ホームページ？）をみたＭさんという方から以下の質問をいただきました。初心者の方で同様の疑問を抱く方がいらっしゃるかも知れないと思いましたので、回答を公開しておきたいと思います。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝始めまして。お世話になります。 電子回路初心者です。東京コスモスのＴＷＥ-Lite Dipの出力（4mA以下？)をフォトカプラでON/OFFしたく、TLP521-4を購入したのですが、データシートではIFが50ｍAとなっております。管理者様の回路図を見ると3.3Vで680Ω＝約5ｍAになると思いますが、このTLP521は最低、何ｍAから確実な動作が出来るのでしょうか？私がデータシートの素人読み込みで50ｍA必要と思い込んでいたのでしょうか？仮に、5ｍAでもOKなら2～3ｍAでもいけますか？宜しくお願いいたします。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝Ｍさん、こんにちは。正直なところアナログ回路はあまり得意では無いのですが、わかる範囲で回答をさせていただきます。ご質問の件については、基準と視点を変えることが必要だと思います。ＴＬＰ５２１の「５０ｍＡ」という数字は、「絶対定格」に記載されている電流だと思います。絶対定格は、素子の動作条件ではなく、その素子の使用条件として、「絶対に超えてはいけない条件」を意味します。この条件を超えてしまったときには、その素子が壊れるかも知れないし、もしかすると発火して家を焼くかも知れない、そうなってもメーカーとしては知らないよ、責任持てません、という意味で「絶対」なのです。５０ｍＡちょうどであれば、いちおう絶対定格の範囲内ではあります。ただ、電源電圧が変動したり、電流制限抵抗の値が温度で変動したり、内部のＬＥＤのＶＦのばらつきなどにより、いつこの絶対定格を超えてしまうかわかりません。ですので、設計をするときには、不確定要因の変更を見込んだ上で、「絶対」に「絶対定格」を超えない電圧や電流を設定します。次にＬＥＤに何ｍＡ流したらよいのかということですが、これは「Ｍさんで無いとわからない」というのが結論になります。というのも、フォトカプラのＬＥＤに何ｍＡ流したらいいかは、フォトカプラのトランジスタに何ｍＡ流したいかで決まるからです。フォトカプラを使うということは、トランジスタでスイッチングしたい回路がその先にあるのだと思います。それはどういった回路でしょうか。通常のＬＥＤであれば数ｍＡでしょう。デジタル系でプルアップ抵抗につなげるだけなら１ｍＡいかでしょうね。フォトカプラのトランジスタ側は、フォトトランジスタであるとはいえ、振る舞いはトランジスタなので、ベース電流の代わりである、受光量に応じて、コレクタからエミッタに流れる電流が変わります。つまり流したい電流に応じて、ＬＥＤの発光量を変えるということです。ＴＬＰ５２１のデータシートの後ろの方を見てもらうと、縦軸がコレクタ電流、横軸が入力電流になっているグラフがあると思います。性能の悪いサンプルＢで考えるとして、コレクタ電流に１０ｍＡ流したいのであれば、入力電流として１０ｍＡぐらいが必要なのがわかります。コレクタ電流として１ｍＡぐらいが欲しいのであれば、入力電流３ｍＡ程度という見積りはグラフ上の参考値にすぎず、確実な動作を保証する値ではありません。ちなみにですが、このデータシートからすると、ＴＬＰ５２１のコレクタ電流は、絶対定格も考えると、３０ｍＡぐらいが限界という感じがします。だんだんカーブが緩やかになって、入力電流を増やしてもコレクタ電流を増やせなくなってますね。ですので、もし、もっとコレクタ電流を流したいという状況なのであれば、後ろに更にトランジスタをつなげるとか、最初からダーリントン出力のフォトカプラを使うといった工夫が必要になるでしょう。そうすれば発光側への入力電流も減らせますから、ＴＷＥの負担も小さくなります。 LED電流は電源電圧を抵抗だけで割るのではなく、IF = (出力電圧 − LEDの順方向電圧VF) / 抵抗値 で見積もります。例えば出力3.3V、VFを仮に1.2V、680Ωとすれば約3.1mAです。VF、GPIOの出力電圧、抵抗のばらつきを見込みます。必要な入力電流は出力側に必要な電流とCTRから見積もりますが、グラフの典型特性と保証された最小CTR・飽和電圧の条件は別です。2～3mAでの動作を保証できるかは、その入力電流・温度・経年変化を含む仕様で確認します。