./lab

ClaudeやCodexに、GBS-ControlをESP-IDFに移植してもらった https://github.com/ntsklab/gbs-control/tree/esp-idf ターゲット 元プロジェクト：ESP8266 今回：ESP32-C3及びC6 開発環境 元プロジェクト：Arduino ESP8266 今回：ESP-IDF 方針 自分でコードを書かない LLMだけでどこまでできるのか、遊ぶ 移植方針など ターゲットデバイスは、XIAO ESP32-C3とC6。ピンヘッダ用の穴に直接JST-XHコネクタなどを実装することで、基板などを起こさなくても比較的楽にGBS8200ボードへ接続可能。（ピッチが違うため、良い子は真似してはいけません） 元がArduinoコードなので、Arduinoコンパチレイヤでラッピングしてなるべく元のソースをそのまま使用できるようにした。 C3/C6はESP8266と違いBLEがついていたりするので、Nordic UART Serviceベースのshell機能が追加になっている。元々は機能拡張版を作る予定がなく、GBS-Cが動作するまでのデバッグ用にBLE経由ログ出力などの機能を追加し始めてからブランチを分けた結果こうなっている。計画性のなさ。 Debugピンの入力や外部クロック処理など、こちらの環境で使用していない機能については動作未チェック。 追加機能あり版 https://github.com/ntsklab/gbs-control/tree/esp-idf-ext 某所で必要な機能を追加したバージョン。これが作りたくて、ESP-IDFへforkした節がある。 ロータリーエンコーダではなく物理ボタンによるジオメトリ、PreCoast、PostCoastレジスタの調整を可能としている。これにより画面のズレや、上部の歪みなどが発生した場合に、ある程度ソフト的に調整が効くようになっている。1 また、ESP8266用は現在のコードでは古いMVSなどが映らない（スタッタリング、同期取れず画面が流れるなど）する。2これは、SyncWatcherが動的にtv5725の同期系レジスタをいじる仕組みが原因の様子。3 こちらのIssueに記載があるが、古いバージョンではMVSも映っていたとのこと これらの情報から、旧GBS-Control互換モードを実装してもらい、無事古いMVSでも同期が取れるようになった。 他にも、複数台運用に耐え得るように各種無線の識別子を任意の文字列に変更する機能などを実装。 一旦こちらを運用に乗せて試験中です。 Coast系パラメータを正しく調整するには、後述するレガシモードで動作させるか、set syncwatcher offコマンドなどでSyncWatcherを明示的に無効化する対応が必要。 ↩︎ 自宅のMV-1Bでは動いていたのに、本番環境で使うMV-1FZでは動かず、大分悩んだ ↩︎ MVSの同期信号が終わってるのが真因ではあるのですが。。。 ↩︎

表題の通りですが、Wordpressやめました。 以前からやめたいな〜とは思っていたのですが、色々思うところがあり一気に実施しました。 旧来の記事が壊れているかもしれませんが、そのうち直します。。。

やすかったのでつい・・・ 購入の（いい）わけ 以前、GPD P2 MAXが壊れつつある話を書きました。 GPD P2 MAXが壊れつつある日記 代わりになるパソコンほしいな〜とは思っていたのですが、小さい端末はそもそも高いですし、フル機能パソコンである必要もないな、と思っていたので使い物になるかも含めてお試しに、というところです。 購入したのは今年初め辺り？から中古という名目でほぼ新品のものが投げ売りされている、Lenovo 14e Chromebook Gen 3 です。 物自体は2023年の商品で、Softbankから5G対応品として販売されているのが特徴ですね。 調べていて分かったんですが、同じ名称でWWAN非対応、性能が増強されているモデルもあるようです。 本体についてのレビューは沢山の方がされているのでそちらを見てもらうとして。液晶画面はIPSなど高輝度/広視野角なものに慣れきった今、下手したらブラウン管並みのノスタルジーを感じるぐらいイマイチですね。そんなことない？そう…。 VS Codeとかの日本語入力 ChromebookということでOSはChromeOSなのですが、開発用という名目でLinuxコンテナを動作させる仕組みがあります。内部ではLXCっぽいアレになっているそうです。 VSCodeが動きそうな話は事前に調べていたので、早速入れてみたのですがなるほど日本語入力が効かない。 ググると分かりますが、ChromeOSからLinuxアプリに対する日本語入力は昔から少し難があったようで、古くはLinuxコンテナ側でIMを動作させていた様子。2023年頃からは、cros-im？という仕組みが標準になりChromeOS側のIMを使うことができるようになったそうです。 それ以降に書かれた記事では、VSCodeはそのまま日本語入力できるようになった、みたいな記述が多く困っていたところ、ChromeOSにおいてもLinuxアプリはWaylandとX11でcros-imの挙動が変わる的な話を発見。（URL失念。。。） 確かに、ネイティブなLinux環境でもその辺でみんな（誰？）悩んでいるのはよく見ます。 というか、多分そういうことなんだろうなとは根拠なく思っていました。 試しに以下で起動してみた結果、日本語入力が普通に動作しました。 code --ozone-platform=x11 Waylandにこだわっているわけでもないですし、これでいいか、と。 ChromeOSは、Linuxコンテナ内で作られたdesktopファイルを読んでメニューにアプリアイコンを出している？そうです。ということで、基となるdesktopファイルのExec行を直接編集して、上記引数を追加してターンエンドです。やったぜ。 VSCodeでGithubアカウントへログインしようとしたところ、keyring周りのエラー。 ストレージ暗号化されているし弱い暗号化？で保管されても構わないよ〜とは思いつつ、gnome-keyringインストールしているのにな〜と。 ということで以下ドキュメント参考にargv.jsonへ設定追加で解決。 https://code.visualstudio.com/docs/configure/settings-sync#_recommended-configure-the-keyring-to-use-with-vs-code WWAN（5G）でDocomo回線を使う せっかくですのでWWAN機能も使いたいですよね。 ChromeOSはAndroidのテザリングを遠隔で有効化できるので、WiFiだけでもそんなに苦労はしないのですが…。 個人の都合で、SB回線のSIMはメイン機で使ってしまっているため、余っているIIJmio type Dあたりを使いたいところです。 APNなどを適当に**（フラグ）**設定してみたのですが、どうにも「モデムが登録されていません」だの「有効期限が切れている」だの出てきてうまく繋がりません。 調べたところChromeOSは、SIMロック時モバイルデータの設定画面に特定のキャリアしか使えない旨の表示が出るらしいです。つまりとくにSB限定になっているわけでもなさそう。 さて困ったな…と思いpovoのSIMを入れてみたところ接続されるじゃありませんか。えぇー(´・ω・｀)となりましたが、動作にキャリア差があるということはAPN設定周りの可能性が高いなと思案。IIJのサポートサイトをよく見ると、ありましたよ。Windows用の設定ページをよ〜くみると… 画像で。すんげえちっちゃく。 APNの種類 （タイプDの場合）インターネットおよびアタッチ （タイプA）インターネット そしてChromeOSのモバイル設定画面が以下。 すでにチェックが入っていますが、「Attach (IA)」はデフォルト無効です。 Androidにはそんな設定ないじゃんねえ(ヽ´ω`) きれいにフラグを回収しましたとさ。同じ轍を踏むな…！ 俺達のChromebookカスタムはまだまだこれからだ！！ Holloのほうでも書いていたのですが、ChromeOSのこういうチマチマしたカスタマイズ、りなざうで遊んでるときの感覚に近いですね。たのしい。 ChromeOSふっ飛ばして遊ぶというのも中々楽しそうなんですが、しばらくは普通に使ってみようかなあというところです。

いつ買ったんだっけ、と調べてみたら2020年4月末。ちょうど、緊急事態宣言によるBCP長期出張の合間ですね。懐かしい。 症状としては致命的なものから順に 一部キー入力ができない マウスクリックが非常に効きにくい バッテリ容量低下 といったところです。 キー入力に関しては、常時右端の全キー（BcSp, Del/`, @, Ins/Ent/_, /→）及びタイミングによっては左下のCtrlが効かない様子です。終わりすぎ。 水ぬれとかはなく、症状発症時もいつも通り文字打っていたら急に効かなくなった、という感じでした。 症状が出ているキーがキーボード外周部に限られているというところから、内部フレキの一部信号が接触不良等でだめになっている説を思いつきました。 しかしこの機種、工事設計認証番号が背面外装パネルに記載されているんですよね。 また、それがGPD社によって取得されているものであるため、分解は良くないのかな、というところでして。。 ※ググった感じ、内部のIntel無線モジュールには別の工事設計認証番号が記載されている様子。となると、こちらの取得にあたって使用したアンテナと異なるものをP2 MAXにて採用したからGPD社が改めて試験をし、工事設計認証を得た、、、とかなんですかね、無線に関する技適（証明）については詳しくないですけど。 軽く叩いてみたり掃除機で吸ってみたりと、外部からできることはやってみましたが、直らず。 その他の不都合についてもだんだん我慢ができなくなってきたので、潮時かなあというところ。5年は使えたし、結果としては買ってよかったかなとは思いました。 変なキー配置も、慣れてしまえば意外となんとかなるもんでした。日本語あんまり打たなかったっていうのはありますが・・・ 新しいものを買うとして、持ち運べるPC環境はほしいのだけど、大して外には出ないんだよな、という悩み。 外でPCを使う用途って、納品したマイコン系物品の実地デバッグや修正、修理とかなんですよね。ノートパソコンである必要があるのかどうか・・。 使うときだけキーボード型ラズパイ持っていく、とかでもいいのかもなあ。。 ところで、調べてて気づいたんですけどR 210-131828を調べるとW52の周波数しか書いてないんですよね。 これどうなんですかね。だめそう。ｗ

概要 「NetMeister」のDDNS機能から「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」へ移行したよ！ 背景 とある施設において、複数拠点でIXルータ（最近終売した2215。。。）を用いてNWを構築しており、それらの遠隔保守のためフレッツ網内折り返し接続（≒v6オプション）によるVPNを使用しております。 ところで、NTTフレッツ光のIPv6アドレスの配布について、10G以外でひかり電話なしだとNTT側からRAで契約回線ごとに/64を配布されます。 そしてこの配布されるプレフィックスは基本的にONU交換や端末交換を行っても不変ですが、NTTやVNE等の都合で稀に変わることがあります。（俗に半固定、とか言われたりしますね。） 上記の問題を解決するため、IXシリーズではNetMeisterというクラウド管理システムへルータを登録することで、DDNS機能が無料で使える仕組みになっていました。（NetMeister無料版では、IPv4/v6共にインターネット経由での接続のみ対応。そのため、v6オプションのみの契約、記事公開時点では2408:210::/30に含まれるPrefixが降ってくる環境での接続は元来よりNetMeister Primeの契約が必要です。参考：NetMeisterサービス仕様 「NetMeister サービス仕様書」） 動機 しかし、去る2025/4/7に以下のリンクの内容がメールにて通知されました。 https://www.necplatforms.co.jp/product/netmeister/info/250407.html NetMeister ダイナミックDNSサービス（IPv6）無償提供終了のお知らせ （中略） IPv6 DDNSサービスの無償提供を終了し、新たにNetMeister Primeの一部として有償での提供を継続させていただくこととしました。 たいへんだ。 乗り換え先の検討 NTT東日本ではネームサービスというものがあり、公式でDDNSのような機能を提供しています。 https://flets.com/v6option しかし、v6ネームはインターネットに存在するDNSサーバ（例えば、Cloudflare 1.1.1.1）では名前解決ができない仕組みになっており、フレッツ網よりDHCPv6で取得できるDNSサーバを使用する必要があるなど、非常に不便です。 そこで、OPENプロジェクトによる以下のサービス「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」を使用することとしました。（β版、と言い張られておりますが。） https://i.open.ad.jp こちらのサービスはフレッツのネームサービスと違い通常のインターネットに存在するDNSサーバでも名前解決が行えるなど、大変に「けしからん」仕組みとなっています。 ちなみに最近知ったのですが、上記のOPEN IPv6 ダイナミック（以下略）をベースにした商用サービス「IPv6ダイナミックDNS」が開始していたようです。いつの間に。（2021/7らしいです。） https://ddns.e-ntt.jp インターネット上に存在する適当な無料DDNSサービスや私の実験用ドメイン（oyasumi.dev）などを使うという手もありそうに思ったのですが、今回の目的がまさにv6オプションによる折り返し接続であるため、そのために作られたサービスのほうが適当であろうという判断のもと、OPENのDDNSを採用しました。 IXルータでの使用 上記サービスの解説ページにもありますが、なんとIXルータにはDDNS更新機能があり、OPENのDDNSはこれに対応しています。そのため、今までのNetMeister DDNSと変わらずIXルータのみ設置している拠点でも自動でレコードの更新ができます。 動作としては、IXルータ側にてアドレス変更（IPv6だとRAによってIXへ新しいPrefixが配布された場合かな・・・？未検証。IPv6に関してアドレス変更もといソースアドレス選択周りは結構闇が深いのである・・・）を検知すると、ddns profileに設定されたアドレスへ指定のqueryをつけて投げる、という簡単な仕組みです。また、IFのアドレス変更がなくても1hに1回は更新を行う、という動作も可能です。大変便利ですね。 また、管理している拠点のうち一部はIPv6でのインターネット接続ができず、前述のNetMeister無料版の縛りにより中途半端にv4インターネット経由での接続が残る構成になっていましたが、今回ようやくその状態も解消しました。 結論 めっちゃ便利なのでさっさと乗り換えておきゃ良かった。これからもけしからん面白いフレッツサービスが生まれることを心より願っています。 おまけ 今回のOPEN DDNSに関してもソフトイーサ社はローンチ時に大変にけしからん参考になる文書を公開されているので、ぜひ読みましょう。楽しいゲームもあるよ。 https://i.open.ad.jp/news-160614

メモ https://hl.oyasumi.dev/@ntek/0192b99e-8468-733e-9592-447423dbc5fa

★2025/1/29 GithubのURLを変更しました Kubernetesでは、Deployment等のPod templateに対しイメージタグにてlatestを指定することは推奨されておりません そのため、sha256によるコンテナイメージのダイジェスト値指定か、バージョンタグを用いた指定を行う必要があります。 Pod templateにバージョンないしはdigest値を書くということは手動でアップデートの管理を行うということです。別に大した手間ではないですしそれでも良いのですが、せっかく（何が？？）ですので自動更新をさせてみたいものです。 但し、X.Y.ZバージョンのうちY部分の更新は何らかの管理者によるマイグレーション操作が発生する可能性を鑑みて、Z版のみ更新できるようにしてみました。（Z版で手動マイグレが必要にならない根拠は、無し。） 本来であれば以前記載した、「Deploymentでのアプリケーション単一性維持が保証できない問題」も含めて解決できる、何らかのOperatorを実装するほうがスマートです。しかし、当たり前ですがそういった実装には手間がかかりますので今回はKubernetesのCronJobでお茶を濁します。 今回の手法を実現するにあたり、JobのPodからKubernetesのDeploymentを書き換える方法を考える必要があります。 kubectl等の汎用クライアントを動かせるようにしてもよいのですが、このコマンドはフットプリントが結構大きく、また、kubeconfigファイルなどを用意する必要がある、応答を基に処理をしようとすると別途jsonの解釈が必要になる、信頼できそうな既製イメージでjqが入っているものが無さそうである、など、少々都合が悪いです。 そこで、今回はcurlコマンドとjqコマンドのみを用いてkubernetes APIを叩き、DeploymentのpodTemplateへ設定されているイメージのバージョン取得、及びその書き換えを行ってみます。 下準備として、PodからkubeAPIを叩くためにServiceAccountやRole等を作成します。以下に例を示します。 apiVersion: v1 kind: ServiceAccount metadata: name: updater namespace: hollo-1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: get-patch-deploy namespace: hollo-1 rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: updater namespace: hollo-1 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: get-patch-deploy subjects: - apiGroup: "" kind: ServiceAccount name: updater namespace: hollo-1 次に、Pod内部で実行するスクリプトを用意します。（力技。。。）curlでKubernetes APIを操作する方法については以下のサイト等を参考にしました。 ...

クリンスイから乗り換えてみました。 説明書を読む限り、TK-CJ14-Wはもともと使用していたクリンスイCB013と比べてもほぼ同様の水道蛇口に取付可能なように見えます。 ところで、我が家の水道は、食洗機の給水に無理やり対応させるために、蛇口から先が変換の嵐となっています。 https://hl.oyasumi.dev/@ntek/01944460-c42e-787a-a5fe-29928b6b0a42 本来TOTOの内ねじ泡沫キャップなのですが、変換を繰り返した結果、最終段がM22外ネジになっています。そのため、付属している灰色のアダプタで対応しました。 クリンスイCB013と比べてカートリッジ寿命が非常に長い（1年、一部除去項目については半年とのこと。）ため、トータルコストは変わらないか安くなるかな？という思いと、もともと使用していたCB013について4年が経過し、少し汚れが気になってきたため交換に踏み切りました。 除去項目が増えているはずなのですが、正直味などについてはあまり差がないように思います。カートリッジの寿命の長さが衛生的にどうなのかという心配がありますが、現状は満足しています。 一点、不満点をあげるとすれば、吐水口の形状の差なのか水勢が変わってしまい、シャワー以外でシンクでめちゃくちゃに水が跳ねるようになってしまったところです。どうにか改善できないか検討中です。 浄水器関連でなにか起きたら、またブログに記載したいと思います。

なんとなく動いている。 https://hl.oyasumi.dev/@ntek Holloとは 以下を参照。 https://docs.hollo.social/ja/intro Kubernetesで動かして何が嬉しいか Holloは基本的に一人用サーバのため、現状ではあまり嬉しいことはないように思える。ただ、弊環境はDocker等のコンテナ基盤が常時動作していないため、Kubernetesに載せた。 使用したKubernetesディストロとオペレータ等 k0s + Cilium CNI + Cloudflare tunnel ingress controller + CloudNativePG + NFS CSI セットアップ Holloは現在、S3互換オブジェクトストレージを必要としている。今回はCloudflare R2を使用。 HolloはHelmの提供を目指している？様子だが、まだ無いのでとりあえずYAMLで書いていく。 Containerが同時に起動してDBにアクセスすると恐らく壊れるので、DeploymentのストラテジをデフォルトからRecreateへ変更する。※k8sドキュメントにあるように、これではContainerの単一性は保証できないので本来はStatefulSetを使用すべきである。 Hollo本体 kind: Deployment apiVersion: apps/v1 metadata: name: hollo-app namespace: hollo-1 spec: strategy: type: Recreate replicas: 1 selector: matchLabels: app: hollo template: metadata: labels: app: hollo spec: initContainers: - name: wait-db image: busybox:latest imagePullPolicy: Always command: ['sh', '-c', 'until nc -z hollo-db-cluster-rw 5432; do echo waiting for hollo-db-cluster-rw; sleep 2; done;'] containers: - name: hollo image: ghcr.io/fedify-dev/hollo:<strong><version></strong> imagePullPolicy: IfNotPresent envFrom: - configMapRef: name: hollo-config ports: - containerPort: 3000 resources: limits: cpu: "2" memory: "2048Mi" volumes: - name: hollo-config configMap: name: hollo-config Service（宅内からの試験用にCiliumのLoadbalancer機能を使用。Calico等の人はMetalLBとか、よしなに。今回のようにCloudflare tunnel Ingressコントローラ使う場合はClusterIPで十分） ...

自分用メモです。そういうことにしておいてください。 追記 多分こっちの方が安上がりだし早い 追記終わり 序章 アーケードゲーム基板や古の家庭用ゲーム機、オールドパソコン等様々な分野で利用されている海外製アップスケーラーであるGBS8x00シリーズですが、ここ数年GBS-Controlなる代替ファームウェアが流行しています。（私も、2020年頃に知人から教えてもらいました。） 私が関わっている気がする某所の録画設備では使用していませんが、コストパフォーマンスを考えると2024年9月末現在でも前述機械類に使う用途ではかなり良い選択肢であると思います。 そのためか、このファームウェアを使用した「GBS-C」を名乗る派生商品が、そこそこの数存在しています。 しかし、これらは正直なところかなり値段が「盛られている」ため、今回はなるべくやす～く、かつ技適問題もなく使えるようにしていきます。 また、上記完成品よりは安価な、「GBSボードの制御部へソケットで直接嵌合し乗っ取るモジュール」も販売されているようですが、値段を考えるとトータルでは上記の完成品と大差なくなってしまいます。こちらは公式Wikiから非推奨とされている方式ですので、今回はパスして自作していきます。 コスト重視で安く仕上げたい ゴールとしては、今回はナムコSystem 2×6基板の15kモードを現代のLCDへ映す目的で調整していきます。なお、GBS-ControlのWeb UIは後述の問題でまともに使えません。今後の課題ですね。 さて、公式Wikiに記載のあるいくつかのESP8266搭載ボードは日本において技適（技術基準適合証明）の問題があるため、別のものを探すことになります。 せっかくコスパよいボードを使うのですから、ここはなるべく安く行きましょう。ESP8266搭載品ということでESP-WROOM-02Dを使用します。記事公開時点でまさかの300円台です。やっす。 こちらのモジュール、Flashの容量が公式で使用しているものの半分（2MB）しかありません。 今回のゴールに必要な機能は動きましたが、付加価値であるOTA等は恐らく動かないでしょう。※どうせ無線は使い物にならないからいいかなって・・・。 ピンアサインの変更 Arduino IDEにて、ボードとしてGeneric ESP8266 Moduleを選択します。 GBS-Control公式のコードのままではピン指定の差分によりコンパイルが通りません。 以下にフォーク版を作っています。適当に活用してください。（最新への追従は保証しません） https://github.com/ntsklab/gbs-control Arduino IDE設定 書き込み設定は以下です。Flash sizeの指定はハイライトしているものを、Crystal Frequencyは26MHz、Reset Methodはno dtrまたはその下のno sync的なやつ、CPU Frequencyは下の画像では変更前ですが160MHzを選びましょう。他は公式手順通りです。 ハードウェア組み立て ピンアサインは以下です。ESPの電源は適当にボードの3.3vなどから取ってください。空中配線をする場合、配線材は適当にGBSボードに付属してくる電源線とかを切って使いましょう。 To GBS SDA : IO4 SCL : IO5 Debug : IO16 Etc EN : Pull Up RST : Pull Up 以下3つはオプション To OLED SDA : IO4 SCL : IO5 To Rotary Encoder A : IO14 B : IO13 Push : IO0 ...