intercomインターホンからの通知をインターネット越しに受け取りたい。最近のインターホンではスマホアプリと連携するようなものもあるようですが、自宅のインターホンでは対応していません。ところで、AIPH〇NEのプロトコルに関する追試ではインターホン室内端末のLCDはNTSCの信号を表示しているという夢を見ました。いうことでやってみました。NTSCの分岐(回路編)まず、NTSC信号の分岐についてです。単純に信号線を分岐させるとこんな感じ1になります。NTSC信号の分岐(単純)もともと受信回路1(既存)だけに繋がっていた信号線を分岐させて、SWを経由して受信回路2(増設)に繋ぐ感じです。それぞれの受信回路内では、NTSCの特性インピーダンスに合わせて75Ωの終端抵抗が存在します。受信回路の(Rと75Ωにより分圧された)入力電圧は1Vp-pの想定です。ここで、SWを閉じる(受信回路2を繋ぐ)と各受信回路内の終端抵抗が合成され、75Ωにはなりません。これによってインピーダンスマッチングがうまくいかなくなる、またRとの分圧比が変わるため受信回路に入力される信号レベルが下がります。受信回路2の抵抗2を外してしまうか、というのは今回の用途以外で使えなくなるので避けたい。するかというと、分岐(正確には分配)させるときは一度終端し、受信回路ごとにアンプで受けてそこから流す構成とするようです。具体的にはこんな感じに。NTSC信号の分岐(分配)これなら問題ないですね。どこかの受信回路が繋がっていようといまいと、他の受信回路に影響を与えることはありません3。今回はインターホンに関する信号を扱っています。これを踏まえると、自分で作った回路をインターホンの室内端末側には繋ぎたくありません。回路に問題があって室内端末をぶっ壊しました、というのは避けたいです。「室内端末」であって幹線に何かするわけではない。インターホンシステム全体を壊すことに比べるとマシとはいえ......。そこで、分岐はするが既存の受信回路はそのままにして、増設部分だけアンプを経由して流すようにします。NTSC信号の分岐(令和最新版)これなら既存部分はなるべく触らないので安心です。既存の受信回路を取り外したり(今回の件とは関係なく)何らかの理由で壊れて終端抵抗がかからなくなったりすると、増設側に意図しない電圧がかかる可能性はあります。その結果、増設した受信回路も壊れる懸念はありますが......ここで使うのは後述の$0.99で買ったデバイス。インターホン側のほうが大事です。NTSCの分岐(実装編)先ほどの回路を実装していきます。Pi)からUSB経由でもらいます。ZHコネクタで接続されていることを利用し、コネクタを使って復元可能な形で信号線を分岐させて取り出しました。オペアンプにはNJM2722を使い、これは負電源を必要とするのでそれ用にNJW4191も使います。NJM2722のスルーレートは1000V/us(!)です。今回の用途だとオーバースペックすぎる。75Ωをドライブできるかは分からず4、本当はビデオ用アンプを使ったほうが良かったでしょう。具体的にはNJM2575など。いうかこっちのほうが消費電流も小さいし、単電源で動くし、LPFも入っているし良いような......。今回の実装では手間をかけてビデオ用アンプのLPF抜きを作ったことになってしまった。基板はKiCadで設計しJLCPCBに発注しました。この基板自体はPCBのみ(アセンブリなし)で製造も順調。Latencyのしっぽ側を引いてしまったようで手元に届くまでちょっと時間がかかった。同梱したことで送料を節約できたかというとそうでもなく、これならわざわざまとめて注文を出すよりこまめに出したほうが良かったかも知れない。発注して待っている間に、次の基板を設計した方が効率が良い。TCP_NODELAY付けておきます。この基板に対して実際にNTSCの信号(インターホンとは関係ない)を分岐させた信号を入力し、動作確認をするとこんな感じに。その1C1(黄)が既存の受信回路に入力される信号、C2(ピンク)がオペアンプの出力で増設した受信回路に入力される信号です。分からないので重ねてみます。その2カラーバーストの部分を拡大しました。ピンクは気持ち遅れている程度で、ちゃんと動いていそうですね。これを3Dプリンタで作ったケースに収め、インターホン室内端末の隙間から信号線を這わせて壁に貼り付けました。ケース手前に棚があり、わざわざ覗き込まない限り配線は見えないという想定です。本当は壁の中に通したかったですが、それは難しかった。分岐されてきた信号をCVBSのキャプチャのデバイスでキャプチャします。画面に何か出してキャプチャしてみた画像はこんな感じです。キャプチャ結果(追記)着荷画面も載せちゃおいい感じですね。インターホン室内端末側の画面も問題なく映っています。これを発展させ、最終的にこんなスクリプトを用意し動かしました。fpsで画像を取得し、動画ファイルにするMJPG形式のまま保存。ここでは何もエンコードせず、右から左へ受け流すだけ一定時間続ける。Wで動かしており、できれば負荷をかけたくない。信号チェックの画像取得をYUYV形式で行っているのは伸張せずに済ませたいため。ここではチェックするだけなので低解像度・低fps(320x240/5fps)で十分です。無信号のときは本当に全画素が黒のようで楽に判定できます。この処理にかかるCPU使用率は2%ほど。多少の誤判定リスクを許容して、YUYV形式のまま最初の1画素のYが0か否か判断してもいけそうでした。この場合のCPU使用率は1%ほど。これくらいのCPU使用率なら別に気にしなくても良いと思いますが、無信号か否か判断するだけならハードウェア側でトリガーかけるようにもできましたね。信号が来たら「高解像度・高fps」で録画を開始しますが......実際は640x480/20fpsほどです。これでももうYUYV形式では取得できず、この時点でMJPG形式に切り替えます。この切り替えにかかる時間は300msほど(この間のフレームは欠落)。このときMJPGの取得だけならCPU使用率はまだ余裕がありますが、伸張してしまうとCPU使用率が100%になりまともに処理できません。そこで、ここでは何も触れず、取得したデータはMJPG形式の動画ファイルとして保存しておきます。動画フォーマットとして統一された仕様は無いようでしたが、取得した画像を単純に連結すればいけました5。録画と同時に別スレッドで通知も行います。pluginを経由したHomeKitへの通知です6。WatchやiPhoneなどに通知が来ます。本当は画像とともに通知したかったのですが、これを行うには動画のストリーミングも行う必要がある。それはリソース的に厳しい......ダミーの動画を流すのもなぁ......ということで、代替としてSlackに画像を添付して通知させています。録画が終わると、別スレッドでMJPG形式の動画をH.264形式に変換します。Wに備わるハードウェアエンコーダを使っても実時間に対して0.6倍ほどの速度しか出ません。CPU使用率は100%。ちなみにソフトウェアでエンコードすると実時間に対して0.1倍の速度になってしまいます。いえ、エンコードせずにMJPGのままにすると取り回しが悪くどうしたものか......という感じです。おわりにインターホンの録画と通知を行いました。「録画」と「通知」だけなので、もし外出先でこの通知を受け取っても会話はできず、解錠の操作もできません。通知があると何か面白くて良かった。それはそれとして、こんなことしなくて済むようにスマホアプリ連携のあるインターホンに設備更新してくれ。FootnotesRはインピーダンスマッチングのため75Ωとするのが基本のようですが、簡易的に信号レベルだけ適正にしたい場合は必ずしもそうではなく、ここではRとしています。↩そもそもレシーバICとかに内蔵されていたらどうしよ......と思い、CVBSのキャプチャのデバイスで確認したところ、このデバイスでは外付けの模様。IC側の(データシートは見れませんが)仕様に沿ったものなのか、コスト削減でこうしているのかは不明です。↩では逆に他の受信回路に影響を与える場合は?たとえば、オペアンプ1個だけ用意して受信回路の数だけ前もって増幅しておく......みたいなことをすると、もし受信回路を付け外しした場合に分圧比が変わって他の受信回路に影響を与えます。試した限りだといけましたが......データシートに記載は無いので適正かは分かりません。»あわせて読ませたいCVBSのキャプチャ2024/8/15LinuxからMS210x系デバイスを使ってNTSC信号をキャプチャしますAIPH〇NEのプロトコルに関する追試2024/7/27アイ〇ンのプロトコルに関する先行事例を追試し、制御データと映像のデコードを行います。入門スマートホーム2024/6/12これじゃ本当に丁寧な暮らしだよ目次NTSCの分岐(回路編)NTSCの分岐(実装編)キャプチャ編おわりにFootnotes!!!XGitHubお問い合わせ。