11-Jan-2026に作成したアダプタを使用して縦振電鍵をパソコンに接続し、DitDahChatで正しく符号が叩けているか見てみたのですが…どうも思ったような結果になりません。電鍵は使っていませんが、HARIO CW SIMULATORの操作も四苦八苦しており、キーon/offのタイミングが正しく伝わっていないのかなと考えています。

Windows APIレベルでの状況とWebSerialでの状況を把握すべく、Google AIの力を借りてテスト用のコードを起こしてみました。諸々一式はここに置いておきます。面倒なので縮小もせずスクリーンショットをぺたぺた貼ってしまうのですが…

・Windows API (COM2)

・Windows API (COM4)

Windows API越しにDSRを読み取る分には、COM2(16550)/COM4(USB-UART)の違いはなさそうです。DSR ON/OFFの期間に3ms程度の差がありますが、これは信号源にTAM-KEYER102を使っているからです（詳細は06-Nov-2025参照）。

・Web Serial API (COM2)

・Web Serial API (COM4)

COM2側のタイミングの暴れっぷりもなかなかすごいですが、だからといってCOM4が落ち着いているとは言い難いものがあります。

PARIS 10WPM（短点長120ms）程度の遅い符号であればWeb Serial API越しでも問題ないかもしれないのでしょうが、webアプリでPARIS 25WPM（短点長48ms）クラスの送信練習をしようとしても、USB-UARTのDSRをチェックするタイプのインタフェースでは追従できなくてもおかしくない気がします。58.0kg(21:35)

17-Jan-2026の続き。欧文モールス符号が文字の出現率に合わせて最適化されているとして、では和文では？という疑問は当然持ちます。

（言語資源の入手元と統計のための加工方法についてはとりあえず伏せます）を使って調べてみたところ、こんな感じのデータが得られました。このデータではヂ(0.000034)とイ(0.056402)との間には1658.88倍の開き…欧文以上に頻度の低い文字と高い文字の差がありますが、資源と加工方法によってはここから大きく変わる可能性も当然あり得ます。たとえばラジオをラヂヲと書いていた時代の文章とか。

MojiGene.iniに設定するCharGroup0の設定、これだけ文字の出現率に開きがあると対数での処理…それもlog₁₀で処理するのが適当かと考えています。こんな感じでしょうか："CharGroup0 = イイイイウウウウンンンンノノノノシシシシツツツツカカカカ、、、、トトトトニニニニタタタタククククヨヨヨヨハハハハガガガガルルルルテテテテココココナナナナデデデデキキキキアアアアモモモモジジジジレレレレススススリリリリソソソソママママ」」」」ララララヲヲヲヲチチチチユユユユセセセセオオオサササケケケエエエドドドダダダヤヤヤロロロワワワメメメミミミ（（（ヒヒヒ）））ブブブホホホバババーーーゲゲゲフフフゴゴゴネネネムムムビビビゼゼゼズズズ１１１パパパギギギヘヘヘベベベザザザ０００ゾゾゾ２２２ボボボポポポグググ５５ヌヌ９９８８ヅヅ３３ププ４４７７ピピ６６ペペヴヴヂ" ※必要に応じヰ・ヱを追加

和文（電報文）においては文字数を減らすために数字を混ぜる、例えば「ツイタチ」を「１ヒ」とするような記法が使われていたと聞きますから、CharGroup1は使わずにCharGroup0に全てまとめてしまいます。57.7kg(22:25)

SoapyRTLSDRについてもrtlsdr_read_sync()化を行ってみようかなと。というのも、CubicSDRのportsが来ていますから。流石にこれらの修正は本家に入れてもらうよりもportsのパッチとして出すのが適当そうなので、そちらの方向を目指してみることにします。

10月にある試験（無線系ではありません）を受けようかなと考えているのですが、なかなか試験勉強が進みません。遊んでいる場合じゃないんですけどね…57.0kg(22:10)