GitHubからクローンしたKeiths' SDR（K7MDL版）のバージョン（特定のバージョン番号はありません）を、2022/04/09時点のクローンから2022/10/23時点のクローンに更新しました。
そして、実機を用いた実験によって、信号処理連鎖のサンプリング周波数をやっと確認できました。
Keiths' SDR（K7MDL版）の更新
設定ファイルの修正
コンパイルを行う前に、以下の設定ファイルを自環境に合わせて修正しました。
- SDR_RA8875/makefile：パスの修正。
- SDR_RA8875/.vscode/arduino.json：COM番号の修正。
- SDR_RA8875/.vscode/c_cpp_properties.json：パスの修正。
- SDR_RA8875/.vscode/settings.json：パスの修正。
- SDR_RA8875/.vscode/tasks.json：パスの修正.
なお、クローンした設定ファイルにおけるArduinoのバージョンは1.8.15で自環境と同じでしたが、Teensyduinoのバージョンは1.56で自環境の1.54より上がっていました（現時点で最新版は1.57）。取りあえず、Teensyduino 1.54のままでコンパイルを行いました。
make の結果
前のバージョンでは、「glcdfonts.cファイルが重複している」旨の原因不明の（Mike OMも原因不明としていた）エラーが出たため、glcdfonts.cファイルを移動して隠す必要がありました。今回の最新バージョンでは、逆に「glcdfonts.cファイルが無い」旨のエラーが出たため、移動していたファイルを元のフォルダに戻しました。根本原因が何であったのか、そしてその原因は取り除かれたのか・・・は不明ですが、新しいバージョンではglcdfonts.cファイルにまつわるエラーは無くなりました。
TyCommanderツールを用いてhexファイルをTeensyにアップロードすると、問題なく起動しました。
前回は確認に至らなかったタッチボタンの動作も確認できました。タッチジェスチャを見ているため、緩慢にタッチするのでは反応せず、メリハリのあるタッチ＆リリースが必要であることが分かりました。
Serial.print メッセージ
しかし、Serial.printメッセージが出力されません。ソースコードを精査すると、Serial.printメッセージは"DEBUG"ディレクティブによって抑制されていることが分かりました。
//#define DEBUG //set to true for debug output, false for no debug output
"DEBUG"定義をアンコメントすると次のSerial.printメッセージが出力されました。
このバージョンの開発時点でMike OMはRFフロントエンドとしてRS-HFIQを使用しているため、RS-HFIQのコマンドインタープリタがアクティブになっています。
なお、I2S ScannerがタッチコントローラFT6206を見つけた旨の報告をしていますが、これはFT5206の間違いと思います。
I2C device found at address 0x38 (RA8875,FT6206)
PJRC社のライブラリからインポートしたと思しきソースコードに、デバイス名「FT6206」はハードコーディングされています。FT6206も実在するため、同じアドレス0x38を割り付けたディスプレイが実在するのかもしれません。
Serial.print メッセージの復活により、懸案だった信号処理連鎖のサンプリング周波数を確認するための実機を用いた実験の準備が整いました。
サンプリング周波数の確認
情報収集
keithsdr@groups.io フォーラムのスレッド「Re: Iowa Hills Hilbert Filter Designer」にKeith OMより次の投稿がありました。
The only difference is we clock at 48kHz ..
Keith OMはKeiths' SDRのHilbert Filterをサンプリング周波数48kHzで設計したことを示しています。
今回のKeiths' SDR（K7MDL版）更新バージョンでは、ソースコードのサンプリング周波数設定箇所は次のようになっていました。
//float sample_rate_Hz = 11000.0f; //43Hz /bin 5K spectrum
//float sample_rate_Hz = 22000.0f; //21Hz /bin 6K wide
//float sample_rate_Hz = 44100.0f; //43Hz /bin 12.5K spectrum
float sample_rate_Hz = 48000.0f; //46Hz /bin 24K spectrum for 1024.
//float sample_rate_Hz = 96000.0f; // <100Hz/bin at 1024FFT, 50Hz at 2048, 40Khz span at 800 pixels and 2048FFT
//float sample_rate_Hz = 192000.0f; // 190Hz/bin - does
前回は96KHzでしたが、今回は48KHzにダウングレードされています。スペクトルウオーターフォールの表示に必要なFFTとの絡みによる適正化ではないかと推定しています。これで、Keith OMによるHilbert Filter設計のサンプリング周波数48kHzとの齟齬は解消されています。
コーディックSGTL5000は96KHzが仕様上の上限ですが、オーバークロックの可能性が追求されたようです。そのため、192KHzまでサンプリング周波数を変更した形跡がソースコードに残っています。本来、サンプリング周波数を変更したらHilbert Filterを設計し直す必要がありますが、それが放置されていたようです。サンプリング周波数が96KHzに設定されていた前回、Hilbert Filterのシミュレーションで帯域が2倍に拡大してしまったのは、それが原因と推定しています。
実機による確認実験の準備
ソースコードに設定したコーディックのサンプリング周波数（sample_rate_Hz）が信号処理連鎖起動のサンプリング周波数と一致しているかどうかを確認するために、下記図の黄色ハッチのコードをDMA割込みのISR（Interrupt Service Routine）に追加しました。
経過時間は、設定した定数の「サンプリング周波数」（48KHz）と「ブロックサイズ」（128ワード）、および逐次計数するサンプリング回数から計算します。経過時間2秒毎にSerial.print メッセージを出力します。
設定した「サンプリング周波数」とDMA割込みで起動する信号処理連鎖のサンプリング周波数（正確には、サンプリング周波数／ブロックサイズ）が一致すれば、Serial.print メッセージ出力のインターバルが設定の2秒と一致するはずです。
実機による確認実験の結果
Inputオブジェクトを宣言した時点で、コンストラクタによってコーディックは初期化されます。あとは何時にDMA割込みを許可するかに依存しますが、早いタイミングでサンプリングを開始するようです。エンコーダ確認中に最初の「2秒経過」メッセージが出力されています。
コマンドラインインタープリタのコマンド待機状態になると、連続して「2秒経過」メッセージが出力されます。これを測定すると、正しく2秒間隔であることが確認されました。
すなわち、設定した「サンプリング周波数」によって、サンプリング周波数／ブロックサイズの周期で信号処理連鎖が起動されていることが確認されました。
