目次: 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になります。
リセット後のシリアルに下記のように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が書き込みできますが、いちいちジャンパーケーブル挿してリセットなどやっていられません。面倒臭すぎます。そもそも今までそんなことしていませんでした。
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ハブを介して接続すると発動しなくなります。なんでだー。
Automatic Bootloaderがうまく行くパターンはRootハブに直接接続したときです。接続例を示します。
うまく行くとログはこんな感じになります。
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ハブはUSB 2.0とUSB 3.0のものを試しましたがどちらもダメでした。嫌な感じの挙動です。バグっぽいなー。
もう一つの可能性として、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オプションで出力形式を変更してください。
基本的に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証明書は年990円のJPRSドメイン認証型SSLにしました。とてもお安いです。購入も簡単で、さくらインターネットからボタン1つで買えました。買った後にLet's Encryptを使えばタダだったのでは?と気づきましたけど、気にしないことにします。
サーバー側の設定以外に日記システム側も改修が必要です。一部のリンクや画像のURL出力などでhttpに決め打ちしていた部分があって、http経由/https経由でアクセスするファイルが混在していました。ブラウザはこのようなサイトを表示させると「完全に安全ではない!」と警告してくれます。良く見てます。ありがたい。
さらに面倒なことに自宅に置いているミラーサーバーはSSL非対応なので、手あたり次第httpを全部httpsに置換するとミラーサーバーの表示が崩壊してしまいます。サイトごとにhttp経由/https経由を設定できるように変更しましょう。
目次: 自宅サーバー
Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース(Gmailユーザへメールが届かなくなる?Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説! - NRIセキュア ブログ)の対応の続きです。
Gmailに大量にメールを送る人(5000通over)でなければSPFだけでも良いらしいです。が、さくらインターネットがDKIMに対応してくれました(DKIM署名、DMARCを設定したい - さくらのサポート情報)し、せっかくなので使ってみます。
DKIM(RFC 5672, RFC 4871, DomainKeys Identified Mail (DKIM) Signatures)はSPFとは異なりメールサーバーの設定が必須です。仕組みとしては、
こんな感じみたいです。間違ってたらごめんなさい。メールサーバーの設定はさくらインターネットの説明通りに設定すれば良いです。ログインしてコントロールパネルからDKIM署名を有効にし、秘密鍵を作成するボタンを押します。簡単でありがたいです。
DNSサーバーのTXTレコードにDKIM Keyレコードを追加します(バリュードメインの設定パネル用の書式で書いています)。"p="タグの値には公開鍵を書きますが、長いので省略します。
txt rs20240131._domainkey.katsuster.net v=DKIM1; k=rsa; p=(略)
先頭にあるrs20240131という謎の文字列はセレクタというそうです。RFCだと場所とか時間とか個人を表すものにする例が書かれています。さくらインターネットの場合はDKIM鍵を作成した日になるみたいですね。
DKIMセレクタの確認(さくらインターネットのコントロールパネル)
セレクタ文字列自体にあまり意味はなくて、メールサーバーがメールヘッダに追加するDKIM-Signatureの"s="タグの値と一致していることが重要です。
最後に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レコードが正しく設定できている必要があります。
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しました。しばらくこれで運用したいと思います。
目次: Arduino
PCとM5Stack/M5StampをBluetooth LEで接続したいと思って、Bluetoothドングルを購入しました。さほど高価ではない&Linuxで動かないドングルがあるかも?と予想して、異なる商品を3つ買いました。Buffalo BSBT5D200(Bluetooth 5.0 + EDR/LE)、Buffalo BSBT4D200(Bluetooth 4.0 + EDR/LE)、Princeton PTM-UBT7X(Bluetooth 4.0 + EDR/LE)です。
一番新しいカーネルが動いているDebian Testing(Linux 6.5.13とBlueZ 5.71)のマシンで試してみましょう。
$ uname -a Linux blackbird 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) x86_64 GNU/Linux # bluetoothd --version 5.71
購入した3つのドングルそれぞれで、Bluetooth LEデバイスのスキャン(hcitool lescan)と、LEデバイス情報の取得(hcitool leinfo)を行ったところ、Bluetooth 5.0対応の一番新しいと思われるBSBT5D200だけ動きがおかしいです。悪い予想が当たってしまいました。
# hcitool -i hci0 leinfo (MACアドレス) Requesting information ... Could not create connection: Input/output error
BSBT5D200だけhcitool lescanが凄まじく遅いし、hcitool leinfo (MACアドレス)を実行するとI/Oエラーになります。あらら……。
幸いなことにBSBT4D200とPTM-UBT7Xは正しく動くので、しばらくこちらを使います。
< | 2024 | > | ||||
<< | < | 02 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | 1 | 2 | 3 |
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | - | - |
合計:
本日: