大陸の覇者ネタで誤魔化します。とはいえ、★5を引くなんてことは無く…

★5

ギルデロイ(槍), ハンイット(弓), ニコラ(短剣), トレサ(槍), ドロテア(槍), ティキレン(剣), リュミス(斧), グロッサム(扇), ステッド(杖), サイラス(本), ヴァルカン(本), アデル(短剣), イデア(剣), リトゥ(短剣), ムールゥ(本), ガートルード(斧), プロメ(杖), オデット(本), プリムロゼ(扇), ユーニィ(弓), コウレン(剣)

手元にいないキャラは増えるだけ。

ナンナ(★3剣)、フェリーネ(★3短剣)、ピア(★4槍)はLvがカンストしました。バラッド(★4槍)とシェルビー(★4斧)もあと2Lv上げればおしまいです。

★3キャラはLv50程度で育成を止めていましたが、八つ子くらいは上限(Lv60)まで育てても良いだろうということで、最近はそちらを進めています。とはいえ、討伐に出すと銅導石よりも経験点が入りすぎてしまい無駄になっているような…

そういえば02-Jul-2021の変更申請（増設）、27-Jul-2021に完了通知が来ました。

SARS-CoV-2感染者がうなぎ上りというこの状況に都心へ行くとは何事か…というお叱りを受けそうなのであまり書きたくはなかったのですが（もうしばらく時間を置いてから書くつもりだった）、JARD測定器室でRetevis RT85および5個のeByte E28-2G4M12Sのスプリアス測定を行ってきました。すべて問題無いとの結果が出ていますので、これで免許申請へ進むことができそうです。53.90kg(21:35)

結局MBRへ戻してもあまり意味が無かったので、元のGPTへ戻そうとしてみたものの…前回保存しておいたGPTを書き戻して、Windowsのブートローダを修復してもC:\Windows\system32\winload.efiが見つからない問題を解決できず、結局MBRのままになりました。

単にGPTを書き戻すだけではダメで、diskpartでドライブレターの割り当てを直す手順が必要なのは分かったのですが、bootrecやbcdbootの操作で何か不足があるのだろうと考えています（bootrec /fixmbrは流石に不要だと思うので実行していませんが…）。あと、Windows回復用USBメディアはBIOSではなくUEFI bootが必要なように思われます。

Windows11が出てから1〜2年くらいした頃にマシンを組み換えようかと考えているので、とりあえずこのままの状態で引っ張る予定です。

JARD測定器室へ色々持っていこうとする直前に、仮想マシンやら申請用の書類やらを書くために使っているWindows10を下手すりゃ起動できなくするような実験をやっていますが、むしろこの時期に格安スペアナが壊れてしまったのが一番痛いです。偽物と思われるCH340Gが死んだのかなという気がするのですが、それ以外の部分が壊れている可能性もありそうで、どうしたものかと頭を抱えています。

LoRaモジュールのテストプログラム自体は出来上がっているので問題は無いと分かっていても、持ち込む直前に最終確認くらいはしたいのにそれができないのはちょっと不安です。ランダムデータの連続送信については（改造元となる）SX128x_Transmit_Interrupt.inoに対応するSX128x_Receive(_Interrupt).inoで受信できれば問題ないとして、シングルキャリアの送信を確認するのは…かつて携帯電話で使われていた光るアンテナのような道具があれば良いのかもしれませんが、調達する時間は無さそうです。

ぶっつけでやるしかありませんかね…53.15kg(20:55)

Windows11動くといいよねーということでWindows10マシンのMBRなSSDをMBR2GPTでGPT化し、UEFI boot対応にしてはみたのですが…TPM2.0モジュールを発注してもお店側でキャンセルされちゃったし、VMware Playerの問題はUEFI/GPT環境で起こるようだ（BIOSでは起こっていない）という情報もあり、MBRへ戻すことを試してみます。

MBR→GPTについてはMBR2GPTに限らず色々なユーティリティが無償で出ているようですが、その逆であるGPT→MBRについてはお金を払わないとどうにもならないようで、一回程度しか行わない操作で\5000近いお金を払う気には到底なれません。

なので、GParted -- Live CD/USB/PXE/HDで足掻くことにします。ここでは自分のマシンのSSDで試した結果を記しているので、細かい部分については適宜自分のマシンに合わせて読み替えてください。当然ですが、自己責任…同じ操作を行ってディスクの中身を吹っ飛ばしても誰も助けてくれませんのでそのへんは御覚悟を。

1. GPartd Live (Default)で起動して、情報収集。gdiskで表示される総セクタ数、各区画の先頭/末端セクタの番号、区画種別を記録。
2. dd if=/dev/sda bs=512 count=16 skip=<各区画の先頭セクタの番号> | hexdump -C | lessとでもして、各区画の先頭セクタの番号とそれに対応する内容が一致していることを確認。
3. MBRの内容を保存: dd if=/dev/sda of=mbr.bin bs=512 count=1
4. GPT第1ヘッダ側を保存: dd if=/dev/sda of=gpt1.bin bs=512 skip=1 count=33
5. GPT第2ヘッダ側を保存: dd if=/dev/sda of=gpt2.bin bs=512 skip=<総セクタ数-33> count=33
6. GPT削除用データの準備: dd if=/dev/zero of=zero.bin bs=512 count=33
7. GPT第1ヘッダを削除: dd if=zero.bin of=/dev/sda bs=512 seek=1
8. GPT第2ヘッダを削除: dd if=zero.bin of=/dev/sda bs=512 seek=<総セクタ数-33>
9. fdiskでMBRのWindows区画・回復区画を設定
10. Windows回復ディスクを使用し、ブートセクタの修復手順でWindows10を起動可能にする（とっても面倒）

GPT→MBRの挿げ替えよりも、むしろWindows10を起動可能にする作業の方が面倒です。bootrec /fixbootでアクセスが拒否されてしまったので、これはbootsect /nt60 sys（参考：ブートセクタを修復する）で対処しましたが…

自分用の覚え書き：GPT時の区画情報はこんな感じでした ----

• 総セクタ数: 937703088
• Microsoft予約区画: 2048(0x00000800)〜1126399(0x00112fff)
• Windows区画: 1126400(0x00113000)〜935870963(0x37c841f3)
• EFI区画: 935872512(0x37c84800)〜936077311(0x37cb67ff)
• 回復区画: 936077312(0x37cb6800)〜937697279(0x37e41fff)

---- ここまで覚え書き

結局、MBRに戻してVMware Playerを動かしても状況が変わらないので（いきなり初っ端からハングアップを起こしました）、今までの苦労は一体なんだったんだ💢と途方に暮れています。とはいえ、これはこれでBIOS/UEFIで動作が変わらないということで一安心だったりします…仮にマイクロコードのパッチがどちらかでしか当たらないなんてことがある方が、より厄介ですし。

MBR2GPTにより勝手にWindows区画を削られ余計な区画を作られたおかげでSSDの内容がぐちゃぐちゃになってきたのと、手間よりもむしろ神経を使うことを考えると、今後は素直にお金を払って区画管理ツールのお世話になった方が良さそうな感じです。とりあえず…またGPTへ戻しちゃおうかなあ。

むしろ本来の目的であるVMware Playerが安心して使えないのは本当に困るので、仮想マシンプラットフォームを有効にしてどうなるか（VMwareではなくWindowsのハイパーバイザを使うようになるなら、状況が変わるのではないか？と考えて）様子を見てみることにします。52.65kg(07:35)

Arch Linuxがpacman -S arduinoでインストールできるのと同様に、Void Linuxではxbps-install arduinoでインストール可能です。しかし、ツール類はパッケージの提供するavr-gcc, avrdudeを使うため、/usr/lib/arduino/hardware/arduino/avr/platform.txtには手が入っています。compiler.path={runtime.avr-gcc.path}/bin/がcompiler.path=/usr/bin/に変わっているのは確認しましたが、それ以外の変更についてはvoid-packages/srcpkgs/arduino/templateを見るのが早そうです。なんかmuslではなくglibcを使った方が良いようなことが書かれているのが気になりますが…

これはlgt8fxを使う際においても同様で、platform.txtのcompiler.pathを修正しないとまともにコンパイルができないので注意が必要です。一応、issueに書いておきましたが…avr-gccの話のみ書いているため、avrdudeについてそのうち追記しないといけないかもしれません。

なお、Void Linuxのavr-gccは9.3.0であり、現時点におけるArduino IDE(1.8.15)に含まれているavr-gcc-7.3.0とバージョンが異なっている点についても注意してください。Arch Linuxについてもarduino-avr-core 1.8.3-1(any)パッケージの内容を見るに、avr-gccパッケージの提供するavr-gcc(11.1.0), avrdudeを使用するよう、platform.txtに手が入っています。52.80kg(06:25)

24-Jul-2021補足：Arch Linuxのarduino-core-avr 1.8.3-1(any)パッケージを見ると、修正前のplatform.txtがplatform.txt.origという形で格納されています。diffを取ってみるに、compiler.path=/usr/bin以外にもtools.avrdude.path=/となっています。

Void Linuxのarduinoパッケージではtools.avrdude.path=/usrとなっているだけでなく、tools.avrdude.config.path=/etc/avrdude.confとなっているため、これらをlgt8fxに適応する必要があります。

27-Jun-2021の続き。releases/R2021071101が出たのでこれをVoid Linux上でビルド→書き込みしてみます。とりあえず08-Jul-2021程度の準備に加え、xbps-install python3-usb python3-urllib3を済ませておいてください。前回と比べ、大きく手順は変わりません。

ソースコードの入手

sources_and_tools/{OpenGD77_FirmwareLoaders.zip,OpenGD77_buildtools.zip,OpenGD77_sources.zip}を取得。

必要なファイル類の展開とビルド用ディレクトリの作成

unzip -x /path/to/OpenGD77_FirmwareLoaders.zip gd-77_firmware_loader.py; unzip -x /path/to/OpenGD77_buildtools.zip; unzip -x /path/to/OpenGD77_sources.zip; cd OpenGD77/firmware; mkdir build

codec_cleanerの修正（スクリプトは改行コードの問題により動かない問題がまた発生しているため、バイナリを直接呼ぶようにする）

mv tools/codec_cleaner tools/codec_cleaner.old; ln -s codec_cleaner.Linux tools/codec_cleaner

ダミーのcodecバイナリ作成(codec_bin_section_1.bin=15360byte, codec_bin_section_2.bin=163984byte)

tools/codec_cleaner -C; mv codec_bin_section_?.bin linkerdata/

ビルド（VERBOSE, RADIO, -jオプションはお好みで、この例ではBaofeng DM-1801向けとする）

cd build; make -f ../Makefile -j5 RADIO=DM1801 VERBOSE=1

blob抽出用ファームウェアの所在を記述（gd-77_firmware_loader.pyを実行するユーザのホームディレクトリに作成すること）

printf "[GLOBAL]\nSourceFirmware=GD-77_V4.3.6.sgl\n" > ~/.gd77firmwareloader.ini

書き込み（GD-77_V4.3.6.sglはカレントディレクトリに置く）

python3 gd-77_firmware_loader.py -m DM-1801 -f /path/to/OpenDM1801.bin

Makefileの修正が不要になったのはありがたいですね。codec_cleanerの文字コード問題が再発生しているのがアレですが。

Windows10上のVMware PlayerとAthlon X4 845の相性が悪いのArch Linuxの仮想マシンが何故かWindows10をリブートさせる現象がその後幾度か見られたので（A10-7850K/A4-5300での不具合報告もあります）、Voidへの移行を決めました。Arch上でも同じビルド/書き込み手順が使えると思われますので、お好みのdistroを使ってください（どっちも良いものだと思います）。

あとはlgt8fxを組み込んだArduino IDEを動かせるようにしないと…古いQEMUは捨てて、素直にcommand ring周りの動作を見た方が良さそうだし…53.90kg(15:30)

qemu-1.0.1とqemu-0.15.1のビルドをちょっと試したくなったので、メモ。

年代物のプログラムになるので、イマドキの環境でビルドするのではなく…Slackware-13.37で。この辺りの時代になると対応するTLSが古いので、HTTPSを使ったサイトから（仮想マシン上に直接）何かをダウンロードするという操作が全滅するので注意が必要です。

予めcelt-0.5.1.3→spice-protocol-0.6.3→spice-0.6.3の順にインストール。PKG_CONFIGのパスはexport PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/share/pkgconfigとして追加しておく必要あり。spiceは0.6.3より前は使用不可。

qemu-1.0.1は./configure --enable-spice --enable-trace-backend=stderr --prefix=/path/to/installで良いのですが、qemu-0.15.1はCFLAGS="-O0 -g" ./configure --enable-spice --enable-trace-backend=stderr --extra-cflags=-I. --prefix=/path/to/installとしないとcompile error in QEMU 0.15.0-rc0 and 0.15.0-rc1という問題を踏んでビルドができないのと、動作しないバイナリが生成されてしまうので最適化を無効化する必要があります。

qemuを起動する際の注意点として、-vga qxl（もしくは-device qxl-vga）では起動できないため、-device qxlを使用する必要があります。ただし、secondary displayとなってしまうようです。0.15.1においては、-device qxl,ram_size=16777216,vram_size=16777216として、RAM/VRAM領域の両方のサイズを記述しないとVRAM/ROM領域がマップされません。

テスト用のコードを動かす舞台は整いましたが、肝心のコードをどう書くかというアイデアがまとまりません…どうしましょう。大陸の覇者の授けし者編/名声第1章も見事に負けましたし（あんな固い相手にどう戦えと…）。54.55kg(12:35)

12-Jul-2021補足：--enable-trace-backend=stderrを追加しました。デフォルトではnopなので、トレースが取れません。

Arch Linuxのカーネルがlinux 5.12.15.arch1-1にアップデートされた影響かどうかは分かりませんが、VMware PlayerがCLOCK_WATCHDOG_TIMEOUT (101)によりハングアップする問題は今のところ発生していません。とはいえ、GitHubにあるArch Linuxのカーネルソースを見ても何をどういじったのかがよく分からないので、何かの拍子に症状が再発する可能性も否定はできません。Windows側も何かアップデートが入っているようですし。

仮想マシン上で動作するLinuxにまつわるトラブルのおかげで2.4GHzのLoRaモジュールの動作テスト用スケッチの作成が滞っていましたが、どうにか終わりました。JARD測定機室からのメールによると、ITU-T O.150に従いPN9符号を送信するようにということなのでそのように修正しました。ありがたいことに、既に生成されたPN9符号のバイナリがメールで送られてきたのでこれを組み込むだけで済んだのですが…どうやって符号を生成するか気になったので、WikipediaのLFSRの説明を見ながらこんなコードを書いてみました（送られてきたバイナリと同一の結果が生成できることを確認しています）。

The LLVM+SDCC toolchainに書かれた方法を試してみたのですが、どうもソースコードが古いのか構築手順を間違えたのか、Arch Linux上でのビルドがうまくいきません。LLVM 3.8はCMakeの書法が古いのとllvm-configが見つからない（インストールしてあるのに何故…）と言われ、llvm-cbeは大量のコンパイルエラーに見舞われました。Debian等、あまり最新を追わないdistroで試す方が良いのでしょうか…？

フェンリル/イノセントシリーズを用意してからにしますと書いてしまっていますが、道中の宝箱から拾ったものについては使っているものの、多くはメテオライトシリーズのまま授けし者編第1章…富/権力を終わらせました。Lv70後半くらいあれば多少危ない場面があっても何とかなる感じではあります。残るは名声。53.80kg(22:00)

04-Jul-2021の問題（VMware PlayerがCLOCK_WATCHDOG_TIMEOUT (101)によりハングアップする）、どうもVMware Player上でArch Linuxを動かしているとよく起こるような印象があります。もともとOpenGD77をビルドするため、arm-none-eabi-gccの8.x以降のものとlibc_nano.aを持っているからという理由で選んだdistroなので、必ずしもArchでなければいけないという訳ではありません。

という訳で、Repologyで見つけたvoid linux(glibc)をインストールしてみました。xbps-install -S base-devel cross-arm-none-eabiとでもすると、arm-none-eabi-gcc-9.3.0とlibc_nano.aがインストールされるので、これで試したところArch Linux上と同様にOpenDM1801.binを得られています。Python3もパッケージがあるようなので、おそらく無線機への書き込みも可能と思われます（そのうち試します）。

大陸の覇者、最近はログインボーナスもらって寝るのではなく簡易討伐でちまちま経験値稼ぎをやっています。銀導石の欠片はどうにか30000個貯めたので、クラスアップアイテムを得てリネットを★4→★5に上げています。あとはテレーズか…

ブリジットもやって来たので居ないのは★5のみ。

★5

ギルデロイ(槍), ハンイット(弓), ニコラ(短剣), トレサ(槍), ドロテア(槍), ティキレン(剣), リュミス(斧), グロッサム(扇), ステッド(杖), サイラス(本), ヴァルカン(本), アデル(短剣), イデア(剣), リトゥ(短剣), ムールゥ(本), ガートルード(斧), プロメ(杖), オデット(本)

妻も大陸の覇者をやっていることが最近発覚したので見せてもらったのですが、ギルデロイ・ドロテア・オデットと…自分の持っていないキャラクタを色々持っていて羨ましいです（逆にヒースコート欲しいと言われました）。

そろそろ授けし者編第1章を片付けましょうかね、と言いたいところですが…武器/防具が未だに極めし者編で使っていたメテオライトシリーズなので、フェンリル/イノセントシリーズを用意してからにします。53.55kg(21:35)

Athlon X4 845なWindows10マシンで動くVMware Playerに、4コアのCPUと12GBのRAMと8GBのswapを与えたRaspberry Pi Desktopで6時間放置して、どうにか。単にビルドするだけでこれなので、開発するならそれこそRyzen ThreadripperとかXeonの載った、CPUコアもメモリもディスクもとにかく盛り盛りなマシンを持ってこないとやってられないんじゃないかなあ。

なお、Raspberry Pi Desktopを使ったのは04-Jul-2021の問題が（今のところ）起きていないという理由によります。

• apt-get install cmake lld
• git clone https://github.com/jacobly0/llvm-project
• cd llvm-project; git checkout z80
• mkdir build; cd build
• cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_LLD=ON -DLLVM_TARGETS_TO_BUILD="" -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=Z80 -DCMAKE_INSTALL_PREFIX=/home/pi/llvm-z80/ ../llvm
• make; make install

ポイントとしては、clangしか現時点では構築できない（libcはエラーが出る）、リリースビルドとする、lldを使う、Z80は現時点ではEXPERIMENTAL扱い、単に試すだけならZ80以外のターゲットは無効化する…といったところでしょうか。

折角なので何か適当なものをビルドしてみます。13-Sep-2020で使ったCRC32生成ルーチンに少し手を入れて、llvm-z80/bin/clang crc32.c -target z80 -S -o crc32.sでビルドしたものを置いておきます。llvm-asがZ80に対応していないのか、Z80対応を抜いてビルドしてしまったのかは分かりませんが、バイナリのオブジェクトを得ることはできていません。得られたアセンブラのソースを何に食わせれば良いのかも分かりません…(binutils-z80?)

なお、現時点では-Oによる最適化は「バグレポートを送ってください」というメッセージとともにクラッシュします。

どうしてもLLVMでZ80を使いたいよ、というのであれば（どの程度使い物になるかが分からないのですが）The LLVM+SDCC toolchainにある手法を使う方が良さそうに見えます。clangで得られたLLVM IRをCに戻し、これをSDCCに処理させるという方法らしいのですが、ちょっと理解が追いつかないので何かの折に試してみます。53.80kg(21:00)

Windows10マシン、ここしばらく突然再起動したりハングアップしたり妙な挙動をすることが多くて困っています。Windows11が出ると言われたこの時期にマシン買い替えなんて本当に勘弁して欲しいと思っていたのですが（Windows11が出ているなら仕方なく買い換えます）、どうも調べているとハードウェアというよりはソフトウェアの問題という可能性が高そうです。

イベントビューアーでシステムのイベントに「このコンピューターはバグチェック後、再起動されました。バグチェック: 0x00000101 (0x0000000000000030, 0x0000000000000000, 0xffffcd80326c1180, 0x0000000000000001)。ダンプの保存先: C:\WINDOWS\MEMORY.DMP。」という記録があり、またダンプファイルをWinDbgで見たところ「CLOCK_WATCHDOG_TIMEOUT (101)」「PROCESS_NAME: vmware-vmx.exe」とあることから…そういえばVMwareを動かすとトラブルが多かったような？と。

googleで調べてみると、全く同じではないのですが「AMD APU(A10-7850K、A4-5300)にてvmwareを実行していると、ホストOSにBSOD CLOCK_WATCHDOG_TIMEOUT(101)が発生します」という、類似した問題が存在していることが分かりました。BIOS(AGESA)のバージョンにより問題の有無が変わるので、おそらくCPUのerrataを踏んでいたとしてもworkaroundで対処可能なものが原因ではないかと推測しています。

Watch Dog Timerが動いてしまうようなCPUのハングアップを起こしそうなerrataというと、Revision Guide for AMD Family 16h Models 00h-0Fh Processorsにある「793 Specific Combination of Writes to Write Combined Memory Types and Locked Instructions May Cause Core Hang」辺りではないかと思うので、何かの折にMSR 0xc0011020のbit15が0かどうかを（1ならworkaroundが適用されている）確かめてみたいのですが…マルチプロセッサなので全てのCPUが正しく設定されていることをどうやって確かめるのかということ、BIOS/UEFIで挙動が違うならそれぞれについて調べないといけないことを考えると、頭が痛いです。

とはいえ、workaroundが未適用だったとしてもこれをWindows10動作中に適用する術がないような気がするので、分かったところで余計にストレスが溜まるだけなのですが。

…と、こういう問題で一日が潰れました。まったくもう💢53.85kg(21:40)

05-Jul-2021補足：読むべき資料が間違っていました。Family 16hはJaguar/Pumaの話で、Bulldozer系コアはFamily 15hになります。KaveriはRevision Guide for AMD Family 15h Models 30h-3Fh Processors、Stoney ridgeはRevision Guide for AMD Family 15h Models 70h-7Fh Processorsで、Athlon X4 845はBristol ridgeと同じmodel 60hなのでこれに対応する資料が必要になるのですが…BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 15h Models 60h-6Fh Processorsくらいしか見当たりません。

BKDGは見ていないのですが、Revision Guideを見るにFamily 16h/17hのようなLOCKにまつわるハングアップに関する記述は見当たらないので、他の問題なのかもしれません。とりあえず、A88M-G/3.1のBIOS更新は無いので、VMwareを動かす際は警戒するくらいしか対処しようがなさそうです。

18-Feb-2021の続き。DMR→YSF/D-STAR変換後の解釈が曖昧な気がする(※)ので、自衛のために書類上はYSF/D-STAR機を持っていることにしておくことにします。こういうことを書くとこれはこれで色々ケチが付いたりするものですが、無免許な状態よりかははるかにマシということで（とはいえ許可されている電波型式は変わらないのですが）。

(※)リフレクタ/HotSpot経由の運用はアマチュア無線と公衆網との接続のための指針ではゲストオペ扱いという解釈。「自分の資格の範囲内かつ訪問先のアマチュア局の免許の範囲内」という制約であれば、従事者資格の範囲内における電波型式の変換は問題ないはず…とはいえ、「ようだ」とか「はず」で違法行為をする訳にはいきませんし。

ということで第6/第7送信機を増設するための変更申請を出しました。忘れる前にメモ。

移動しない局（変わっていない）：電信級アマチュア無線技士の従事者免許と紐付け

第1送信機 (ICOM IC-7200M)

技術基準適合証明番号 002KN528

第2送信機 (JumboSPOT)

430MHz F1D(2FSK)/F7W(GMSK)/F7W(4FSK) ADF7021×1@3.3V 定格出力0.02W

送信空中線の形式

単一(TI)/ダイポール(DP)/平面(PL)

移動する局：電話級アマチュア無線技士の従事者免許と紐付け

第1送信機 (TYT MD-380)

430MHz F2D,F3E(数値演算型周波数変調)/F7W(数値演算型四値周波数偏移変調) RD07MUS2B×1@7.4V 定格出力5W

第2送信機 (Retevis RT80)

430MHz F2D,F3E(数値演算型周波数変調)/F7W(数値演算型四値周波数偏移変調) RD02LUS2×1@7.4V 定格出力5W

第3送信機 (Radioddity GD-73A)

430MHz F3E(FM,数値演算型周波数変調)/F7W(4FSK) RFM04U6P×1@3.7V 定格出力2W

第4送信機 (Baofeng DM-1801)

144MHz F2D,F3E(FM,数値演算型周波数変調)/F7W(4FSK) HTL7G06S006P×1@7.4V 定格出力5W
430MHz F2D,F3E(FM,数値演算型周波数変調)/F7W(4FSK) HTL7G06S006P×1@7.4V 定格出力5W

第5送信機 (Dragino LoRa Shieldっぽい何か/HopeRF RFM98W)

430MHz F1D(SS) RF98×1@3.3V 定格出力0.1W

第6送信機 (ICOM ID-51)

技術基準適合証明番号 002KN623

第7送信機 (YAESU FT-70D)

技術基準適合証明番号 002-160015

送信空中線の形式

(移動する局につき、記載を省略している)

今後、これに2.4GHzのLoRaモジュールとRetevis RT85が載る予定です。53.70kg(05:35)

31-Jul-2021補足：XLX499(JP1AWP)のAbout XLX499では、「各モジュールご利用の際は、それぞれに見合った電波形式の送信機免許をお受け下さる様お願い致します。BlueDV などでインターネット経由の”非”無線接続をされても、ネットワーク上のどこかで無線接続されていると、リフレクターというリモート装置を通じて電波を出したという解釈になりますのでご注意ください。」という記述があります。

これ、おそらくはアマチュア無線と公衆網との接続のための指針の、インターネットに接続する場合/接続例1の項にある、「Ｃ（無線従事者）は、Ｂ局のゲストオペレーターと同じように、Ｂ局の運用設備を操作できる資格を有していること。」の解釈の問題と思われます。原文では「操作できる資格」および「ゲストオペレーター」とあるため、自分は従事者資格の有無を問われていると解釈しています…仮にＢ局の運用を行うための無線局免許を要求するのであれば「運用できる免許」辺りの文言になるのでしょうが、そうしてしまうとゲストオペレーターの要件と整合しません。

誰の解釈が正しいか/間違っているかという、勝ち負けの話ではありません。このように複数の解釈が生じてしまい、それにより正しい運用形態であっても「それは違法ではないか」等のケチを付けられて運用に支障が出てしまう状況と、それに怯えなければいけないことを問題にしています（それを回避するために書面上のhackをしたというのが日記の意図です）。

おそらく将来の拡張等を見越して法を意図的に空白にしている箇所があるのかもしれませんが、実行しても問題ないことに対しては問題ない旨をきちんと明文化しておかないと、こういう厄介は減りません。とにかく、現状の「解釈により足を引っ張られるかもしれない事象に対する予防的な申請」で時間と手間を取られるのは、本当に勘弁してほしいです。