HOME >> 鉄道模型実験室 > SLの動輪の動きを捕えよう その２
鉄道模型実験室 SLの動輪の動きを捕えよう その２
■ いきさつ
ともかくも、測定車両からはクロスヘッドの動きを示すパルスを発信させることが出来たのので、今度は測定台の上で走行させる事にしよう。 しかし、ここでも失敗の罠が待ち受けていたのである。
■ 性能測定台での走行実験
性能測定台では、試験車両にセンサユニットを装着した動力車と、測定ユニットを乗せた測定車を連結させ走行させる。 車両はKATOのC55-62号機である。
.
◆ サテライト・ユニットが反応しない！
追加新設したサテライト・ユニットのピンヘッダにジャンパーピンを挿入し、赤外線受光モジュールの出力をトランジスタのベース入力に短絡させる。 即ち、赤外線受光モジュールの出力は、カウンタＩＣをスルーさせてトランジスタを介してArduino に送信させるのである。 （この状態のユニットについては、撮影を忘れたため写真はありません。）
各部をセットして試験車両を走行させたが、最初のトラブルに遭遇する。 赤外線通信を受け取るサテライト・ユニットが反応しない（ ＝LED類がまったく点灯しない ）のである。 出力状態を表示する橙色のLEDだけは点灯するものと思い込んでいたため、サテライト・ユニットが機能していないと早合点してしまったのである。
そこで、ジャンパーピンを取り去り、カウンタＩＣ のQ1ポートからトランジスタのベース入力回路をクリップ付きコードで右の写真のように結んで見た。 すると、橙色のLEDは無事に点灯を始めたのである。 これは、赤外線受光モジュールの出力パワーが小さいため、うしろの回路が駆動出来ないと考え、それならばIC 回路の増幅機能を利用すれば良いと単純に考えたのである。
このレポートを作成しながらその原因を考えていたが、二つのミスに気が付いた。 一つは、LEDは点灯していないけれど、トランジスタを介して増幅された信号は、Arduino には正しく信号を送信していたはずで、サテライト・ユニットとしては問題無く作動していたものと推察する。 未確認であった。
改めて赤外線受光モジュールのカタログよりその出力回路を見ると、22KΩの抵抗からなるプルアップ回路となっていた。 左の図参照。 電源電圧を5Volt とし、トランジスタを単純化してスイッチのように考えると、カウンタＩＣ のCLK 端子では、最大でも 0.22 ボルトにしかならない。 これではカウンタIC を駆動させる事は出来ないであろう。
しかし、トランジスタには電流は流れていたはずでなので、Arduino には送信されていたはずである。 電気回路は難しいですね。 しかし、考えると面白ですね。
二つ目のミスは、Q1ポートから信号を取りだしたので、パルスカウントが一段遅くなっている事に気が付かなかったことである。 一回目の赤外線受光モジュールからの出力パルスで、一段目のフリップフロップ(FF)回路は ON 状態になり、二回目のパルスで、FFはOFF になる動作を繰り返してカウントして行くはずである。 従ってQ1ポートのパルス出力のタイムチャートを考えると、サイクルタイムは半分になるはずである・・・・・・・・・・。 ここから信号を取り出してはダメなのだ・・・・・・・！。
この結果は、後ほど考察しよう。
◆ サテライト・ユニットが自己発振してしまう！
ミスはさておいて、やっとLEDが点灯し始めたので、テストを始めたが、どうも様子がおかしいのである。 LEDの点灯がランダムなのである。 オシロを持ち出して端子をいろいろな部分に取り付けて観察したが良くわからなかった。 その時の状態を下左の写真に示す。
そこで、動力車の電源をOFFにして車両の走行を止めてみた。 しかし、LEDは相変わらずパカパカしているし、前回のレポートに紹介した測定ユニットが悪いのではと思って測定ユニットの電源もOFF にしたのだが、無情にもLEDはパカパカ点滅している状態であった。
そこで、ジャンパーピンでの短絡をやめ、DIPスイッチを使ってQ11 にセットし、Q1の信号をオシロに取込んで観察してみることにした。 この状態を右のビデオで紹介しよう。 Q1の波形を観察すると、パルスを発信している事が確認出来る。 測定ユニットからは信号を発信していないのに、サテライト・ユニットは反応している。 どこからか赤外線信号が発信されているのだろうか？ 使用しているセンサはリモコン受信センサなので、単なる赤外線ノイズは反応しないはずである。 38Kのキャリア波に搬送させる必要があるのである。 しからば、どこかでリモコン信号を連続的に送信されているのだろうか？
それも考え難いので、サテライト・ユニットの内部回路のどこかに発振回路が形成されて、自己発振しているとしかおもえないのである。 こうなるとお手上げの状態であるが、そこは粘りのMT君である。 Arduio の電源ノイズを疑って、安定化電源を持ち出した。
◆ 安定化電源を使ってみる
まずは、その結果のビデオを紹介しよう。 下のビデオ２に示す。
いろいろテストした結果なので、上記の状態と状態は変わっているが、正常と思われる（？）パルスが出ている事が分かる。 測定用のArduino は停止させ、サテライト・ユニットには安定化電源から５ボルトを供給している。 動力車はTOMIXのN-401を使用して走行させている。 サテライト・ユニットでは、カウンタＩＣ のQ1ポートとトランジスタのベース入力回路をクリップ付きコードで結んでいる。 そしてサテライト・ユニットの供給電圧をCH1に、出力端子をCH2 にオシロにつないで観察した。
勿論、動力車を停止させるとパルス信号は停止した状態で静かに待機していた。 前のようにLEDのランダム点灯は見られなかった。 原因もわからないまま、この様な対応でなぜ落ち着くのかも理解出来ていない。 しかし、効果はありそうである。
◆ 平滑回路を作ってみよう
.
サテライト・ユニットのための安定した電源として、Arduino の電源から自己流の平滑回路を作って見た。 コンデンサは手持ちの 100μFと 10μFのものを使い、抵抗は出力電圧を測定しながら選定した結果、5.6ボルトだったので 1.8KΩと決めた。 その回路を右に示す。
今度は、サテライト・ユニットは正常に作動しているように見えたので、試しにデータを測定してみることにした。
◆ データの測定
まず、シリアルモニタで送信されてきたデータを観察した。 そのデータを見るとモータ電圧は正常に送られてくるが、クロスヘッドのサイクル時間は “０” であった。
LEDは点滅しているので、サテライト・ユニットからは送信されているはずであると考え、Arduino のスケッチを疑って見た。 まず、実施していた割り込み処理の中止部分を疑ってみた。 出力処理中に割り込みが入ったら時間データの順番が狂ってしまうと思って挿入していた命令である
noInterrupts(); // 割り込みを無効にする
******* 出力処理 ***********
interrupts() ; //割り込みを有効にする
この処理を無効にしてみた。 すると、時間データを送信するようになったが、へんな配慮は、いらぬお世話であったようである。
--------- New_Keninryoku_test6.1 ------- **************** 省略 **********// 割り込み処理 void cros_count() { Tn2 = millis(); ts = Tn2 - Tn1 ; Tn1 = Tn2; cros_n = cros_n + 1; if (cros_n > 5) { cros_n = 0; } cros_data[cros_n] = ts; } **************** 省略 ****************
送られてきたデータは、EXCEL を使って加工しグラフ化しているが、今回もEXCEL のデータ処理の一部を修正してクロスヘッドのサイクル時間をグラフ化してみた。 左のグラフを参照。
期待して表示してみたが、やはり裏切られてしまった。
横軸は送信されてきた順番を示しているが、サイクル時間の平均値 ts [ msec ] はバラバラであった。 これでは使い物にならないのである。
そこで、ひとつずつのサイクル時間データを知りたくなったのでスケッチを修正した。
それは、パルスひとつずつの間隔を割り込み処理のなかで計算させ、６個の配列に順番に入れ込み、最後にそれらのデータをまとめて送信するようにしたのである。 右のスケッチは、その割り込み処理の部分だけを示す。
.
◆ データの検証
そして、修正したスケッチを使ってデータを取って見た。 その時のシリアルモニタの一部の画面を右に示す。 データ終了を示すE の前の６個のデータが ts データである。 各パルスのサイクル時間 ts を正確に送ってきている事が分かるが、その値はやはりバラバラである。
そしてこの時のデータをグラフ化したものを下に示す。 ６個のデータを個別に表示させると共に、EXCEL上で計算したその平均値も表示する。 さらに、このサイクルタイムから計算されたスリップ率も計算してみた。
この測定ではカウンタＩＣ のQ1ポートと、トランジスタのベース入力回路をクリップ付きコードで接続した状態で測定しているので、パルス出力は半分になるはずであるが、ここではまだ、その考えは頭になかったので、パルスサイクル＝クロスヘッドサイクルと思い込んで計算している。
左側の二つのグラフを見ていても良くわからないので、少しグラフを工夫することにした。 それは、測定したデータには車両のスケールスピードのデータがあるので、この値からスリップ率ゼロの場合のクロスヘッドのサイクルタイムを逆算して測定データと比較してみた。
スケールスピードを V (km/h) 、動輪の直径を D (mm) とすると、サイクルタイム ts (msec) は、Ｎゲージの場合 ts = πD×540÷V で計算される。 このC55-62号機の場合は、D = φ12.0mm であったので ts = 20359/V となる。 この特性曲線について、横軸をスケールスピードにしすると共に、サイクルタイムのデータに重ねてグラフ化してみた。 そのグラフを上右に示す。 測定されたサイクルタイムのデータは、特性曲線に沿ってプロットされるものと、下のほうに群がっているものに分別されている。
このように、ts の測定値は、計算値と合致しているものが散見されるものの、多くの場合はそれよりも小さい値を示している。 このことより、
- パルスサイクル＝クロスヘッドサイクルと思い込んで計算しているが、正解ではないだろうか。
- 計算した曲線よりも小さいことは、途中に余分なパルスが入って来て、サイクルタイムを短く測定している事を示唆していると思われる。
- 計算した曲線よりも大きなパルスが殆ど無い事は、正しいパルスは確実に発信されており、抜け落ちることは無いものと考えられる。
- これだけバラツキの大きなデータは、やはり使いものにならない事ははっきりしていると言えよう。
- さらに原因不明の自己発振の影響があるかもしれないし・・・・・・・・。
.
などの考察を引き出すことが出来る。
******************************
“Q1ポートのパルスを使用した場合、パルスサイクル＝クロスヘッドサイクルではない！” という点について、どうしても気になったので、 カウンタICのデータシートを見てみた。
このカウンタは TEXAS Ins.社の CD74HC4020E 14ステージ・バイナリカウンタを使用した。 そのロジックダイアグラムの一部を右に示す。 CP端子から入力されたパルスを何段にも連結されたFFでパルスをカウントして行くものと理解しているが、問題のQ1端子には、ドット記号が付いて、“ Q1' ”と表現されており、取り出し口も、
“ Q' ” と他にはないポートから引き出されている。 通常の出力ポートではない事を示しているが、これ以上調べる方法が無い。
メーカーに問い合わせる？ 程の重要問題でないので、“ Q1' ”ポートは特殊なポートのようであると理解しておこう。 そして、もしかして CPポートと同期した出力を出すポートではないかと勝手に解釈しておこう。 今後もこのポートを使用することは無いだろうと思っているかである。
■ まとめ
ここまで四苦八苦して、SLの動輪の動きを捕えよう と意気込んできたが、結果として失敗であると結論することにした。
その原因として、パルス間隔の時間から速度を割り出そうとするロジックは、ノイズに弱いということである。 途中で外乱が入ってしまうと、それを外乱と認識する方法が無ければ正規のパルスとして認識してしまうのである。
今まで実施してきた一定のパルスを数えてその時間を計測する方法は、外乱によってカウント数が狂って来るものの、その影響が小さいのである。 モータの回転数を検知する方法と、今回の方法との影響度は、一個の外乱パルスに対する影響度は、ギヤ比×２倍の40〜50倍も影響度が違うのである。 リモコン（赤外線）受光モジュールのカタログ説明書では、
リモコン受光モジュール出力信号処理の受信判定について、単発パルスで受信判定すような処理を行うと周辺のノイズ源等の影響により誤動作する可能性があります。 誤動作防止のため、必ずリーダー信号を含むコード化されたパルス列による受信判定を行って下さい。
と注記されています。 この注記の内容を身に浸みて感じた次第である。
我が自動測定では、車両の速度をゲート通過時間で測定しているが、この方法ではノイズは少なく、精度良く測定出来ている。 しかし、今回の方法では赤外線通信というノイズだらけの手段を使い、さらにノイズに弱いロジックを採用したことが、失敗の要因であると結論付けたのである。
でも、いろいろ勉強になりました。 そして、赤外線通信の様子をさらに調べたくて、このサテライト・ユニット単品をいろいろ調べてみる事にした。 次回はその内容を報告しよう。
なお、 SLの動輪の動きを捕えよう との意気込みについては、小型のフォトリフレクタを手に入れたので、ノイズに強い電気機関車と同様な方法で検討する予定である。