地元で草。……地元? まあ、隣町も四捨五入すれば地元だろ…… 隣町と2つ隣町の合わせて2箇所。どっちも行ったことないけど(もちろん名前程度は聞いたことあるが)。
にじさんじ NIJISANJI EN×アマノフーズコラボ開催!! - インスタント味噌汁・フリーズドライ食品（即席味噌汁・みそ汁） | アマノフーズ公式通販
レオスとメロコが案件配信やってたフリーズドライ詰め合わせセット、試しにメロコセットをポチってみた。
届いたので、とりあえずカレーを試食。150mlのお湯でちょっとシャバシャバな感じになる。中辛だけど結構スパイシーで、刺激の強いものが苦手なので単体で食うのはちょっときつい。レトルトのご飯(180g)と一緒に食べるとちょうどいい味&量。パックご飯とレトルトカレーを合わせて食べようとすると2回に分けて加熱する必要があるけど、フリーズドライのカレーならご飯を温めている間にカレーを用意できるから、結構便利。ただしレトルトカレーだとパックご飯の片隅に少しずつ注ぎながら食べたりすればスプーン以外の食器が不要であるのに対して、フリーズドライだと器を用意する必要がある。まあ、普通はそこまで切羽詰まって食うこともそうそうあるまいし……
セットの他のカレーや味噌汁・豚汁も美味しかった。汁物はちょっと塩味が強い気がするけど、そのあたりはお湯の分量で適宜調整という感じで。
この案件は受付期間が結構長くて、しかも注文したらすぐ発送してくれる(注文の翌営業日に発送された)。フリーズドライの食品はあまり食べたことがなかったので、とりあえず1セットだけ注文してみたけど、届いて実食したうえで、もう一度コラボ商品を追加注文したりできる。あと、届いた人のレビューを見た人が注文する余地もある。その代わりに受注生産の案件みたいに特典がついているわけでもないけど。まあ、受注生産で発送まで2ヶ月かかるような商品でも入ってるのはチェキ風カード程度だしね。案件配信としては、気軽に注文とか再注文できるようなこういうタイプの販売形式のほうが好き。
Gmail、広告を表示するために受信したメールの時系列をデタラメにする馬鹿みたいな機能どうにかしてくれんかなぁ。最近のGoogleは結構高い頻度で頭の悪いことをやらかす。
WindowsSearchHostが中断または応答なしとなり検索ができない。 - Microsoft コミュニティ
スタートメニューの検索ボックス(おそらくタスクバーの検索ボックスも)が使えない問題。
1) Google IMEからMS IMEへ切り替える
2) SearchHost.exeのタスクを停止する
3) 検索ボックスに適当な文字列を入力する
4) Google IMEへ戻す
で治った。ような気がする。3を省略するとまたSearchHost.exeが応答しなくなるから、適当な文字列を突っ込んで一旦呼んでおく必要がある。Googleが原因かぁ。。。
Pixel6aに保護フィルム(ガラス)を貼ってみた。シートの付属品がかなり色々ついていて、貼り付け用の治具とか、アルコールシート、レンズクリーナー、ペリペリはがせるシール(ホコリ除去用)など。その割に説明書がペラペラで内容がかなり薄い。治具の使い方の説明とかも書いてないし。おそらくQRコードから動画を開けばいいんだろうけど。
結構気をつけて作業したけど、3個ほど埃が入ってしまった。小さいけど目立つねぇ。
ゆっくり作業するとその分埃が落ちる確率が高くなるから、手早く作業するべきだったんだろうな。あとは、入浴して体を清めてから薄着で作業するとか。作業領域の周りにろうそくを何本か立てるとか…… どんどん儀式っぽくなってくる。短気な神様が相手と考えるとちょうど良さそう。化物語の登場人物達がスマホの保護フィルムを貼る薄い本。
GPSロガーに使っている単4のNi-MH、なんか容量がすげー少ないような気がする。電池残量結構多いはずなのに低電圧で電源落ちることが2度ほど。電池の寿命かな? Ni-MHの寿命ってどうやって測ればいいんだろう。1Ω3Wくらいの抵抗を繋いで無負荷時と電圧を比べて、降下が大きければ(ESRが大きければ)寿命と判断する、みたいな感じだろうか。1A程度を流せる電池ボックス…… 本来は満充電のセルから1V付近まで放電させて電圧と電流の積和を取って容量を直接測るほうがいいんだろうけどな。結構手間がかかりそう。
本職の人たちが「充電池なんて信用できねぇ(CR123なら新品のセルを突っ込めば確実に使える)」といってた気持ちがなんとなくわかる気がする。再利用できる(使い捨てでない)やつを買うと捨て時を見失う。
***
GPS、RF受信から擬似距離を経てアンテナ位置の計算まで、とりあえず動くようになった。4週間くらい前の地点までようやく戻ってきた。長い回り道だったぜ…… キャリアへの位相ロックを省略したり、色々手抜きだけど。
前回は航法メッセージの送信時刻を固定として受信時刻から擬似距離を測っていた。要するにサブフレームが始まったタイミングの受信機時刻を擬似距離として使用していた。時刻分解能は1/sps(≒0.42us≒125m)に制限される。今回は任意の受信機時刻におけるサブフレームのタイミング(+GPS秒数)を擬似距離として使用している。内部的にはNCOでC/Aコードを出しているので、1/spsより細かい時刻分解能がある。実際にどの程度の精度が得られるかは怪しいところではあるけど。
クロック補正だけ適用して正解値との誤差が100m強、相対論を適用して60m弱。
電離層遅延を補正して50m弱。微妙な違いだけど、効果はある。電離層遅延を使わない場合、ENUで34m、9m、47m、位の誤差だったのが、電離層遅延を使うと37m、15m、22mと、上下方向の誤差が半減する。その分3次元的に平均的な誤差になる。東西方向の誤差が大きいけど、このときは7機の衛星(5xGPS+2xQZS)の内、東側にいたのは1機、北側にいたのも1機で、5機は南西側に固まっていたから、衛星配置はあまり良くなかった。その影響で東西の誤差が大きめに出ているんだと思う。
GPSからは電離層モデルは12.5分に1回しか送られてこないから、昼間にコールドスタートした受信機は最大で10分から15分程度待たないとある程度の精度の単独測位ができない(夜間であれば固定値なので情報を受信せずに補正できる)。UTC時差(主にうるう秒)も同じペースなので、起動してからしばらくは協定世界時ではなくGPS時刻を出力することになる。とはいえ、GPSのうるう秒の挿入は最大2^8週(約4.9年)先まで指定できるから、数週間前に受信したうるう秒の値があれば、UTCに比較的近いGPS時刻を出力できるはず。GPSのうるう秒の通知ってどれくらい前から実施されるんだろうか。というかうるう秒の挿入・削除ってどれくらい前から決定してるんだろうか。100年に1度程度の挿入へ変更すると「数年前から計画できる」とのことだから、今の1秒差未満の条件だともっと短期間でしか推定できないんだろうな。夏に急に台風が来て慌てて冬にうるう秒を入れたりみたいなこともあったんだろうか? 今後最大10年程度はうるう秒が使われるはずだし、廃止される前に1回くらいは受信しておきたいな。/* もしかしたら電離層とかUTCのパラメータはSBAS経由で頻繁に出ているのかもしれないけど */
地理院地図の標高って、いわゆる「標高」なのかな? ジオイド高を足して楕円体高に変換したうえで、GPSで求めた位置座標と比較すると、高度方向の誤差が+22m→-10mに変わって、ENUの距離も40m強まで(数m程度)改善する。
このあたりまで来ると、瞬時値(ある特定のタイミングで測定した擬似距離)を使って評価するのはあまり適切とは言えないな。もう少し長い時間、数秒から数十秒・数百点から数千点のサンプルで評価したほうが良さそう。
ということで、10Hzで500ポイントくらい計算。
↑電離層補正無し
↑電離層補正有り
上下方向がかなり改善している。水平方向は若干東側にずれる。もう少し大きく補正すると上下方向はほぼピッタリになりそう。対流圏遅延かな。
位置は綺麗に分散するのではなく、楕円形に固まっている。北東・南西に長い楕円なのは、衛星の配置が南西に固まっていて、かつ北北西と南南東に衛星が1基ずついるから、北西・南東の向きは拘束できている、という感じかな。衛星の配置が適切であればもう少しきれいな球に固まりそう。このときのDOPはGDOP4.98, PDOP3.93, HDOP2.54, VDOP2.99, TDOP3.05、くらい。HDOPは結構いい数字。北東側に衛星がないからもっと悪そうな気がするけど。測距精度が0.1チップ程度としてPDOPを掛けると120m程度。実際の測距精度を40mとしてPDOPで割ると測距精度10m(0.033チップ)程度、といったところか。まあ、妥当な感じかな?
ちなみに、電離層補正はQZSから得た値を使っている(先に航法メッセージを取り込んでから測位するので、距離的に遠いQZSの補正値が保存される)。GPSから得た補正値を使うとさらに5mくらい下がって、上下方向がより正しい位置に近づく。GPSとQZSの補正値、どっちを使うべきなんだろうか。QZSは日本地域向けの補正情報を出しているから、World補正値は日本周辺の重みを多少減らしていそうな気もする。
物の本で、測位に使うGPS衛星の位置(時刻)を未知として扱っているのが謎い。受信機の時刻にクロック誤差と伝搬時間を加味した時刻でGPS衛星の位置を計算して、位置計算に使用する、という流れらしい。しかし、ある受信機時刻に受信した航法メッセージは、そのメッセージが送信された時刻が100ns程度の精度でわかっているわけだから、その時刻の衛星位置を使うことができるはず。
測位でサニャック効果を含めなきゃいけない、というようなことも書いてあるけど、いまいちよくわからない(ググってもGPS/IMUのFOGとかRLGの話ばっかり出てくる)。確かにECEFの座標系は慣性空間の回転しているから、光速度が(見かけ上)変化しそうではあるが。
GPSの本、「GPSのための実用プログラミング」(2007)より新しいこの手の本(お手頃価格)ってないんだろうか? 軽くamazonで探した感じだと見当たらない。1980年代の技術がここ10年で急激に変わったみたいなこともないだろうから、わざわざ新しく出版するようなものでもないということなのかな。それ以降だとオンラインでの情報共有が活発になったから本にしなくても、という可能性もありそう。
***
C#で0xFFFFFFFF << 32の結果が0xFFFFFFFFになるのって直感に反する気がするけど、これってどういう処理になってるんだろう? シフト幅は下位5bitしか見てないから0bitシフトとして計算される、みたいなことなんだろうか?
上の方のシフト演算子の説明に何も書いてないからそんな制限はないはずなのに、と思ってたら、下の方に書いてあった。intとuintは5bitだけ、longとulongは6bitだけ使う、とのこと。もう少し上に書いておいてくれませんかねぇ。。。
こういう実装を採用した確たる理由は書いてないけど、環境依存を減らしたいんじゃね?みたいなことらしい。32bitのシフト命令には右オペランドの下位5bitしか見ないCPUがあるから、そいつに合わせた、みたいな。そういうCPUで1<<32を0にするには左シフト命令を呼ぶ前に右オペランドが32以上の場合は0を返すような分岐処理が必要になるから、そのコストを避けたいってことなのかな。
切り捨てするのもそれで追加コストかかるだろ、とも思うけど、分岐するよりはandのほうが軽いからそっちを優先したのかな。大抵のCPU(で走るランタイム)は切り捨てたりする必要ないから、32bit幅の右オペランドをそのまま使うほうが楽そうだけど。
***
WindowsからBluetoothで他のデバイスへファイルを転送するやつ、fsquirt.exeにファイルをドラッグアンドドロップすると送信モードでファイルが選択された状態で起動する(ターゲットデバイスをダブルクリックすれば転送が始まる)のに、コマンドラインとかで適当なファイルパスをオプションに与えてもその通りに動作しないの、謎い。なんでだ。Windowsで割り込んでなにかオプション追加してるんだろうか?
Fast Bluetooth Sharing From Windows- CodeProject
「"fsqirt filepath"で送信できるよ」とのこと。実行ファイル名間違ってるが。本当に送信できるんだろうか。
レジストリを見てみるとHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\BTHENUMの下にDev_XXXXXXXXXXXXみたいにデバイス固有の16進12桁のフォルダがあるから、fsquirtでデバイスIDとファイルパスを指定して、ドラッグアンドドロップするだけで特定のデバイスに送信してくれたら便利だな、と思ったんだけど、そうもいかないらしい。
fsquirtってWin XP SP2あたりで入った機能なのかな? SP1の頃は対応デバイスが少なくてテストしきれないからSP1にはBluetoothのサポートは入らない、みたいな記事があった。SP1より後にWindows Updateで入ったのか、あるいはSP2で入ったのか。
en.wikipedia曰くSP2ではBluetoothの部分的サポートを追加だそう。とはいえ、fsquirtの古い記事は2004年頃の物が出てくるから、SP2(2004年9月)から乗ってそう。20年前のアプリかぁ。ちなみにSP1(2002年9月)ではUSB 2.0のサポートが追加されているらしい。この当時だと実効100kB/s程度でもBluetoothのワイヤレスファイル転送は(対応デバイスが十分にあれば)魅力的だったんだろうなぁ。今の時代だと相当低速だけど。
***
2000年? 中部電力で、モノリシックRLGとサーボ加速度計を使った可搬型のIMUを試作。
電力会社は送電線の保守とかで森林の中を歩き回らなきゃいけないけど、ナビゲーションに問題があるので、IMUで解決したいみたいな方向性(この頃のGPSは樹冠の下では厳しいらしい)。
0 件のコメント:
コメントを投稿