IM920c

　IM920cというモジュールを触ってみました。

　９２０ＭＨｚ無線モジュール（コンパクトタイプ）: 無線、高周波関連商品 秋月電子通商-電子部品・ネット通販
　ＩＭ９２０ｃ用変換アダプタ: 無線、高周波関連商品 秋月電子通商-電子部品・ネット通販

　モジュール本体は表面実装の小さなコネクタで、そのままでは使いづらいので、変換基板で2.54mmに変換します。なお、コンパクト以外のモジュールの標準的なコネクタは1.27mm(ハーフピッチ)のピンソケットです(変換基板にもハーフピッチピンソケットが生えています)。

　モジュールは3.3V動作なので、USBで使う場合は自分でレギュレータを持っておく必要があります。XBeeの変換基板だと大抵はLDOを載せてますが、その場合は3.3Vを入れたいときにムカー!!ってなりながら引っ剥がすので、どっちもどっちですね。

　とりあえず今回はGND, 5V, TX, RXを結線しています。というかこの変換モジュールはそれしか出てないので。
　メーカーのドキュメントを見ると、BUSYをフロー制御に使え、みたいな事が書いてあります。ビジー中にコマンドを打つとNGが返りますが、フローに使えばハードウェアでディレイしてくれるので良さそうです。

　コマンド自体はクセも少なく素直なもんです。タイミングだけ気をつける必要がありますが、それもシビアではないので、人間が使う分には何も気にする必要はありません。
　19.2kボー/CRLFは注意する必要がありそうです。よくある9.6kボーとか115.2kボーではないです。また改行もCRが必要です。

　それから、通信を行う場合は、登録したIDから以外の送信は受信しないという動作です。なので、一番最初に使うときにはペアリングが必要です。「無線機器なんて送信すれば受信するだろ～」とか油断してるとハマります。subGHzなので特小トランシーバみたいな雰囲気ですが、モノとしてはXBeeに近いです。まぁそりゃそうだ。

　スペクトルはこんな感じです。
　下側の、帯域幅が広くて時間が短いほうが高速モード、上側の、帯域幅が狭くて時間が長いほうが長距離モードです。
　長距離モードは「スペクトラム拡散」と説明されてますが、高速モードのほうが帯域幅はかなり広いですね。
　当然、通信モードが違うデバイス間では通信はできません。

　長距離モードなら帯域幅が狭いので、SDR#からRAWで吐いてステレオミキサ経由で受け取ればソフトウェアデコーダが作れそうですね。どんな変調方式なんだろう。

***

　例の、「2.4GHz帯は使いたくない」用途でこのモジュールを使おうか、と思いっています。通信距離はせいぜい300m未満なので、おそらく足りるはずです。コレで駄目ならXBeeだって駄目だろうし(XBeeのほうが周波数が高いので、地上対地上ならフレネルゾーンが狭い分有利かもしれませんが)。

　どれくらいの速度が出るかわかりませんが、高速モードは50kbpsが出るそうなので、2kbyte/sec前後は通ると思います。それでも低画質なJPEG1枚送るのに5秒以上かかる計算ですが。。。

　スペースプローブ/缶サットでカメラで撮影してダウンリンクする、というミッションをやる場合は、QVGAでガッツリ画質落として、それでも10KB以上あるので、1枚しかダウンリンクできません。もちろん、ARLISSのような、高高度から放出したりするなら別ですが。
　1枚しかダウンリンクできないなら、確実に最初の1枚で写したいものを写す必要があります。そうすると、太陽センサのようなもので自分の姿勢を判断して、カメラが下を向いたタイミングで撮影する、という機能が必要になると思います。ちゃんと下を向くかは運任せなので辛いところですが、何も写ってない青空をダウンリンクするよりはマシなはずです。JPEGならソフト的に判断するのもありかもしれませんね。

　ま、今のところはミッションも何も決まってないので、どうなるかはわかりませんが。とりあえず通信モジュールくらいは使えるようにしておかないと何も作れないので、もうちょっと調べてみます。
　もっとも、自分でプローブを打ち上げると、プローブのほうが気になって、ダウンリンク画面なんて見てる余裕ないんだよなぁ。WinとかMacなら音声合成が簡単に使えるので、ダウンリンクを音声化できるような仕組みを作っておくといいかもね。

PICマイコン(再)入門

　久しぶりにPICマイコンを触ってみた。
　いつ以来かは覚えていないが、11年秋ごろから12年夏ごろまでの間にSTM32をメインに使うようになっているので、そのあたりだろうか。

　今回は手持ち部品の中から簡単に見つかった、PIC16F84AでLチカしてみた。セラロックを探すのも面倒だったので、これまた簡単に見つかった10MHzの水晶と15pFの負荷でタイミングを作った。

　ライタにはPICKIT3を使用し、開発環境はMPLAB X + XC8を使用した。
　夜中に思い立ったので、トータル1GB近い開発環境のダウンロードにおもいくそ時間がかかった。どーしてこんなにデカイんだ。
　ソースコードのビルド自体は、マイクロチップのオンライン開発環境でも行えるらしい。ということで簡単にLチカコードを書いてみたのだが、PICへの書き込みにははやりMPLAB X(に付属の書き込みソフト)が必要なので、結局MPLAB Xをダウンロードしたのでオンラインコンパイラでは動作確認していない。

　LチカのコードをCで書いた場合、ROMは44ワード、RAMは5バイトほど消費したらしい。信じられないくらい狭い空間で動いてる。


　僕がSTM32に移行した頃は、ちょうどMPLABからMPLAB Xへの移行時期でもあった。なので、僕はMPLAB Xをほとんど触ったことがない。
　でもまぁとりあえずなんとかなった。


　普段はSTM32を使っているが、今回はできるだけ小さいマイコンを使いたいという需要があったので、PIC10F222を使ってみたかった。ということで、久しぶりにPICの開発環境を構築してみた次第。機会があったら10F222も買ってみようっと。

天体の位置

　太陽や月、いくつかの惑星、いくつかの恒星の位置を計算するための方法は、海上保安庁の天文・暦情報に計算方法やパラメータが書いてある。
　パラメータはテキストファイルで渡されるが、parseが非常に面倒。いちおう太陽と惑星の関係だけはparseできたが、なんかきれいじゃない。もっとうまいやり方を考える必要がある。

　パラメータは1年毎に更新する必要があり、数字の数が膨大なので、手作業でやるのは現実的じゃない。機械的に処理するべきだが、その機械的な処理の信頼性が低い。


　とりあえず、パラメータは別の方法でプログラムに埋め込んでおいて、指定した日時の太陽のRa/Dec/Auを計算する、というのはなんとなく動くようになった。
　もっとも、Ra/Decでしかないので、ここからAziEleにするにはまた別の面倒な処理が必要になるのだが。


　面白いのは、いくつかの主要な恒星のRa/Decを求めるパラメータも付属している点。恒星位置なんてそうぽんぽん動くものじゃないだろうから、そうそう補正しなくても事足りるだろうに。それとも恒星ってそんなに動くんだろうか。

　海保の情報だから主に天測航法を行うもので、揺れる洋上での肉眼観測程度の精度だと思うのだが、どれくらいの精度まで想定しているんだろうか。

　赤道上で東西方向に1度ズレれば100kmを超える誤差になってしまう。
　六分儀を使った天測航法では5km程度の精度で測位できるそうだから、0.05度(3分度)程度の精度で角度を計測できるのか。
　ちなみに、地球は0.05度回転するのに12秒しかかからない。天測航法を行う場合、恒星の高さを0.025度の精度で観測できたとして、時計のズレを6秒未満にしておく必要がある。
　ヨットで太平洋を横断するのは、最速で数週間、ゆっくり行って2ヶ月前後、という感じ? 最速で行く場合、月差10秒程度の時計でいいので、比較的精度のいいデジタル時計なら達成できる。それでも、クォーツ時計でも月差20秒程度とのことなので、事前に信頼できる時計と比較して精度の高い時計を選ぶ必要がある。
　2ヶ月で横断するとなると、月差2秒程度の時計が必要になるので、市販のクォーツ時計より10倍精度の高い時計が必要になる。
　今の時代でもこの有様なんだから、昔の航海に使われてた時計というのはどのようなものだったのか。昔はいまより時間をかけて航海していただろうから、さらに高精度の時計も必要になるはず。もっとも、これは精度5kmで測位する時の話だから、大昔の「陸地にたどり着ければOK」くらいの話なら1-2桁低精度でもいいが、それでも機械時計で達成するのは大変そう。


　とりあえず、直接テキストファイルをロードするのは一旦諦めて、別の方法を考えておこう。パラメータは年1回の更新だから、数字のうち間違えが発生しないような方法であれば手動で読み込みやすいように整形するのも非現実的ではない。
　それにしても諸々処理が多くてかったるい。

Boston Dynamics Sand Flea

　今更かよ、という気もするけど。
　人と話しててコイツの構造はどうなってるんだろうねぇ、という話題になったので。



　SandFlea | Boston Dynamics

　動画のサムネイルの、向かって左側の黒い突起が、ピストンの先端で、こいつを押し出すことによって飛ぶらしい。このピストンがある方が機体の後方。
　後輪の内側、機体の外に、機体を立てるためのアームが内蔵されている。可動範囲は±100度くらいかな? 立ち上げるだけなら90度あれば十分だけど、もう少し起こせば裏表ひっくり返せる。必要はないだろうけど、あれば何かの役に立つかも。

　この機体は、たぶん上下の区別がない。「地面に接している面が下側」という考え方。なので、アームも上下に出せるようになっているはず。
　飛翔中の姿勢は、タイヤをリアクションホイールのようにして制御する、とのこと。ただ、この方法では1軸しか制御できない。残りの2軸はどうにもならないので、「4輪で接地して衝撃を吸収する」とか「飛翔中のオンボードカメラを安定化する」というのに、どれくらい効果があるかは不明。でもまぁ普通に押し出せばロール軸の速度は与えられないし、バランスが良ければヨー軸も影響を受けないだろうから、ピッチ軸だけでもかなり安定できるのかも。

　1回のチャージでおよそ25回ジャンプできる、とのこと。中に高圧ガスでも持ってるんだろうか。ピストンのストロークはあまり無いので、ガスの消費量はそれほどでもないのかも。
　ジャンプの高さはある程度制御できてるっぽい。地上から屋上に乗る場合と、屋上から地上に降りる場合では、必要なジャンプ量は全く違うし、同じジャンプ量だと後者は前者の2倍の高さから落ちるから、何らかの制御は必要なはず。
　バルブを開く長さである程度は制御できそうな気もするけど、そもそもの加速時間が短いのでどれくらい効果があるんだろうか。

　ピッチ軸を制御できて、ヨーとロールの回転がほとんど無いなら、ピストンを陽圧にして、ピストン側から落ちれば、エアサスペンションみたいに衝撃吸収できそう。地面が柔らかいと突き刺さるので諸刃の剣だけど。

***

　小型の筐体でも不整地で動き回れるソリューションがほしいけど、あんまりいいものがないなぁ。
　ピストンだと、地面が硬いことが大前提なので、草の上とかに落ちたら力を伝達できない気がする。


　その人と話してるときに面白そうな機構を教えてもらったけど、作るのが大変そう。
　部品を探そうと思って地元のホームセンターに行ったら使えそうなもの何もなかった。田舎は試作が辛い。という話を東京住みの人に言うと「秋葉原に電車で行ったって送料以上に交通量がかかるんだから通販使ったほうが安い」とか言われるんだが。

アンテナ

　水平偏波で受信したと言ったな。あれは(ry

　ベランダの外に、屋根をクリアするようにコリニアを持ち上げて、その横にV/Uの垂直偏波で受信アンテナを取り付けています。
　また、手の届く範囲にもV/Uのアンテナがあり、これを水平にしてキューブサットの受信を行っています。行っているはずでした。
　が、実際はこの2本のアンテナを取り違えており、実際には上段の垂直偏波で受信していました。

　どーりで家の影になるところでもガッツリ受信できるはずだ。。

　下半分が上段の垂直偏波、上半分が下段の水平偏波です。
　下段には変なノイズが乗っている感じですね。同軸線を通してる経路はほぼ同じなので、何が原因か不明。近くにGPSアンテナがあるけど、こっちは未使用なので悪影響はないはず。浮いてるのが悪影響の影響がないとは言えないかもしれないけど。
　ワンセグチューナのすぐ横にWiMAX2ルーターがあるけど、上段には影響がないので、あまり大きな影響はないはず。ADS-B受信のRasPiもあるけど、こちらも同上。


　おまけ

　違法局強すぎるんじゃ～
　バンドプランでいえばこの周波数は衛星専用ですが、まぁバンドプランに従うような奴らではないので。っていうかコールサイン自体言ってないし。
　違法局にピンポイントにHANE来ねーかなー。

FSK

　特小にFSK(周波数偏移変調)を通してみた。

　上が送信、下が受信で、位置はおおよそ合わせてある。
　こんなに歪むのかぁ。。。

　高側2400Hz、低側1200Hzの2値だが、音声帯域幅の関係か、高側がかなり減衰してる。あと、低側の周辺はDCカットが強く効いているのか、波形の乱れが激しい。
　こんなのを復調しなきゃいけないなんて悪夢。


　最初は「振幅2値と周期2値で4値送ればいいんじゃね」とか思ってたが、それどころじゃない。

　試しに、2ASKを送ってみたが、これも乱れる。
　念の為、OOKを送ってみたが、これも乱れる。

　どーすりゃいいんだ。

　音声帯域使うのって大変だなぁ。
　アマチュア無線でデータ通信するの、よくこんな劣悪な回線で通せるもんだ。


　ビットレートをガッツリ落とせば、そりゃ通るだろうけど、缶サットのHKデータだって通らない。
　キューブサットの場合、どんなに軌道高度が低くても、直上のパスなら数分間はウインドウがあるので、CWの速度でも問題ないけど、ロケットで高度150mとかに打ち上げる缶サットの場合、飛行時間は10数秒程しか確保できない。その間に変化のあるデータを得ようとすれば、データ1組を1秒として、2秒毎に送信しても5回しかデータを得られない。
　1秒で16バイトのデータを送る場合、128bit/sec以上が必要になる。
　DTMFは1秒に10回送ったとして、1回に4bitしか送れないので、1秒では40bitしか送れない。
　DTMFの4倍程度のデータレートがあればいい、と考えればなんとかなりそうな気もするが、それにしたって得られるのはHKデータだけだから、画像のダウンリンクなんて夢のまた夢だねぇ。

　おとなしくXBeeとか使ったほうがいい気がしてきた。モジュール小さいし。UARTで通信できるし。
　2.4GHz帯を避けたいというだけなら、920MHz帯のモジュールを使えばいいわけだし。

***

　なんか、最近、自宅のWiMax2がどんどん遅くなってきた。この時間帯はかなり遅い。昼間でも400kByte/sec程度しか出てない感じ。公称値の100分の1か。
　QAM仕事しろーー！！って感じだけど、自分もここまで苦労するとあんまり無線通信の悪口言えない。。。

手探りでデコードしてみる

　とりあえずVOXを使えば音声データを送信できるのはわかったので、試しに特小からIC-R6にQAMっぽい信号を送ってみた。

　上が受信波形、下がそれに正弦波・余弦波をかけてLPFを通した波形。
　QAMは800baudで、QAM16、最初の0.5秒間は無変調の正弦波、0.5から0.75秒の間は規則増加、という信号にした。

　IC-R6はスケルチが開くときに大きなDCオフセットが発生するので、今回はスケルチを開きっぱなしで受信した。
　スケルチを開いているところは、ホワイトノイズなので、800Hzのスペクトルがそれなりに出ている。
　最初の無変調(パイロット信号)の部分はsinが0.2くらい、cosが0くらいで、周波数ズレも無く計測できてる。そりゃ1台のPCで送信と受信を同時にやってるんだから、周波数ズレが出たらそれはそれで困るんだが。

　その後、若干QAMの信号に対してもsin/cosをかけた波形が見えている。

規則増加の部分を処理した図。
　sin成分は4値で規則増加しているように見えるが、cos成分はほとんど何も出てきていない。1変調で1ずつ増加するので、sinが4変調で1増加するなら、cosが1変調で1増加するはず。
　
　送信した波形と受信した波形を見比べると、かなり形が崩れているのがわかる。おそらく帯域幅が足りなくて、DC付近と高周波がカットされているんであろう。
　高周波が足りないなら、ボーレートを下げれば擬似的に高周波側を広くできるけど、そうするとDC側がカットされる。QAMはDC成分にも意味があるので、それは困る。


　実際のところ、QAMってどれくらいの帯域幅があれば足りるんだろうか?
　電波をQAMで変調する場合、DC成分はカットされるだろうし、帯域幅の制限もあるから、ある程度のバンドパスフィルタを通していると思うんだが。
　ざっくりしたQAMの説明はいろいろ見つかるけど、こういう細かいところはあんまり見つからない。。


　特小帯域でデータ飛ばすならFSKとか使ったほうが楽だろうなぁ。


追記
　最近のデータ通信はOFDM+QAMの組み合わせが多いらしい。地デジとか、LTEとか、その他いろいろ。
　OFDMはスペクトル幅が広すぎるとうまくいかないはずなので、QAMのスペクトルもそれほど広がりはないはず。

　どこが違うんだろうか。
　振幅値のあとにLPFを通すのかな? それにしたって受信側でどうするかという問題が残るけど。

OPC-2133

　アイコムのOPC-2133を買ってみたのだが、結論から言うと、当初の目的には使えなかった。一方で、予想外の使い方はできた。

　もともとは、外部でPTTを操作して音声ラインを特小で飛ばしたかった。
　が、この変換アダプタではその使い方はできなかった。
　どうやら、この変換アダプタはVOXで使う前提らしい。

　それなら、と思い、本体のVOXをoutにして、変換アダプタの向こうに、以前作ったDTMFエンコーダ(STM32F3のDACからDTMF信号を出すやつ)を接続してみた。
　予想通り、外部から信号が入ったらそれを送信してくれる。
　DTMFエンコーダからは80mVppくらいの信号が出ていて、特小から送信すると、普通にマイクに話し比べるのとくらべて、かなり大きな音量で出力される。もっと低い信号レベルでいいかもしれない。
　ただ、僕が持ってる特小はマイク感度がかなり低い気がするので、何を基準にすればいいのかわからないが。
　SDRで受信してaudioのスペクトルを見るとかなり高調波が出ているから、クリップされてるのかもしれない。とすると、やはり信号レベルはもっと落とすべきか。


　ということで、目的の、PTTをマイコンから制御して、というのには使えないのはわかったが、VOXで勝手にPTTを操作させるというのはできることがわかった。
　QAMを送るなら、最初に無変調の正弦波を出してやれば、頭が切られることもないし、位相同期用のパイロット信号としても使えるし、まぁなんとかなるんじゃなかろうか。

　ただ、正直、QAMはかなり飽きてきたので、どこまでやれるか不明。

違法局滅ぶべし

　CUTE-1.7+APD IIです。
　このあとかなり強いピークが出てました。IQで取ってあるのでで気が向いたらデコードしてみようっと。

　ウチの傾向として、北側のほうが強く受信できてる感じ。
　ベランダは南西向きで、北側は家の影に入ってるはずなんだけど。

　4エレくらいの八木でトラッキングしたいなー。


追記

　IQファイルを読んでFFT通して画像化するプログラムを作ってみた。パラメーターの調整が大変。
　画像の中心は437.275MHzで、CUTE-1.7+APDIIのCWの周波数に合わせてある。右が高周波側、左が低周波側で、上が開始地点、下が終了地点。SDR#とかとは上下が逆なので注意。
　CUTEのCWはうにょんと曲がってるのがわかる。
　受信中は気が付かなかったけど、結構ノイズフロアが動いてる。なんだろう? 見えないところの違法局から影響受けてAGC動いたかな?

　この画像はブログに貼り付けるようの、解像度の低い画像。モールスのデコードには、時間分解能を高めて出力した画像を使う。
　1パスで10分弱の録音だが、CWのデコードがなんとかできる程度の解像度の分解能でも18000ピクセル強ある。1800ピクセルじゃないぞ。

　ざっくりデコードしてみると、307A632E17CUTE87CBAEA33C32307A6F2917CUTEあたりが読み取れた。
　Cute-1.7 + APD II - CW Telemetry Format -によると、1回の転送で32文字が1組となるらしい。上のデコード結果だと数文字足りないので、デコードミスかも。
　ただ、CUTEが2回出てきているから、少なくともCUTE系の衛星であることは間違いないはず。


追記
　上記の桁数で問題ないようだ。
　デコード結果は、3.3V電圧が3.26V、5V電源が4.90V、バッテリーが4.20V、メインバス電圧が5.90V、通信ボード温度が28.8℃、バッテリー電圧が24.9℃、バッテリー電流が-0.99A、144MHzのSmeterが-83.1dBm、といった感じらしい。1.2GHzのSmeterはレンジ外っぽいので除外。
　

謎衛星

　SEEDS-IIを受信しようと思ったら、25kHzくらい下にドップラーシフトを伴うCWがあった。
　録音してなかったのでスペクトルから解析。
　なんの衛星だろう?

追記
　XI-IVのあたり

追記

　CUTE-IのCW(緑の線の間)。相変わらず、文字通りの無変調波が出てる。強弱があるのは衛星の回転かな? ほぼ直上を通過するパス。JS Orbit上で直上付近の時にCW周波数から1kHzもずれてなかった気がするので、周波数精度は高そうだ。
　2000km離れて仰角17度でもタイミングによってはかなり強いCWが入ってくる。モノポールの水平固定で、すでに屋根の影に入ってるのにこんなに強く入ってくるとは。ドップラーシフトがなきゃ衛星だとは思えんな。
　2900km、仰角4度でもそれなりにピークが見えている。3000km/仰角2度でもたまーにピークが出てる。さすがに水平線より下に入るとピークも途切れたが。
　本当に100mWなんだろうか?

　CUTE-1を基準に考えるのはマズそうだが、衛星からのCWがそれなりに取れてることを考えれば、amazonで安売りしてるLNAを挟めばだいぶ改善しそうな気がする。
　このあたりも違法無線は入ってくるけど、ガッツリ潰されるというほどではないから、大きく影響を受けてるわけではない。

SEEDS II

　昨日の夕方に、何の気なしにSEEDS-IIの周波数を覗いてみたら、それらしいビーコンがいた。同定はできてないが、周波数とドップラーシフトと強度から考えれば、SEEDS-IIの可能性が高そう。
　受信は144/430のモービル用マグネットアンテナをベランダに水平偏波に設置し、ワンセグチューナーに直結しているので、お世辞にもいい環境とは言えない。
　試しにXI-Vを聞いてみたが、何も受信できなかった。

　SEEDS-IIのCWは100mWらしい(←うろ覚え。ちょろっと探しても出てこなかった。どこで読んだんだろう?)。
　XI-Vは10mWとかだった気がする(←うろ覚え。東大のページは404になってる。。。)。
　この記憶が正しいなら、SEEDS-IIが受信できてXI-IVが受信できないのは、まぁわからんでもない。


　ベランダに430の2エレか3エレを設置して、安いLNAを通してからSDRに入れれば、ちょっとしたキューブサットのCWなら受信できるかな、と計画中。
　昔とある手伝いをしたときに(自腹で)買った430の15エレが押し入れに入ってるけど、15エレだと細すぎて固定運用は無理だと思う。ベランダから5mくらい立ち上げてAziEle追尾したいなぁ。

***

　最近、衛星追尾Webカメラを作り直してる。
　とりあえず最低限の機能は一通り実装して、ロケットボディのような大きな物体を追尾すれば、ちゃんと光点を捉えるので、TLEからAziEleを計算して追尾、というのは正常に行えているのは確認できた。
　ただ、捕捉時の誤差がかなり大きいのが気になる。
　試しに大きく離れた恒星を複数個観測してみると、だいぶ誤差がある。例えば東側の恒星でAziEleを合わせると、西側の恒星に対してそれぞれ数度のズレが生じる。
　ステッピングモーターの128マイクロステップ、ダイレクトドライブなので、バックラッシュ等の問題はない。マイクロステップが線形かどうか気になるところだが、今回の場合はあまり関係ないはず。200ステップのモーターなら1ステップ1.8度なので、それ以上の誤差があるということは、モータードライバの前に問題がある、ということになるはず。
　恒星の計算はdoubleで行い、AziEleからモータードライバまではfloatで計算している。いくらfloatの誤差が大きいとはいえ、3度の誤差だと有効桁数3桁未満ということになる。そんなはずはない。floatなら少なくとも6桁はあるはず。

　TLEの計算に誤差が入ってるのは既知の問題だが、それが恒星の追尾に影響を出すことはありえない。ということは、恒星の計算に問題がある? それともその後? どうやって切り分ければいいだろうか。。。
　軸にエンコーダでもつけて指定した角度に動いているか直接確認するのが一番手っ取り早いが。どうしたものか。
　壁にメジャーを貼り付けて、Webカメラで指定した角度が動いたときに、その角度分の距離を移動するか、という感じで調べれば、1度とか5度くらいなら調べられそう。でもそれ以上の角度を調べようとするとかなり大変になりそう。今回の場合は90度とか180度回したときの誤差が問題になっている。
　どこから手を付ければいいものか。

QAM

　QAM(Quadrature Amplitude Modulation / 直交振幅変調)を試してみた。

　QAMの動作原理を回路に落とし込んでみる - ecmemo_nのブログ
　ここが一番わかりやすかった。

　サンプリングレート32kHz、搬送波320Hz、ボーレート16baud、という条件でQAM16を試してみた、の図。
　下の図はIQをXYにマップした図。最初は0から始まるが、やがて一番右上に落ち着いて、その次はひとつ左に移動し、一番左側に移動したらひとつ下の右端に移動し、という感じに動作してるのがわかる。

　LPFの特性が悪いので遷移が遅かったり、ぐるぐるしたりしてるが、ボーレートの区切りさえしっかり見つけて、0.8bitあたりでちゃんとサンプリングできれば、しっかり復調できそう。
　ただ、送信側と受信側でキャリアの位相がズレると全く別の結果に復調してしまうので、このあたりの実装が面倒かも。どうやって合わせるんだろうか?
　あと、同じ符号が連続した場合、変調の区切りが見つからない気がする。8B10Bみたいな、常に符号が切り替わるような符号化を予め行うんだろうか? 8B10Bで10bitに変換してQAM32で送る、ってのはアリかもな。


　16baudで変調しても、1baudあたり4bitを送れるので、64bit/secとなる。
　実際に使うなら、音声帯域で伝送するにしても、搬送波は1.36kHzにすれば4倍になるし、ボーレートももう少し上げれそう。ということは、512bit/secくらいは簡単にできそう。とはいえ、64byte/secだと凄まじく遅いなぁ。
　缶サットっぽいヤツのダウンリンクに特小トランシーバで伝送しようか、とか考えたりしたけど、64byte/secだと簡単なHKデータくらいしか載せられない。QVGAくらいのJPEGをダウンリンクできたらいいなーとか思ってたんだが。JPEG1枚15KBとして、4分とかかかってしまう。プローブの飛行時間は12秒程度しかない。


　スペースプローブコンテストだと、今年は運営がyoutubeライブストリーミングをやってて、打ち上げが終わったら回収の様子をドローンで空撮してた。
　なんで打ち上げは空撮しないの?と聞いたら、ドローンの映像ダウンリンクが強くて、XBee等に悪影響を与えやすいため、とのこと。じゃぁプローブ側で2.4GHz帯を使わなければ打ち上げ全体を中継してくれるのか? と思った次第。


　実際のQAM16とかQAM256とかがクッソ早いのは、主搬送波を直接変調してしまうので、例えば800MHzで伝送するなら、1変調あたり10パルス使うとしても、80Mbaudくらい出せる。QAM16としても320Mbps(40Mbyte/sec)くらい出せる。
　特小トランシーバを使う場合、音声帯域の副搬送波を使う必要があるので、QAMのキャリアをせいぜい2kHz程度にしかできない。
　FMトランスミッタにQAM16を入れて、SDRで受信したらもっと帯域出せるかな? でもアップリンクに使えないのが欠点か。そもそもFMトランスミッタの出力ならよほど受信側で利得稼がないと無理だろうし。

　缶サット/スペースプローブは別にしても、音声帯域でそれなりに速度が出る変調方式が作れればいろいろ使いみちはありそうなので、もうちょっといろいろ考えてみる予定。64byte/secとしてもDTMFに比べれば10倍は早いので。って、10倍しか違わないんか～い！うーん。。。


追記

　32ksps、キャリア320Hz、320baudの設定で試してみた。
　前回はLPFに a = a * (1 - k) + b * k のタイプを使っていたが、今回は平均移動を使うようにした。そうするとかなり綺麗な波形になる。
　下の画像は見づらいが、16箇所に強いピークが出ている。ピークの強さは対数スケールなので、途中の成分はほとんど出ていない。

　上の画像は1秒間、320変調期間で、下は10変調期間の拡大。1変調あたりの後半半分は綺麗な形。

　ということで、320Hzのキャリアで320baud、1280bps/sec(160byte/sec)が達成できた。最初に書いた「大した性能でねーじゃん」というのは、やり方がまずかった、というだけの話だった。
　200byte/secくらいのテレメ用通信モジュール、作れるかな? 理論値だと800byte/secくらい出るけど、それにしたってもう一声ほしいよなぁ。音声帯域でQAMを送るとキャリア周波数が上げられないのがネックになるか。FMの音質に期待するなら、64QAMくらいは通せるかな? 256QAMとか通せればいいけど、さすがにつらそう。頑張って256QAMにしても、16QAMの2倍にしかならないんだよなぁ。。4096QAMとかどんな魔法使ってるのかね。


追記

　256QAMのテスト。
　PC内で振幅も位相もキッチリ合わせてあるので綺麗なもの。現実もこうなってくれれば楽でいいんだが。。。

　QAMの制限はどこにあるんだろうか? QAMで必要な帯域幅ってどれくらいなんだろう。バックボーンや放送でQAMの多値化が進んでるってことは、帯域幅を無闇矢鱈と増やさずに拡張できる、と考えれば、QAMのシンボルあたりのビット数と帯域幅は比例しないと考えられるが、そんなことを言うともっと細い帯域で送ればよかろう、という話になるので、たぶんQAMでも帯域幅を増やしたほうが安定するんだろうな。
　振幅のダイナミックレンジに帯域幅が効くのかも。知らんけど。


追記
　QAMの復調の方法、「同期した局発を掛けます」みたいな説明ばっかりで、どうやって同期するかという話がほとんど出てこない。

　このグラフは、IとQをそれぞれ前回からの差をとり、その絶対値を加算している。
　変調が変化するときは急峻な立ち上がりがあり、変調の後半半分は変化がほぼ出ない。つまり、差の和が閾値未満が0.5変調期間に近い間続き、その直後に急峻な立ち上がりがあれば、そこが位相0の地点、ということがわかる。はず。
　ある程度位相がずれていてもこの傾向は変わらないようだ。
　どこかで重大な考え違いをしている可能性もあるけど。


　特小トランシーバから任意の波形を出すためには、マイク入力としてライン出力を入れてやる必要がある。とりあえず変換コネクタをぽちったので、来週中には届くはず。うまく出せるといいが。

　特小トランシーバは変調方式がFM電話なので、デジタル信号を入れるのはやめてね、というのがメーカーの言い分らしい。なので、DTMFのようなデジタル信号を通すのはダメ、ってことらしい。その理論で言えば、当然QAMも不可だろう。
　もっとも、技適取ってある無改造の送信機から10mWのUHFを、未使用のchを確認した上で、クッソ田舎で放射したところで誰にも迷惑かけるわけじゃないし、という気もする。トランシーバに入れるのはただの音声信号だし。後でどっかから大目玉食らうかもしれんが。。。

　国が補助金出してる工事でデジ簡を使ってデジタルデータを飛ばしてるらしい、という噂はある。その噂が正しいなら、デジ簡易にデジタルデータを入れて飛ばすのは問題ない気がする。
　ただ、デジ簡はデジタル変調なので、その中に入ってるのが音声信号だろうが、音声信号に偽造したデジタル信号だろうが、関係なくデジタル符号に変調してしまうし、デジ簡をデコードできない機材から見れば、たぶんどっちもホワイトノイズが入ったFMにしか聞こえないはず。そういう意味では、デジ簡は目的外使用がやりやすい、とも言えるかも?


追記

　QAMの生成をC#に移植して、乱数を変調してWAVEに書き出してみた。
　よく考えたらWAVEは整数並べただけなんだから、てきとーにヘッダつければCのコードそのまま流用できるじゃん。後の祭り。まぁCでヘッダ作るよりは、前に作ったC#のコードを流用したほうが楽だと思うので。。
　横軸は10msec/divです。

　44.1ksps, 1.5kbaud, 16QAM, 6kbit/sec(0.75kbyte/sec)の設定。
　かなり低域側にスペクトルが広いし、高域側にもそれなりになだらかに出てる。DC付近でも0にならず、かなり出てるのが気になる。
　QAMはDCにも意味があるはずなので、AC結合されると復調できないかも。ざっくりと波形を見る限りはほとんどDC成分無いように見えるんだけどねぇ。
　baudrateを変えても、スペクトルのピークが移動するだけで、坂の形状(dB/octとか?)はあまり変わらない感じ。
　実際のQAM変調でも似たような感じになるはずなので、空間に放射する前にBPFに通して帯域制限してるはず。
　QAMの変調はあんまり計算コストかからないけど、BPF通すのは大変だなぁ。マイコン内でFIRに通すより、外にオペアンプでもおいたほうがいいかも? 音声帯域なら高速OPアンプは必要ないし。でもOPアンプ1-2段分くらいならIIRやFIRでやっても大したコストじゃないかな?

ATCトランスポンダ

　興味本位で探してみたけど、いまいち理解できてない。
　わかりやすい資料とかあったら教えてください。


　トランスポンダは軍用が1,2,3,4,5で、民間用がA,C,Sになる。モード3とモードAは同じもの、モードCはモード3/Aの拡張、という感じらしい。モードSは軍民両用らしい。モード5はモードSの暗号化らしい。モードSを拡張したモードES(Enhanced Squitter)というのもある。
　モード5はモードSの暗号化のようだが、ただの暗号化だけじゃなく、スペクトラム拡散とかいろいろやってるんであろう。


　モード3/Aはスコークの応答、CはAに加えて気圧高度、SはCに加えて機体固有のIDが含まれる。ESではSに加えて位置情報や進路、上昇率を送信する。S/ESは定期的に送信(放送: Broadcast)される。ADS-Bはこれを利用しているからB。放送頻度はESで最大6.2Hz以下、Sで1Hz(±0.2Hz)の範囲らしい。ESの場合は通常4Hz、何かあったら6Hzまで増加可能、という感じだろうか。S/ESの0.2Hzはマージンの意味っぽい。
　ESは位置情報があるからBroadcastに意味があるけど、Sを放送する意味はなんだろうか? 「自分はこの空間に存在しているよ」以上の情報は送信できない気がする。それにESを受信すればSの情報は不要なはずだし。ESに非対応のTCASではSの放送を受信した後にその機体のアドレスを指定して質問し、C/Sで応答する、という感じだろうか?


　トランスポンダは空中衝突防止装置(TCAS)にも使われる。
　アンテナはある程度の指向性アンテナを複数内蔵しているので、どの方向からの応答かはおおよそ把握できる。応答を複数回受信し、自機と衝突しそうなコースである場合はその旨をパイロットに通知する。
　たぶんAはTCASには使用できない。
　C/S/ESでは気圧高度をやりとりするので、どれくらい上にいるかがわかるし、時系列で見れば上昇率も推測できる。
　ESであればGPSの位置情報と気圧高度、上昇率があるから、より細かく判断できるはず。


　で、S/ESの場合は機体固有の番号が含まれている(パリティ含めて24bit?)。この固有番号は機体のレジと1対1で登録されているらしい。
　この場合、機体にレジがなければモードS/ESの放送はできないのか? たぶんできない。レジがない機体はA/Cのみ、となるはず。もっとも、レジがない機体は飛行機としての飛行ができないし、日本ではわざわざホームビルドしてレジ取ろうなんて人はごく少数だろうし、レジが取れない物(e.g.熱気球)は航空機扱いじゃないし、それで問題ないんだろう。

　米国では2020年までにすべての飛行機がADS-B(モードES)に対応する必要があるらしい。米国の場合、ホームビルド機が多いようだ。が、それに比例するように、ホームビルド機でも比較的簡単に(実験機用の)レジの発行を受けることができるらしい。レジさえ得られればモードESの機材は搭載できるはず。
　ただ、例外もあるようで、ざっくり言えば「発電機がない機体は免除」ということらしい。グライダーとか、気球とか?
　トラポンの消費電力は20W程度だそうなので、リチウムイオンバッテリーで言えば1.5kg分位を載せておけば十分に1フライト分の給電はできるはず。でも充電の手間とか考えたら無しにしちゃったほうがいい、という判断だろうか。そもそも気球は最初から民間航路とは分離してるだろうし、グライダーのような積極的に山岳波を使う機体と民間機(ホームビルド動力機含む)の航路も分離されてるだろうし、そもそも衝突の危険が少ない、というのがあるのかも。


　モードESとは別の方法として、UAT(Universal Access Transceiver)という方法もある。低高度を飛ぶ小型機はUATを、高高度を飛行する場合はESを、という使い分けらしい。小型機向けとはいえ、978MHzを使うので、1090MHzとあんまり差がない。これくらいの差ならどっちでもコストは対して変わらない気がする。
　UATの978MHzというのは、DMEのch17Xに該当する。飛行中にDMEを17Xに設定しておけば、UATに対応した他の航空機が接近した場合、DMEにその機までの直線距離が表示されるので、定期的にDMEを確認しておいて、接近してきたら周辺確認を厳となす、みたいな運用なのかな? 僕の理解だとDMEってそんなに柔軟じゃないと思うんだが、近年のモノは柔軟に使えるのかも。
　UATを使う場合、質問の送信には既存のDME機材が使用できる点、応答の送信も質問の送信と同じような回路構成が使えるため、送受信機のコストが安く抑えられる、というのが小型機向けに普及した理由かも。


　日本では、だいぶ前(08年前後)の重気球(1t未満?)にもATCトランスポンダが搭載された例があるらしい。国内の実験用の気球ならもちろんレジは無いだろうから、AかCになるはず。その他にも、大気球にトラポンを乗せるのはよくあることらしい? ただ高高度を飛翔する場合は搭載できる重量が数kgしかないので、トラポンを乗せるのはつらそう。もっとも、50kmなんて高度には飛行機なんぞ一切いないわけだから、ミッション機材の重量に余裕のある、高度数kmから15km程度の実験にはトラポンを乗せる、という程度だろう。


　過去の事例では、エアロメヒコ航空498便空中衝突事故(1986年)では、DC-9と小型機が空中衝突したが、小型機にはAだけで、Cは搭載されていなかった模様。DC-9についてはトラポンについては書いていないが、"自動警報装置"(automatic warning systems)は搭載されていなかった模様。
　"この事故やターミナル・コントロール・エリア内で発生したその他のニアミス (near mid-air collisions, NMAC) の結果として、連邦航空局 (FAA) はアメリカの空域を飛行する全てのジェット機に空中衝突防止装置 (TCAS) を搭載すること、および混雑した空域を飛行する軽飛行機に高度を報告できる「モードC」トランスポンダを搭載することを義務付けた[11]"(ja.wikipediaより)とのことなので、衝突回避のためにはTCASが必要で、そのためにはモードCが必要、ということになるはず。小型機全てにTCASを装備するのは、当時は現実的ではなかったのかな。小型機にはTCASがないにしても、もう片方のTCASで回避するには、小型機からのモードCの応答が必須、ということなのだろう。片側だけでもTCASがあれば、衝突コースからの回避を提案できるので、なにもないよりはマシ、とのことなんだろう。


　モードSが制定されたのが1987年、ESが1998年、だそうで、モードSは先の事故の翌年には制定されているらしい。ただ、TCA内を飛ぶ小型機に必要なのはモードCだから、モードSの制定とこの事故ははあんまり関係ない気もする。

　87年ってまだ昭和なわけですが、その当時に1.09GHzのトラポンを載せようってのがすげーな。もっとも、イージスシステムを載せたタイコンデロガ級は1983年から就役しているわけだが。F-22はかろうじて平成生まれ。ATF計画も含めれば昭和だけど。平成生まれが思ってるほど昭和は昔じゃない。


　モードA/C/S/ESは1090MHzで応答するが、その信号は1MbpsのCWで返される。1ビットは1usecの長さだが、ビット1の場合は最初の0.5usecを送信し、後の0.5usecを送信しない。0の場合は逆で、最初の0.5usecは送信せず、後の0.5usecで送信する。
　ADS-Bデコーダのオプションで「パリティチェックに失敗したら0.5ビット動かして再試行」ってこういう意味だったのか。0.5bit動かしてどうなるの?と思っていたのだが、納得。
　モードSの場合は56bitかな? 1.09GHzを56usecの間、デューティー比50%で送信する。モードESは112usecで、6Hzで送信すると1秒あたり672usecを専有する。
　モードA/C/S/ESは最小200W、標準250Wで送信するらしい。もっとも、実際の送信出力はdBで規定されているようだが。最小200Wで送信するトラポンを使う場合は、200W入力で規定のdB以上を出せる利得のアンテナが必要になる。


　超大型ドローンとか、大気球とか、何らかの飛翔物体にトランスポンダを乗せる場合、法規制とかその他様々をクリアできたとして、おそらく日本ではA/Cしか載せられないはず。A/Cは位置情報を放送しないので、位置を知るには二次レーダーを運用する必要がある。
　Aの場合は高度情報が得られないので、ペンシルビームの二次レーダーが必要。Cの場合は高度情報が得られるので、ファンビームの二次レーダーでいい。

　今後、ドローンがますます普及した場合(←個人的には懐疑的だが)、何らかのトランスポンダーの搭載が必須になるかもしれない。トラポンとはいえ、ADS-Bのような運用を行うなら放送だけでいいので、機材としてはGPSと処理装置、アンテナの3点セットがあって、それを取り付ける、という形になるはず。
　海外で一定規模以上のドローンからの位置情報の放送が必須になった場合は、日本でもそれをコピーしたような規則ができるはず。その場合、ドローンの位置情報は航空機でも受信できる必要があるはず。ただ、モードESではアドレスが足りないはずなので、アドレスを拡張した、拡張ESを作る必要がある。ただ、その場合は既存の機材との互換性がないから、かなり微妙。既存の機材との互換性を維持するならモードCしかないが、そうすると放送ではなく応答になるので、ドローン側に求められる能力が高くなる。もっとも、今の電子技術ならそれほど大変ではないのかもしれないが。
　ESが使えればそれが一番いいと思うが、いかんせんアドレスが足りないのが問題。
　もしくは、ドローンはADS-Bの受信のみを行い、自分がコリジョンコースにいる場合は問答無用で移動させる、みたいな運用もアリかもしれない。そもそもドローンを空路に入れるなという大前提があるし、空路に入れるならちゃんとNOTAM出しとけ、という話なので、ドローン側の事情は一切酌量しない、という運用。

***

　サクッと探した限りでは、あんまり詳しい話が見つからなかった。ちょっと消化不良な感じ。


追記：2018/10/16
　そういえば、DMEには質問1027MHz/応答1090MHzのチャンネルがあるけど、モード3/Aはこれとなにか関係あるんだろうか?
　UATはDMEの機材を流用できたので小型機に乗せられる程度に低価格化できたかも、という予想を書いたけど、モード3/AもDMEとほぼ同じ周波数だから、この説は説得力が低いな。周波数帯が同じならモード3/AやADS-BもUATと同じように低価格化できるはず。
　UATは測距だけなのでDMEとほぼ同じ機材で、モード3/Aはスコークの返事がある分複雑で高価格化、という感じなんだろうか?

正規表現でTLEのDEBを削除する

　Space-trackからFull Catalogをダウンロードするとデブリが大半を占めている。
　そのままJS Orbitとかで表示すると、さすがに邪魔くさい。

　一旦テキストエディタで開き、正規表現で".+DEB.*\n.+\n.+\n"を削除してやれば、DEBを含む名前のデータが削除される。

　Space-trackだとデブリを除外した一覧、とかも取れそうな気がしないでもない。
　ただSpace-trackのAPIはフォーマットが独特な感じで、パラメータも謎な感じで、使い方がわからない。

***

　最近Qiitaに登録してちょこまかと書いてるけど、小ネタ的な短いのを書くのは罪悪感を感じる。ので、こっちに書いている次第。
　たぶんググってqiitaが出てきて「よっしゃ有効な情報発見！」とか思ったら初心者の覚え書き(馴れた人ならメモもいらないような内容)とかだったりするのが多いので、そういうのに似た短いのを書くのは避けがちなんだろう。
　なんとなくqiitaのエントリの情報量は正規分布でなく、バスタブ曲線になりそうなきがする。そんなこと言っても、普通のブログとかだって、情報量が皆無とか、場合によっては負に振り切ってるようなのも多いけど。