a1a_genはこんな風に直しました。文字→符号テーブルを直し、「ゔ」という文字が来たら「･･- ･･」を鳴らすという安直な対応です。「ゔ」→「う」＋「゛」に分解するなんて高度なことは、しません。

というのも、icu4c、まさかC++向けのライブラリだったとは…C/C++混在についてはMojiGeneの乱数生成部分の改良やnsdemuのuBitcoin対応で既にやっているので別に気にならないものの、ICU: Unicode正規化 (icu::Normalizer2) [C++]のサンプルコードを見るとこれはお気楽には扱えないなと。

「㌠」を「サンチーム」と分解してくれるのは非常に魅力的なのですが、そもそもa1a_genにその辺の文章を食わせる訳ではなく、乱数で生成した文字列（そこには㌕だの㌫といった組文字は存在しない）を与える以上は、安直な対応で十分使えるはずです。そもそも、あれこれ悩むための時間が無いんですよ。55.7kg(22:40)

WabunMorseProで和文のリハビリを始めて気付いたのですが、これMojiGene+a1a_genではできない濁点/半濁点付きの文字の練習ができるんですよね（a1a_genが濁点付き文字に対応してないだけともいう）。

濁点付きの文字を文字＋濁点に分解する手法は…テーブルを作ってa1a_genにやらせるか、icu4cを組み込んでUnicode正規化(NFKD)により分解するか、悩むところです。icu4cを使う方向にしたいとはいえ、wchar_tをicu4cのUChar(UCS-2)にどう変換したものかという問題もあって。

OpenBSD等のPC-UNIXなら基本的にwchar_tはUCS-4であることが多いものの、UCS-4であることは一切保証されていません（__STDC_ISO_10646__が定義されている場合は除く）。またアルファベット＋かな程度の文字が使えれば良いのでUCS-2で表現できないUCS-4の文字は�に置き換えてしまえば良いと思うのですが、本当にそれでいいのかとも思うのです。かといって、fgetws()で一気にUTF-8→たぶんUCS-4に変換できる部分を、iconvなりmbrtoc16()でちまちま変換したいかというと…やりたくない…55.8kg(22:20)

随分前に買ってはいたのですが、ちゃんと動かしていなかったなーって。なにしろ、ピンヘッダを生やしてブレッドボードに装着するとmicroSDの抜き差しができなくなるのがツラいんだもん…

U-bootのビルド ※https://docs.u-boot.org/en/latest/board/sophgo/licheerv_nano.html

git clone https://github.com/u-boot/u-boot/; cd u-boot; export CROSS_COMPILE=riscv64-unknown-elf-; gamke sipeed_licheerv_nano_defconfig; gmake

OpenSBIのビルド ※https://github.com/sophgo/fiptool

git clone https://github.com/riscv-software-src/opensbi; cd opensbi; export CROSS_COMPILE=riscv64-unknown-elf-; gmake PLATFORM=generic FW_FDT_PATH=/path/to/u-boot/u-boot.dtb

fiptoolを使用したFIP(Firmware Image Package)の作成

git clone https://github.com/sophgo/fiptool; cd fiptool; python3 fiptool --fsbl data/fsbl/cv181x.bin --ddr_param data/ddr_param.bin --opensbi /path/to/fw_dynamic.bin --uboot /path/to/u-boot.bin --rtos /dev/null

出来上がったfip.binを食わせればおしまいなので…こんな感じのスクリプトでディスクイメージを作り、microSDに書き込んで起動すると、なんとなく動くことを確認しています。56.3kg(22:25)

相変わらず腰は微妙に痛いのですが、文字通りの重い腰を上げて、MX-K2の残骸を100円均一のお店で売られていた食品保管用のケースに納め直しました。金属ケースではないため、高出力運用時におけるRFの回り込みによる誤動作の可能性を考えると頭が痛くなりますが…とりあえずゴミにしないことを主眼に置くなら、これで。

開け閉めのしやすいケースなのでUSB電源化せず電池のままでも良かったのでは？とか、半透明なケースなら別にLEDの付け替えは不要だよねとか、反省点は多々あります。ついでに、yack-arduinoをエレキーとして使えるようパドル接続部/コマンドボタンを補うものを作ってみました。seeed studioのリレーシールド互換品と組み合わせて、こんな感じ。

リレーシールド互換品はseeed本家と違い裏側に絶縁板は無く、Arduino UNOのUSBコネクタとの接触に注意という文言があります（実際、接触してしまい使えたものではありません）。なので手元のArduino UNO R3はどれもダメで、Arduinoに見える物はWAVGATのLGT8F328P搭載品を使っています。搭載されるリレーはTIANBO HJR-4102L-05V、データシートによれば動作時間/復帰時間ともに≦5msだそうで。半導体スイッチのように即座に動かないことがキーイングにどう影響するかは、少し気になります。

リレーシールドはD4〜D7で制御するのでD4を使用し、パドルはD14（長点側）とD15（短点側）、コマンドボタンはD19に割り当てました。D14とD15はYACKの説明書に従い、それぞれ10nF(0.01μF)をGNDと並列に接続しています。サイドトーンが無いのと、それを代替するにもArduinoに装備されたLEDがリレーシールドで隠れてしまっているのがちょっと困りますね…パドルに割り当てるGPIOを変更してパドル接続基板にLEDを付けられる場所を用意するのが難しそうなので、これはLED基板を挿して対応するしか無さそうです。確か、随分前にその手の物を買っていた気もするのですが、どこへやってしまったのやら。

危うく20/21日恒例の、JMH電波予報を見逃すところでした。20-Apr-2025以来です。いつも通り、13988.5kHzです。

昨年(21-Jul-2024)よりかは綺麗に受信できてい…る……？56.3kg(12:35)

iambicモードのお勧めに関する話をどこかで見てたはずなんだけど…と探していたら、all about squeeze-keyingで見つけました。これ、いくつかの版があるみたいですがhttp://cq-cq.eu/DJ5IL_rt007.pdfにある最新版でないと載ってません。

"comparing the modes"の手前、"dot/dash-memory scrutinized"の最後にある

The bottom-line is that with a twin-lever keyer in single-dot or iambic mode dot-memory does really make sense only if it is operated like a single-lever keyer, which means not to utilize the benefits of queeze-keying and to blow the chance to learn and ingrain proper timing. Therefore it is my advise to all those who want to start with iambic keying to decide for the plain iambic mode without dot- or dash- memory.

（原文ママ）、ということなんでしょうかね。「ダブルレバーパドルを使ってsingle-dotないし短点メモリを有したiambicモードが意味を成すのは、シングルレバーパドルのような操作を行う場合に限る。すなわちこれはスクイーズ操作の利点を使わず、（注：パドル操作の？）適切なタイミングを学び、身につける機会を失ってしまう。ゆえに、iambic keyingを始めたい人は長短点メモリを装備しないplain iambicモードを選ぶことを勧める。」と。もうAとかBとか関係ないですよねそれ…

汎用 CMOS ロジック IC を使ったキーヤーの製作(JI3CSH, 11-Aug-2020)（原典は「アクセプト区間を工夫した メモリー付きエレキー」(JA4DWQ, CQ ham radio 1981/9)）やDAIWA DK-200/DK-210のようなエレキーの存在を知ってしまうと、長短点メモリの有無を確認するだけでなく、どの時点からどの時点までの操作を長短点メモリの対象とするのかというのを調べてみる必要もありそうな気がします。56.7kg(23:15)

TAM-KEYER102が\10kちょっとで出ていたので買ってしまいました。今は後継機種のTAM-KEYER203が出ていますが、エレキーとしてのリファレンスとしては旧機種でも十分役立つだろうということで。パドルを繋いで叩いてみた感じだと、Iambic-B(Accu-keyer)な動作ということで良さそうな気がします、特段そのような動作をするとは商品紹介ページに書かれていませんけど。

Iambic-A/Bの動作の違いについてはA1 CLUBの説明よりも、Gensparkに尋ねた結果：Iambic-A(Curtis)は短点メモリは確実に装備しているという説を信じます。これは、BAMA archiveにあるCurtis 8043のマニュアル(INSTRUCTION MANUAL FOR 8043-3, 8043-4, 8044-3, 8044-4 KEYER KITS)の

Dot memory

The self-completing function of electronic keyers can cause dots to get lost because the operator tends to lead the keyer. Since dashes are naturally held, the seldom get lost. To prevent lost dots, the 8043 employs a memory to remember when a dot is called for and to insert it at the proper time. The dot memory also helps om squeeze keying where a tap on the dot paddle will insert a dot into a series of dashes.

Dash memory

Similar to dot memory except that a dash is memorized. (8044 only)

という記述が根拠になります。単にパドルの操作に慣れていないだけだ、という指摘はありそうですが…MX-K2をいじっていた時はIambic-Bだと氷の上を滑るような感覚とでも書けば良いのでしょうか、要らぬdot/dashが出がちという印象を受けます。おそらく修練を積めば回避できる問題であり、実際多くの方々はうまく克服しているのだろうと思いますが。

Iambic-AかBかについては、調べれば調べるほどIambic-Bを選ぶのが現実解と考えてしまいます。Iambic-Bの動作（左右のパドルを同時押しした状態から手を離した際に、長点であれば短点、短点であれば長点が付加される）についてはThe K4ICY Minty Keyerの"MODE A or B? Basic?"の少し手前にある

Now there are other modes which benefit from inter-character dot/dash memory, including (true) "Curtis A" and "Curtis B" modes. "Curtis B," which is incorrectly named and should actually be credited to WB4VVF’s “Accu-Keyer,” an element is always added to the end of your string of iambic elements that is opposite of the element you release both paddle in, such as "dih-dah-dit," or "dah-dih-dah." This action was actually caused by an error in the logic design which happened to stick! Most proficient CW hams and telegraphers prefer the Accu-Keyer mode (Mode B) as the circuit became a popular must-have item at the time when the majority of them were getting into the hobby. (please visit: http://wb9kzy.com/modeab.pdf for a more concise description. Also read the 2015 article; All About Squeeze-Keying by By Karl Fischer, DJ5IL: http://cq-cq.eu/DJ5IL_rt007.pdf at http://cq-cq.eu/root.htm )

によればロジック上の問題だそうで、さらに

• 当時Accu-Keyerは爆発的に流行した（のでデファクトスタンダードに近い扱いになっていた…Curtisが"mode B"として実装するくらい）
• Curtis 8043/8044と異なりAccu-Keyerの回路図やタイミングチャートは記事として公開されていた

ということを考えると、ソフトウェアで再現した際の完成度はIambic-AよりもIambic-Bの方が高いと考えます。この前Arduinoに移植したYACKもIambic-Aでは長短点メモリが無効化されていますし（これはIambic-AではなくBasic Iambicと呼ばれるものではないでしょうか）、Please Fix Iambic A Keying Modeなんて話が出るとなると、実際のCurtis 8043/8044を手に入れていじり倒すなり内部に関する情報をどうにかして出してもらうようにするといったアクションをしない限り、Iambic-Aの再現性がイマイチな状況は変わらないのではないかと。

YACKやK3NG Keyer等のように設定をあれこれ変えられるエレキーを使うならともかく、TAM-KEYERのように設定を変えられないようなものでどうにかしないといけない場合で取れる対策があるとしたら、（本質的な解決方法ではないのですが）シングルレバーパドルの使用になるのでしょうか。ダブルレバーパドルよりも選択肢の幅は狭く、入手性もあまり良くないとはいえ…GHD GN205Sの説明にある「ダブルレバーのパドルでミス符号が出やすい方にもお薦め」の文言は気になりますし。56.9kg(24:10)

結論を先に書いてしまいますけど、USB電源に対応させるならケースも変えないとダメだと思っています。

色々試行錯誤した末に分かったこととしては（と書くと格好良く見えますが、行き当たりばったりでやった結果滅茶苦茶なことになってしまい、途方に暮れているというのが実情です）

• メモリ再生だけでなくモード設定でも必要とするため、F1/F2のスイッチを外してはいけない
• USB-Cコネクタは意外と大きいため、ブザーを取り払ってもKEY/OUTのジャックの間には収まらない
• ブザーの+側は電源に直結、-側をPICで制御しているので音声出力を取り出して外部の機器と連携させたいなら一工夫が必要かも（スピーカ等を内蔵させるならそこまで心配はいらないと思う）
• USB-Cコネクタ越しに+5Vを供給しても動作はする

要するに、押しボタンスイッチ全部とジャック一つを取り払ってもケースには収まらなかったようわああああん（泣）、ということです。ジャックは予備がありますし、スイッチもPCケースのリフォームを行った際の残りがあったはずなので、欠いた部品を補って適当な箱に納め直せばゴミを作る事態は避けられそうですが…工人舎MLのCMOSバッテリ交換も含め、色々と根を詰めすぎたせいか腰を痛めてしまい今は何もやりたくありません。

とはいえ、パドルだけあってエレキーが無いのも困ります。手元にArduino UNOだのLGT8F328Pだのが載ったボードがいくつか転がっているので、これで代替するのも一案かもしれません。K3NG Arduino CW Keyerが定番ではあるものの、LGT8Fxで使うには修正が必要ですし、機能をフルに使いたいならArduino Megaが必要、おまけに機能山盛りで設定も大変そうだとなると他に適当な物は無いのかと探したくなります。

で、Basic Yack Iambic Keyer KITからYACK(Yet Another CW Keyer)なるものを知ったのですが、これはATtiny45用…ソースコードを見るに、多少手を入れればArduino上で動かせそうだということで動かせるようにしてみました。基本的な部分はいじらないようにしているとはいえ、

• Arduinoの流儀に合わせてファイル名を変更
• main()は、setup()とloop()に分割
• 信号線の制御は、DDRB/PINB/POUTBレジスタの操作→pinMode()/digitalRead()/digitalWrite()に置き換え
• サイドトーンはTimer0レジスタの操作→tone()/noTone()に置き換え、周波数はctcvalue±1→±10Hz単位の設定に変更
• 5msタイマは、Timer1レジスタの操作をdelay()に置き換え
• POWERSAVEは非対応とするが、代わりにyield()を実装しCPUのSLEEP命令をdelay()中で使用できるようにする

程度のことはしています。気を付けないといけないのは、Arduinoへコードを移植する際はmain()のままでもビルドが通ってしまうという点です。ArduinoCore-avr/cores/arduino/main.cppを見れば分かるように、これのmain()からwiring.cのinit()を呼び出すので、アプリケーション側ではmain()を使わずにsetup()/loop()を使う必要があります。

EEPROM操作部分は<avr/eeprom.h>に依存してしまっているため、Arduino UNO R4でも動かせるようにするならArduino標準の<EEPROM.h>への移行は必須です。既に移行作業を始めており、近いうちに移るつもりです。57.0kg(22:10)