前文
我々は、ブラウザの WebAudio サポートによって、空気をメディアに使う方法を手に入れた。これにより、またひとつクロスドメイン通信の方法が増えたといえよう。
知っている人は少ないと思うが、古代人は空気によって伝送できる程度の周波数を用いてデータ伝送を行っていたという記録が残っている。これは失われた暗黒の技術であって、現在ではもはや ITU という国連の機関によってその存在の記録が残されているのみである。
デモ
小さな画像を音声帯域を使って送受信する
実際にマイク入力を使う場合、
マイク入力はやはり難しくて、周囲の環境によって波形が乱れるとうまくいかなかったりする。
V.21
ITU-T 勧告 V.21 は全二重 300bps の通信プロトコルで、変調方式は単純な FSK (周波数変移変調) になってる。
FSK
FSK (周波数変移変調) は、2つの周波数をそれぞれ 1 と 0 とに割当てて、切替えながら送信することでデータを送信する変調方法。単純でノイズに強いのが特徴。
かなり面倒くさがって WebAudio だけに依存するように書いたので、いちいち全サンプルに対して処理をしていてとても重い。アルゴリズム自体にも、もっと根本的にいい方法がありそうだけれど、知らないので直交信号をそれぞれヘテロダインする方法にしてある。
このへん、ノウハウがなさすぎて精度良く検出するのが僕にはかなり難しかった。
FSK 部分は以下
V.21 の周波数
既設の電話回線をデータ通信に応用する技術なので、可聴帯域の周波数を搬送波に使っており、全二重なのでチャンネルが2つある。つまり使う周波数は4つ。
- channel No.1: FA=1180Hz, FB=980Hz (200Hz shift)
- channel No.2: FA=1850Hz, FB=1650Hz (200Hz shift)
WebAudio + 空気の場合、別にこの帯域に拘る必要はなくて、可聴域限界ぎりぎりまで周波数をあげてもいいと思う。実際そのようにしても動くし、速度もあがるしモスキート音なのであまり煩くなくなる。今回はそれだとモデムっぽさがなくなってカッコよくないのでやめた。
プロトコル
プロトコルは以下のようにした
- 非同期
- スタートビット1bit
- ストップビット1.5bit
- データ8bit
でバイト単位のやりとりをする。1バイトにつき10.5bit使うので、最大で 28.6bytes/sec ぐらい。
さらにまとまったデータ送信のプロトコルとして以下のような xmodem ライクな実装を書いた
- 送信側が待ちうけ
- 受信側が NACK 送信
- 送信側がデータブロック (128bytes) を送信
- 受信側が ACK 送信
- ... 繰り返し
- 送信側が EOT を送信
- 受信側は ACK を送信して終了
データ部は「SOH, データブロック番号, ビット反転したデータブロック番号」をヘッダにして、最後に CRC8 を付与している。これらが意図した値でなかった場合 NAK を返し、該当ブロックの再送要求をする。また、途中でバイト単位のやりとり自体が失敗した場合にそなえてタイムアウトによる再送もやってある。
まとめ
ポエティックでフィクションな前文を書くのを広めたい。
