Android Chrome の Wi-Fi 経由デバッグ

上記手順を踏んでいれば chrome://inspect を開くと該当デバイスの Chrome インスタンスも見えているはず。そのままデバッグできる。

なぜ WiFi 経由で adb したいか

Android をホストとして USB デバイスを接続していると、USB ポートは必ず埋まってしまう。もし USB で adb 接続しようと思うと大変煩雑になる

なんか接続が切れる

デバイス側のセキュリティ要件なのかわからないが、しばらく経過すると、勝手に USB デバッグのチェックが外れたりする。よくわかってない。

とりあえず wakelock をとったほうがいいのかも

やりかた

• deploy された GitHub Pages を wkhtmltopdf で PDF 化
• ghr で PDF を releases にアップロード

が基本的なところ。GitHub Pages のデプロイは Actions よりも遥かに早く終わるので、厳密に同期をしていない (Actions で Jekyll を起動して HTML を生成するのが正攻法だけど、この方法はものすごく時間がかかってしまう)。

wkhtmltopdf は openlabs/docker-wkhtmltopdf という Docker イメージを利用した。ただし、このイメージには日本語フォントが入っていないので、ちょっと工夫する必要がある。具体的にはレンダリングしたい HTML 側で、明示的に Google Fonts などから Web Fonts としてロードしてやる必要がある。

ghr は go を入れるところからやってしまったが、たぶん ghr の releases からバイナリ落としてきて展開するほうが早いと思う。そのうち変更するかも。

実際の設定

name: document release

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
        
    - name: Set up Go 1.12
      uses: actions/setup-go@v1
      with:
        version: 1.12
      id: go
      
    - name: Convert HTML to PDF
      run: |
        docker run \
        -v ${{ github.workspace }}:/srv/jekyll  -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
        openlabs/docker-wkhtmltopdf  --print-media-type https://cho45.github.io/NanoVNA-manual/ /srv/jekyll/_site/NanoVNA-manual.pdf

    - name: Upload to releases
      env:
        GO111MODULE: on
        GOPATH: /home/runner/work/
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        go get -u github.com/tcnksm/ghr
        $GOPATH/bin/ghr -u cho45 -r NanoVNA-manual -recreate -replace -n latest -b "latest" latest ${{ github.workspace }}/_site/NanoVNA-manual.pdf

実行コンテキストの違い

Cordova は file: で実行される。Capacitor は http: (Android) で実行される。

この違いは案外大きい。ESM (type="module" などでロードされる ECMAScript Modules) は application/javascript でなければ実行されないという厳格なルールがあるが、file:// ではすべてのファイルに mime-type が設定されないため、実行できない。回避する方法は結局のところ localhost にサーバを立てるぐらいしかない。この点だけでももう Cordova は厳しい。

アプリケーションの本体はどこに…

Cordova はビルド時に必要なソースコードを生成する。このため実際のビルドは必ず cordova コマンドを介す。

Capacitor はソースコードのスキャフォルドを最初に生成する。レポジトリには各プラットフォームの完全なプロジェクトが生成される。このため、実際のビルドは Android Studio や Xcode など、ネイティブな環境で行われる。

デバッグ機能の分類

• デバッグ制御インターフェイス : CPU制御を行う。ブレークポイントやプログラムカウンタの増加(実行)など
• トレース機能: 実行履歴を出力する機能。デバッガではいちいち実行を止めるため、実際の速度で動かしたときのタイミング問題などを検出するのは難しい。そこでトレース機能が必要になる。

デバッグ制御インターフェイス

• ICE: in-circuit emulator CPU の代わりに回路中のCPUをエミュレーションするもの。元々は専用の IC だったが、最近のMCUはオンチップエミュレータとなっている。
• JTAG デバッグ制御インターフェイス。元々はデバッグ用ではなく検査用。5線で通信する。各ピンの状態がわかる (バウンダリスキャン)、というのが本来の用途。
• JTAG エミュレータ: JTAG をデバッグ制御として、オンチップエミュレータを操作する形のICE
• SWD デバッグ制御インターフェイス 2線ですむ。ARM MCU はこれが主流。デバッグ専用で、検査ポートとしては使えない (バウンダリスキャンはできない)。プロトコルは32bit値のR/Wに特化している。

JTAG も SWD も CPU 内部のレジスタを読み書きすることで、CPU 側にある任意の機能を呼び出している。なので、デバッグプロトコルは JTAGとSWDの上に乗っており、CPU によって異る。

トレース機能

• ETM: Embedded Trace Macrocell 分岐のたびにPC情報を得ることでトレースする。
• SWV: Serial Wire Viewer PCをサンプリングすることでトレースする。(サンプリングなので抜けが発生しうる)

(高級な print デバッグを想像するとよい。が、自分は使ったことがないのでわからない)

ARM 関連

• CMSIS-DAP: Cortex Microcontroller Software Interface. Standard - CoreSight Debug Access Port . ARM が定義した USB と SWD/JTAG インターフェイスのプロトコル
• ARM CoreSight: ARM Core 内のデバッグ用コンポーネント

USB から CMSIS-DAP を使って JTAG/SWD を操作し、CPU 内部の CoreSight に接続する、という感じ。

USB デバッガ

• SEGGER J-Link: JTAG/SWD を USB 経由で扱うインターフェイス
• ST-Link: STM8/STM32 専用の JTAG/SWD を USB 経由で扱うインターフェイス
• LPC-Link2: CMSIS-DAPデバッガにしたり SEGGER J-Link にしたり Redlink にしたりできるボード。

このへんややこしいが、「SERGGER J-Link」はデバッガハードウェアの名称でもあり、USB 接続時のプロトコルでもある。

ST-Link も同様で、ST-Link2 ST-Link3 というデバッガハードウェアもあるし、USB 接続時のプロトコルでもある。

LPC-Link2 は USB 接続時のプロトコルとして SEGGER J-Link / CMSIS-DAP / Redlink (nxp の独自プロトコル) を切り替えられるボード。

結局どのプロトコルでも、同じCPUならできることは一緒。だが、ホスト側のドライバの関係でパフォーマンスに違いがでることがある。

3行で

• 信頼性のあるキーボードがほしいなら買わないほうが良い
• 打鍵感は十分に良い
• これにしかない魅力はある

NiZ というキーボード

https://www.nizkeyboard.com/ が公式っぽい。中華製の静電容量無接点キーボード (HHKBやRealforceなどと同じ分類)。

HHKB と比べると以下のような特徴がある

• 35g / 45g を選べる。35g モデルでも 10g 増やすバネで、特定のキー(ホームポジションとか)だけ荷重を増やせる
  • HHKB は 45g キーストローク 4mm
• キー数のバリエーションが多い
• 完全にキーマップをカスタマイズ可能 (ファームウェアレベルで行う)
• Type-C コネクタ (mini-B よりも機械的に丈夫なコネクタ)
• Bluetooth 接続対応・バッテリー内蔵
• 価格は若干安い

価格が安いだけなら買うつもりはなかったけど、キーが HHKB よりも軽くて Bluetooth 接続が可能で、Type-C 接続な点で気になった。66キー(HHKBとほぼ同じ大きさ) 35g のモデルを買ってみた。スペック通りなら HHKB 信者を止めることになる。

初期設定とハマったところ

デフォルトだと「Office モード」というモードらしく、キーのリマップが効かないモードになっている。 Fn+M キーを同時に2秒押して Program モードというモードにしなくてはいけない。

専用アプリを使ってのキーカスタマイズはこのモードでしか適用されない。

キーが効きにくい……

試しうちしてすぐ気付いたが、左 Ctrl (というか位置的には Caps-Lock)、スペース、RET、Shift が叩くように入力しないと反応しない、または普通に使っていて入力をとりこぼすことがわかった。

https://www.nizkeyboard.com/2019/07/07/some-keys-doesnt-work-look-at-this/ 公式にこういうエントリがあるぐらいなので頻出問題みたい。手順では F2 F10 を押しながらキャリブレーションすると書いてあるけど、単に基準となるキーが変わるだけで、どのキーを押しながらでもキャリブレーションできる。自分の場合は左 Shift + スペースを軽く押しながらキャリブレーションすることで、気になる範囲の取りこぼしはなくなった気がする。

キーボードの信頼性

市販のキーボードは「普通に動く」けれど、それはもうそれだけですごいのだ、ということに気付く。キーボードの信頼性というのはそこで、普段意識するようなことはない。最低限ちゃんと思った通りに入力できなければならない。

NiZ は(自分の場合は)キャリブレーションなしには全く使いものにならないものだった。普通に考えたら初期不良だし、キーボードをキャリブレーションしたらなおるとか思いもしないだろう。そういう初期調整も含めての安価な値段だと思う。

NiZの良い点

良い点は冒頭でもほとんど記したけど

• 打鍵が軽い
• スコスコしたスムーズな打鍵感
• 打鍵音が静か (HHKB と比べると雲泥の差)
• カスタマイズ性
• Bluetooth

とかいろいろある。このキーボードにしかない特徴があるので、うまくキャリブレーションするか、あたり個体を掴めれば良い選択かもしれない。

とりあえず普段遣いできる感じのキャリブレーションはすることができたので、しばらく使ってみるつもり。

細かいメモ

USB デバイスとしては `ID 0483:512a STMicroelectronics 66EC-S ` で認識されている。STM32 っぽい……と言いたいところだけど、中華デバイスは STM32 互換の MCU に STM32 のツールで作ったファームウェアを書いていたりするので、これだけでは判断できない。

できたもの

実行するとこういう出力をする。最後の数字がキーに対応するカウント。

key=  1 hwcode=   1             ESC: 35
key=  2 hwcode=  15               1: 66
key=  3 hwcode=  16               2: 92
key=  4 hwcode=  17               3: 114
key=  5 hwcode=  18               4: 119
key=  6 hwcode=  19               5: 53
key=  7 hwcode=  20               6: 99
key=  8 hwcode=  21               7: 18
key=  9 hwcode=  22               8: 115
key= 10 hwcode=  23               9: 76
key= 11 hwcode=  24               0: 171
key= 12 hwcode=  25               -: 307
key= 13 hwcode=  26               =: 78
key= 14 hwcode=  41               \: 38
key= 15 hwcode=  14               `: 33
key= 16 hwcode=  28             TAB: 575
key= 17 hwcode=  29               Q: 253
key= 18 hwcode=  30               W: 627
key= 19 hwcode=  31               E: 1461
key= 20 hwcode=  32               R: 911
key= 21 hwcode=  33               T: 1137
key= 22 hwcode=  34               Y: 616
key= 23 hwcode=  35               U: 1317
key= 24 hwcode=  36               I: 1662
key= 25 hwcode=  37               O: 1536
key= 26 hwcode=  38               P: 549
key= 27 hwcode=  39               [: 584
key= 28 hwcode=  40               ]: 41
key= 29 hwcode=  27              BS: 1662
key= 30 hwcode=  67          L-CTRL: 18
key= 31 hwcode=  43               A: 1794
key= 32 hwcode=  44               S: 914
key= 33 hwcode=  45               D: 853
key= 34 hwcode=  46               F: 249
key= 35 hwcode=  47               G: 520
key= 36 hwcode=  48               H: 828
key= 37 hwcode=  49               J: 671
key= 38 hwcode=  50               K: 1424
key= 39 hwcode=  51               L: 696
key= 40 hwcode=  52               ;: 452
key= 41 hwcode=  53               ': 155
key= 42 hwcode=  54             RET: 1281
key= 43 hwcode=  55         L-Shift: 1610
key= 44 hwcode=  56               Z: 177
key= 45 hwcode=  57               X: 128
key= 46 hwcode=  58               C: 459
key= 47 hwcode=  59               V: 253
key= 48 hwcode=  60               B: 384
key= 49 hwcode=  61               N: 1352
key= 50 hwcode=  62               M: 482
key= 51 hwcode=  63               ,: 383
key= 52 hwcode=  64               .: 255
key= 53 hwcode=  65               /: 161
key= 54 hwcode=  66         R-Shift: 850
key= 55 hwcode= 156            R-Fn: 135
key= 56 hwcode=  67          L-CTRL: 1653
key= 57 hwcode= 166            L-Fn: 6
key= 58 hwcode=  69           L-Alt: 35
key= 59 hwcode=  68           Super: 703
key= 60 hwcode=  70           Space: 2037
key= 61 hwcode=  68           Super: 7
key= 62 hwcode=  71           R-Alt: 5
key= 63 hwcode=  74          R-Ctrl: 5
key= 64 hwcode=  88      Left Arrow: 24
key= 65 hwcode=  89      Down Arrow: 19
key= 66 hwcode=  90     Right Arrow: 34
key= 67 hwcode=   0                : 0
key= 68 hwcode=   0                : 0
key= 69 hwcode=   0                : 0
key= 70 hwcode=   0                : 0
key= 71 hwcode=   0                : 0
key= 72 hwcode=   0                : 0
key= 73 hwcode=   0                : 0
key= 74 hwcode=   0                : 0
key= 75 hwcode=   0                : 0

プロトコルの概要

すべて HID 上で行われる。64bytes 固定で read/write する。

日本語で説明するよりソースコード読んだほうが早いので説明するのをやめる。

カウントを得るためにすること

備考

macOS だからか、実装が悪いのか、どこが悪いのかわからないが、挙動が不安定

• HidApi.open がしばしば失敗する
• read に失敗する (タイムアウト)

何回か繰替えすと成功する。

hid_api

hid_api は timeout のメソッドがあるにも関わらず timeout の処理が抜けているので、モンキーパッチを書いてる。PR 作ろうかと思ったけど結構放置されてそうでめんどい。

macOS でもキーマップを書きかえたいんだけど？？？

read した形式で書き戻せばいいだけだと思う。

どうやって解析したか？

Windows に USBPcap を入れて、公式のアプリケーションを操作しながらログをとった。

あとは気合

ソースコード

https://github.com/cho45/niz-tools-ruby github にうつしました

>

ポイント

キーマップの書きかえコマンドを送ると、まず既存のキーマップが全てリセットされるみたい。つまり、プロトコル的には一部のキーだけを書きかえということはできない。常に全部のキーマップを送信する必要がある。

なので、一部の書きかえを実現したいのであれば、

1. 全キーマップの読み出し
2. キーマップの更新
3. 全キーマップの書き出し

という手順になる。

HWCODE の定義

NiZ は内部的にキーに対応する数値を HWCODE という名前で持っている。このコードは USB HID の scan code や、multi media キーや、その他いろいろな機能キーを一意に特定するものになっている。HWCODE は ASCII や Usage とまったく別の規則で割り当てられているようで、マッピングは気合で作るしかない。

気合で作るしかないので、おおむね作った。https://github.com/cho45/niz-tools-ruby/blob/master/niz.rb#L13 ということで、ここを読んでいる良い子のみんなは気合を入れる必要がなくなった。

マクロは？

自分で使わないのでまったく調べてない。マクロ登録用のコマンドがあるっぽい。

Choose Runtime プラグインをいれる

• https://plugins.jetbrains.com/plugin/12836-choose-runtime

再起動後に

Shift 連打とかで Choose Runtime... のダイアログを出す。

適当に 1.8.0 の JDK を選んで Install ボタンを押すと勝手に再起動する。

これでおわり。

JDK11 を指定したら起動しなくなった……

なんとなく AdoptOpenJDK 11 を入れて指定したら、起動しなくなってしまった。起動しないので Choose Runtime も使えない。

macOS の場合 ~/Library/Preferences/AndroidStudio3.5 以下に設定ファイルがある。~/Library/Preferences/AndroidStudio3.5/studio.jdk というファイルがあるので、これを消せばデフォルトの JDK に戻すことができる。

測定方法について

以下を根拠に測定する

• 特性試験の試験方法
• 別表第一 スプリアス発射又は不要発射の強度の測定方法
  • 一 スプリアス領域における不要発射の強度の測定方法
  • 二 帯域外領域におけるスプリアス発射の強度の測定方法
• 別表第三十五 証明規則第２条第１項第12号に掲げる無線設備の試験方法。「第２条第１項第12号」はアマチュア無線局のこと。証明規則第2条と種別名の対応表

新スプリアス規定

測定結果を提出データとして使うためには測定器(スペアナ)が1年以内に校正されていなければならないので、現実的に個人でこれを行うのは難しい。

しかしアマチュアであれば JARD に対してスペアナ(校正済みでなくてもよい) の測定結果をもって保証してもらうという手がある。

測定周波数

アマチュアの場合広い帯域を一括で免許をうけるので、どの周波数を使うのかと思うが、割り当て帯域幅によって異なり、帯域幅が1MHz以下なら指定周波数 (免許状に書いてある、周波数帯域の中央) で測定をすれば良いらしい。別表第35

ただし電波形式は免許を受けるすべての形式で行う必要がある。

具体的な測定方法

スプリアス領域における不要発射等の測定方法の陸上関係無線設備(一般)にしたがう。

スペアナの設定のうちRBW, VBW, 検波モードが必ず指定された通りになっていることを確認すること。

実際にやってみる

面倒なので 40m (7100kHz) の CW だけでやる。変調をかけ最大送信電力にするということになっている。できるだけ厳しい条件でやるという意図だと思われるので、短点連続(帯域が最大)でやってみる。技適の手順だと25ボーとか、外部変調装置がある場合その最高速度みたいな手順みたいだが…

10W 7100kHz の場合、帯域外領域のスプリアス発射強度の許容値は 50mW (17dBm) 以下かつ、基本周波数の平均電力より40dB低い値。スプリアス領域での不要発射の強度の許容値は 50μW (-13dBm)以下。

• 10W = 40dBm
• 30dB 50W のアッテネータで 10dBm (0.01W)
• 10dB 2W のアッテネータで 0dBm。これをスペアナに入力

必要周波数帯 (BN) は基本的に占有周波数帯幅の許容値と同値になるので CW の場合は 0.5kHz。スプリアス領域 は 2.5BN 離れた領域なため、7100±1.25kHz の外側がスプリアス領域。

7MHz の場合、基本波が9kHz〜100MHzのケースのためなのでスプリアスの測定範囲は 9kHz〜1GHz。ただし10倍高調波まで見る。

ref

• 帯域外領域とは？ https://www.tele.soumu.go.jp/resource/j/others/spurious/files/sanko002.pdf
• https://www.tele.soumu.go.jp/horei/reiki_honbun/72081000006.html
• 総務省の測定方法例: https://www.tele.soumu.go.jp/resource/j/others/spurious/files/sanko003.pdf
• アンリツのスペアナ基礎: 測定方法で必ず指定される項目が便利 http://dl.cdn-anritsu.com/ja-jp/test-measurement/files/Product-Introductions/Product-Introduction/ms2830a-jz4100.pdf
• 技適の測定方法 https://www.tele.soumu.go.jp/j/sys/equ/tech/test/index.htm

capacitor で keep すべきもの

capacitor の場合、JavaScript 経由で呼ばれるものには全て keep しておく必要がある。

• com.getcapacitor.plugin.* のうち、利用しているもの。
  • 名前も含めて keep しないとダメ。JS 側から見える名前はリフレクションで取得されるため
• その他、利用しているプラグイン以下のクラス

例

-keep public class com.getcapacitor.plugin.App {
    static *;
    public *;
}
-keep public class com.getcapacitor.plugin.Device {
    static *;
    public *;
}
-keep public class com.getcapacitor.plugin.Filesystem {
    static *;
    public *;
}

-keep public class org.apache.cordova.CordovaPlugin

-keep public class fr.drangies.cordova.serial.**
-keepclasseswithmembers class com.hoho.android.usbserial.driver.** {
    static *;
    public *;
}

-printconfiguration /tmp/full-r8-config.txt
-printusage /tmp/usage.txt

`-keep public class com.getcapacitor.plugin.Filesystem` だけだと名前が変わってしまう。ProGuard の指定方法がややこしつてよくわからなかったが、上記のようにしたらうまくいった。

cordovarduino という Cordova のプラグインを利用しているので、それ系の設定もある。

`-printusage` で指定したファイルには「削除された」クラスやメソッド名が出力される。必要なメソッドが意図せず削除されているかも?と思ったらこのファイルを見てみる。

9段のPN符号

「4.1 511-bit pseudo-random test pattern」となっているところが9段のもの。

「The pattern may be generated in a nine-stage shift register whose 5th and 9th stage outputs are added in a modulo-two addition stage, and the result is fed back to the input of the first stage. The pattern begins with the first ONE of 9 consecutive ONEs.」と文章で書いてある。

5th and 9th と書いてあるところが帰還多項式に対応しており、この場合

JavaScript での実装

以下のような任意のビット数(ただし32ビット以下)の LFSR のコードを書いた。全ビットが0でない限りは最大周期で全ての状態が出現する。

/**
 * Linear-feedback shift register
 *
 * reg: n bits register state
 * n: Bits(n) (up to 32bits)
 * taps: feedback polynomial (eg. x^16 + x^14 + x^13 + x^11 + 1 => [16, 14, 13, 11])
 * ref. https://en.wikipedia.org/wiki/Linear-feedback_shift_register
 */
function LFSR(reg, n, taps) {
	const mask = n === 32 ? (-1>>>0) : (1 << n) - 1;
	reg &= mask;

	const bit = taps.
		map( (tap) => reg >> (n - tap) ).
		reduce( (r, i) => r ^ i ) & 1;

	return ( (reg >>> 1) | ( bit <<  (n-1) ) ) & mask;
}

const start = 511;
let lfsr = start;
let period = 0;
do {
	lfsr = LFSR(lfsr, 9, [9, 5]);
	console.log('output:', lfsr>>(9-1), 'internal:', (lfsr | (1<<9)).toString(2).slice(1));
	period++;
} while(lfsr !== start);
console.log('this feedback polynomial period:', period);

プログラム方法

この MCU は System Memory という領域を持っており、ブートローダーが最初から書きこまれている。詳細は AN2606

USB 経由で DFU するには、基板上の BOOT0 を押しながら、NRST を押せば良い。

Bus 020 Device 008: ID 0483:df11 STMicroelectronics STM32  BOOTLOADER  Serial

として認識される。

platformio

https://docs.platformio.org/en/latest/boards/ststm32/blackpill_f401cc.html

blackpill_f401cc というのがある。たぶんこれなので、一旦これで試す。

platformio init --board=blackpill_f401cc

残念ながら mbed framework が使えないみたいなので、一旦 arduino でいく src/main.cpp

#include "Arduino.h"

#ifndef LED_BUILTIN
#define LED_BUILTIN 13
#endif

void setup() {
	pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
	digitalWrite(LED_BUILTIN, HIGH);
	delay(500);
	digitalWrite(LED_BUILTIN, LOW);
	delay(500);
}

pio run

.pio/build/blackpill_f401cc/firmware.bin ができるので、BOOT0 を押しながら NRST を押し、USB DFU モードにする。この状態で dfu-util で書きこめる。

dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D .pio/build/blackpill_f401cc/firmware.bin 

mbed のカスタムボード定義

とりあえず mbed のほうが好みなので mbed を使えるようにしてみる。こういうことするとハマりやすいのであまりよくないが…

403 Forbidden に従いながらカスタムボードを定義する。

platformi.ini

[env:f401cc]
platform = ststm32
board = f401cc
framework = mbed
build_flags = -I$PROJECTSRC_DIR/TARGET_F401CC

boards/f401cc.json

# https://github.com/platformio/platform-ststm32/blob/develop/boards/blackpill_f401cc.json をコピペ

custom_targets.json https://github.com/ARMmbed/mbed-os/blob/e1c3de649dd9c16d9548f73b4bbb71858af904f7/targets/targets.json#L4834 から抜き出してコピペ

{
	"F401CC": {
		"inherits": ["FAMILY_STM32"],
		"core": "Cortex-M4F",
		"default_toolchain": "GCC_ARM",
		"extra_labels_add": [
			"STM32F4",
			"STM32F401",
			"STM32F401xC",
			"STM32F401VC"
		],
		"supported_toolchains": ["GCC_ARM"],
		"device_has_add": ["MPU"],
		"device_name": "STM32F401CC"
	}
}

cp -r ~/.platformio/packages/framework-mbed/targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F401xC/TARGET_DISCO_F401VC src/TARGET_F401CC

#include "mbed.h"

DigitalOut led(PC_13);

int main() {
	for (;;) {
		led = 1;
		wait(0.2);
		led = 0;
		wait(0.2);
	}
}

これで pio run が走って .pio/build/f401cc/firmware.bin ができるはず。

time dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D .pio/build/f401cc/firmware.bin 

で書きこみ。

ITU-T G.227

Conventional Telephone Signal という名前の勧告。伝達関数が書いてある。600Hz ぐらいにピークのあるフィルタになっている。

ホワイトノイズをこのフィルタに通すことによって疑似音声となる。なので、この周波数特性を持つフィルタを設計する。

フィルタの設計方法

フィルタの知識がないので、試行錯誤しながら以下のようにすすめていった。

• 周波数特性をそのままFIRフィルタにする
• 最初から実数 FIR フィルタとして設計してみる
• 双一次変換を使って IIR フィルタにしてみる

結論からいえば、今回の場合はアナログフィルタの伝達関数が示されているので、そこからデジタル IIR フィルタに変換するのが一番良かった (と思う)

求めるのは Jupyter Notebook 上で行なった。

周波数特性をそのままFIRフィルタにする

• https://nbviewer.jupyter.org/github/cho45/pseudo-audio-signal/blob/master/docs/01-complex-to-real-fir.ipynb

FIR フィルタは周波数特性がわかっていれば IFFT で作ることができる。ほぼ何も考えずに作れる。

最初は対称をつくらず IFFT して、最後に実数だけとるのを作った。

実数 FIR フィルタとして設計する

• https://nbviewer.jupyter.org/github/cho45/pseudo-audio-signal/blob/master/docs/02-real-fir.ipynb

フィルタを左右対称にすればほぼ実数フィルタになるはずだが、低域の減衰が急峻すぎるせいかこれでも虚数が出てきてしまう。しかたないのでこのまま虚数を捨てて実数フィルタとして評価した。

まぁまぁうまくいくけど、かなり重くなってしまう。そして、それなりに G.227 の特性から誤差が発生して気持ちがわるい。FIR なので次数を増やせばそれだけ近似はできるが、どんどん重くなっていく。

なお FIR フィルタを WebAudio で使いたい場合は、ConvolverNode を使えば良い。

アナログフィルタを双一次変換 (bilinear transform) してIIRフィルタを得て FIR フィルタで補正する

↑補正なし↓補正

• https://nbviewer.jupyter.org/github/cho45/pseudo-audio-signal/blob/master/docs/03-iir-fir.ipynb

アナログフィルタ(周波数連続という意味)からデジタルフィルタ(離散という意味)をつくる方法の一つに双一次変換がある。scipy で簡単にできるので、これを試す。

今回の場合、アナログの伝達関数はわかっているので、この規格に書いてある伝達関数を双一次変換してIIRフィルタの係数を得る。つまり以下を変換してデジタルフィルタを得たい。

なぜ微妙に括弧がついてるのかわからないが、結局これは次数ごとに書きなおすと見なれた以下の形になる。ほぼ scipy.signal.freqs などが受けとる形になっている。4次。

ただ、p が なので、これを角周波数 をとる関数に変えたい。

python で上記通り係数計算して、signal.bilinear() に渡してあげると、デジタルフィルタの係数になる。ただ、双一次変換は周波数歪みが起こるので、完全にアナログフィルタの特性と一致するわけではない。

こういう場合どうするのかよくわからなかったが、次数の少ない FIR で容易に補正できそうだったため、アナログフィルタの周波数特性との差分をとって補正する FIR フィルタを追加で設計する。

IIR フィルタを WebAudio で使う場合は IIRFilterNode を使えば良い。feedForward に分子 feedBack に分母の係数を渡せば動いてくれる。

ということでできたのが冒頭にリンクしたレポジトリとなる。https://github.com/cho45/pseudo-audio-signal