体重、増えますね…57.9kg(22:55)
Weact StudioのCH552ボード、随分前に買っていたのがあったのでちょっとArduino IDEでつついてみたのですが…VirtualBox上のDebian-13でArduino IDEを動かしていたせいか、どう頑張っても書き込めない事態になっていました。
単にボードを接続しただけの状態では、bootloaderによりUSB-CDC(/dev/ttyACM0, idVendor:idProduct=1209:c550)として振る舞います。書き込み時はここから一瞬だけDFUモード(idProduct=4348:55e0)に切り替わり、書き込み終了後に再びUSB-CDCデバイスとして動作します。
VirtualBoxのUSBフィルタ設定でUSB-CDC動作時はゲストOSへ自動的に接続することができるようになるものの、DFU動作時の設定を加えてもVirtualBoxがエラーを起こしてゲストOSへ自動接続できず、その結果書き込みに失敗します。あと少し何かをすれば解決するのかもしれませんが、面倒なのでLinux実機でArduino IDEを動かせば良いとぶん投げることにしました。
とはいえ、Linux上でもDeqingSun/ch55xduinoの説明にあるように、/etc/udev/rules.d/99-ch55xbl.rulesを設定する必要があります。57.6kg(21:35)
Windows APIレベルでのキー入力インターバルの測定は09-Aug-2026でコードを書いていますが、PC-UNIXについても測定用のコードが必要だよねということでGoogle AIと相談しながら作ってみました(今回はlibinputのサンプルをベースにしているのでAIには書かせていません)。Linux(Debian-13)/OpenBSDでの動作を確認しており、注意事項が三つあります:1)実行にはroot権限が必要 2)OpenBSDにおいてはX.orgが動作していない状況で実行する 3)ESCキーの押下で実行を終了する
OpenBSD上で実行し、USBキーボード(DELL KB216)を適当にがしがし叩いて入力インターバルを測ってみると、最短で16msのようです。Endpoint DescriptorのbIntervalは24。USBホスト側の実装にもよりますが、インタラプト転送は2nフレーム周期でトランザクションを行うことが多いために16という数字はおかしな話ではありません。
USB-HID経由の電鍵接続アダプタをどうしたものか…これについてはDitDahChat 電鍵・パドルインタフェース(DDCI01)を使います、モニタに応募したら当たってしまったので。応募条件にあった、組み立てと感想に関する一連のポストはこちらにあります。ソースコードは今後公開予定らしいのですが、UIAPduino(CH3V003)をベースにしているため、おそらくrv003usbを使用してUSBを喋らせているのでしょう。TAM-KEYER102を接続し、大体30msくらいの長さの短点をひたすら送信した場合の結果を見る限りでは、32ms±8ms…TAM-KEYER102側の周期とUSB側の周期とのずれが揺らぎとして見えています。bIntervalは10なので、8フレーム毎のトランザクションを行っている、で良さそうです。
±8msのずれが生じるとなると…許容範囲を±10%と仮定するなら短点長は80msになるのでしょうか。そうなると、PARIS WPMは1200÷80=15、和文があった頃の一アマの電気通信術程度の速度(欧文なら60文字/分、和文は50文字/分)までは対応できそうだと考えます。これよりも高速な打鍵を行って「ちゃんと符号が打てない」と宣う輩は、クレーマー扱いで良いでしょう。57.6kg(23:10)
05-Sep-2026補足:測定用のコード、折角なのでマウスボタンへの対応も行ってみました。何に使うのと言われても分からないのですが…欲しくなったので。旧版はこちら。
電鍵をPCに接続するアダプタ、(USB-)UART経由の場合におけるタイミングの測定は09-Aug-2026で一応できたことにして、ではUSB-HID経由の場合はどうなん?ということになります。今回もGoogle AIに作ってもらったコードをここに転がしているのですが、アダプタをどうしたものか…
とりあえず、自分が現在試作している、Arduinoでタイミングを計測してその結果をPCへ送るタイプの電鍵インタフェース(Simple Key Interface、skifと名付けました)にTAM-KEYER102を接続した場合のスクリーンショットを上げてお茶を濁してしまいます。

YACK(Yet Anothier CW Keyer)に倣いキー入力の信号線とGNDに0.01μF(10nF)を入れることでチャタリング対策をしていますが、TAM-KEYER102相手ならこれで問題無いものの、縦振電鍵相手では効果不十分だったのでeager debounceのロジックを入れています。UART越しのアダプタなのでWeb serialを使ったweb appでも使えるのが利点と考えていますが、USB-UARTの使えるArduino UNOの類が必要なのでコスト面では不利そうです。
とりあえず、こちらとしてはアダプタの考え方を示す(プロトコルの策定と基本的な動作を確立させる)ことが目的なので、あとは実装者に丸投げしちゃいます。57.2kg(23:55)
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の設定、これだけ文字の出現率に開きがあると対数での処理…それもlog10で処理するのが適当かと考えています。こんな感じでしょうか:"CharGroup0 = イイイイウウウウンンンンノノノノシシシシツツツツカカカカ、、、、トトトトニニニニタタタタククククヨヨヨヨハハハハガガガガルルルルテテテテココココナナナナデデデデキキキキアアアアモモモモジジジジレレレレススススリリリリソソソソママママ」」」」ララララヲヲヲヲチチチチユユユユセセセセオオオサササケケケエエエドドドダダダヤヤヤロロロワワワメメメミミミ(((ヒヒヒ)))ブブブホホホバババーーーゲゲゲフフフゴゴゴネネネムムムビビビゼゼゼズズズ111パパパギギギヘヘヘベベベザザザ000ゾゾゾ222ボボボポポポグググ55ヌヌ9988ヅヅ33ププ4477ピピ66ペペヴヴヂ" ※必要に応じヰ・ヱを追加
和文(電報文)においては文字数を減らすために数字を混ぜる、例えば「ツイタチ」を「1ヒ」とするような記法が使われていたと聞きますから、CharGroup1は使わずにCharGroup0に全てまとめてしまいます。57.7kg(22:25)
SoapyRTLSDRについてもrtlsdr_read_sync()化を行ってみようかなと。というのも、CubicSDRのportsが来ていますから。流石にこれらの修正は本家に入れてもらうよりもportsのパッチとして出すのが適当そうなので、そちらの方向を目指してみることにします。
10月にある試験(無線系ではありません)を受けようかなと考えているのですが、なかなか試験勉強が進みません。遊んでいる場合じゃないんですけどね…57.0kg(22:10)