小ネタ

　桜も散った5月に雪が降って草ですわ

　Veritasium Can a quantum sensor detect your heartbeat from 60 km away? - YouTube

　量子磁気センサで60km先から人間の心拍を見つけることは可能か?

　クリックベイトのタイトルはともかくとして、ゼーマン分裂の説明はわかりやすくていいな。「こういう原理だよ」ってアナロジーを見せられるとたしかにそうだと納得せざるを得ない(正しく理解できているかはまた別の問題として)。

　タイトルの結論としては、そんなに弱い信号は見つけられない、という話だけど、でも、人間の心拍に限らなければ可能なんじゃね?という気はする。数Hzとかの強力な交番磁界なんて簡単に作れそうだが。それこそ、ポケベルを鳴らせばスピーカーから強烈な磁場が出てくるんだし。受信専用に設定した無線機に接続したイヤホンのイヤーピースから出る磁場とかも使えるだろうし。無線を受信させてスピーカーなりを鳴らすなら相手が電波を受信できる必要があるけど、送信側は被探知はあまり気にしなくていいから強力な電波を絞って送れば済むし、それが嫌なら向こう側から手動で磁場を出すとかどうにでもできるし。DTMFみたいに適当に変調した磁場を出せばいろいろな情報(健康状態とか)を含めて受信できるし、複数個所で到達時刻を得れば双曲線で測位もできるし。

　GPS普及で役割終えた「ボルデメ」、展望台に…有視界飛行の操縦士目線（読売新聞オンライン） - Yahoo!ニュース

　操縦士目線……??

　面白そうなアイディアではあるな。これだけの設備を撤去するのもだいぶコストかかるだろうし、大量のアンテナを載せられるだけの強度もあるし、マルチパスが大きくならないように高い場所にあるし。グランドプレーンはスカスカだから足場に使えないのが難点ではあるけど。

「ストリートファイター6」とのコラボでeスポーツギアに本格参入 ゲーミングチェア、ゲーミングコントローラー、振動タイプ「ボルレッチ」発売｜ミズノ株式会社

　既存商品のラインナップを見る感じ、布製品に強い会社であって、eスポーツのデバイスに活かせるような技術を持ってる感じはしないんだよなぁ。なのでチームのウェアを提供するみたいな話は納得感があるけど、周辺機器に参入したところで……という感はなきにしもあらず。

　日本メーカーのゲーミングデバイス、OA機器某大手が作ったゲーミングマウスがプロゲーマーに酷評されてるのを見て、その動画を見る前に自分も買ってて実際に使っていてこりゃ確かにプロゲーマーから酷評されるのは納得だな、という出来ではあるんだけど、とはいえ日本メーカーらしい部分(コスト配分、日本人の手に馴染むデザイン、細かい気遣い、etc)も感じられるし、たぶん大手が本気でeスポーツに参入して、プレイヤー側からも適切なフィードバックがあれば、日本国内という狭いパイではあってもある程度の競争力はありそうな気がする。

　ただ、例えば韓国・台湾・中国みたいなアジア地域(概ね体格が近い)はすでに各国に強力な周辺機器産業があったりeスポーツに力を入れていたりというのがあるので、今から日本メーカーがそこに食らいつくのは厳しいはず。あと、欧米系の製品が体格に合わないという日本のプレイヤーはすでにアジア系のメーカーの製品を使っているはずだから、あとから参入した日本メーカーが取りに行くには、かなり強力に展開する必要がある。

　OA機器メーカーが、OA機器という「ダサい」イメージを脱却するために本腰入れてかっこいいデバイスを作るみたいな可能性はあるんだけど、とはいえ先述のメーカーはそれで大失敗してるからなぁ。/* 改めてamazonで見てみたらそれなりに新製品を出しているし、レビューもそれほど悪くなさそう。値段もアジア系の海外製品に比べると高いけど、欧米系の製品に比べれば安いし */

　観光施設で起きた事件をマスコミが毎日々々何度も繰り返し報道した挙句、開園したら「風評被害に負けずに！」みたいな報道をするの、マッチポンプがすごい。ネットで炎上したとかならともかく、それ以外の風評被害の大半はマスコミが加害者だろ。北海道のローカル民放局のYouTubeチャンネル、各々1日に何本同じ事件の動画を投稿してるんだよ。しかも容疑者顔大写しのサムネで。

　他の諸々も含めて、世の中のマスコミにもう少しでも良心があればもっと良い世界になるだろうになぁ。

https://www.hattori-hokokai.or.jp/pdf/90th_special.pdf

　光格子時計の公演の書き起こし。

　最後の方に、「提案したころはうまくいかないだろうと言われてcuriosity drivenで研究を進めた」的なことが書いてある。

　光格子時計は提案当初に18桁まで行けると示して、実際に18桁目まで出て、19桁目までは行けそう、みたいな感じらしい。セシウムは当初は10桁だったものが16桁まで、6桁の改善が進んだのと比較すると、光格子時計は2,3桁の改善はできるにしろ、発展性という意味ではちょっと厳しそうな感も拭えない雰囲気。まあ、これから四半世紀も改良を行えばもう何桁か行けるのかもしれないけど。

　光格子時計の精度があれば1ナノ秒ずれるのに30年かかるから、高速な通信で同期が楽になる、とは言われても、光格子時計を使うくらいならクロックを引き回せる距離じゃないから少なくとも数km離れた場所を想定しているんだろうけど、とはいえそんなに離れたら一般論的効果が効いてくるから結局クロック同期は必要なんじゃね?って気がするが。潮汐が同相と仮定してバイアスを掛けるみたいな使い方になるのかもしれないけど。

　モノリシック光格子時計みたいなものって作れるんだろうか? 1cm³+周辺回路くらいで16,7桁のクロックがあれば面白そうだが。しかし光的な周波数だと使いづらいから、周波数コムみたいなものも小型化して一緒に載せないと使いづらいだろうし、それにしたって相当高い周波数だろうし。

　周波数コム周りを調べてみると6G通信で使いたいとか言っているから、普及させようと思えば5年10年程度でスマホに積めるくらいに小型化できる見込みはあるんだろうけど。

https://www.nict.go.jp/publication/kiho/45/001-002/Kiho_Vol45_SI_No001-002_pp019-026.pdf

　1999年。時刻の決め方とか、HM、Rb、Csの大まかな構造とか。

　Cs原子時計でCs原子を使い捨てにしているのってなんでなんだろう? CSACみたいなデザインだとCsガスセルの中身を入れ替えずに使うから、原理的に原子時計では原子の再利用が不可能ということはないと思うんだけど。ある程度の大きさ(相互作用時間)のキャビティで再利用しようとすると原子を運ぶのが面倒(故障率マシマシ)で、10g弱詰め込んでおけば数十年は使えるから、よほどカリカリに小型化しようとしなければ使い捨てにしたほうが設計が楽、みたいなことなんだろうか。

　RF64/WAV、ヘッダ部を除けばRIFFと互換のはずだけど、SDR#が吐いたRF64は十分に小さいファイル(数十MB)でも、RIFFファイルサイズ(4バイト目以降)とdataチャンクサイズは-1(FFFFFFFFh)で埋められていて、ds64を参照しないとファイルサイズ/dataチャンクの大きさがわからないようになっている。

　RIFFでファイル/dataチャンクのサイズが-1になっていると、例えばSoundEngine Freeでは音声ファイルの長さを正しく認識できない(実際のデータの後ろに0固定の波形が続く)みたいな挙動があるけど、でも-1埋めのRF64は正しい長さ(SEFはサンプルレートが正しく読めないのでスケールがあるけど)で表示されるから、両方とも-1埋めが正しい実装なんだろうか。

　どうせRF64に非対応ならWAVとして開けないから、中途半端にRIFFとRF64を互換にする必要はない、というようなことなのかもしれないけど。

　RTL2832/R820TのDLLを叩こうとして、"rtl-sdr cb transfer status: 4, canceling"のエラーでデータが取れない現象、rtlsdr_reset_bufferを呼んだら解決。rtl-sdr.hには何も書いてないけど、サンプルアプリのソースにはReset endpoint before we start reading from it (mandatory)とコメントに書いてある。あの、そういう大事なことはライブラリのヘッダの方に書いておいてくれませんかね。。。

　rtlsdr_read_asyncのコメントにRead samples from the device asynchronously. This function will block until it is being canceled using rtlsdr_cancel_async()と書いてあるんだけど、非同期とは一体……

　rtlsdr_read_syncを使うとlibusb_bulk_transferを直接呼ぶので、バッファが埋まるまでブロッキングで動作するけど、少なくとも指定した長さのブロックが埋まれば制御が帰るので、read_asyncで完全にブロックされるよりはマシ(libusbでタイムアウトが0なので低sps+大容量バッファみたいな組み合わせだと長時間ブロックされる)。ただし低レベルを直接コールするから、呼び出し間隔が長いとデータを取りこぼしたりするはず。

　read_syncとread_asyncは、呼び出し側から見たsync/asyncではなく、デバイスに対して同期的か非同期的かという感じなんだろうな。syncは呼び出し側がデバイスと同期的に処理する必要があるから、ノンブロッキングな代わりに動作に余裕がない。asyncは間に1層挟まっているから呼び出し側(コールバック関数に渡した処理)で若干時間がかかっても吸収できる。まあ、間に挟まったバッファも無限に容量があるわけじゃないから、程度の問題だろうけど。

　結局asyncでブロッキングされるくらいなら、C#から呼ぶなら適当なタスクを挟んで、自前でsync読み出しをやるほうが便利そう。でも、適当なタスクからasyncを呼んでも、結局やることは変わらないんだよな。syncだとメモリコピーが2回減るからパフォーマンス的には有利だけど、今どき数MB/s程度のメモリコピーのコストなんて気にしても……