■ ソフトウェア変更
上記問題点の中には明らかにソフトだと言えるものもありますが、ノイズや波形変動はハードかソフトか判断がつきません。
外から見ているだけではよくわからないので、いろいろ実験するためにトップメニュー内に DEBUG を追加し、その中でいろいろ設定を変更できるようにしました。
どうして DEBUG メニュー内の各設定項目を追加したのか（追加する必要性にかられたのか）を説明すると NanoVNA のハード・ソフトの説明にもなりますので、まずは DEBUG メニューに入っている項目を順番に説明します。
DEBUG メニューには以下の項目が入っています。
・FETCH SIG
・WINDOW FN
・DSP DELAY
・OFFSET FREQ
・CH0(TX) OUTPUT
・FETCH SIG
NanoVNA は mixer(SA612AD) を S11用(U7)、S21用(U8)、REF用(U6)の 3 つ持っています。
それぞれの mixer で周波数変換して IF(オーディオ帯域)に落とし、AUDIO CODEC(U9 TLV320AIC3204)で AD 変換します。
これらを IF_S11、IF_S21、IF_REF とすると、
S11(CH0) = IF_S11 / IF_REF
S21(CH1) = IF_S21 / IF_REF
という計算をしています。
FETCH SIG メニューではこの計算をする前の生データを見ることができるようになっています。
AMPLI を選択すると、
CH0 = IF_S11
CH1 = IF_S21
REF を選択すると、
CH0 = IF_REF
CH1 = IF_REF
が CH0、CH1 として画面に表示されます。
ハードウェアの特性評価に使います。
・WINDOW FN default=HANN
NanoVNA は IF周波数=5kHz で、AUDIO CODEC(U9 TLV320AIC3204)は FS=48kHz なので、5kHz の歪成分のうち 10kHz、15kHz、20kHz は ADC 帯域内になります(ナイキスト周波数 24kHz 以上の歪成分は TLV320AIC3204 のデジタルフィルターで除去されます)。
dsp.c での信号処理では -5kHz の周波数変換をしたのち、48 サンプル分のデータを加算してゼロ周波数成分を検出します。 これは矩形窓になります。
-5kHz の周波数変換によって、負の周波数成分や、10kHz、15kHz、20kHz の歪成分も周波数変換され、ゼロをセンターに 5kHz おきに正負の周波数にスプリアスがある状態になります。 48 サンプル分の加算をすると 1kHz おきに null 点がある sinc 関数の周波数特性になりますので IF周波数が正確に 5kHz ならスプリアスはすべて null 点に一致し除去されるので問題ありません。 しかし、GHz オーダーで正確に 5kHz の周波数差をつくれるのか？、PLL の揺れはないのか？ といった疑問があり、周波数がずれた場合にスプリアスを軽減するため HANN 窓関数を適用できるようにしました。 他からのかぶり（電源ノイズなど）にも有効です。
なお、HANN窓 の ENBW(等価雑音帯域幅) は 1.5 なので矩形窓(ENBW=1)より S/N は 1.8dB 悪くなります（白色雑音の場合）。
RBW の設定を狭くした場合、加算回数を RBW=300Hz時 48x3回、RBW=100Hz時 48x10回 ... と多くしていて、これで S/N が上がりますので HANN窓での 1.8dB の悪化分は気にすることはないでしょう。
ちなみに HANN窓 のテーブルだけで 9600 バイトも使っています。 FLASH が足りなくなったら三角窓が良いかもしれません。 ENBW=1.333 ですし、簡単に計算できるのでテーブルがいらなくなります。
(2020/05/20追記) mixer での歪ではなく 3 倍高調波ミキシングの方がレベル大きいかもしれません。 たとえば 100MHz では PLL は RF=100MHz、LO=100.005MHz を出力しています。 これが 3 倍高調波の 300MHz では RF=300MHz(100MHz*3)、LO=300.015MHz(100.005MHz*3) と 15kHz の差になりレベルは基本波の -10dB と大きいです。
・DSP DELAY
PLL(U5 SI5351A) の設定を変更したとき、PLL が安定するまで一定期間 AUDIO CODEC(U9 TLV320AIC3204)からきた信号を使わないで読み飛ばすようになっています。 48 サンプル(1ms)を 1 単位として何回読み飛ばすのかを細かく設定しているのですが、それが本当に充分なのか調べるためにこの項目を追加しました。 DELAY を増やしたとき波形のおかしなところが変化するかどうかで DELAY が足りているかどうかわかります。
また、ぎりぎり NG のときは、窓関数を HANN窓にすることで、時間軸上で最初に近い方のデータが使われなくなり、改善することもあります。
この機能を使って、最適な DELAY 値を探しプログラム修正しました。
・OFFSET FREQ default=12kHz
先に説明した IF 周波数と同じになります。 PLL に周波数設定する際、RF 信号の周波数に +offset した周波数を LO 信号に設定しています。 300MHz 以上では高調波を使いますので、例えば RF=500MHz の時、LO=500MHz+offset となりますが、実際に PLL に設定する周波数は RF=500MHz/3、LO=(500MHz+offset)/5 となります。
先に説明したように IF=5kHz にしている意味がわからないため、いろいろ設定できるようにしました。 12kHz だと高調波がナイキスト周波数内に入らないし、周波数変換しても負の周波数成分はナイキスト周波数になるので良いと思うのですが...
・CH0(TX) OUTPUT
NanoVNA 本体の CH0 から出力される RF 信号を OFF にする設定です。
CH0 を終端して方向性を見る時や CH1 への漏れを見る時、見えているのが RF 信号由来なのか他からのかぶりなのか分からなくなった時や、雑音レベルを見る時に OFF にします。
実際に OFF する信号は PLL の ch0 出力で、これは SWR bridge につながって CH0(TX) 出力になると同時に REF用 mixer(U6) にもつながっています。 OFF にすると REF mixer への信号も OFF になるので、FETCH SIG で生データ( AMPLI または REF )を選びます。
ハードウェアの特性評価に使います。
・その他ソフトウェア変更点
・Progress bar 追加 ： sweep に合わせて 10 測定点ごとに伸びていきます。
・メニューに色付け ： サブメニューがあるか、CANCEL か、など種類によって色を変えました。
・トップメニュー ： トップメニューがわかりやすくなるよう項目名にドットを付けました。
・BACK ボタンの間隔 ： BACK のとき 1 pixel ボタン間隔を拡げました。
・FONT 変更 ： 読みやすくなるようフォント変更（完全に個人の好みの問題ですね）
・TLV320AIC3204 MCLK を 26MHzにする： 周波数スイープのたびに SI5351 再設定するのを止め、常に 26MHz を出すようにしました。
・SWR bridge 変更点
なるべく SA612 入力信号レベルを上げるためインピーダンスを上げました。
R20、R21 を大きくすると SA612 の入力容量(3pF) とでできる LPF のカットオフ周波数が低くなりますが、実際に SA612 に入いる信号レベルはどの周波数でも大きくなります。
R11 と R12 の接続点に 10mm ぐらいの UEW 線の片側を付けて、UEW 線のもう片側を R11 や R12 の近くに動かしてみると方向性が良くなるところが見つかるかもしれません。 残念ながら私の白 NanoVNA では、良くなるところがありませんでしたのでつけていませんが。
・RX PORT 変更点
なるべく広帯域に入力インピーダンスが 50Ω に近くなるよう -6dB π型 ATT にしました。
SA612 IN-B は IN-A と同じインピーダンスになるよう 27Ωでバランスを取りました。 変更したときはこの方が雑音特性が良かったのですが、そのあと下記の電源デカップリング強化したので単純に GND に落とすだけでも良いかもしれません。
・mixer(SA612)の電源 変更点
+5V には SW REG のノイズが盛大にのっています。
RC フィルターの抵抗は SA612 の電源電圧が落ちすぎないギリギリの値にしました。 実測 4.63V です。
デカップリングに 100pF しか入っていないので 0.1 をパラ付けします。
高周波を扱う回路ではデカップリングに 0.1 と 100pF をパラ付けするのは普通ですが、100pF だけというのは初めてです。 これを回路図で発見したときは目を疑いました。
・その他
他にも、GND を強化したり、シールド板を入れたりしてみたり、フェライト板をいれたりしてみたのですが、いまいち効果がはっきりしませんでした。
2022/11/27 capture のバグ修正しました。（ファームウェアはこちら）
NanoVNA や NanoVNA_V2 のスクリーンキャプチャーするソフト NanoVNAcapture をつくりました。
これを使って NanoVNA のスクリーンキャプチャーのテストをしていたのですが、時々画面途中までデータ転送したあとハングするという症状がでました。
数日、コードを追ってやっと原因がわかりました。
ili9341.c の中の ili9341_read_memory という関数で VRAM の内容を読むのですが、SPI の DMA を開始する際、送信、受信の順になっています。 送信で 8bit 送ると 1バイト受信するので、それまでに受信 DMA が起動していないといけませんが、送信開始のあと割り込みが入ると受信開始が遅れ、そのあとの受信 DMA 完了待ちでハングしているようです。
対策は簡単で、受信 DMA 開始してから送信 DMA を開始するようにするだけです。
これで基本的にキャプチャーは OK になったのですが、使っていると不満も多いのです。
2022/12/09 トレース描画を上書きに変更（ 対応ファームウェアはこちら ）
NanoVNAcapture にカラーマップ機能を追加しました。
トレースの重なったところが前のデータと OR（一種の加色混合？）にしていて汚いので上書きに変更しました。
詳細はこちら