だいぶデカいけど、機能を考えればまあしょうがない大きさではあるか。量産するんだったらひと回り小さくなるんだろうけど。
見た目とか名前が自衛隊装備品っぽいけど、自衛隊の無線通信のセキュアな情報に関わるから自衛隊が管理したいのか、あるいは他の組織(警察や消防)には配備/教育する余裕がないから、ある程度特殊な通信機器でも組織的に扱えるという理由で自衛隊が持つことになったのか。
近距離高速の通信だけでなくて、山を回り込めるような長距離通信機能もあると便利そうよなー。端末を運んで大容量通信を行うだけでなくて、どういう情報を誰が持っているか、どこに行けば入手できるかを把握できるような機能。HAPSが普及すればそういう機能もわりと簡単に作れそうだけど、現状はHFとかで飛ばすしかないから厳しそう。
次の選挙で投票を呼びかける某政党のパンフレット等が入ってたけど、「内部資料」と書いてあるのがアレだな。普通にパンフレットを配布したら多分何らかの法に引っかかるんだろうな。で、「これは有権者に配布する資料ではありませんよ、関係者しか見ちゃいけない内部資料ですよ」という扱いにしてるんだろうな。
10年以上前に買ったJustSystemsのソフト(大昔に使用を終了)、最近になって「重要なご案内」と称してサポート終了済みである通知と新しいバージョンへの買い替えの案内が毎日届く。いくらなんでも毎日送ってくるのはやりすぎだろうよ。。。
amazon.co.jpってこんなものまで売ってるのか…… 価格だけ見れば、ちゃんとしたケーブルAssyっぽい値段。こんなもの売れると思えないんだけど、なんで20近い出品者が合わせて30本くらい出品してるんだろう?
ChromeでYouTubeを再生したら「オーディオレンダラエラー」が出て、OSの再起動を要求する画面。数ヶ月に1回くらい起きる気がする。原因がよくわからない。OSを再起動しなくても勝手に治る気がする。前はどうだったか覚えてないけど、今回は再起動しなくても治った。ただ、何を契機として治るのかもわからない。
この症状のときは、ChromeからはYouTubeだけでなく、ローカルのMP4ファイルを開いても再生できない。同じ動画をEdgeで開けば問題なく再生できる。で、また同じファイルをChromeで開くと、再生できる。その後はYouTubeとかも問題なく再生できる。謎い。
AndroidのQuick Share、対Windowsで使おうとすると不便な気がする。
Windows側でQuick Shareクライアントを起動しなきゃいけないけど、1回目の起動時は高確率でハングアップするから、タスクマネージャからnearby_shareを殺して蘇生させなきゃいけないし、受信するときもPC側で受信許可の操作が必要になる。1回正常に起動してしまえば問題ないから、OS再起動のたびに1回の手間と考えれば、そう大きい手間ではないとしても。
Quick Shareがもっと使いやすいならそっちを使ってもいいんだけど、現状ではBluetoothのほうが便利。ただ、最近はAndroid側でBluetooth転送を選択すると毎回Quick Shareへリダイレクトする画面が挟まるから、操作が煩雑になっている。
Googleって時々ユーザーエクスペリエンスを悪化させる変更を平気でやるからなぁ。最近はChromeのデザインが変わって訪問済みと未訪問のリンクの色がめちゃくちゃ似てて不便になったり(セキュリティ云々のvisitedとはまた別)。訪問済みと未訪問のリンクの色が似てるって相当不便なはずなんだけど。色分けしたら訪問済みのサイトが別のサイトにリークするから危険、とか言ったって、じゃあ以前訪問した正規のサイトと新しく出てきた偽造のサイトが同じ色(見分けがつかない状態)で表示されるのは危険じゃないのかよ、って話だし。まあ、Chromeは訪問済みと未訪問で別の色が表示されるから、「同じ色で表示されるようになった」じゃなくて「似たような色で表示されるようになった」という、単純な改悪だけなんだけど。Googleは時々本当に頭の悪いことをやる。
***
コードレスチャイムのリモコン(何年か前に買った製品)。なんか調子悪かったので、ついでにRFのサンプリング(結局、リモコン側の電池の電圧低下だったっぽい)。
このチャイムは3chを設定できるので、切り替えながら3回送信している。1個目の振幅変調成分は見かけ上のものだと思う。
ch Aの全体(I軸だけ、以下同じ)。
末尾の拡大
13個のパルスを繰り返し送っていて、その中9パルス目は立ち上がりが早い。
繰り返しの最後はバーストを一回送っている。
ch Bの末尾
同様に13パルスの繰り返しと、最後にバースト。長いパルスは8パルス目。
ch Cの末尾
同様。長いパルスは7パルス目。
13パルスを36ペア、その後にバースト、パルスの立ち上がり位置を替えてチャンネル番号を変調、という感じか。
最後にバーストがあるってことは、各ペアを積分してSNRを稼いで、最後にバーストで積分を壊している感じなのかな。
受信機側をバラしてみると、RF周りはコンデンサ・コイル・トランジスタで共振させて、それをCOBに引き込んでるっぽい。アンテナっぽいパターンとかワイヤが一切無いのが面白い。インダクタに磁場を拾わせてるんだろうか?
***
GPSの電離圏補正情報を受信する方法を考えてるんだけど、なかなか難しい。
DataId1, SvId56だけに限っても、更新タイミング(コンステへ伝播する速度が遅い)の関係で新しい情報と古い情報の識別を考えなきゃいけない(単に受信タイミングだけで振り変えると、コールドスターで最悪値24時間古い情報を使い続ける)。
QZSSも含めると、DataId3, SvId56とかDataId3, SvId61も、同様に識別して、受信機位置で使い分けなきゃいけない。
電離圏補正情報にもIODx(IODI?)が欲しかったな。SvId56には14bitの予備ビットがあるんだから、IODIを乗せても良かっただろうに。
GPS衛星のエフェメリスの計算で位置・速度・加速度が得られるけど、衛星の加速度って何に使うんだろう? ドップラーレートと合わせて受信機の加速度が計算できるはずだけど、ドップラーレートはドップラの微分だから、速度を微分して得た加速度と大して変わらない気がするのだが。
車でカーブを曲がったときのデータからドップラを微分してドップラレートを得て、加速度を計算してみたけど、意味の有りそうな結果は得られなかった。計算方法が間違ってるのか、車程度の加速度だとノイズに埋もれてるのか。交差点みたいに減速・加速のデータならともかく、巡航中のカーブはよほどの速度・曲率でもない限りはあんまり加速度もなさそうだしなぁ。
前に札幌に行ったときに取ったIQファイルから測位演算
サニャック、電離層(QZSS Japan)だけ考慮、対流圏とかは未補正。衛星9個でHDOP1.24くらい。右上から左上に向かっていて、右下側の車線を走っているけど、ちゃんと道路の片側を通っている。さすがに車線レベルの精度は出ないけど。
高度方向はノイズが多い。若干上にバイアスがあるけど、概ね妥当な結果が得られている。アンテナは車の屋根に積んであるから、路面から車1台分上にオフセットすると考えれば、かなり良い結果とも言える。
QZSS SLASの補正値を加えると、水平方向には若干変わるけど、ほぼ変化しない一方で、垂直方向はかなり上に(10m程度)バイアスが出る。基準点(札幌)とは30kmくらいの距離で、標高も石狩平野の中でほぼ同じ高さだから、補正値に対する補正は行っていない。
本来は対流圏の補正を行うべきなんだろうけど、SLASの補正結果の擬似距離は 補正後擬似距離 = 擬似距離観測値 + 補正値 + ユーザー対流圏補正値 - 基準点対流圏補正値 で計算して、対流圏はユーザーと基準点の差分を加える形になる。つまりユーザーと基準点の距離が十分に近い場合は打ち消して対流圏補正値は消えるから、今回の場合は無くてもいいはず。
電離層の計算方法はIS-GPS-200にも書いてあるけど、対流圏の計算方法ってIS-GPS-200でもIS-QZSS-PNTでも全く言及されていないのが不思議。IS-QZSS-PNTでは1箇所だけ出てくるけど、UREの説明で「電離層や対流圏も含むよ」と言及しているだけに過ぎない。
ΔPRの残差
単独測位とSLAS補正を、電離層と対流圏の有無で比較。全衛星のRMSで比べればどの手法も差は無い。
空港のシュードライトの研究で「特に垂直方向」の精度が改善するみたいな話があるけど、GNSS(含シュードライト)の観測値って視線方向の距離だから、地上にシュードライトを置いても垂直方向の改善は期待できないような気がするんだけど。
***
試しに放物面を3Dプリンタで出力
壁の厚さは1mmに設定。下部は問題ないけど、上部はかなりペラペラ。外周を囲うような補強が必要だな。底面はベッドに張り付く+三脚固定用の穴とか色々開けてるので4mmの厚さだけど、造形時間の半分近くがここに食われた。
焦点近くにマイクをつけて、前方で音源を動かしてみると、確かに指向性はありそう。ただ、思ったほどじゃない。大きさが大きさだから指向性はあまり無いだろうとは予想していたけど、集音性はもっと高いと思っていたのだが、かなり小さい。マイクの音を受ける部分が直径数mm程度だろうから、それより遥かに広い面積(前から見て150x100mm)から集めたらかなり高い利得が得られると思っていたんだが。さすがに波長に比べて小さすぎるか。とはいえ音響の波長って。。。
なんか既視感あるなーと思ったら、イギリスの東海岸に置いてあるやつだ
試作だけしたけどChain Homeの実用化のほうが早くて結局使われなかったと言われているやつ。
音響ミラーは放物面でなく球面で作っていたらしい。開口率は悪くなるけど、焦点の位置を選んでビームステアリングできるのが利点だそう。アレシボ300mやFAST500mが球面なのも同じ理由。
Parabolic microphone - Wikipedia
Parabolic microphones were used in many parts of the world as early as World War II, especially by the Japanese. (Google翻訳：パラボラマイクは第二次世界大戦初期から世界各地で使用され、特に日本では広く使用されていました)
まあ、使ってないわけ無いだろうけど、あんまり印象ないな。
もう少し大面積
230x150mm、f200mm、軸外し。造形時間がかなり長い。ちなみに、短辺を上下に立ててスライスすると6時間、長辺を立ててスライスすると7時間、くらい。また、背面をグリッドでなく100%ソリッドにすると3時間くらいになる。インフィルは早送りで一気に詰め込めるから、かなり早い。レジンとかパウダーだと体積率がそのまま消耗品の使用量になるけど、FFFなら内側は中空になるから、下手に凝って肉抜きするよりもスライサーでスカスカにしたほうが圧倒的に楽。見た目にこだわりたいとかならともかくとして。
230x230mm、f175mmの軸外し
170gで4.5時間。
150x100に比べれば面積比で3.5倍程度だけど、1辺では2倍弱程度だから、音響の波長(1m弱～)だとどちらも波長未満であることに違いはない。
***
C#のCursor.Show()/Cursor.Hide()ってカウントするんだな…… なんでェ。。。
Curosr.Show/HideはWinuser.hのShowCursorを呼んでいるだけ
ShowCursor 関数 (winuser.h) - Win32 apps | Microsoft Learn
初期値0のカウンタがあって、Showでインクリメント、Hideでデクリメントして、0以上の場合は表示される。
定期的に条件を判定してShow/Hideを切り替えるような処理をするときはラップしなきゃいけないのがちょっと面倒。
C#のGraphics系の処理、いつの間にかparams ReadOnlySpan<PointF>とかに対応しててすごいな。GDI+系処理って完全に捨てられたものだと思ってた。
Graphics.DrawLines メソッド (System.Drawing) | Microsoft Learn
.NET 9から対応したらしい。最近はConsoleばっかりでBitmapをゴリゴリ使うような遊びをしてなかったので気が付かなかった。
Spanの対応で、List<(float,float)>list;みたいなのを用意して、適当に座標を突っ込んで、g.DrawLines(Pens.Black, MemoryMarshal.Cast<(float, float), PointF>(CollectionsMarshal.AsSpan(list)));みたいにGraphicsに書き込めるようになった。List<PointF>で座標ごとにPointFを作らなくても済むし、list.ToArrayとかで配列に変換する必要もない。
ソースリンクを見てみても、ちゃんとSpanをfixedで固定して得たポインタをGdipに渡しているから、ToArrayをラッパーで隠しているわけでもない。
こうなるといよいよMarshal.CopyでSpanが使えないのが結構不便。
C#でint配列に入ったARGBをBitmapにするやつ。
argbの型は何でもいい(GCHandle.Allocはobjectで受け取るので)。今回はint配列でargbを入れているけど、好きな形を使えるはず(タプルはワードアライメントがあるはずなので、24bppとかを使うならreadonly record structとかでラップする必要があるはず)。
Bitmapはポインタを持っているだけなので、Bitmapを捨てるまではgcHandleを捨てちゃだめ。Bitmapのインスタンスを作るときにメモリコピーが発生するわけではない。逆に言えば、bmp.SetPixelとかGraphics経由で書き込めば、argbにも反映される。Bitmapを戻り値で返すとかで、与えられた配列が生きていることを保証できないなら、BitmapのコンストラクタやCloneでメモリをコピーする必要がある。
ちなみに、bmp.LockBitsでポインタを取ってそこに書き込んだら元の配列に反映される。ただ、gcHandleとBitmapData.Scan0では別の場所を指している。論理アドレスが違うだけかもしれないけど。BitmapのインスタンスとLockBitsで同じPixelFormatを与えた場合はMarshal.WriteInt32とかで書き込んだ値が直ちにargbに反映されるけど、違う値を与えた場合はすぐには反映されず、bmp.UnlockBitsで閉じたら反映される。また、その場合、例えばBitmapのインスタンスが32BppArgbでLockBitsが24BppRgbの場合、argbがゼロクリア(完全透過画像)でも、UnlockBitsで閉じたらargbの上位8bitは0xFF埋めになる。
一部の操作でちょっと不思議な挙動をしているような気もするけど、今回はデバッグ用に画像を保存するのが目的だったので、あまり深堀りせず、放置。
固定したint配列を取ってきて開放したりするクラスを書いて、Bitmapのインスタンスにそれを与えてやれば、Bitmap経由でGraphicsも使えるし、Span経由で読み書きもできるから、MarshalのSpanが使えない制限は多少回避できる。内部でどういう処理が走ってるのかわからないので本当に効率が良くなっているのかはさておき。
C#の引数でoutはf(out var result);みたいに受け取れるのに、refは先に変数を宣言しなきゃいけないのが地味に不便な気がする。f(ref var result=default)みたいな機能があれば便利そうな気がする。
usingでDisposeを呼ぶ構文で無名変数を作りたいんだけど、C#だとそういう処理ができないっぽいんだよなー。確実にクローズをやりたいメソッドで戻り値にIDisposeを返してそのクラスでクローズを行い、実際に触るデータはoutで返す、みたいなときに、using _ = method(arg1, arg2, out var result);みたいな感じで呼びたい。_ = method();みたいに戻り値を明示的に破棄する構文はあるんだから、同様に明示的に破棄しつつusingでDisposeは呼んでもらう、みたいな構文もほしい。
Taskの静的プロパティとかでIsCompletedにtrueを返すようなモノって無いのかな。タスクを実行しているかどうかの変数を使い回すときに、ひとまずnull以外の状態を入れておきたいような場合。var task=Task.Run(()=>{});みたいに空のタスクを入れてすぐ終わらせてもいいんだけど。というか空のタスクを1回走らせてそのタスクを使い回せばいいのかもしれないけど。
