最近の電信の受信練習、使うんだか使わないんだか分からない機能を使っています。謎機能はトーンの周波数に対しても有効なので、-t 600,900とすると600〜900Hzの間の適当な周波数で鳴ります。練習の度に周波数が変わるので飽きないんじゃないかな、多分。こうなると波形のタイプをランダムにする機能も実装したくなるのですが、これについては種別の指定が面倒そうなので（全種類の中からランダムでも良いのかもしれません）現状では何もせず、鋸波の音に飽きた時にどうするかも考えます。
文字間は、135msを目安にして練習しています。25WPMなら2.8点、22WPMなら2.5点くらい。基準となる、短点の長さが同じでもだいぶ速く感じますし、一分間当たりの文字数もちょっと増えます。これが効果的な練習になるかは分からないものの、現実において送信者がきちんと文字間3点を守ってくれる保証もないので、多少詰まった符号でも怯えない訓練は必要かなと。
最近は、欧文がボロボロになりがちです。特に、実際の文字の出現率に合わせた乱文において。なんというか、文字間を短くしたところで文字に反応できても、符号の鳴っている間に文字を書き切れないとかうっかり書き間違えた場合は消している間に数文字落とすとか、そういう状況です。出現率一定の5文字暗語でもその傾向が多少減る程度で、まだ和文の方が取れている？感じです（同じ短点長でも符号構成の関係で相対的に遅くなるからなのですが）。とはいえ、和文についても文字の出現率に応じた乱文を作成した場合はどうなることやら。
OpenBSDでrtl-tcpがちゃんと動いていない、どうも受信データを流すbulk pipeが動きまくっていると周波数変更等のコマンドを送るcontrol pipeが詰まるみたいだ、ということでrtl-tcpの再実装(rtl_tcp_sync)を勢いに任せてやってしまいました。とはいえ、Experimenting with RTL-SDR on NetBSD 10という先行事例、あったんですね。これはrtl-tcpにパッチを当てて、rtlsdr_read_sync()の後にrtlsdr_callback()を呼び出すworkerスレッドを作ることでうまくsync read化しています。sync readの隙間にrtlsdr_set_center_freq()等の制御を挟み込ませてもらえるかは分かりませんが、多分大丈夫なのでしょう。コードを書く前に、最初にこっちを試せば良かったか。
rtl_tcp_syncは、rtl_tcp.cを参考に書き直した物をGoogleのAIモードに食わせてレビューしてもらうというスタイルで作っています。反生成AI派からすれば、レビューしてもらおうがAIにコードを書かせようが、AIを関わらせる時点でお前の手で作った物じゃねえだろと恰好のサンドバッグになりそうですが、そもそもrtl_tcp_syncはrtl-tcpの焼き直しなので最初っから自分の物ではありません。自分にしては珍しくGPL-2.0にしているのも、rtl-tcpのライセンスに従ったからです。
AIのレビューは本当に強力で、不慣れなpthreadの扱いについての意見をもらえるとか（実は13-Jul-2026の日記もこれに絡んだものだったりします）、rtl-sdrが有名なOSSということもあり原典との比較もやってもらえるのは非常に助かりました。これ、自分一人だと目視のチェックだけで相当の時間を使ってしまいますし、スレッド絡みの厄介なバグを作り込んだかもしれません。
ただし、AIを使うならAIではなく「自分で」書いたコードを主体にしたいと思っています。AIにコードを書かせるとしたら、std::scoped_lock lock{m_mutex}をデッドロックさせるサンプルコードのような、ちょっとした動作検証用の物を任せたいです…そのコードが何をやっているか、自分自身で把握したいというのがありますから。コードを書くことが仕事ではなく趣味になったからそう言えるのかもしれませんけどね。
20日ないし21日恒例の、JMHの電波予報。前回は21-Mar-2026。周波数はいつもの13MHz帯。
一年前の20-Jul-2025と比べると、00:00〜03:00, 15:00〜18:00(JST)の状況が少し異なっています。57.4kg(22:15)
