2021年2月のてきとーな日記

［RT85を分解］

ハンディ機をあまり増やさないようにしようと思っていたのですが、安かったのと、AT1846S/RDA1846とは違う石が載っているという噂（Youtubeのコメント）を聞いたのでそれを確かめる理由でRetevis RT85を買いました。

お値段の割に質感は良い感じです。しかし今まで分解してきた機種と違い、分解した事がバレちゃうシールを付けてくるようになりました。遠慮なくひっぺがして開けますけど。

TYT TH-UV88のラベル替えではないか…とこれも同じYoutubeのコメントにありましたが、基板のシルクにAUV88VK VER 1.3とあるのでその可能性は高そうです。むしろCPSを覗くとTH-UV88の文字列がそのままあったりするので、可能性が高そうどころかそのものかもしれません。

分解手順は、

ボリュームのツマミ・アンテナ・バッテリーを外す
本体下部のネジ2本を外す
アンテナを留めているリングを外す（ここまででケースから外せる）
金属シャーシと基板を留めているネジを5つ外す（5つ目はLCDの裏に隠れているので注意）
ボリュームを留めているリングを外す
ハンダごてを使用しアンテナ端子を外す

という二度とやりたくない、手間のかかるものです。5つ目のネジは本当に罠としか言えません…LCD自体はプラスチックの爪で基板に留まっているので軽く力を入れれば外せますが、フレキシブルケーブルを痛めないよう注意が必要です。

ここから子細に見ていきます。例によって雑な写真ですが…

チップの型番が読めるよう、チップだけ拡大して撮ったものもあります。妙なアングルなのは、照明の都合と型番だけ読めれば良いという理由です。

ざっとまとめるとこうでしょうか。

制御用MCUの表面は削られており型番が分からない
噂どおりBEKEN BK4815Qが使われている
BK4815Q→2SC3356(R25)→HE3078(H3)→HTL7G06S006P(H0606E)、DM-1801と異なりHTL7G06S006P(H0606E)のみ144/430MHzに分かれている
小さい方のR25は2SC4226？何故か見つけたVV-898S service manualという名の回路図(PDF)を見ると送信でも受信でも使われるようなので、RT85では受信用と推測

RT80でもFMラジオは聞けますが、無線機/ラジオの切り替えが面倒なのと受信範囲が87.5MHz〜108.0MHzと狭いのが難点です。RT85では65.0MHz〜108.0MHzと広いものとなっており、切り替えも楽なので電波の出せるラジオとしては良いです。とはいえ、標準付属品のアンテナを付けた状態で比較するに、RT85の方が感度が少し弱いです。

この作りでこれだけ安いと（スプリアス面での評価がまだですが）RT85やTH-UV88はBaofeng UV-5Rのライバルになり得るんじゃないか…と思っていたらIs the TYT-TH-UV88 a Baofeng UV-5R Killer?(podcast)やTYT TH-UV88 versus Baofeng UV-5Rのように同じようなことを考える人が既にいるようで。

あと、細かいことをいくつか。

RT85に書き込まれていたファームウェアの更新は、How to update Retevis RT85 Firmwareを参考にhttps://www.ailunce.com/ResourceCenter/から最新版を落とします。書き込まれていたバージョンが1.33で、現時点の最新版が1.35…ファームウェア書き込みプログラムにはModel: 5W/10Wの選択がありますが、これは5Wを選びます。TYTの場合はTH-UV88(5W)/TH-UV98(10W)で選ぶようになっていたので、この辺りは適当に使い回しなのでしょう。

RT85をリセットしてから気付いたのですが、実はVFOが使えません（この表現は正しくないのですが、ここではそういうことにしておきます）。なので、基本的にはDMR機と同様にCPS経由で周波数を書き込んで使うことになります。VFOを使わなくても200chものメモリがあるので、20kHz毎に周波数を記憶させておけば実用上問題無いはずです。まだ試してはいませんがCHIRPが対応しているので、Excel等で作ったCSVを流し込めるでしょうし。

スプリアスを測定し保証認定取って変更申請（増設）を出すかどうかは、気が向いたら考えます。53.10kg(09:50)

［ちょっと必要があったので］

Arduino（wemos TTGO XIっぽいもの）に書き込まれたブートローダーのダンプが必要になったので、スケッチを作ってみました。動作がトロいのはArduino IDEのシリアルモニタで動作確認をした際になぜかシリアルモニタが止まるという理由によるものなので、他の適当な通信プログラムから使う場合は適宜delay()を取り払う方が良いと思います。

ATmega328Pっぽい石向けなので0x7000〜0x7fffの範囲を、こんな感じにIntel HEX形式でダンプします。多分この例だとlgt8fx8p/optiboot_lgt8f328p.hexを書き込んでいるんじゃないかなあ…53.20kg(18:20)

24-Feb-2022補足：折角なのでLGT8F328PではなくATmega328Pでも実行してみました。しかしArduinoのCPUのデーターを全部抜く（ダンプする）にも書かれているように、ATmega328Pではbootloaderを読み出せませんね…

［アマチュア無線における430MHz帯LoRa送信機に関するメモ］

RFM98W（430MHz帯向けLoRaモジュール）、どうにか免許されました。先にこの場を借りて、JL1NIE 友部様にお礼を申し上げます。あのソフトウェアが無ければにっちもさっちもいかなかったので…本当にありがとうございました。

変更申請を出す→不備が有り通知書を受け取る→修正して再度変更申請を出す、の繰り返しを何度もやっていたのでこれだけ時間がかかってしまったのですが、どういう部分で引っかかったかをここにメモしておきます。日記に以前記した内容と重複する部分もありますが、まとめとしてここにも書きます。

・通知書一回目 (通知年月日: 令和2年09月10日)

電波型式を500KD1D、通信方式（プロトコル）に関する資料は添付せずに申請書を提出。

電波型式の問題：500KD1Dで申請を出していたが、F1Dとするようにとの指示。また占有周波数帯域幅の許容値は30kHzゆえ、500kHzは許可できない。
通信方式の問題：LoRaWANについては秘匿性が有り許可できない。LoRa変調を使用したこれ以外の通信方式については、通信方式の詳細資料（通信可能な対象が限定されないこと、通信方式の公開状況）を提出すること。資料については日本語で作成すること。

・通知書二回目 (通知年月日: 令和2年11月06日)

通信方式については、RadioLibの解説を添付し、アプリケーションは今後作成予定として申請書を提出。

通信方式の問題：通信方式の仕様やアプリケーション等が未作成では審査できない。他の免許人が同じシステムで交信できるよう資料を公開してから申請を行うよう指示。なお、新たな通信方式を作る場合は申請者のみでは通信の相手方となる局がいない状態となるため、別の無線従事者が操作する無線局と同時に変更申請等を行うようにとの但し書き有り。

・通知書三回目 (通知年月日: 令和2年12月18日)

既に免許実績のあるLoRaKissTNCをRadioLib対応に書き直し、プロトコルの詳細およびGitHubのURL(https://github.com/jg1uaa/LoRaKissTNC/tree/jg1uaa)を記載して申請書を提出。

送信機系統図の問題(1)：送信機系統図では周波数の発射範囲が430〜440MHzとなっているのに対し、Arduinoスケッチでは周波数の発射範囲が438〜439MHzとなっているため、修正指示。※どっちをどう直せ、という指示は無い
送信機系統図の問題(2)：PCを接続せず、Arduino単体で自律動作させる場合はそれに対応するArduinoスケッチを用意し、どのような場合に自律動作するかを記載するよう指示。

・通知書四回目 (通知年月日: 令和3年01月14日)

送信機系統図から自律動作に関する記述を削除。スケッチおよび送信機系統図の発射可能な周波数の範囲を430〜440MHzとし、申請書を提出。

送信機系統図の問題：発射可能な周波数の範囲が430〜440MHzとなっているが、運用可能な周波数帯は438〜439MHzとなるためにそのように修正するよう指示。

なんというか、四回目の通知書は「なんじゃそりゃ？」というのが正直な感想です。13-Feb-2021と同じことを書きますが、FMのトランシーバーは430〜440MHzの送信が可能で送信機系統図もそのように書くのに、なぜLoRaについては438〜439MHzの範囲を強いるのか。これについては通知書内で説明が欲しかったですね。

申請に使用したTeXファイルはそのうちGitHubに上げておきます。あまり綺麗なTeXソースではないので、無いよりかはマシ程度にお考えください。53.80kg(16:00)

［無線局免許おぼえがき(2)］

14-Jun-2020の続き。やっとLoRaとDM-1801の変更申請（増設）が終わったので、メモ。

移動しない局、変わっていないけどメモなので。電信級アマチュア無線技士の従事者免許と紐付け。

第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
送信空中線の形式: (移動する局につき、記載を省略している)

移動する局は、もういくつか送信機を追加したいです。FPVドローン向け5.8GHz VTX、2.4GHz LoRa(SX1280)、安そうな中華V/UHFハンディ機（BF-T1の件があっても懲りない）、その辺りを考えています。52.35kg(06:55)

［メモ(2)］

なんとなく引いたガチャで★3のコルネリア(斧)がやってきたので、たまたま揃っていたクラスアップアイテムを使って即座に★4化。★3→★4にしてもパラメーターが上がっていないように見えますが、Lv1の時点では違いがないだけで、育っていくと変わるのでしょうか？という訳で残りはこんな感じ。

★5: ギルデロイ(槍), ソフィア(本), ハンイット(弓), ニコラ(短剣), トレサ(槍), ライオネル(剣), ドロテア(槍), ザンター(弓), ティキレン(剣)
★4: ケネス(本), エフレン(杖), レヴァン(本)

そろそろ★3な★4とか、★4な★5の一覧も作らないとダメかもしれません。それくらい人数が多くて管理が大変です。

♪

テスト用にRock Pi S (Rockchip RK3308)を発注しました。Cortex-A35が載っているので、Cortex-A53とどのような違いを見ることができるのか、楽しみです。ケースがあるにはあるのですが、（送料が）高いのでちょっと手が出せません。

direwolf、sio_open(SIO_REC | SIO_PLAY)で一つのハンドルに録再を割り当てるとどうもうまく動かすことができなくて、sio_open(SIO_REC)とsio_open(SIO_PLAY)の二つのハンドルを用意すると動くようになったのでその形で作ってみました。なぜ駄目なのかが分からずに違う方法を試すのはちょっとどうなのと思うのですが、動かせない状態で止まっている訳にもいきませんし。

少しは動くようになったとはいえ、AGW Terminalを使って自分自身に接続ししばらく放っておくとなぜかdirewolfが止まっているという謎の現象が発生しており、これを追いかける必要が生じています。発生頻度を見るに、なんか解決するのが厄介そうな感じです。

LoRaの申請、大体金曜日にお返事が来ることが多いのですがこの数週間は見ていません。本当はきちんとした形で何をどうしたかという記述を残す必要があるのですが、簡単に書くと「430MHz帯のLoRaでは438〜439MHz以外の使用を総合通信局は望んでいない」ようです。FMのトランシーバーは430〜440MHzの送信が可能ですし送信機系統図もそのように書くのですが、同じように書いてみたら突っ返された…というのがここ1〜2回のやり取りです。突っ返される→書き直して申請を出し直す、から次のお返事が来るまで大体一ヶ月はかかる、そんな感じです。いつになったら終わるのでしょうか。

なお、144MHz帯でもLoRaの運用ができたら面白そうかなと思っていたのですが、全電波形式の区分は145.65〜145.80MHzの15kHzしかなく、7.8kHzないし10.4kHzの帯域幅で一局出るだけで手一杯な状態…どう使うんだろう？という感じです。全国的に周波数をどこかに決めて、送信頻度の低いビーコンなりテレメトリなりを送るくらいしか思いつきません。53.45kg(19:45)

［メモ］

大陸の覇者、とりあえず居ないキャラクタが着実に増えています。

★5: ギルデロイ(槍), ソフィア(本), ハンイット(弓), ニコラ(短剣), トレサ(槍), ライオネル(剣), ドロテア(槍), ザンター(弓), ティキレン(剣)
★4: コルネリア(斧), ケネス(本), エフレン(杖), レヴァン(本)

最近はメンテ明けにとりあえず10連引ければいいかな、程度にルビーを貯めるようにしているつもりです。たまにガチャ引いて「あぁぁ…」となりますが。

とりあえずキャラクタが実装された当日にパーラ（★4ではなく★3）と、ハーレー（こっちは★5）を引いてます。リネットが★4なのと、そろそろLvの天井が近いという状況で（限界突破に必要な金導石や、★4→5のクラスアップアイテムを集めるのが★4キャラと比べてツラい）、一時的にリネットを他の誰かに変えた方が良いのかなと考えています。

とはいえ、ハーレーを入れると風属性持ちが増えすぎてしまう（既にスケアクロウとモルルッソが居る）し、ある程度の火力も欲しいしなあとなると…パーティー全体の見直しが必要そうです。★の数に関係なく全てのトラベラーが魅力的なので（限られた時間の中で長く遊びたいとなるとどうしても★の多い人を選んでしまうのですが）、メンバー選びも楽じゃないです。

♪

なんか色々手を広げすぎちゃったのか収拾がつかなくなってしまったので、書き出して整理してみるとしましょう。

OpenBSD: Allwinner H6におけるUARTの問題: dw-apb-uartに限りFIFO enalbeにしないとダメっぽいとパッチを投げてみたけど、Allwinner以外のSoC(Rockchip, Marvell)でのテストが要るとの返答あり。Cortex-A72系を試してみたいこともあり、RK3399辺りので何か買わないとダメだろうか？
OpenBSD: OrangePi One Plusにおけるネットワークの問題: EMACは見えていても、どうもX-Powers AXP805(PMIC)を操作してPHYへの電源供給を行わないといけない様子。AXP805対応についてはパッチ投げてみたけど…対応してもAXP805との通信がうまくいっていない。AXP805が操作できたとしても、ネットワークがちゃんと動くかどうかは分からない。
M17: 仕様書の日本語訳: ちょろっとやっただけ。肝心要の物理層とかデータリンク層とかがまだなので、そこを腰据えてやらないと…
OpenGD77: 特になし: ビルドの通し方は分かったし、ビルド時のwarningについては慌てて修正作らなくても良いかな…？LoRa機と一緒に出したDM-1801(BF-1801)の増設申請がまだ完了していない（最初に申請投げたのっていつだったっけ…？）ので動きようがないというのもある。
xlxd: IPv6対応の再々作成: IPv6化したxlxd、既に二度ほどpull-request投げてはいるのですが塩対応＋本家のアップデート追従でコミット内容も荒れてきちゃったな…ということで一旦取り下げてます。作り直して再度pull-requestを投げてみようかとは思うのですが、結構手間がかかるのでどうしようかなーと。
LGT8Fx: 支援: プロジェクトの主が忙しいようで、助けてくれってissue立てていたからどう支援できるかなと。テストとかレビューとかなんかできそうなことはある気がするけど…とりあえずTTGO XIっぽいものだけでなくWAVGATのArduino UNO R3っぽいのも手にしておきますかね。
LoRa: 2.4GHz: 430MHzのが未だに申請が終わっていないので、動けず。優先度は今のところ低め。とりあえずDIO0にRxDone/TxDone、DIO1にCadDetected割り込みを割り当てるように作れば良いはず？電波出ているかどうかの確認は、以前買った簡易スペアナ(LTDZ 35-4400M)でチェックすることになるか。LoRaモジュールからの出力を簡易スペアナが対応する入力レベルに適合させるためのアッテネーターも揃えないと。
direwolf: sndio対応: SIO_REC | SIO_PLAYによる全二重動作って一体どうやってやるの？なんかsio_read()で止まってしまうのだけど…から未だに先に進めていません。どうすればいいんだろう。

他にも色々あるのですが、手を出してしまうと…もっと収拾がつかなくなりそうですね。とりあえず一個一個確実に潰していくしかなさそうです。54.10kg(15:35)

［そろそろ(2)］

03-Sep-2019にOrange Pi One Plus向けのU-Bootの作成を記しましたが、ATF(ARM Trusted Firmware)とU-Bootだけでなく、SCP(System Control Processor) firmwareも組み込んでおかないと困る場面があるようです。という訳で、ATF/SCP入りU-Bootの作成手順を書きます。

Debian上でも良いのですが、今回はArch Linux上でやります。というのも、SCP firmware（Orange Pi One Plusでは、crustを使います）の構築に必要なor1kのtoolchainが揃っているという理由によります。crustの推奨はor1k-linux-musl-crossではあるんですけどね。

まずはpacman -S aarch64-linux-gnu-binutils aarch64-linux-gnu-gcc or1k-elf-binutils or1k-elf-gcc or1k-newlibで必要なtoolchainを揃えます。git, swig, bc, dtc等ビルドに必要な他のツールも入れておいてください。

crustのビルドは、git clone https://github.com/crust-firmware/crust; cd crust; make CROSS_COMPILE=or1k-elf-で。とはいえ、実際のビルドが始まるまでの間に以下の質問に答える必要があります。予めOrange Pi One Plusの回路図を手に入れておくと答えやすいでしょう。

Platform selection: 4. H6 (PLATFORM_H6)
CIR (infrared) receiver (CIR): n (default)
OSC24M clock source: 1. DCXO (OSC24M_SRC_DCXO) (default)
Poll the GPIO controller for EINT IRQs (DEPRECATED) (IRQ_POLL_EINT): n (default)
I2C controller pin selection: 2. PL0/PL1 (I2C_PINS_PL0_PL1) (default)
Multi-function driver for X-Powers PMICs (MFD_AXP20X): y
X-Powers PMIC variant: 2. AXP805 (MFD_AXP805) (default)
GPIO-controlled CPU power supply (REGULATOR_GPIO_CPU): n (default)
GPIO-controlled DRAM power supply (REGULATOR_GPIO_DRAM): n (default)
GPIO-controlled VDD-SYS power supply (REGULATOR_GPIO_VDD_SYS): n (default)
Silergy SY8106A voltage regulator (REGULATOR_SY8106A): n (default)
Serial input/output support (SERIAL): y (default)
Device: 1. UART0 (SERIAL_DEV_UART0) (default)
Use PMIC for full hardware shutdown (PMIC_SHUTDOWN): y (default)
Enable runtime assertion checking (ASSERT): y (default)
Verbose logging of assertion failures (ASSERT_VERBOSE): n (default)
Allow compiling a firmware that does not run (COMPILE_TEST): n (default)
Compile the firmware with debug info (DEBUG_INFO): y (default)
Print additional debug-level log messages (DEBUG_LOG): n (default)
Provide an interactive debug monitor while off/asleep (DEBUG_MONITOR): n (default)
Print average latency after each state transition (DEBUG_PRINT_LATENCY): n (default)
Print the contents of Special Purpose Registers at boot (DEBUG_PRINT_SPRS): n (default)

基本的にはどれもデフォルトのままなのですが、Allwinner H6を使うこと、PMICとしてAXP805を使う設定は必要です。その後aarch64-linux-musl-gcc: not foundで中断してしまいますが、build/scp/scp.binは得られているのでこれで十分です。

ATF(ARM Trusted Firmware)のビルドは、git clone https://github.com/ARM-software/arm-trusted-firmware.git; cd arm-trusted-firmware; make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 bl31で。build/sun50i_h6/release/bl31.binが得られていればok。

最後に、U-Bootのソースコードをダウンロードして展開し、cd u-boot-xxxx.xx; make CROSS_COMPILE=aarch64-linux-gnu- orangepi_one_plus_defconfig; make CROSS_COMPILE=aarch64-linux-gnu- BL31=/path/to/bl31.bin SCP=/path/to/scp.binでビルドします。

とりあえず、U-Boot起動前にPSCI: System suspend is unavailableと表示されていたのがPSCI: System suspend is available via SCPIに変わったため、crustを組み込めてはいるようなのですが…ArmbianだとAXP805 detected等の表示があり、crustの設定をもう少し煮詰める必要があるかもしれません。53.00kg(20:50)

08-Feb-2021補足：crustのDEBUG_LOGやDEBUG_PRINT_SPRSを有効にすると使用する領域が大きすぎて収まらないといった感じのエラーが出てしまうので、あまりオプションをいじる余地は無さそうです。また、Armbianの起動時に色々と情報が表示されるのは、ATFがreleaseではなくdebugビルドになっていたという理由でした。