エアバス機に不具合 全日空の国内線95便がきょう欠航 | NHKニュース | 航空、交通・インフラ
A320 Family precautionary fleet action | Airbus
2008年頃にA330のインシデントがあって、デバイスの劣化と外部要因の複合現象みたいな感じの原因という説明だったけど、それとはまた別のやつなのかしら?
暗黒物質がついに見えた！？ ー天の川銀河のハローから高エネルギーガンマ線放射を発見ー Press Releases - 東京大学 大学院理学系研究科・理学部
「箱の中身は何色だろな」で「箱に手を入れたら何かが手に触れた」位の感じかな。これからもっと撫で回して形を決めていって、この形ならこの色に違いない、といろいろ探していく感じで。最終的には箱から出して実際に眼の前に持ってきて観察するのが究極だけど、まだまだかかりそう。とはいえ、「箱の中に入っているよ」とは言われていたけど手を振り回してもどこにあるのかもわからなかったものが、「ここにありそう」とわかっただけでも大きな進歩。
しかしまあ、WIMPの対消滅で発生したガンマ線で想定される放射に一致する観測値が得られた、とはいえ、それでプレスリリースのタイトルに「見えた！？」と書くのはちょっと先走りすぎてる気がしないでもない気がする。まあ、そんなこと言ったら、新元素の発見だって崩壊過程を見て予想と一致していれば塊として眼の前に用意しなくたって発見と認められるわけだけど、元素の場合は複数の崩壊過程を経るのに対して、今回の場合は単純にガンマ線を見つけただけなので…… ちゃんと根拠のあるパターンを見つけたんだろうけども。
リアル月面探索ゲーム『REAL MOON』発表、Steamで無料配信へ。JAXAがゲーム会社と共同研究、精密に再現された月面で自由に動ける - AUTOMATON
UE開発で実績のある会社が作ったゲームなら、まあ安心かな?
まるでゲーム開発の実績がない会社が作った宇宙系のゲームに不安があるみたいじゃないですかぁ。いやまさかそんなことはないですよ?
重箱の隅をつつくようなことを言うと、影のライティングがちょっと暗すぎるよーな気がする。アポロの写真を見ると、月面の反射がかなり強いので、物体の日照の無い面も結構明るいのよな。それの再反射で影の中の月面も結構明るい。そのわりにゲーム中の背景は恒星がかなり目立つし。アポロの写真の場合、影の中がはっきり見えるような明るさでも恒星は全く見えない。実際には写真と肉眼のダイナミックレンジの差の関係もあるので、この比較が正しいかもわからないけど。
あとは、普通の(地球を舞台にした)ゲームを作っているチームだと、重力のイメージがだいぶ違う部分が影響しそうな気もする。重力が少ない中で歩くとどうなるのか、あるいはどうやって移動するのがいいのか、みたいな部分が特に。とはいえ、まさか1Gでモデル化してるわけは無いだろうしなぁ。なんか、スタスタ歩いてるのが気になるんだよなぁ。
映画『ジャガーノート』(英1974年)、いつか見たいなーと頭の片隅に置いてあったんだけど、このあいだCSで放送していたので録画して視聴。半世紀前の映画だってよ。そんなに昔なのか…… そりゃ『エアフォースワン』より古い映画だって基準点は持ってたけど。っていうかエアフォースワンって'97年の映画なんだな。結構最近だ。
内容はWikipediaで結末まで知っていたから、見ていて本来ほどハラハラ・ドキドキするわけでもないけど、とはいえ十分楽しめた。
***
壁をデータ化して近い経路を探索するような処理を作ってみた。
このゲームではマップを再利用することができるけど、再利用すると迷路が閉じていることが保証されなくなる。その場合、左手の法則みたいなのだとループに入って抜け出せなくなったりするので、経路の探索が必要。
1回目は迷路が閉じていることが保証されているから、最初に左手の法則を使ってすべての壁をデータ化して、以降は現在位置とゴールの位置、それから先に取っておいた壁の位置から最短経路を探している。そして移動中に壁が消えたことを検出した場合は、次回以降にその情報を使用する。
マップを再利用すると、壁が既知というだけでなくて、壁が消えることでより短い経路が発生する可能性がある。なので、何回も繰り返し利用したほうが少しずつ効率が良くなるはず。
今のところ、最短経路探索の処理がかなり重いので、あんまり早い気はしない。
300回近くまで再利用するとかなりスカスカになる。ただ、あくまでも自分が通った前後左右しか壁の消失を検出できないから、実際にはショートカットできるのに遠回りする、みたいな状況もある。再探索みたいな処理を挟めば最適経路を見つけられるようになるけど、それはそれで大変そうだ。時間もかかるし。
Pythonって今まで触ったことなかったけど、あんまり違和感なく使えてる。たまにセミコロンを書いて怒られたりとか、その程度。C#とかに戻ったときにifを()で囲わなくなるのがちょっと罠かな。あとはタプルの分解がx, y = measure()とかでできて若干キモいとか。
TFWRのインタプリタは三項演算子が使えないのが地味に不便。あと、大きなテーブルを使いたいときに、Pythonではlist = [0] * 1024みたいな書き方ができるらしいんだけど、TFWRではそれができないから、for i in range(1024): list.append(0)みたいな感じで自分で初期化子きゃいけないのが面倒。
PythonのNone判定はif hoge is None:やif hoge is not None:でやりなさい(Falseや0みたいにFalsyな値をまとめて弾きたい場合は除く)、というコンセンサスがあるらしいんだけど、TFWRでif hoge is None:みたいなコードを書くとシンタックスエラーで弾かれる。
ちゃんとしたコードを書こうとする(orちゃんとした書き方の勉強に使おうとする)と、TFWRはちょっとびみょいかもなー。
マイクロマウスみたいな題材、というか迷路を解くようなプログラムって、書いてみたいなーとは思いつつ、いままでやったことがなかった。左手の法則で解くなら閉じた迷路を生成するプログラムを先に書かなきゃいけないし、閉じていない迷路を解くならちゃんと経路を計算しなきゃいけないし。そもそも閉じてない迷路でも生成するのは大変そうだし。
初めて迷路を解いてみて、しかも触ったことない言語で、ということを考えれば、解くのにそれなりの時間はかかるけど、まあ、ちゃんと動いてるし良い方なんじゃないだろうか。
これで本物のマイクロマウスだとハードウェア(物理空間)に起因する問題が色々と出てくるんだろうけど。迷路を走らせている合間にVeritasiumの動画を見てたけど、元々は数学的な問題だったのが、最近はロボット工学の問題になってきて、いかに物理空間で特性よく計測・制御するかが問題になってきている、みたいなことを言ってて、さもありなん、という感じ。
マイクロマウスでマウスのイメージセンサを使うようなやつってないのかな。最近のゲーミングマウス用のイメージセンサだとフレームレートがアホほど早いし滅茶苦茶な加速度にも対応しているから、マイクロマウスの速度・加速度でもある程度正しくトラッキングできそうだが。迷路の床面の材質が厳しそうではあるけど。
マイクロマウスの場合、移動距離を直接(摩擦力に依存せずに)計測できるセンサはあれば便利だろうけど、とはいえ角分解能(積分してヘディング)が悪いと意味ないからなぁ。マウスのイメージセンサだとその軸は感度が悪い。
計算量でゴリ押しするなら試走したコースの路面画像と別のセンサで取った座標データを保存しておいて、高速走行中にパターンマッチングで位置決定するみたいなことも考えられそうだけども。推定値はかなりいい精度で持っているから、誤差を補正する程度でいいわけで、計算量はさほど高くないだろうし。積分しなくていいから誤差も増えないし。とはいえ、その程度のことはもうやってそうな気もするが。
組み込み側の計算能力より、開発用のリソース(ワークステーションとかクラウドとか)の計算コストが圧倒的に下がってきたから、デジタルツインとか機械学習で最適な構造(タイヤの配置とか)をゴリ押しで探索するような方向もそのうち出てきそうだな。
TFWRの方は、とりあえず迷路は解けたし、ヘビゲームは文字通りエッジケースやコーナーケースの対策が思いつかないのでブルートフォースで書いて放置してるし、ツリーは骨100M以外は解放したし、とりあえず一区切りついた感じ。というか飽きてきた。放置ゲーは放置するところまで進むと放置が義務になるから楽しめないのよなー。
***
https://www.jstage.jst.go.jp/article/itej1978/34/2/34_2_135/_pdf/-char/ja
1980年。PCMアダプタの話。
ビデオテープの広帯域特性を使用して、音声データをデジタルデータとして保存する装置が1969年にNHKによって開発・公開された。その後に多様な装置が色々と出てきて、一部のオーディオマニアも使うようになって広まったが、互換性の無さが問題になったので規格を統一しようということでEIAJで作られた規格。
サンプリングレートの設定理由も書いてある。あくまでもNTSCに合わせて44.0559kHzを選定していて、PLAとの互換性や値の丸めは考えていないっぽい(一番最後に、今後PALやSECAMに対応したいみたいな話は書いてある)。
テレビ信号としての同期信号(伝送路のAGCに必要)はあるけど、カラー映像信号としてのバースト信号は必要ないわけだから、モノクロの15.75kHzを基準にして44.1kHzにしても良さそうなのに、わざわざカラー放送に合わせて中途半端な値に設定しているのが謎い。NHKが開発したものだと局内のシステムに同期しなきゃいけないからみたいな理由があるのかもしれないけど。
データは14bit/Wが6ワード(ステレオで3ワードずつ)、誤り訂正が2ワード、誤り検出が16bitで、合わせて128bitが水平走査線1本に入る。誤り訂正によって6W中2Wの誤りを訂正できる。各ワードはインターリブして記録されているから、最大で32Hまでのバースト誤りに対応できる。
https://www.jstage.jst.go.jp/article/biophys1961/26/6/26_6_291/_pdf
1986年。PCMアダプタを改造して生理学実験に流用する提案。主にAC結合のオーディオ機器をDC結合に改造したり、フィルタ周りを変更したりとか。PCMアダプタは映像信号しか使わないので、VTRのオーディオ信号も使えば、デジタルPCMが2chとアナログ信号が2chの合わせて4chを記録・再生できる。
https://www.jstage.jst.go.jp/article/itej1978/39/4/39_4_338/_pdf
1985年。業務用PCM録音機。
音声データの編集方法で、テープを手動で切ったりつなげたりして編集する方法があるらしい。デジタルデータだとインターリーブで時間方向にデータが広がっていたり、独特の課題もあるらしい。あとは、複数のヘッドでそれぞれのトラックを書き込むようなシステムだと、トラックごとに時間軸でズレているというものもある。
例えば映画フィルムなら目で見てわかるから手切り編集もそんなに難しくなさそうな気がするけど、磁気テープってどうやってタイミングを決めるんだろう? 「ここ！」って場所で再生を止めて、その時のヘッドの位置で切る、とか?
アナログ磁気テープだとダビングするたびに音質が劣化していくから、磁気テープを物理的に切り貼りして編集するのは劣化防止である程度有効な気もするけど、デジタルデータの場合はダビングしても音質が劣化しないのが特徴だから、わざわざ手切りしなくてもなぁ、という気がするのだが。最初の頃は編集機材のコストが高いから、従来のアナログテープと同様の方法で編集したかった、ということなのかな。
https://www.jstage.jst.go.jp/article/itej1997/52/8/52_8_1179/_pdf/-char/en
ソニーでCDの開発に関わった人の話。
ベータマックス用PCMアダプタをなかば不完全な状態で発売して膨大なクレーム処理に追われ、そのおかげでデジタルデータの誤り訂正を評価するのに必要なデータを得て、CDに活かした、という感じらしい。付け焼き刃のソニーの技術陣はフィリップスの足元にも及ばないレベルだったが、誤り訂正用のシミュレーションだけはソニーの強みだった、と。
https://www.jstage.jst.go.jp/article/itej1978/33/1/33_1_2/_pdf/-char/ja
1978年。PCM録音の説明。
最初に従来のテープレコーダーとの違いやPCMの特徴について。磁気テープは磁気特有のひずみやアナログ特有の情報の劣化がある。デジタルデータならそれを除いたクリアな信号が得られる。
低振幅の信号を入れたときの説明とかも。振幅が1bitの正弦波を突っ込むとデジタルデータ上では矩形波になるから大量の高調波が生じる、みたいな話。
中盤に符号化やデータ圧縮の話。エントロピーとかの解説が色々。ただしPCM録音はどんな波形が入ってくるかわからないから、圧縮率は稼げない(アーカイブデータなら統計的に圧縮できる)。
シャノン限界に軽く触れて、VTRなら理論的には30Mbpsで保存できる、PCM記録なら40-60チャンネル、圧縮を併用すれば150チャンネルを記録できる、と。現状は1桁低いのでまだまだ改善の余地がある。
PCMは走行系のジッターが消える(バッファメモリで吸収できる)から、そのあたりがアナログ記録と差別化できる。手切り編集が難しいという声があるが、コピーによる劣化がないから、コンピュータが発達すればより高度な編集が容易になるはず。
アナログ録音は技術的に飽和していて、今後の大幅な低価格化も望めない。デジタルは集積度の向上(小型化)や低価格化がしばらくは続くはず。将来的には家庭にもデジタル化した音が届くようになる。半導体メモリや磁気バルブの小型化・低価格化傾向を考えると、遠くない未来には「固体デジタルレコーダー」「固体レコード」が出現する可能性もある。
固体化レコード、そもそもレコードは固体だろうという気もするけど(ひねくれた考え方をすればレコードやCDみたいな高分子材料は液体であるということを否定できない可能性はあるけど)、ここで言う固体化というのは機械的な可動部を含まない、ソリッドステートな半導体を指しているんだろう(大抵の文脈ではそういう意味だろうけど)。iPodも最初はメカニカルドライブを内蔵していたし、完全に固体化したのは結構時代が下ってからという感じがするな。iPodの前にも数十MB程度の固体化オーディオプレイヤーが市販されていたとはいえ、競争力を持って普及していたかというと微妙な気がするし。
https://www.jstage.jst.go.jp/article/itej1978/33/1/33_1_32/_pdf
1978年。PCM録音に関する座談会の文字起こし。
歴史的な背景。
SPレコードは3分から5分くらいで、演奏を直接レコード盤に記録するダイレクトカッティングをやっていた。このくらいの時間なら奏者や技師への負担も少ないが、LPレコードの片面15分(両面30分)くらい録音できるやつが出てくると、失敗が許されないダイレクトカッティングの負担が大きくなった。
同時期にテープレコーダーが開発されたので、一旦これに収録し、編集などを行ってからレコード盤をカットする方式が生まれた。LPレコードというのはテープレコーダーが生まれたから実用化できた。
ただ、そのうちにレコード盤を聞いてもテープレコーダーの特性が聞こえるようになってきた。テープレコーダーの音質が悪いので、レコードもそれでリミットされる。試しにLPにダイレクトカッティングをやってみると音質は素晴らしいんだが、なにせ録音が大変で実用にならない。
ちょうどその頃にNHKのPCMレコーダ開発が一段落したので、試しにその機材で録音してレコードを切ってみると、かなりいい音がする。これがレコード盤にPCM録音が使われたきっかけではないか。
そもそものPCMのきっかけ。FM放送を実験放送から本放送に切り替える際に、音質劣化の原因探しが行われた。やはりテープレコーダーが問題ということがわかり、その対策が必要になった。テープレコーダー自体の改良と並行してPCM録音の開発も行われた。
PCMを担当した人はオーディオテープの前はビデオテープもやっていて、テープの品質についてもある程度知っていた。結局、エラー対策を重点的に開発することになった。音質の評価というのはえてしてバラバラな結果が得られるが、PCMでは珍しく一致した意見が出て、開発を進めることになった。
将来的には録音から編集、中継、放送、再生までエンドツーエンドでオールデジタル化を目指していた(結局、日本のラジオ放送のオールデジタル化が現実的に実現したのはradikoとかが出てくるまで時間がかかったな。アナログ放送も(そろそろ廃止が始まるとはいえ)まだ現役だし。デジタル放送の規格としてはISDB-T SBとかもあったけど、普及しなかったし)。
ヨーロッパにPCM機材を持っていって録音したときに、現地のエンジニアはPCM(映像信号の同期の隙間にデータを入れる)を理解してくれない。向こうはオーディオ屋はオーディオ専門だから、テレビ技術がわからない。日本の会社は一人が色々な分野に動いて、技術の流用がやりやすいのかも。
FM放送にPCMを使う実験を行った。東京でも音質向上は明らかだが、特に地方への影響が大きい。中継回線で音質が劣化するから、距離で劣化しないPCMで放送すると明らかに良くなる。夜間のテレビ放送を行っていない時間帯に回線を借りてPCMビデオ信号を伝送すれば、地方でも1日8時間くらいはPCMを放送できるはずだ。放送側はDACだけあればいい(ADCはいらない)から、機材の価格は半分で済む。
将来構想の話が面白いな。バブルメモリが安くなればこれで行けるんじゃないかとか。さらに未来で信号処理系はものすごく小さくなって、巨大なスピーカーだけになるんじゃないかとか。21世紀になるとデジタルになるだろうけど、またその次にアナログが来るんじゃないかとか。
デジタル技術は3年くらいで形になる。アナログ技術は10年はかかる。ノウハウも色々必要になる。技術者としてはデジタルよりアナログのほうが面白い。
PCMはテープレコーダーの特性の悪さから逃げた結果。テープレコーダーの特性が改善されればまたアナログに戻るのではないか。
というところで終了している。
カセットテープは(まだ生きながらえているとはいえ)ある程度衰退して、デジタルのCDもほとんど衰退して、残ったのは完全に固体化したサブスクとアナログのレコードという状況の現代から見ると、半世紀前の話も面白いな。結構当たってるところもあるし、外しているところもある。当時は大容量の固体メモリといえば磁気バブルメモリしかなかっただろうし、フラッシュメモリとか、あるいはユーザーに対して1本1本回線を引いて要求されたデータをリアルタイムに飛ばすなんて夢のまた夢だろうし。/* サブスクの向こう側はまだまだHDDとか、機械的に記録している媒体だろうから、完全に固体化してると断言していいのかはともかく */
Digital audio needed videotape to be possible - and the early days were wild! - YouTube
家電とかの仕組みを解説しているチャンネルの人がソニーのPCMアダプタを説明している動画。
海外の人が日本で作られた技術の詳細を探そうとすると結構大変なんだな。Google Patentsで特許情報を探すとかしないと見つからないらしい。日本人が探そうと思えばjstageで適当に探すなり、あるいはGoogleでPDFファイルを指定して検索すれば結構色々出てくるけど。まあ、我々も英語圏で開発された技術を探そうとすると苦労するからな。言語が違う場所で生まれた情報を探すのは大変よな。
「なぜこのような製品が存在しているのかわからない。ラジオを録音するには明らかに過剰だし、その他の用途にしてもカセットテープで十分なはずだ」(意訳)
確かに。そう言われると民生用でわざわざ統一規格まで作って商品化した理由って何だったんだろう? PCMオーディオが書き込まれたビデオテープのプログラムが発売されていたとかならわからないでもないけど。あるいは、だから普及しなかったのかもしれないけど。
面白いコメントがあった。かつて放送局のエンジニアでこの手の機械を使っていた人だそう。デジタルオーディオは映像チャンネルに記録されているが、オーディオチャンネルにも同じ音声を入れておけば、PCMアダプタが無い環境でもそのビデオテープに保存されている音声を聞くことができる。うまくやればPCMアダプタ無し(通常のビデオ編集環境)でもデジタルオーディオの編集作業ができたらしい。
あるいは、コンサートを録音する際に、演者側の音をデジタルで記録し、観客側の音(歓声とか)をアナログで記録する、というような使い方もあったらしい。
多くの登録者数を抱えているチャンネルが古い技術にフォーカスした動画を作ると実際に使っていた人たちがどんどん湧いて出てくるから面白いな。
元々PCMレコーダは、アナログ方式のマスターデータがレコードの音質を制限するようになってきて、マスターデータを高音質で管理するために作られたんだそうだ。ってことはアナログレコードも結局はデジタルデータなんだな。後年はともかく、初期は48kHz16bitを使っていたっぽいし、結局アナログレコードってCDをレコードに焼いただけってことになりそう(当時も業務用PCMはもうちょっとsps高いらしいけど)。あるいは、CDはアナログレコードに焼く前のマスターデータをそのまま販売しているということになる。なんか気づいちゃいけない世界の真実を見つけた気分だ。
PCMアダプタの信号がビデオ信号の形ならfl2kで生成もできるだろうし、44.1kHz16bit2chのWAVデータをPCM用のデータに変換するのも容易だろうけど、今の時代にPCMアダプタの存在自体がな…… 古い家電(オーディオ機器)のコレクションをしている人なら自分で持ってるPCMアダプタでアナデジ変換すれば済むし。中間にアナログを含まない完全なデジタルのオーディオファイルを作りたい場合はPC側で作れれば便利かもしれんが。
ビデオ信号とはいえ映像信号ほど厳密に処理する必要もないから、STM32F4くらいでもデコードできそうだけどな。ADCでPCMフォーマットをI2Sに変換するアダプタくらいなら作れそう。じゃあWAVを直接I2Sで出せばいいだろう、という話ではあるけど。
***
前回のNTSC映像信号で色がくすんでいたやつ、クロマの振幅がかなり低かったのが原因だったので、適正な振幅へ設定。
適当な写真を変調。IQはそれぞれ1.5MHzのVBSと0.5MHzのAM。
FIRの遅れがあるので、それに合わせて表示エリアを左にオフセットしている。
色合いが若干違うのと、まだ褪せた感じになる。ただ、画質は「そうそう、NTSCってこんな感じだよね」に近くなった。LPFを外すと輪郭がパキッとしすぎる。左右端はフィルタのリンギングが若干出ている。水平同期のブランキングエリアはちょうどぴったり、垂直同期は下が少し狭くて上がかなり狭い、という感じ。おそらく16:9用に調整しているんだと思う。
実数空間で計算するならSystem.NumericsのVector3やMatrix4x4で処理したり、ベクトル積の水平加算は内積で計算できるから、それを使うと便利。複素空間で処理しようとするとだいぶ面倒だけど。
Matrix4x4、左上から右側に並ぶんじゃなくて左上から下側に並んでるのがちょっとキモい気がする。単に不慣れだからなのかもしれないけど。
YIQのFIRの周波数特性
Yは左右非対称のVBS(-0.5 - +3.5 MHz)、Iも左右非対称のVBS(-1.5 - +0.5 MHz)、Qは左右対称のAM(0.5MHz)、といった感じ。FIRの後でIQは33度傾けてUV平面に回転したあとに、fscをかけて+3.58MHzの位置に持ち上げる。もうちょっと急峻なフィルタを作っておいたほうが良さそうな気もするな。
FIRは複素フィルタ3本だから計算コストが結構きつい。仕様が固まってガッツリ最適化することになれば並列で回すとかもできるけど、今はシングルスレッド処理だからそこそこ時間がかかる。時間がかかると、デバッグが不便。。。
適当なテスト画像が欲しいんだけど、いまいち良い方法が思いつかない。色的にも空間的にも広いスペクトルを持った画像ってなかなか無い。
NTSCの映像としては最低限見れるようになって、少なくとも色相が90度ずれているというほどではないけど、いまいちちゃんとした色合いにならない。もうちょっと根本的に理解してからコードを書き直したほうが良さそう。
試しにベクトルスコープのレチクルを作成。なんか前にもやった気がするなぁ。確かSTM32F4でNTSCのサンプリング(1フィールドのキャプチャ)とかだった気がする。
少しずれるけど、おおよそいい感じの位置関係は得られている。ということで、この画像を作成するための計算式を理解して、RGBをNTSCに変換するコードを考えるのが、次の作業。
バーストには75%と100%に2個ずつドットを打ってある。片方はセットアップレベル7.5%(アメリカ仕様)、もう片方は0%(日本仕様)の位置。7.5%の方が近い。fscの変調レベルって白-黒レベルに合わせなきゃいけないんか? なんでそんな七面倒臭いことを。。。
https://www.jstage.jst.go.jp/article/itej1954/9/3/9_3_100/_pdf/-char/ja
https://www.jstage.jst.go.jp/article/itej1954/9/4/9_4_130/_pdf/-char/ja
NTSCの色信号について、上が理論寄り、下が実際の機器の話題。
色は2次元空間で、極座標で表現すれば色相と彩度がある(実際の色情報は輝度を含めた3次元空間)。ただし人間の目は対象物の物理的な大きさ(視直径)によって色の2次元平面を見分ける感度が変わる。十分に大きな物体は2次元的に分解できるが、どんどん小さくなると応答が楕円形に潰れて、2次元でなく1次元にしか色を分解できなくなり、さらに小さくすると0次元に、つまり色を分解できなくなる。
NTSCでは小さいものまで分解できる方向(赤・シアン軸)をI軸に、ある程度の大きさで分解できなくなる方向(青・緑軸)をQ軸に割り当てて、それぞれ異なる帯域幅で変調する。これがIQ平面。あと、直交変調するときに両方が単側波帯(残留側波帯?)だと分離できないから、片方は両側波帯で送る必要がある、という理由もあるらしい。
このIQ軸はRGB空間では直交性が悪いので、放送する際はR-YとB-Yで直交する座標(比較的簡単な回路でRGBが得られる軸配置)に変換する。これがUV平面。結局は座標回転でしかないけど、とはいえ33度の遅延素子を各テレビに入れてそれぞれを調整させるよりは、放送側で作るほうが安く済むんだろう。
https://www.jstage.jst.go.jp/article/itej1954/29/10/29_10_760/_pdf
1975年。色々なテレビ信号の仕様とか。かなり細かく列挙されてる。主に映像信号だけど、AFやRFにも軽く触れてる。
https://www.jstage.jst.go.jp/article/nictkenkyuhoukoku/22/118/22_135/_pdf
1976年。RRLの放送衛星を使用した時刻比較の提案。
標準電波を使用した場合は1ms程度の精度。それ以上は伝搬特性の不安定さで制限される。
放送衛星は日本国内の大部分で大電力で受信でき、受信装置も全国各地に配備された装置で可能(この当時はまだ直接放送衛星は打上げられていないはず。たとえばBSE(ゆり、本州で1.6m程度のアンテナで受信できる)の打上げは'78年)。
衛星との位置関係が問題になるのはGOESタイムコードと同様(GOES TCは'74年あたりから運用が始まったGOES(米静止気象衛星)を経由して時刻を配信したシステム)。衛星位置と地上2地点の距離差の計算式も書いてある。
GOES TCは地上から上げた不定期な時刻(平均的な伝搬時間は補正済みのはず)を必要に応じて受信側で補正する方式のはずだけど、RRL方式は衛星放送で配信されている時刻をRRL鹿島で受信し、その時刻を引き込んでいくようなフィードバックで、受信側は距離差分を補正して時刻を決める。
鹿島を基準にすると、稚内や沖縄では2,3ms程度の時間差があるが、テレビのフレーム周期は33ms程度なので、アンビギュイティ無しに時刻を決定できる。10us程度は比較的簡単に達成できる見込みかな。もう少し手間を掛ければ0.5us程度までは行ける。
やはりというか、アメリカ(GOES TC)のほうが一日の長があるな、という感じはする。こういうシステムって実際のところ運用されたんだろうか? それともその前にNNSSとかGNSSとかが出てきたんだろうか。放送衛星の場合、放送に影響を与えないようなシステムであるとか、あるいは放送法との兼ね合いもあるから、あまり自由にデータを乗せることはできない。GOES TCはDCPインテロゲーションを使っているから、DCPIを使うユーザに対してそれを受信できるシステムを構築させる必要はあるけど、とはいえ比較的自由にいろいろ情報を載せられるから、最初にしっかり規格を作って普及させてしまえばあとは好きに運用できる利点はありそう。DCPIだってうまく互換性を持たせておけばそれ以前の機器でも読み捨てれるようなパケットは作れるだろうしな。
RS-170A NTSC映像信号のカラー化される前の規格って何と言う名前だったんだろう、と気になってたんだけど、これはRS-170というらしい。オリジナルの白黒映像がRS-170で、それをカラー化したものがRS-170A。ただしA版はあくまでも暫定仕様であって、正式なものではない。正式なカラー信号はEIA/RSではなく、CCIR System-Mとして国際規格で指定されている。
10年以上前に電子工作をやっていた人間だとRS-232Cは結構馴染み深いはずだけど、どちらもEIAのRecommended Standard仕様。
1,2年前にRS-170のオリジナルのドキュメントを探している人のスレ。技術史的に重要な仕様書なのに、オリジナルは著作権がかかっていて有料で販売されていたからオンラインのアーカイブにも残っておらず、監理団体(EIA)もすでに解散しているから正規ルートで購入することもできない。だれかスキャンしたPDFを持ってない? というような話。
技術史として重要なのにドキュメントが残ってないものってのはたくさんあるんだろうなぁ。
0 件のコメント:
コメントを投稿