MojiGene/a1a_genでどんな感じの練習をしているのか、シェルスクリプトを晒してみます。これは以前からやりたかったことなのですが、なかなか練習の方法が固まらなかったので…

ecode.sh, ecoden.sh, ecode.ini

欧文（暗語）用。ecode.shはアルファベットのみ、ecoden.shはアルファベット＋数字。ecode.iniは設定ファイル（とりあえず300文字、5秒待ってから再生開始）。

etext.sh, etextn.sh, etext.ini

欧文（普通文）用…とはいえ、中身は2文字〜12文字の単語っぽい感じの乱文。etext.iniで文字の出現率をいじっている（詳細は17-Jan-2026を参照）。

jcode.sh, jcode0.sh, jcode1.sh, jcode.ini

和文用。jcode0.shは短い符号に特化、jcode1.shはその逆。jcode.shは符号の縛りなし。文字がずらーっと並んでいると読みにくいので、'｜'で区切るようにしている。

player.sh

[ej]*.shから呼び出される、PCM再生プログラムの設定用スクリプト。OpenBSDはaucat、それ以外はpacatを使うようになっている。

指定が無ければPARIS 24WPMで、./etext.sh 20のように値を指定した場合はその速度で再生します。本当の（普通文を意識した乱文ではなく）普通文や額表については、日替わり通信術練習やモールス練習帳（電報編）に頼ることになるでしょう。56.3kg(22:00)

電気通信術（欧文）の練習、PARIS 24WPMの暗語で300文字のうち10文字落とすかどうかくらいの領域までどうにか来ることができました。とはいえ調子次第では20文字以上落とすこともあり、未だ安定しません。普通文の練習をそろそろ始めないとなーと考えている際に、3.1.3普通語への対応(plus TK2S)にある、暗語は取れても普通文は取れないことについて調べてみました（リンク先に答えは書かれていますけどね）。

欧文モールス符号、文字の出現率に応じて最適化されていることはよく知られている話です。では文字の出現率とは実際どんな数字なのか…genspark.aiに尋ねたところLetter Frequencies in Englishを紹介されたので、これを使います。この統計が何をソースにしているのかについては、とりあえず一旦脇に置きます。

頻繁に出てくるe(0.12702)、滅多に出てこないz(0.00074)、171.65倍の開きがあります。MojiGeneが乱文を生成する際に使用する文字セット（主）(CharGroup0)の指定は、同じ文字を書けば書くほどその文字が出やすくなる作りになっているので、出現率の高い文字を数多く記述すれば実現できそうですが…現時点の作りでは、設定ファイルの一行の上限は改行文字とヌル文字を含めて256文字です。なので、eを172個列挙するのは流石に無理があります。また、ここまで極端にeやt(0.09056)が突出していると、他の文字の練習はおろそかにならないのかという疑問もあります。

出現率をそのまま使ってしまうとあまりにも幅が広いため、列挙する文字の数をこんな感じで求めてみることにしました。ばらけ具合(?)はlogの底で調整しますが、log₂, ln, log₁₀を比べるに…とりあえずlnで良さそうな気がします。

対数で処理しているため実際の出現率より穏やかになっているとはいえ、出現率一定(1/26)から少し偏らせてみるとどうなるかという実験としてはこれで十分でしょう。

という訳で、"CharGroup0 = eeeeeettttttaaaaaaooooooiiiiiinnnnnnssssshhhhhrrrrrdddddlllllcccccuuuuummmmwwwwffffggggyyyyppppbbbbvvvvkkkjjxxqz"を指定して作成した暗語をa1a_genで鳴らしてみると…同じPARIS 24WPMでも速いです。出現率一定だと100cpmくらいなのに対し、こちらは110cpm。流石に取れなくなります。実際の出現率に合わせると、文字通り120cpmまで跳ね上がるのかもしれません。

結論として、符号自体の速度は同じであっても「単位時間当たりの符号の数」が普通文では増すため、通信速度が上がります。短い符号が増えればその分速くなるのは当たり前だろ？という話ではあるのですが…だとしても、普通文が速く感じるのは何故なのかと気になっていましたから。57.9kg(23:35)

18-Jan-2026補足：出現率を対数で処理しない場合のCharGroup0を作ってみました。MojiGeneに手を入れてこれを扱えるようにし（現時点ではdevブランチのみです）、a1a_genで鳴らすと130cpm近辺まで跳ね上がります。流石にこれで練習するのは厳しそうなので、まずは対数(ln)で処理したものを使うことにします。

欧文電報送信練習帳・和文電報練習帳を入手したので、縦振電鍵を久々に叩いてみようとHK-705（旧モデル）を引っ張り出したは良いのですが…発振器モードに設定したTAM-KEYER102を繋いでみるとマトモに鳴らず、符号がかすれます。接触不良を起こしているとはいえ、磨いても直るのかどうか。接点の交換が可能であれば、これを試みたいところです。

オークションで手に入れたHK-707（こちらも旧モデル）は、裏の金属製の部品を外してみると液体をかけられたと思しき錆が大量に。写真で見えない部分の問題は流石に分かりませんし、未チェック現状品として出品されていたのでクレームの出しようもありません。分解清掃の練習台にしてしまいましょう。

これらに加え、Digital Sound CW(DSCW)とUSBサウンドアダプタとの相性が悪いのかどう頑張ってもTAM-KEYER102の音響出力を受け付けてくれないとか、CWTW-Pro Rev 3.01ではUSB-UARTアダプタのDTR-DSRピンをキーに繋いでもキー入力を検出してくれないという問題に遭遇しています。

前者については諦めるとして、後者についてはConnect a CW Key to a PCにもあるように、DTR→DSR/CTSに繋ぐことは確かに合っています。ただし、それはRS-232Cでの話。USB-UARTアダプタでは使用するチップにもよりますが、DTR#, DSR#, CTS#が負論理…DTR#で給電するなら"High"を出力するようにソフトウェアを修正する必要がありますDTR#は使わずに適当なVcc出力とプルアップ抵抗でDSR#, CTS#をhigh側に吊っておき、キーダウン時にlow(GND)に落とすように作ると良さそうです。なんか面倒なので部品箱からDB9コネクタを引っ張り出して、USB RS-232Cアダプタ越しに繋げることにします。

和文（電報形式）の特別取扱と局内心得、和文電報練習帳に例文があるというblog記事を見ました。手元の和文電報練習帳（令和3年11月1日発行）と少し内容が違うようです。

【古い(?)版の練習帳】…雷撃を受けた船舶の沈没による死亡を伝える

• 練習課題一〇（47ページ）
• 種類：クヤミ
• 特別取扱：三〇ヒゴゼン
• 局内心得：オシバナ

【手元にある練習帳】…南方の洋上から結婚を祝う

• 練習課題一〇（44ページ）
• 種類：イワイ
• 特別取扱：（なし）
• 局内心得：デラツクスオシバナ

練習帳を見る限り、種類・局内心得の設定された課題はこれだけに見えます。どのような内容がこれらに設定され得るかは、（そんなものが現存するかどうかは分かりませんが）電報の内規について調べる必要がありそうです。日本無線電信電話法規集だけでは、全ての問いに答えてくれないので。57.6kg(22:25)

12-Jan-2026補足：DTR#をhighレベルに上げるという問題ではなく、DSR#, CTS#が負論理になっている点への対処が必要なので、改めました。

和文電信、"、"はともかく"（）」"が混じると確実に取れません（そしてその後の数文字も巻き添えを食らう）。これは国試にも出る文字なので確実なものにする必要があります。

手に無駄な力が入り過ぎているせいかは分からないのですが、文字を書いているうちに右手が痛くなってきます。Acroballを使っているのですが、他のボールペン…JETSTREAMやSARASAも試してみようと思います。

でも一番重要なのは練習環境ですかね。数分間も集中させてもらえない（邪魔する要素があまりにも多すぎる）というのは、流石に練習になりません。家の中ではなく車の中に逃げ込むくらいしか案が無いのですが、寒いのは流石に…

工人舎ML＋OpenBSD-currentでX.orgがSegmentation Faultする件は、openbsd-techで聞いてみたところxorg.confで 1)intelドライバを使うように指定する 2)modesettingドライバならSWCursor onを指定する のどちらかで対処できるそうなので、2)で対処しています。Void linuxやNetBSDも確かX.orgの機嫌が悪いと記憶しているので（何もせずにマトモに動くのはSlackware{,-current}くらい）、同じ方法で解決できれば良いのですが。

とりあえず、この状況なら…OpenBSD/i386用のマシンは無くても大丈夫かな？（稼働できるようHDDを載せたりmemtest86+での動作確認くらいはしてある）57.3kg(22:55)

本年もよろしくお願いします。

CMOSバッテリを交換した工人舎MLにOpenBSD-currentを入れてみたところ、X.orgを動かそうとするとSegmentation Faultを吐いて動きません。そりゃないぜ、ということで問題を解決するための手がかりが何か得られれば良いな…と思ってxenocaraのビルドを試みたりしています。

とはいえ、今となっては非常に遅いんですよねこのマシン。i7-7700上のQEMUを使ったOpenBSD-current仮想マシンでxenocaraをビルドすると1時間ちょっとの時間で済むのに対し、MLだと8時間かかります。もちろん、必要な箇所だけビルドするようにすれば時間の短縮はできるのですが、それでも（デバッグ用のprintf()を仕込んだ場所では）結構な時間がかかっています。

QEMU上でOpenBSD/i386を動かす場合はmpbios/acpimadtの両方を殺さないと異常に遅いという問題もありますので、これ専用にマシンを一台、マシンの組み直しでお払い箱になった部品を適当にかき集めたものを…既に昨年組んでいたりするのですが、これを実戦投入すべきかどうか悩んでいるところです。

なにしろストレージがHDDだったり、xenocaraのビルドはmake -jで複数のCPUコアを使うことを推奨していないので、なんだかんだでQEMU上の仮想マシンの方が速いという可能性もありそうです。

他にも色々やらないといけないことがなんか山積みという気がしますが（去年サボっていたことがそのまま残っているだけです）、少しずつ片付けるしかないのでしょう。うぅ。57.1kg(23:20)