コグノスケ

M5Stamp C3をBluetooth LE子機にする

目次: Arduino

M5Stamp C3はWi-FiとBluetooth LEが使えます。私はBluetooth規格は全く知らないですが、Arduino-ESP32にはBLEライブラリがあってお手軽にBluetooth LEによる通信ができます。Arduino-ESP32とは何者か？については以前の日記（2024年1月7日の日記参照）をご覧ください。

ライブラリがあるとはいえゼロからコードを書くのは結構大変です。しかし世の中にはArduino-ESP32 BLEのサンプル（ESP_32_BLE_Arduino）を公開している素敵なリポジトリがありまして、これを元に改造すると簡単です。ありがたいですね。

動作確認にはスマホを使います。Bluetooth LEに対応しているアプリならなんでも良いです。参考までに私はSerial Bluetooth Terminalというアプリ（Serial Bluetooth Terminal - Google Play）で確認しています。iPhoneは持ってないのでわかりません、アプリがあると思いますので頑張って探してください……。

TXとRXの割当

Arduino-ESP32 BLEのサンプル側はNordic nUARTのCharacteristic GATTのUUIDを使っていて、こんな設定になっています。

• 6E400001-B5A3-F393-E0A9-E50E24DCCA9E: Service GATT UUID
• 6E400002-B5A3-F393-E0A9-E50E24DCCA9E: RX（受信用、アプリから見たらWritable）Characteristic GATT UUID
• 6E400003-B5A3-F393-E0A9-E50E24DCCA9E: TX（送信用、アプリから見たらReadable）Characteristic GATT UUID

TXとRXがどちらから見た方向なのか混乱しますが、Serial Bluetooth TerminalのPredefined設定は賢いので間違えてTXとRXの定義が逆になっていても通信できてしまいます。

通信できれば問題ないとはいえ、正解を調べておいて損はないでしょう。Nordic Semiconductorのドキュメント（UART/Serial Port Emulation over BLE - Nordic Semiconductor Infocenter）を見ると、下記の記述があります。

This service exposes two characteristics: one for transmitting and one for receiving (as seen from the peer).

  - RX Characteristic (UUID: 6E400002-B5A3-F393-E0A9-E50E24DCCA9E)
    The peer can send data to the device by writing to the RX Characteristic of the service.
    ATT Write Request or ATT Write Command can be used. The received data is sent on the UART interface.
  - TX Characteristic (UUID: 6E400003-B5A3-F393-E0A9-E50E24DCCA9E)
    If the peer has enabled notifications for the TX Characteristic, the application can send data to the
    peer as notifications. The application will transmit all data received over UART as notifications.

RX Characteristic（UUID: 6E400002）の説明はsend data to deviceとあります。すなわちアプリ側にとってTXでありサンプル側にとってはRXとなるはずです。TXはその逆ですね。

• 6E400002-B5A3-F393-E0A9-E50E24DCCA9E: サンプルのRX Characteristic GATT UUID
• 6E400003-B5A3-F393-E0A9-E50E24DCCA9E: サンプルのTX Characteristic GATT UUID

• 6E400003-B5A3-F393-E0A9-E50E24DCCA9E: アプリから見たらRX方向
• 6E400002-B5A3-F393-E0A9-E50E24DCCA9E: アプリから見たらTX方向

とするのが正しそうですね。

気難しいM5Stamp C3のAutomatic Bootloader

目次: Arduino

M5Stamp C3の接続を変更したところ、Arduino Sketchが書き込めなくなってしまいました。こんなエラーで怒られます。

Sketch uses 1003156 bytes (76%) of program storage space. Maximum is 1310720 bytes.
Global variables use 38676 bytes (11%) of dynamic memory, leaving 289004 bytes for local variables. Maximum is 327680 bytes.
esptool.py v4.5.1
Serial port COM3
Connecting......................................

A fatal error occurred: Failed to connect to ESP32-C3: Wrong boot mode detected (0xc)! The chip needs to be in download mode.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Failed uploading: uploading error: exit status 2

回避策としてはboot modeを変えれば良いです。ジャンパーケーブルなどでGPIO 9をLowにして（隣のGNDと繋ぐと簡単）リセットします。リセットしたらジャンパーケーブルは外しましょう。GPIO 9はPull-upされているので、未接続だと勝手にHighになります。

M5Stamp C3のGPIO 9の位置

リセット後のシリアルに下記のようにROM serial bootloader for esptool Modeに入ったと表示されれば成功で、Arduinoなどから書き込みができる状態です。

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x1 (POWERON),boot:0x4 (DOWNLOAD(USB/UART0/1))
waiting for download

これでArduino Sketchが書き込みできますが、いちいちジャンパーケーブル挿してリセットなどやっていられません。面倒臭すぎます。そもそも今までそんなことしていませんでした。

Automatic Bootloader

M5Stamp C3が採用しているEspressif ESP32-C3というSoCの書き込みツールesptoolは、Automatic Bootloaderといって先ほど紹介した「GPIO 9をLowにしてリセット」という操作を不要にする機能、つまりDownload Modeに勝手に切り替えてSketchを書き込んで、Normal Bootしてくれる素敵な機能があります（Boot Mode Selection - ESP32-C3 - esptool.py latest documentation）。

とても便利なAutomatic Bootloaderですが、USB接続のトポロジーに敏感で結構気難しいやつだということがわかりました。私の環境ではUSBハブを介して接続すると発動しなくなります。なんでだー。

• CPU: AMD Ryzen 7 2700
• マザーボード: ASUS ROG STRIX B450-F GAMING
• OS: Windows 10 Pro 22H2
• USBポート: フロントパネル用ポート（オンボードコネクタから引き出すタイプ）

Automatic Bootloaderがうまく行くパターンはRootハブに直接接続したときです。接続例を示します。

Rootハブに直接M5Stamp C3を接続

うまく行くとログはこんな感じになります。

Sketch uses 1003156 bytes (76%) of program storage space. Maximum is 1310720 bytes.
Global variables use 38676 bytes (11%) of dynamic memory, leaving 289004 bytes for local variables. Maximum is 327680 bytes.
esptool.py v4.5.1
Serial port COM3
Connecting....
Chip is ESP32-C3 (revision v0.3)
Features: WiFi, BLE
Crystal is 40MHz
MAC: 84:f7:03:27:f8:14
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
（...以下略...）

うまく行かないパターンはUSBハブを介して接続したときです。接続例を示します。

USBハブを経由してM5Stamp C3を接続

ハブに依存するかもしれないと思い、USBハブはUSB 2.0とUSB 3.0のものを試しましたがどちらもダメでした。嫌な感じの挙動です。バグっぽいなー。

複数台接続はOK

もう一つの可能性として、M5Stamp C3を複数台繋ぐこと自体がだめな可能性を考えました。が、こちらは特に問題ありませんでした。せめてもの救いですね。

1台でも2台でも、USBハブを入れるとAutomatic Bootloaderが無効になってしまうようです。接続したい台数は3台なんですが、フロントポートは2つしかありません。困ったね……。

複数の音声ファイルのラウドネスを統一したい

PCやデジタル音楽プレーヤーで音楽を聞いていると、曲によって音量の大小が激しく違っていて鬱陶しいです。片や何も聞こえず、片やリスナーの耳を壊す勢いの爆音で同じ音量で聞き続けるのが困難です。

人が感じる音の大きさをラウドネス（Loudness）と呼びますけども、全ての曲のラウドネスを一定レベルに修正すれば、極端な沈黙や爆音を避け同じくらいの音量で楽しめるはずです。ラウドネスの修正を行うツールはffmpeg-normalizeが簡単でわかりやすかったです。Pythonで実装されていて内部ではffmpegのloudnormフィルターを使っているそうです。

インストール方法はpipを実行するだけで簡単です。ローカルのPython環境に影響が及ぶのが嫌な方はvenv（venv - 仮想環境の作成 - Python 3.12 ドキュメント）を作成し、仮想環境にインストールすると良いです。

$ python3 -m venv ./venv
$ source ./venv/bin/activate
$ pip install ffmpeg-normalize

基本的な使い方はffmpeg-normalize (入力ファイル名) -o (出力ファイル名)ですが、デフォルトパラメータがターゲットレベル-23LUFS、サンプリングレート192kHz、Matroska（拡張子.mkv）形式となっています。サンプリングレートとかは好み次第ですけど、ターゲットレベル-23LUFSはすっっっごい音が小さいです……。最初試したときに、音が消えてしまうぞ？おかしいなあ？？と悩みました。

これらの設定を変更するときは、-tオプションでターゲットレベルを、-arオプションでサンプリングレートを、-extオプションで出力形式を変更してください。

2パス処理を諦めないで

基本的にffmpeg-normalizeは2パス（1回目でファイル全体を解析、2回目でノーマライズ処理）でノーマライズを試みますが、曲のラウドネスの幅がターゲットLRA（Loudness Range、曲全体のラウドネスの幅、デフォルトは7.0LUFS）を超えると2パスのノーマライズを諦めてしまいます。

$ ffmpeg-normalize test.mp3

WARNING: Output directory 'normalized' does not exist, will create

★★↑出力ディレクトリを指定しないとnormalizedというディレクトリを自動的に作る


WARNING: Input file had loudness range of 7.8. This is larger than the loudness range target (7.0). Normalization will revert to dynamic mode. Choose a higher target loudness range if you want linear normalization. Alternatively, use the --keep-loudness-range-target or --keep-lra-above-loudness-range-target option to keep the target loudness range from the input.

★★↑2パスを諦めたよ、というWARNING


WARNING: In dynamic mode, the sample rate will automatically be set to 192 kHz by the loudnorm filter. Specify -ar/--sample-rate to override it.

★★↑2パスを諦めてdynamicモードになると192kHzで再エンコードし始める

WARNINGを見ると、この挙動を回避したければ--keep-lra-above-loudness-range-targetオプションを付けてねと書いてありますが、オプションによる悪影響の有無が良くわかりません。変換後の音楽をいくつか確認した限りでは、破綻やクリッピングが発生している様子はなさそうです、たぶん付けておいて良いのかな……？？

複数ファイルの扱い

複数のファイルを処理する際はシェルスクリプトを組んだほうが良いと思います。ffmpeg-normalizeに複数ファイルを渡すと1つのディレクトリ（デフォルトではnormalizedという名前のディレクトリ）に出力するからです。

例えばアルバムごとにディレクトリを分けて音声ファイルを格納している場合に困ります。ノーマライズ後のファイルが1つのディレクトリにまとめられてしまうと、再度アルバムのディレクトリに分配しなければならず面倒です。

for i in */*.flac; \
  do echo $i -----; \
  ffmpeg-normalize -t -14 --keep-lra-above-loudness-range-target \
    -ar 48000 -ext wav "$i" \
    -o "`echo $i | sed -e 's/flac\$/wav/g'`"; \
done

全アルバムディレクトリのflacを、ノーマライズしたwavに変換するならこんな感じです。適当スクリプトなので入力と出力を同じファイル名にできません。一度別名を経由して元の名前にリネームするように改造していただければと思います。

SSLに対応

目次: 自宅サーバー

今更感がありますが、このサイトもSSL対応にしました。ブラウザに「安全ではない接続です！」と怒られなくなりました。まあ、それだけですね……。

SSL対応

SSL証明書は年990円のJPRSドメイン認証型SSLにしました。とてもお安いです。購入も簡単で、さくらインターネットからボタン1つで買えました。買った後にLet's Encryptを使えばタダだったのでは？と気づきましたけど、気にしないことにします。

日記システムも直した

サーバー側の設定以外に日記システム側も改修が必要です。一部のリンクや画像のURL出力などでhttpに決め打ちしていた部分があって、http経由/https経由でアクセスするファイルが混在していました。ブラウザはこのようなサイトを表示させると「完全に安全ではない！」と警告してくれます。良く見てます。ありがたい。

さらに面倒なことに自宅に置いているミラーサーバーはSSL非対応なので、手あたり次第httpを全部httpsに置換するとミラーサーバーの表示が崩壊してしまいます。サイトごとにhttp経由/https経由を設定できるように変更しましょう。

自分のドメインとGmailとDNSのDKIM, DMARC

目次: 自宅サーバー

Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース（Gmailユーザへメールが届かなくなる？Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説！ - NRIセキュア ブログ）の対応の続きです。

Gmailに大量にメールを送る人（5000通over）でなければSPFだけでも良いらしいです。が、さくらインターネットがDKIMに対応してくれました（DKIM署名、DMARCを設定したい - さくらのサポート情報）し、せっかくなので使ってみます。

DKIM Keyレコード

DKIM（RFC 5672, RFC 4871, DomainKeys Identified Mail (DKIM) Signatures）はSPFとは異なりメールサーバーの設定が必須です。仕組みとしては、

• 送信側メールサーバー（さくらインターネット）にRSA秘密鍵を登録
• DNSサーバーにRSA公開鍵、ドメイン名を登録（DKIM Keyレコード）
• 送信側メールサーバー（さくらインターネット）はメールヘッダにドメイン名と署名を追加
• 受信側メールサーバー（Gmail）はDKIM Keyレコードから公開鍵を取得、メールヘッダの署名を検証し改ざんがないことを確認

こんな感じみたいです。間違ってたらごめんなさい。メールサーバーの設定はさくらインターネットの説明通りに設定すれば良いです。ログインしてコントロールパネルからDKIM署名を有効にし、秘密鍵を作成するボタンを押します。簡単でありがたいです。

DNSサーバーのTXTレコードにDKIM Keyレコードを追加します（バリュードメインの設定パネル用の書式で書いています）。"p="タグの値には公開鍵を書きますが、長いので省略します。

txt rs20240131._domainkey.katsuster.net v=DKIM1; k=rsa; p=(略)

先頭にあるrs20240131という謎の文字列はセレクタというそうです。RFCだと場所とか時間とか個人を表すものにする例が書かれています。さくらインターネットの場合はDKIM鍵を作成した日になるみたいですね。

DKIMセレクタの確認（さくらインターネットのコントロールパネル）

DKIM署名の確認（メールヘッダの一部から抜粋）

セレクタ文字列自体にあまり意味はなくて、メールサーバーがメールヘッダに追加するDKIM-Signatureの"s="タグの値と一致していることが重要です。

DMARCレコード

最後にDMARC（RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)）レコードを設定します。

txt _dmarc.katsuster.net v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:(略)

DMARCはメールの送信元の改ざんや詐称を防ぐ仕組みですが、DMARC自体が何かする訳ではなく実際にはSPFとDKIMの合わせ技です。DMARCはポリシー適用の厳密さだったり、違反していたらどうしたら良いか？だったりを宣言しています。なのでSPFレコードとDKIMレコードが正しく設定できている必要があります。

Gmailに送って確認

DMARCの設定をしたらGmailにメールを送り、メールヘッダを確認します。

Authentication-Results: mx.google.com;
       dkim=pass header.i=@katsuster.net header.s=rs20240131 header.b=uzgJOfTY;
       spf=pass (google.com: domain of (略) designates 219.94.129.142 as permitted sender) smtp.mailfrom=(略);
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=katsuster.net

SPF, DKIM, DMARCともに無事passしました。しばらくこれで運用したいと思います。