三菱VisiTel：1980年代ズームコミュニケーション

窓の外は2020年です。リモート作業はすでに完全に正常です。大手電気通信会社の何十年にもわたる広告がついに彼らの仕事をしました-私の母にビデオ通話をする方法を教えました。確かに、ビデオ通信への予想外の一般の関心を引き起こしたここ数ヶ月の出来事は、ウェブサイトの前例のない不足につながりました。しかし、これが私たちの通常の生活を妨げることを許すことはできません。結局のところ、私たち一人一人が電話をかけるにはたくさんの人が必要です。ウェブサイトの欠如の問題に対する解決策があります。三菱VisiTelです！

Mitsubishi VisiTel



このデバイスが1988年に導入されたとき、それは間違いなく未来を表しています。そして、その低価格（たったの399ドル）で、どうしてすぐに人気になることができなかったのでしょうか？1988年2月に発行された雑誌PopularMechanicsでは、ページ全体がMitsubishiVisiTelに捧げられました。そこには、予想外に大量の技術的な詳細が記載されたデバイスが説明されていました。そして、のプレゼンターガジェット教祖WSMVテレビチャンネル上では、彼らはVisiTelについて話し始めた直後は、非常に重要な質問質問：「？私はこの事は、回線に接続されている間、通常の電話を使用し続けることができますし」



同僚に電話する前にシャワーを浴びて自分自身を整える必要があるという避けられない事実を最終的に受け入れるには、30年と世界的な大流行が必要でした。さて、誰が何と言おうと、ビデオ電話から逃れることはできません。



VisiTelについて特にキツネのようなものがあると思うのは私が最初ではありません。人々は 長い間 このデバイスをいじくり回してきました。ビデオ信号を送信せず、写真を共有することしかできないという事実にもかかわらず、それはエンジニアリングにおいて優れた成果と見なされている製品の1つです。これは、時代をはるかに超えた開発です。この



後、VisiTelへの興味が現れましたビデオ。その作者は、VisiTelによって送信された画像のキャプチャを遅くしたり速くしたりすることで、画面上の画像を歪める方法を示しました。これを知ってすぐに、デバイスが単純な振幅変調方式を使用していることに気付きました。これを知って、私はeBayに行き、そこでVisiTelの適切なコピーを見つけました。私の目標は、1980年代後半の技術的進歩と、私が選択した最新のテクノロジーを組み合わせて、この驚くべき「タイムカプセル」を機能させることでした。特に、Zoomの同僚とのコミュニケーションを整理したかったのです。さらに、VisiTelハードウェアを変更せずにこれを実現したかったのです。このデバイスには、元の形式のままにしておきたいという特別なものがあります。

ステップ1.接続

VisiTelの実験を開始します



VisiTelは、起動して実行するのが途方もなく簡単です。デバイスの背面から、端に向かってY字型のスプリッター（詳細は以下）と1対のコネクターを備えた長いケーブルが付属しています。そのうちの1つは2.1mmの電源コネクタです。デバイスには15ボルトが必要です。デバイスの開発者が、碑文に「ISボルト」と表示されるようなフォントで15という数字を書くことにしたのは少し奇妙です。 2番目のコネクタは通常のRJ-11で、2つのピンを使用します。これは標準の電話ジャックです。通常の有線電話を覚えている場合は、ハンドセットがRJ-9コネクタを使用してデバイスに接続され、電話がRJ-11コネクタを使用して回線に接続されていることも覚えておくことができます。これは、携帯電話だけでなく、他の何かにも接続できるという意味であり、何かが起こった場合にケーブルやチューブを交換できるようにします。確かに、電話から携帯電話に至るケーブルには、特別で非常に柔軟なワイヤーが製造に使用されていたため、何かが頻繁に起こったとは言えません。





VisiTel





, VisiTel



VisiTelの背面に戻ると、ケーブルに加えて、RJ-11コネクタがあります。なぜ彼がそこに必要なのかをしばらく考えた後、それは私に夜明けしました。このデバイスは、通常の電話セットと電話回線の間の仲介役として機能します。これにより、VisiTelは通常の通話中に回線を監視したり、画像を送信したりできます。これは明らかな問題につながります。つまり、VisiTelは電話と同時に電話回線を使用するため、加入者は画像の送受信に伴う音を聞くことができます。しかし、三菱のエンジニアがそれを処理しました。画像を送受信する前に、大きなカチッという音が聞こえます。これは、リレーによって電話がしばらくオフになっていることを示しています。デバイスから受信したオーディオ信号が気にならないように、VisiTelを使用します。したがって、デバイスの背面にあるRJ-11コネクタには何も接続しません。これにより、対応するリレーが不要になります。つまり、画像の送信に関連するクリックを取り除くために、リレーを削除できます。



このデバイスとのデータ交換を整理するにはどうすればよいですか？たとえば、私のコンピュータにはRJ-11コネクタがありません。確かに、RJ-9コネクタ付きの携帯電話をスマートフォンに接続するためのアダプタが販売されているので、これは怖いことではありません。接続オプションの1つは、RJ-11コネクタを切断し、3.5mmプラグをワイヤにはんだ付けして、モノラルオーディオ伝送を構成できることです。当初、VisiTelにはRJ-11コネクタではなくRJ-9コネクタがあると想定していたことに注意してください。



3.5mmプラグを使用すると、VisiTelをコンピュータに接続するのは非常に簡単です。つまり、マイクとヘッドフォン（TRSSではない）を接続するための個別の出力を備えたUSBアダプターを入手し、VisiTelを適切なコネクターに接続する必要があります。



上で、Y字型スプリッターに戻ると言いました。私のVisiTelは、このスプリッターの周りのワイヤーに何らかの問題がありました。さらに、すべてが単に機能することを拒否したとき、および問題が完全に明白であるとき、ワイヤーは壊れていませんでした。それは、すべてが夕方に機能し、翌朝には機能しなくなるという不快な機能不全の1つでした。 VisiTelの作成者が製品に特別なフレキシブルワイヤーを使用するといいでしょう。現れたり消えたりしたこの問題は、その解決策を無意味に探すのに何日もかかりました。私はあまり成功せずに過熱の問題を探しましたデバイス、オーディオカードの設定を3回確認しました。テスト中にデバイスを持ち上げたときに、問題を見つけることになりました。その後、録音中に接続の損傷の特徴的な兆候を見つけました。この話から私が学んだ1つの教訓は、古いハードウェアでの作業についてです。これは、デバイスの操作中にデバイスを少し動かして、この時点ですべてが以前と同じように機能するかどうかを確認する必要があるという事実にあります。





ワイヤーの損傷箇所は丸でマークされています

ステップ2.画像伝送メカニズムの調査

トリッキーな配線の問題を解決し、デバイスをコンピューターに接続したら、送信された画像のエンコードに使用されているプロトコルを特定します。 VisiTelに関するビデオと記事により、画像はオーディオ信号の振幅変調を使用してエンコードされていると結論付けることができます。振幅変調は、キャリア信号の振幅を変更することによって実行されるデータコーディングです。振幅変調は、電波を使用して送信される音をエンコードするために一般的に使用されますが、同じアプローチを使用して、電波または音波を使用して画像を送信することもできます。ここに練習を通して新しいことを学ぶことに慣れている人を対象とした、Pythonコードの例を使用して、このプロセスの優れた詳細な説明を見つけることができます。



データがオーディオ信号のAM変調メカニズムを使用してエンコードされていることがわかっているので、このデータのデコードに向けた最初のステップを実行できます。このステップは、既知のプロパティを持つサンプル画像を送信する変調信号を記録することで構成されます。オーディオをキャプチャするために、私はいつものオーディオソフトウェアであるAudacityを使用しました。





オーディオ信号のグラフィック表現



上記は、データがどのようにエンコードされているかをよりよく理解するために、VisiTelから非常に単純な特別に準備された画像を送信した方法を示しています。以下に示すこの画像は、デバイスのカメラの前に持っていた白黒のカードのペアでした。これに対応する信号は、プログラムでとしてマークされblackWhiteVます。





実験で使用した画像



受信した音声信号を詳しく見てみましょう。





オーディオ信号を詳しく見る



この信号はここで聞くことができます。



ご覧のとおり、各ブロックの先頭には、初期化を示すヘッダーまたはシーケンスがあります（この例では17.55から17.80）。これにより、受信デバイスは、別のデバイスが画像を送信しようとしていることを認識し、最大信号振幅を決定できます。このインジケータは、画像をデコードする際のスケーリング係数として使用されます。その結果、電話回線に欠陥があると、画像のコントラストや明るさが失われることはありません。一部の回線で送信される信号は、ノイズが多いか、減衰している可能性があります。 17.55までの信号は単なるノイズであり、VisiTelで使用されるデータプロトコルにとって重要ではないことに注意してください。



私が見つけたヘッダーシーケンスが、別のデバイスが画像を送信しようとしていることをVisiTelに実際に示していることを確認するために、デバイスに録音のこの小さな部分だけを聞かせ、リレークリックで報われました。このシーケンスがいくつかのメカニズムを開始することは明らかでした。しかし、ヘッダーの30ミリ秒だけデバイスを送信した後、ヘッダーの後の画像が送信されていないことをデバイスが検出したことに気付きました。ヘッダー送信が終了してから数ミリ秒後にリレーがオフになります。タイトルとそれに続くサウンドの最初の数ミリ秒を再生すると、VisiTelは画面に画像の表示を開始します。デバイスが画面に画像を表示しているときにサウンドをオフにすると、作業は続行されます。VisiTelは、画像の保存に使用されるバッファーがいっぱいになるまで、一部のデータを受信し続けます。これは、VisiTelがグラフィックデータの処理を開始した後、デバイスが必要なデータが信号のどこにエンコードされているかを正確に見つけるために外部発振器に依存しないことをもう一度証明します。彼は自分の必要なものを正確に伝える独自のクロックジェネレーターを持っています。彼が必要としているのは正確にはどこですか。彼が必要としているのは正確にはどこですか。



信号のヘッダー部分は接続の確立のみを担当し、送信された画像に依存しないという事実を考えると、その特徴の研究を掘り下げることは望んでいませんでした。私たちにとって、私たちの目標を達成するには、ヘッダーが接続を確立する責任があることを知っているだけで十分であり、またそれがどのように見えるかについて大まかな考えを持っているだけで十分です。



そして今、最も難しい部分に移りましょう。グラフィック情報がどのようにエンコードされているか、ピクセルがどのように「聞こえる」かを正確に調べるためです。まず、ピクセルデータがオーディオ信号でどのように表されるかを理解する必要がありました。私の最初の推測は、各全波が1つのピクセルを表すということでした。テストパターンの繰り返し間の波の数を数えることによって、このアイデアをテストしました。私が得たのは、古い広告のVisiTel仕様に沿ったものでした。つまり、96x96ピクセルで、画像自体の開始前に数行が出力されます。



これはすべて、デバイスが各波の振幅を分析し、VisiTelのデジタル画像を表すバッファピクセルの形式でデータを書き込むことを意味します。 VisiTelのマーケティング資料から、表示される画像のすべてのピクセルに16のグレーの色調があることがわかっています。しかし、私は「アナログ」信号からピクセルを分析しましたが、デコードまたはエンコード時にそれらをポスタライズする効果を適用する必要性を感じませんでした。



興味深いことに、ピクセルの明るさは変調の前に反転されます。その結果、最大の波は最も暗いピクセルに対応します。また、画像は左から右に反射され、鏡像が形成されます。この資料の読者が、信号を送信する前にピクセルの輝度を反転させる理由についてどう思うか知りたいです。これは、ランダムに散らばった黒いピクセルの方が、同じように白いピクセルよりも人間の視覚が落ち着いているためだと思います。結局のところ、電話回線のノイズは、VisiTelが1988年に確実に対処しなければならなかった問題です。





信号調査



確かに、上記の画像エンコード方式には1つの例外があり、数週間は理解できませんでした。この逆コーディング方式では、完全に白いピクセルは無音で表されます。そのようなピクセルを表す信号があってはなりません。しかし、VisiTelの作成者はこのアイデアが気に入らなかったように感じました。代わりに、真っ白なピクセルをエンコードするために、キャリア信号が1/4波長シフトされたため、このような波は通常の波と位相がずれていました。この場合、以前と同様に、信号を別のデバイスに送信できます。このような信号を受信すると、受信デバイスは「通常の」信号との同期を維持し、通常と同じ場所で信号の振幅に関する情報を取得しましたが、これらの瞬間に波は0を通過しました。ピクセルを白くしました。すでに述べたように、画像転送中にサウンドをオフにすると、VisiTelはバッファがいっぱいになるまで画像を表示し続けます。これらは白いピクセルです。その結果、ラインに有用な信号が存在しなくても、無音はデバイスによって白として認識されることがわかります。デバイスの作成者が、このような位相シフトモードを導入して変調方式を複雑にすることにした理由はわかりません。私の場合、これには多くの労力が費やされましたが、そのようなステップのメリットがないか、非常に重要ではありません。そのため、デバイスの作成者は、そのような位相シフトモードをデバイスに導入することによって変調スキームを複雑にすることを決定しました。私の場合、これには多くの労力が費やされましたが、そのようなステップのメリットがないか、非常に重要ではありません。そのため、デバイスの作成者は、そのような位相シフトモードをデバイスに導入することによって変調スキームを複雑にすることを決定しました。私の場合、これには多くの労力が費やされましたが、そのようなステップのメリットがないか、非常に重要ではありません。



位相シフト変調について知らない私は、最初に各波の最大値を見つけて、結果の値をピクセルとして表現しようとしました。改行は、式で計算されたステップで実行されました96*( )。これは、いくつかの行に少し多いまたは少し少ないピクセルがあるという事実につながりました。さらに、信号分析へのそのような大雑把なアプローチは、波の小さなピークでさえ余分なピクセルの出現につながる可能性があるため、ノイズに非常に敏感でした。確かに、このような画像デコードメカニズムは実装が非常に簡単でした。この単純なアイデアを実装すると、レシーバーとソースを同期する必要なしに画像をデコードできます。しかし、そのような信号デコードシステムを適用した後、私にはまともなことは何も起こりませんでした。



画像をより正確にデコードするには、VisiTelと同じようにする必要があります。つまり、ヘッダー処理時に信号と同期してから、一定の間隔で信号をサンプリングする必要があります。当然のことながら、このような信号処理には非常に正確なタイミングが必要です。私の場合、44100 Hzの周波数でサウンドを録音する場合、1波あたり25.23158サンプルがあります（これは、キャリア波の周波数が1747.80968929 Hzであることを意味します）。その結果、ピクセルに関する情報を読み取るたびに、オーディオバッファーで、前のピクセルから25.23158サンプルの距離にある次のピクセルのデータを探します。サンプル位置は整数値で記述されているため、対応する数値を最も近い整数に丸めて使用します。ここで最も重要なことは、丸めエラーが蓄積しないようにすることです。これにより、サンプリング位置が音波に対して急速に位相がずれます。また、画像のデコード中に同様の変位が発生した場合、小さいものではありますが、完成した画像はアーティファクトで埋められます。





アーティファクトでいっぱいの画像



幸いなことに、波ごとのサンプル数は非常に安定しています。問題になるのではないかと心配していましたが、ウォームアップ後も変化はありませんでした。この安定性により、画像デコードコードに適切な値を簡単にハードコーディングすることができました。理想的には、波ごとのサンプル数はタイトルから学習する必要がありますが、小数点以下5桁の精度を達成するのに十分なサンプルがないことがわかりました。そして、ハードコードされた値は、安定した結果を達成することを可能にしました。信号デコードシステムのこのより正確な実装のおかげで、1ピクセルを生成する関数が96回呼び出された後、改行が簡単に実行されました。



これまで、WAVファイルからデコードされた録音済みのオーディオスニペットを使用してきました。インタラクティブに動作し、コンピューターのオーディオインターフェイスに入る画像をデコードするには、デコーダーにヘッダーを検出して画像データの先頭を見つける機能を装備する必要がありました。見出しを見ると、明確に区別できる3つの断片が含まれていることがわかります。





ヘッダー分析：キャリア-沈黙-キャリア



これを検出するために、単純なFFTベースの検出器とステートマシンを実装しました。ソースマテリアルが最初に処理され、次に検出器がオーディオ信号の各ブロックを調べて、強い1747Hz信号を検出します。次に、信号が消えてから再び現れる場所が見つかるまで、ブロックが調べられます。これは、送信を開始する瞬間を見つけることを意味します。その後、単純な静的オフセットを使用して画像データ送信の開始時刻を見つけ、上記のメカニズムを適用して画像をデコードします。デコードが完了すると、画像が表示され、ステートマシンは元の状態にリセットされ、次の送信が開始されるのを待ちます。

ステップ3.VisiTelをWebサイトとして提示する

VisiTelから受信した画像をデコードできるようになったので、パズルの最後のピースを配置する必要があります。デコードされた画像をビデオフレームの形式で提示し、ビデオストリームをビデオ会議プログラムに送信する必要があります。これはLinuxでは驚くほど簡単です。ビデオ入力はV4L2インターフェイスで抽象化されていますが、これは残念ながらカーネル空間で発生します。カーネルモジュールの作成に関連する複雑さに巻き込まれないようにするために、既製のソリューションを使用できます-v4l2loopback..。このモジュールは、入力デバイスと出力デバイスの両方です。渡されたグラフィック入力は、Zoomなどの他のプログラムが受け入れることができる出力になります。それをさらに抽象化するPythonパッケージもあり、OpenCVとNumPyを使用してこの種のデータを操作できます。私はこれらのパッケージの1つを使用しました- pyfakewebcam。非常にシンプルなインターフェースを備えています。仮想Webサイトを作成するには、次の手順を実行します。

import
      pyfakewebcam
self.camera
    =
    pyfakewebcam.FakeWebcam(self.v4l2_device, 640, 480)

そして、新しいフレームを受け取ったら、これを行う必要があります。

self.camera.schedule_frame(output)

さて、この小さなデコーダーの追加後、すべてが正常に機能しました。ZoomはVisiTelから画像を受信でき、1980年代のスタイルでビデオチャットを整理できます。





1980年代の精神に基づいたビデオチャット



また、LinuxドライバーのDirect Rendering Managerをインストールしたいと思います。これにより、VisiTelから画像を受信するだけでなく、画像を表示することもできます。しかし、今のところ、このプロジェクトが成功したことを認識するためには、1988年のデバイスを使用してZoomで通信できれば十分です。ここに、興味があれば、GitHubのプロジェクトコードがあります。



遠い昔からいくつかのデバイスにセカンドライフを与えようとしましたか？