前につくったアッテネータを測ってみる 高周波用アッテネータを作ってみる | tech - 氾濫原

NanoVNA だと 300MHz 付近にデコボコがあるようにみえますが、これはおそらく 0.5〜900MHz でキャリブレーションした状態で、0.5〜500MHz の範囲を見ている (校正の補完を使っている) せいと思われるので、再度この範囲でキャリブレーションしなおしてみます。(300MHz を超えると高調波モードを使うので段差ができやすい)

消えました。

1. トップ
2. tech
3. NanoVNA の測定メモ

#!/usr/bin/env ruby

require 'pp'

D = Struct.new(:sec, :size, :name)

target = ARGV.shift

sram = `arm-none-eabi-objdump -t '#{target}'`.chomp.split(/\n/).
	select {|l| /\.bss|\.data/ =~ l }.
	map {|l|
		sec, size0 = *l.split(/\t/)
		size, name = *size0.split(/\s+/) if size0
		D.new(sec, size.to_i(16), name)
	}

total = sram.map {|i| i.size }.reduce {|r,i| r + i}

sram.sort_by {|i|
	i.size
}.each { |i|
	puts "% 3d%% % 10d %s" % [i.size.to_f / total * 100, i.size, i.name]
}

puts "total: %d bytes" % total

こういうのを書いて

$ foo  build/ch.elf

と実行すると

...
  0%        124 SD1
  0%        132 USBD1
  1%        192 dump_buffer
  1%        208 ch_idle_thread_wa
  2%        384 SDU1
  2%        384 rx_buffer
  4%        640 waThread2
  6%        960 waThread1
  7%       1064 impure_data
 10%       1616 measured
 10%       1616 trace_index
 13%       2048 spi_buffer
 30%       4552 current_props
total: 15081 bytes

こういう感じである程度わかる。

1. トップ
2. tech
3. SRAM 使用量のカウント

avstack.pl である程度できる。

avstack.pl の $objdump を適当にアーキテクチャをあわせて変えておく。

my $objdump = "arm-none-eabi-objdump";

このうえで、GCC のコンパイルフラグに -fstack-usage をつける。そうすると .o の同じ名前で .su というファイルができる。

asm から変換されたファイルとかでは .su は作られないので、.su がない .o を除外して、avstack.pl の引数にすべて与える。

$ ./avstack.pl build/obj/Font5x7.o build/obj/adc.o ...
  Func                               Cost    Frame   Height
------------------------------------------------------------------------
> Thread1                             792       20       16
  sweep                               772       84       15
  ui_process                          688       12       14
  ui_process_touch                    676       12       13
  touch_pickup_marker                 664       52       12
  drag_marker                         612       44       11
  ui_process_lever                    608       12       12
  ui_process_normal                   596       28       11
> menu_marker_sel_cb                  580       12       11
...

すると、使用率順に表示してくれる。> マークはどこからもそれが呼ばれていない関数、つまり呼び出し元と思われるもの。

Cost は最大スタック利用量。Frame は該当関数のスタック利用量 (コールコストを含む)。Height は最大コールスタック数。

Height * コールコストが意外とでかい。

1. トップ
2. tech
3. スタック使用量の静的解析

NanoVNA という非常に小型で低コストのスタンドアロン VNA (ベクターネットワークアナライザ) がにわかにグローバルで流行している。VNA は高周波回路設計・実装に必須の測定器のひとつだが、もともと非常に高価なため、個人でちゃんとしたメーカーものを所有することはまずない。たとえ低価格と言われるものでも数万円〜だった。それがさらに低コストで使える性能であると評判なので、VNA の民主化だというおもむき。

NanoVNA の設計のオリジナルはTT (ttrftech) さんという日本語でブログも書かれているかたの設計のもの。自分もハムフェアかMaker Faireかで実機をちらっと見たことがある気がする (もしかするとVNAではなく後続プロジェクトのSDRのほうだったかもしれないが)。少量のキット化までされていたが、これを hugen79 さんが手を加えてしPCBアートワークなどをやりなおして売っているようだ (もともとPCBの設計はソースに含まれてない)。ファームにも独自のコードが入っている。

aliexpress などでは、hugen79 版を元にした (おそらく) さらにこれのクローンと思われるものが非常に安価に売っている。hugen79 レポジトリの README では、粗悪なものがあって性能が出ないことがある (ミキサーまわりに齟齬があるらしい？ シールドの有無など違いもある) けど、本来の性能じゃないから買う側でちゃんと調べろや、ということが書いてある。

自分には技術レベル的にVNAは必要ないが、VNAとして使わなくても、これはそのままアンテナアナライザーにもなるわけで、もはや自作するより良さそうだ。

ちなみに2ポートのうちCH0だけ反射を計測できるので、繋ぎかえて測定してマージしないと s2p 相当の結果を得られない。(S11 S21 を得て、繋ぎかえて S11、S21をS22 S12 に読み替える) 入出力が全く同じで対称の受動コンポーネントなら S22=S11 S12=S21 としてもまぁいいのかも (VNA使ったことないので温度感がわからない)。

1. トップ
2. tech
3. 中華 NanoVNA とコードのメモ

• PR https://github.com/ttrftech/NanoVNA/pull/8/files (マージしてもらいました)

NanoVNA の実装を軽く読んだ感じでは画面のキャプチャをとる機能がなさそうだったので、実装を書いてみた。測定器はとにかくキャプチャをとりたいし、せっかく綺麗にレンダリングされているので、できれば保存したい。

中華 NanoVNA とコードのメモ | tech - 氾濫原 にも少し書いたけど、画面描画はメモリ消費を抑える実装になっており、MCU 側で画面バッファを全て持っているわけではない。

そこで、使っているLCDドライバの ILI9341 のデータシートを見てみたところ、ドライバ側で持っているメモリ内容を SPI 経由で読み出せそうであったので、そちらを利用した。

メモリ内容を読めるといっても、MCU 側のメモリ容量的に全てを一気に読むことはできないので、一部読んではUSBに流し、一部読んではUSBに流すというのを繰り返す実装にした。

1. トップ
2. tech
3. NanoVNA に capture コマンドを追加してみる