等価原理と後戻りしてくる光

おなじみの1次元の空間と時間との2次元で考えよう。
横軸がx方向、縦軸が時間。単位は斜め45°が c となるよう設定する。
ここで、一様にx軸のマイナス方向に加速度 a が働いているとする。(いつでもどこでも物はx軸のマイナス方向に落ちてゆく)

任意の点を取って、その時点で自由落下し始める空間の座標軸を加速度の働いている空間から見てみよう。
次の図は、ガリレイ変換での図だ。

下が、いま注目している時点で、その上が微少時間Δt後である。　え、何で矢印の基点が左にずれていないのかって。
それは、座標軸の向きに注目しているからで、最初同じ位置にあった点がΔt後にどこにあるかは気にしていないから。

さて、ガリレイ変換では自由落下する座標権はΔt後にx軸のマイナス方向にΔv = a Δt だけ速度を持つ。つまり、時間軸のベクトルは左にすこし傾くわけだ。従ってx軸方向への光速cでの移動をあらわす緑の矢印は、自由落下する系から見れば 速度c (時間軸のベクトルと空間軸のベクトルの和) で変わらないが加速度aの働いている空間から見ればちょっとだけ立っていて、ちょっとだけ速度cから遅くなる。
これが繰り返されるとどうなるか。最初は右45°のベクトルもちょっとずつ立っていって仕舞いには左へ向いてしまう。
ボールを加速度に逆らって投げても戻ってくるという話だが、光を放ってもやはり光が戻ってきてしまうという事でもある。
何しろ今の話で重さとか力とかは一切出てきていないからね。

いっぽう、ローレンツ変換だとこうなる。

微少時間Δt後に自由落下する系が速度を得ると、時間軸は左に少し傾くのだが、それと同時に空間軸も右下へ少し傾く。
そのため、自由落下する系での光速cをあらわす緑のベクトル (= 時間軸のベクトルと空間軸のベクトルの和)は、加速度aを持つ空間から見ても右45°のままで変わらない。速度の話をしているので、傾きだけが重要。
ということで、これが繰り返されたところで、緑のベクトルの向きは右45°、つまり光速c で変わらない。
光を放ったら加速度aにかかわらず、光速cでずっと進み続けるということ。

... hi.

AMレシーバはNG

順序が逆だが、FMラジオに引き続きAMラジオを試すが受信にはいたらず。

雑誌記事では素のLPC-Link2にスピーカ&アンテナをつけているが、こちらは既にFMステレオラジオ基板を取り付けているので、その基板に配線する。
ロータリーエンコーダの右下にPWMが引き出されているし、基板の上辺の右から2番目にADC3が引き出されているの。
アンテナ線には、キット付属のビニル線(FMのアンテナにも使った)を使用。
で、キットに付属のAMReceiverをそのままビルドして実行。

が、鳴るのはノイズばかり。受信周波数を変えるとノイズが変わり、時々はビート音などがするし、アンテナ線の付けはずしでノイズが変わるのでAM receiver として動作しているのではあろうが受信能力として足りていないのだろう。
585KHz付近でノイズにまざりかすかにハングルらしき声が聞こえるが、中波なのか短波放送が折り返してそこに現れているのか... NHK第1が入らない位だから短波のほうだろうなぁ。

ということで、AMReceiverをベースに改造、まずは出力部をPWMからこーデックに変えて..という予定が、あてはずれ。さてどうしたものか。

神は永遠に幾何学する

そうであるならば、それはきっと微分幾何に違いない。

テスト音源ファイルの無限ループ再生 HTML5で楽勝

ステレオ信号処理の実験準備として、左右チャンネルをはっきり区別できる音源を準備した。
ACID Music Studioでサンプルのループを使ってジングルを作成し、ひとまずwavファイルに。
が、実験だと場合によっては長々とテスト音を流しておく必要もある。さて、どうやってループ再生しようかと思ったが...

HTML5であっさり解決。下のようなタグを書いたHTMLを作ってchromeで開けば再生/停止もボタン制御できて、再生している間は無限ループ再生になる。

<audio src="test1.wav" loop controls></audio>

リバースエンジニアリング メモ

まずは、出力部分。

音声データは、0x2000 (ステレオで4Kサンプル)のリングバッファを介してI2Sの出力ハードへ渡される。

バッファからは、I2Sからの割り込み駆動で、送信バッファがあるていど空くたびに I2S0_IRQHandler()が呼ばれ、前記リングバッファからI2Sの送信バッファへ詰め込む。

FMRecieverのケースでは、すべてが一つのマスタークロックからなるので音声データ生成とI2Sの送出の速度差はでないはずだが、ADCのクロックを外部から純粋なクロックを投入することを考えているので、その場合音声データの生成とコーデックでの消費のスピードのずれが積算してやがて大きくなることが予想される。

で、現在のコードをみてみると、audio_adjust_buffer( )のリングバッファの書き込みと読み出しスピードの差が積算して顕著になったときの調整コードがある。　通常は読み出しと書き込みがバッファの半分の距離にたもつので、2Kサンプル、45ms位かなぁ、のレテンシか。で、1.5Kサンプル程度ずれると読み込み位置を2Kサンプルに戻す。つまり一瞬30mSぐらい飛ぶ/戻るという勘定か。

これでもさほど悪くはないはずだが、将来何か工夫がある場所ではあると思う。