小ネタ

　ニデックが2度目の質問状に回答、「企図するシナジーの定量化は困難」：製造マネジメントニュース - MONOist

　我が社(ニデック側)が欲しいから買う、牧野側への利点は特には無い、株主には牧野独立では得られない利益を与えるんだから文句を言うな、みたいな雰囲気。

　フォトカプラを使って商用電源の周波数を捉えるプローブを作製する：電力ブラックアウトを予測する（2）（2/3 ページ） - MONOist

　普通のフォトカプラをRだけでAC100Vに接続するのってやっちゃだめじゃね? このフォトカプラの発光部の逆電圧(絶対定格)は5Vだから、AC100Vだと数十倍オーバーしてる。AC100Vをフォトカプラに突っ込むならAC対応型のフォトカプラを使うか、あるいはフォトカプラと並列に逆電圧を逃がすためのダイオードをいれる必要があるはず。

　ブラックアウトって周波数で予想できるのかな? 最近のブラックアウトってトラブル(発電所の停止とか運用ミスとか)で突発的に起きてる印象。周波数の監視って10年くらい前に話題になってた気がする。この人の記事、話題が10年くらい前の雰囲気がある。

　高知に宇宙港を。「スペースポート高知」発足、目標は'29年ロケット打ち上げ | TECH+（テックプラス）

　イメージ図、生成AIで作ったものとはいえ、なんだかなぁ。

　Delta Forceで遊んでたらいきなりOSが落ちてびっくり。しかもOSが起動できなくなって、電源長押しで落としてから再起動したらWindowsの修復が走った。以前遊んでいたゲームではOSが落ちるのはよくあることだったけど、DFでは初めて。今シーズンはour system detected irregular data activityでゲームが落ちる頻度も高いし、なんか調子悪そう。とはいえ、irregular data activityはアンチチートの誤検知としても、OS巻き込んでクラッシュはちょっとやることが大きすぎるというか。

　誤検知で落とされるのもプレイのモチベーションにかなり悪影響が大きいし、最近はウォーフェアで猛者がモサモサしてるマッチに入れられてリスキルされまくったり、DF遊んでて楽しくなくなってきた。そろそろ潮時かなー。

　自分は遊んだことのない某PvPメインのゲームジャンルを興味本位でぐぐってみたら「初心者だから勝てないとか言ってる暇があったら基礎的な部分を学んでからゲームをやれ」みたいなことを大手ネットメディアが書いてて、うーん、厳しい世界、って感じ。自分で座学をやってガチってからじゃないと入門すらできない世界ってあっという間に衰退しそうだが。

***

https://jjy.nict.go.jp/QandA/reference/Proceeding/sympo-pro6.pdf

　JJYを使った高安定クロック。-11乗くらいの安定性。Rbを内蔵しているので数時間程度の停波でも安定。国家標準の周波数に同期できる。感度の高いアンテナに接続する必要がある。いつ頃の話かわからないけど、2005年前後あたり? もう少し前かも。

https://www.jstage.jst.go.jp/article/jinnavib/62/0/62_KJ00004995621/_pdf

　1979年。NAVSTAR/GPSに関する解説。Block Iの時代。

　我が国では最近、小型の漁船にまでNNSSの受信機が普及をして、衛星航法が非常に身近なものとなってきている。(後略

　NNSS、そんなに普及してたのか。

　PコードとC/Aコード。C/Aについては「Clear/Acquisition(明瞭/捕捉)」という説明。

　CMDAの原理とか色々。

　軍用のPコード受信機。2周波4chを受信する。

　民間用のC/A信号受信機。1周波1chの受信機で4衛星を時分割受信。「なお、C/A信号のみの受信機の価格は、量産の個数にもよるが15000～25000ドルと言われている」すげー値段だ。1980年から2025年のインフレ調整を行って現在のレートで940～1600万円くらい。半世紀経って、高性能化したうえで3,4桁安くなっている。電子技術の発達ってすごいんだな。

https://www.jstage.jst.go.jp/article/itej1978/41/4/41_4_334/_pdf

　1987年。衛星航法の説明とか。

　NNSS。改良型のNOVAの仕組み。衛星の中に金属球を浮かせ、それを一定の位置に維持するようにスラスタで制御を行う。これにより空気抵抗による減速を除去する。ドラッグフリー制御をやっていたらしい。

　その他のシステムの解説とか。GPS(米軍)、GEOSTAR(米民)、GLONASS(露)、NAVSAT(欧)、GRANAS(西独)。

https://www.jstage.jst.go.jp/article/jinnavib/67/0/67_KJ00004995745/_pdf/-char/ja

　1981年。NOVAの解説。NNSSの精度改善に必要な事項など。

　ドラッグフリー制御(DISCOS; Disturbance Compensation System)の説明。内径40mmの空間に直径22mmの合金球を浮かべ、その位置変化を衛星の軌道制御にフィードバックする。合金は非磁性と質量の要求から、金70%、プラチナ30％の合金で、重さは111g(衛星全質量の0.13%、水との比重でほぼ20)。軌道制御は小型のイオンエンジンを使うらしい。最初は3次元で、以降は1次元で軌道修正を行う(進行方向のドラッグが支配的らしい)。衛星のイラストに「テフロン推進器」というのがあるけど、これがDISCOSのスラスタかな。

　衛星にコンピュータを乗せて、衛星側でいろいろな計算を行う試み。

　スペクトラム拡散の追加。コード周期19.66ms(NNSSの航法メッセージの1bitに相当する時間)の拡散符号を使用して時刻同期を行う。ドップラとレンジングを併用したDOPRANという手法で測距したり、USNOとNBS(現NIST)で時刻比較の実験を行ったり。

https://www.jstage.jst.go.jp/article/zogakusi/665/0/665_KJ00001777323/_pdf

　1984年。GNSSの解説とか。

　NNSS。米軍が使用している受信機のマニュアルを実費で販売することになり、様々な組織で受信機が作られるようになった。測位の原理等。NOVAの改良点。受信機の概観。受信機は28社が製造し、中23社の集計で、’83年までの累計で5万台程度が販売されている。その中1周波型が93％を占め、全体の中で軍用は400台程度。GPS運用開始後5年後(’94年頃想定)まではNNSSとNOVAをそれぞれ2基ずつ運用する計画。

　NAVSTAR GPS。NNSSの欠点を解消できるように計画。原理とか色々な解説。当初計画で24個の衛星が、予算的な問題から18個(+予備3個)へ削減。予備無し(18個)では1日に2回、測位ができなくなる地点が発生する。予備を含めた21個でも1日に1,2回測位精度の劣化が発生する。受信機の試作。4-5chの受信機を使用し、航空機等に搭載するもの。1chを1秒程度ずつ切り替えて使う、低速な乗り物に使用するもの。1chを小型軽量化しマンパック形にしたもの。C/Aコードを使用する1chの受信機で、輸送機等に使用(後に民間用へ変更)。1chだけだとメッセージの受信にそれぞれ30秒ずつ受信する必要があるから、2chのモデルがあったり、あるいは1bit区間で複数の衛星を切り替えて1chで受信できるモデルだったり、いろいろ提案されている。フェーズドアレイアンテナの提案も。’83年の大韓航空機撃墜事件の後、大統領がGPSを民間航空機で使用する決定を行ったが、軍用システムであることから民間機で使用することに対する根強い反対がある(この頃のアメリカはデュアルユースに対してかなり否定的)。事件前には議会はGPSユーザーから使用料を徴収しようとしていたが、事件後は態度を軟化させ、無料で使えるようにする方針。ただしC/Aコードでも測位精度が高いため、意図的に精度を劣化させる措置を行う。

　ソ連のシステム。NNSSと同様のCicada(Tsikada)と、GPSと同様のGLONASS。Cicadaをイギリスが解析した報告。GLONASSについては詳細は不明。

　欧州が提案する民間用の測位衛星NAVSAT。衛星に原子時計を搭載せず、ベントパイプで放送する。3軌道面8個ずつ24衛星。DSSS(10Mcps程度) or CWを予定。DSSSは測距しやすく、CWはドップラ解析しやすい。データ133ms+ガードタイム17ms(1周期150ms)のTDMA形式。地球の裏側にいる衛星とはフレームを共有できるので、12フレーム(1.8秒周期)で1巡。

　IMOでの検討。今のところGPSが唯一のシステムだが、軍用(デュアルユース)への拒否感がある。米民間が構想しているGEOSTARもあるが、これは静止軌道上のトランスポンダを使用した地域測位システムであって、IMOが求める全地球規模で測位する能力はない。GPSかNAVSATかどちらを使うか、という感じ。

　最後に「(前略)最終的には腕時計程度の大きさの利用者装置による個人用の衛星航法装置が実現される可能性も考えられている。21世紀の前半のある時期にはそのような時代が来るであろう」とのこと。GPSを内蔵した世界初の腕時計とされるのがカシオのPROTREK PRT-1GPJで、発売が1999年。15年後、20世紀の末にはすでに実現していた。

https://www.hitachi.co.jp/New/cnews/month/2009/02/0218.pdf

　2009年。IMES送信機の試作例。かなり小さい。

　L1 C/Aの送信ってどんな感じでやるんだろうか。変調方式を工夫して少リソース化したみたいなことが書いてあるから、本来はある程度複雑な演算が必要なんだろうけど。しかし、GHz帯とはいえWiFiやBluetoothよりは低い周波数だし、BPSKだし。そこまで複雑になるものかな。

https://www.jstage.jst.go.jp/article/sicejl1962/20/2/20_2_236/_pdf/-char/ja

　1981年。m系列に関する数学的な解説とかが色々。

　単に乱数としての特性を求めている感じ。100bitのレジスタで乱数を発生させれば1Gbpsで出力しても地球の年齢の8000倍くらいの長さの乱数が得られる、とか。

　デジタル回路(フリップフロップとかXOR素子)でm系列を作る場合、200Mbps程度で頭打ちで、将来的にもさほど改善はしないだろう、という予測。遅延線を使うと700Mbps程度で出力できた報告がある。

https://www.jstage.jst.go.jp/article/safety/31/2/31_117/_pdf/-char/ja

　1992年。土木工事で発破作業を行うときに、起爆タイミングをm系列で遅延させればスペクトルのピークを下げられて、低周波音の問題(窓のガタツキとか)を減らせるのではないか、という提案。ググってもあまり出てこないので本格的に導入するほどの効果は無いんだろうけど。共振が問題なら各段で遅延時間を増す(or減らす)シンプルなチャープ変調で良さそうな気がするが。

https://www.jstage.jst.go.jp/article/jasj/53/6/53_KJ00003054009/_pdf/-char/en

　1997年。エアコンのファンを等間隔でなくm系列に従った間隔で配置することで、ノイズのスペクトルを分散させる提案。

***

　rtlsdrblog v.1.3.4のrtl_tcp.exe経由でサンプリングした1575.42MHzの特定の衛星に対する時刻差

　やっぱりドロップする。バージョンの問題ではないのか。

　受信時のクイックルック画面

　1575.42MHzを2.4Mspsで受信中(切断しているのでbias teeのチェックが外れているが、どちらもB-T ONで受信)。ゲインはテーブルから28を設定している。ppmの設定をリセットするの忘れてるけど、5ppm程度なら誤差ということで。

　一番下が周波数スペクトル、その上がサンプルのヒストグラム。左が1.3.4、右が1.3.6で受信(同じドングルに対してrtl_tcp.exeを切り替えて受信)。1.3.4に比べて1.3.6はヒストグラムが広く、スペクトルも高めに出ている。1.3.5でLバンドの感度が改善したそうだが、ちゃんと効果はありそう。まあ、この図だけだとノイズが増えただけという可能性も捨てきれないが……

　rtl_tcpでなく、rtl_sdrで直接ファイルに保存

　やっぱりだめっぽい。

　rtl_sdr、オプションでBias-Teeを指定できないのがつらい。運が良いとrtl_tcpとかで有効にしたBias-Teeが残っているけど、残る条件がよくわからない。結局10分とかサンプリングしたあとに解析してみないとわからないので、作業効率が著しく悪い。毎回rtl_eepromでBT強制有効化とかするのも嫌だしな。

　rtlsdrblog版でなく、フォーク元のosmocom版のrtl_tcp経由でサンプリング

　やっぱりドロップする。rtlsdrblogがフォークしたのが6年前だから、それより前からあるバグなんだな。

　PCの処理能力の問題かと思って、SDRのサーバーとして同軸ケーブルを引き込んでいる場所においてあるNUC(N5105)から、ノートPC(core i5 gen2 M)に変えてみたけど、相変わらずドロップする。i5とはいえ10世代以上前だし、N5100のほうが早そうな気がしないでも。。。とにかく、悪化も改善もしないから、PCの問題(含USBの帯域幅等)ではなさそうというのがわかっただけでも収穫。

　サンプリングレートに2.4Mspsを設定したのは、帯域幅が広いほうが良かろうみたいな理由もあるけど、もう一つはサンプル数が多いほうが相対的にノイズを減らせる(信号はコヒーレントだがノイズはインコヒーレントだから、コヒーレント積分すれば信号はN倍になるがノイズは√N倍になるはず)みたいな理由もある。

　NUCのrtl_tcp経由でいくつかのサンプリングレートで取得

　1.024Mspsと1.44Mspsを除いて、2.048Msps以下はドロップしていない。2.304Mspsや2.4Msps、2.56Mspsは高い頻度でドロップする。

　0.96MspsはC/Aコードのチップレート(1.023Mcps)よりも帯域幅が狭いが、それでも一応コードの追尾やメッセージの復調はできる。

　それぞれのサンプルを15分ほど記録しているので、0.96Mcpsと2.56Mcpsでは3時間以上の時間差があって、衛星の配置や伝播状況も違うだろうから、単純な比較はできないとしても、やはり帯域幅が広くなればそれだけSNRが改善する傾向は見て取れる。1.28Mspsの500秒付近とか、1.6Mspsの300秒前後とか、1.8Mspsの500秒付近とか、相関値がかなり低下した部分でもメッセージの復調が行えている。ここまでロバストだとは思わなかった。BPSKの多数決ってすごいんだな。

　途中、メッセージの復調率が極端に低下する事があった。そういう場合、TOWは適当な値(今回は144972)に固定されて、メッセージは6秒(サブフレーム)毎ではなく、30秒(ページ)毎に復調された。おそらくSF1,2,3のどこかに偶然プリアンブルが出てきて、しかもそれらの前後で正しいパリティのビット列が生成されてしまったんだと思う。LNAVメッセージって偶然にプリアンブルやパリティが出てくることは防げないっぽい。あくまでも1ページ毎の繰り返しなので、例えばサブフレームを挟んで2箇所のプリアンブルをチェックするとかで、誤った位置にロックすることができる。正しいプリアンブルは必ず300bit周期で出てくるが、偶然なプリアンブルが300bit離れた場所に出現して、しかもその周囲のパリティも正しくなるという確率はかなり低いはず。絶対に有り得ないかと言うと、わからないけど。念を入れるなら例えば1ページ30秒のビット列を持っておいて、プリアンブル5個とサブフレームIDの連続性を確認する、みたいな手法は考えられるけど、計算量とか、メモリ使用量とか、実装の手間とか、色々高コスト。一番大きいのはTTFFがその分遅くなる点。まあ、同期ができた時点で1ページ丸ごとメモリに入っているから、その時点でエフェメリスとか必要な情報は全部持っている、という利点はある。うまく実装できればこっちのほうが楽な可能性もあるな。PCで処理する前提ならPRN1個毎に3.6万ポイント(int型複素数なら約300kB)は問題になるような量じゃないし。

　RTL-SDR Blog V4ドングルならなにか変わるかな?と思ったけど、これダウンコンバータが変わっただけでADC以降はRTL2832Uのままだから、サンプリング周りは変わらないのか。

　別のタイミングでサンプリング

　今度は2.048Msps以上はすべてドロップしているが、1.92Msps以下は問題ない。

　ドロップしたサンプリングレートを捨てて別のサンプルを取り直す

　↑2回戦。1.28Mspsと1.536Mspsが脱落。

　↑3回戦。脱落者なし。

　↑4回戦。うーん、落ちない。。。。。。

　その後、第5回戦、6回戦でも脱落者なし。第7回戦でようやく1.8Mspsが脱落。もっと高頻度にドロップするような印象があったけど、なかなか落ちないな。

　1.92Mspsで4フルフレーム分サンプリング

　2800秒あたりで途切れてる

　ドロップした場合はある程度高い相関値から急激に落ちるけど、落ち方がゆっくりしている。衛星が障害物に隠れたみたいな感じ。急に高い相関値で現れているけど、これは相関器をリセットして再同期したため。別のPRNを指定すると途切れずに復調できるので、データのドロップではない。

　この時の衛星の方向には立木(松)が1本あって、この日は雪が降っていたので、木に積もった雪がLバンドをブロックしていた可能性は無きにしもあらず。とはいえ、GPS衛星の軌道速度(2.3万km先で4km/s)でこんなに動くものかな。100秒で1度くらいしか動かないはずだが。回折とか反射で干渉したみたいなことなんだろうか。

　1.92Mspsは結構優秀かも。ほとんどドロップしないし、サンプリングレートは高いし。

　逆に、超低SPSでサンプリング

　0.3Msps、C/Aのチップレートの29%の速度。短時間のサンプルで、最後の方はデコードに失敗しているし、Early/Late/PromptのMagnitudeの差が無くてなんで追尾できているのかわからないけど、それなりにメッセージの復調ができている。取得したTOWも受信時刻に対して整合的。復調処理も高spsに対してかなり早い(データ量が1桁少ないんだから、1桁早い)。ただまあ、復調の性能はかなり悪いと思う。

　やはりワンセグチューナー(RTL2832U)系のSDR受信機は安定性にネックがある、ということなのかな。もう少し上のグレードの受信機がほしいけど、とはいえHackRF Oneとかだとちょっと大げさじゃね、と思いつつ、でもそれ以外の選択肢ってあんまりなさそう。Airspy MiniとかR2はプロプライエタリな感じっぽい。libusbデバイスのはずだからWin32で叩けばアクセスはできるんだろうけど。HackRF OneはWindowsのツール郡の入手性が悪そう。最近はWindows版バイナリは配布されていないっぽい? Ubuntuが推奨環境だそうだ。HRO本体が4万円～、それを叩くためのUbuntuの実機を買うのに中古のノートなり安いNUCを買うなりで3-5万円～、気軽に買える値段じゃない。SDR#でHROの受信に対応しているらしいから、IQバイナリを数秒取る程度ならWinでもサクッと行けそうだけど、長時間(4GB以上)とかリアルタイムに処理したいとか中途半端なサンプリングレート(8.127Mspsとか、16.254Mspsとか)を設定したいとかだと困りそう。

　試しにPコードを生成してみた。first 12 chipsを見る限りは多分正しく生成できている。Pコードは約1.5秒のコードを繋げていくので、せめて数十秒くらい確認しないと本当に正しいかはわからないけど。

　Pコードって頭の数十チップは全PRNで共通なんだな(PRN番号が低い方ほど共通部が短い)。時間にすれば数マイクロ秒程度だけど。C/Aコードに比べれば複雑ではあるけど、リアルタイムに生成するのが前提のコードだから、極端に複雑というものでもない。

　P(Y)コードってPコードだけで逆拡散したらどんなスペクトルになるんだろうか。幅500kHzくらいのSinc型に見えるんだろうか? 20Mspsくらいの受信機か……

　GPSのWコードってどうにか解析できないんだろうか? 何らかの法規制でP(Y)コードを使う機器がアメリカで販売できないとしても、例えば中国で作って国内で使う分にはどうなんだろうか。DJIのRTKキットでWコードを解析してドローンとPコードでRTKを行う、みたいな。

　アメリカのDJIに対する規制ってどうなったんだろうか。あんまり規制しすぎるとアメリカ市場を完全に分離して、中国国内でGPSの機密コードを積極的に活用するような方向に行きそうな気もするが。それともYコードはそう簡単に解析できるようなものじゃないのかな。

　amazonで先月22日に注文したU.FL-SMA変換コネクタがようやく届いた。当初予定だと1週間くらい前には届いていたはずなんだけど、春節にぶつかった感じ。

　小さなGPSアンテナをSDRドングルに接続できる。ただそれだけ。窓際に置いてサンプリングしてみたけど、1個も相関強度でなかった。まあ、アンテナがこの大きさだしね。。。暖かくなったら(その時に覚えていたら)外でサンプリングしてみよう。

　一応、Bias-TeeをONにすればヒストグラムが広がるので、DCは通るし、Lバンドも通っているはず。アンテナ自体はNEO-6Mに接続して野外で受信できたから、問題ないはず。SDRと組み合わせたときの感度が十分かはまた別の話。