|
Namazu for hns による簡易全文検索 詳しくは 詳細指定/ヘルプを参照して下さい |
||||||||||||||||||||||||||||||||||||||||||||||
2009年09月29日(火) 旧暦 [n年日記] [更新:"2009/09/30 11:13:05"]#1 [無線] 同軸線の長さ (測定用)
同軸線に、特性インピーダンスと異る負荷をつないだ場合に、
給電側では、どのようなインピーダンスになるか、という話があります。
これは Q マッチで知られているように
給電側 in 負荷側 out 特性インピーダンス zとすると、 1/4 波長毎に in * out = z^2の関係になります。このことを利用すると、同軸線を 1/2 波長または、その整数倍の長さにしておくと、 給電側で、負荷側のインピーダンスが再現することになります。 ここに書いたことは、「そうすると減衰が少ない」というようなこと ではなく、「アンテナの特性を手元でそのまま観察出来る」ということ だけのことですが
同軸の長さ (短縮率 66.7% の場合) 1.810 55.2m 3.510 28.4m 7.015 14.25m .. 28.5m 50.5 1.9m 144.1 0.69m実際には、これらの整数倍よりも少し長めに切って同軸コネクタを片側 だけ半田付し、それをインピーダンスメータにつないで、利用する周波数 で ∞ になっているかを確認します。 もし低めだったら、比率を計算して その長さを切断します。 ∞ は確認し難いということであれば 1/4 波長に換算して 0 Ω 点を見るのも一つの方法かと思います (先端が短絡出来れば、1/2 波長で 0 Ω になります) で、100m 単位で買ったりしますが、60m くらいの方が良いなと思う訳です。 100m で買った時に、そのままコネクタを付けて長さを見ると、ちょうど 150m の波長になっていることを確認したこともあります。 1.810MHz の 55m はちょっと長いので、10m くらいまでで、出来るだけ短く、 というのも一つの方法かも知れません。 正直なところ、 「こんなこと常識」なのか、「普通そこまでやらない」なのかを知りたいところです。... 測定する時だけそのようにして、実運用は都合の良い長さで使う、 というのも実際的な気がして来ました。つまり測定用の同軸を作っておく訳です。 (でもそれは、上げ下げが容易な場合かな) (後日談): 100m 買って来て 55m 測るのは結構大変なので、ヒロ電子さんに 電話で聞いて見たら、60m でも買えるそうです。その時には、 ヒロ電子さんで測るので、長さはそれほど正確には切れない、とのことでした。 でもおおよその長さが分っていれば、後はインピーダンスメータで 何とかなると思います。実は 58m というのを注文してしまいました。 55.2m の 1.810MHz 用です ( つっこみ )
2009年09月03日(木) 旧暦 [n年日記] [更新:"2010/01/01 17:21:41"]#1 [zsh] login shell を zsh にしようと
login shell を zsh にしようとして色々な機械で pkg_add とか make package
とかをしている。中には 2005 年頃に作った、多分 bulk build のものを
pkg_add したものもある。
それで、4.99.3/powerpc という機械だけは、pkg_install を作る時に、
次のようになって、先に進まない。
audit.c: In function 'fetch_pkg_vulnerabilities': audit.c:321: error: 'struct url' has no member named 'last_modified' audit.c:333: error: 'FETCH_UNCHANGED' undeclared (first use in this function) audit.c:333: error: (Each undeclared identifier is reported only once audit.c:333: error: for each function it appears in.)全然解決方法になっていないけれど、 思い直して野良ビルドというのか configure; make をしたら、何なく出来た。 158 21:17 tar zxf $DIST/zsh-4.3.4.tar.bz2 159 21:17 cd zsh-4.3.4/ 160 21:17 ./configure 161 21:20 gmake 162 21:27 sudo make install ＠ net/libfetch:
(2010/01/01 追記) 上記問題は pkg_install を作る時に参照する
libnbcompat の方で起きているはずだが、更に、これは
pkgsrc/net/libfetch の版が古いこと
による(らしい)。それを cvs update することにより解決した。
cd pkgsrc/net/libfetch cvs update -dPA cd ../pkgtools/libnbcompat/ sudo make package ( つっこみ )
#2 [機械] Mac OS X の VMWare Fusion での NetBSD の時計
Mac OS X の VMWare Fusion で動いている NetBSD/amd64 5.99.15
だけれど、日付が 2009/08/30 になっている。これって独立なのかな。
Sun Aug 30 07:48:18 JST 2009Mac OS X の方の時計は合っている。試しに date で合せて見たが、 すぐには Mac OS X の方には伝わらない(当然か ?) 起動する時に時刻を拾えないと いうことか (再起動したばかり)。もしかして dmesg を吊しておいた方が良い ? 実は全部で 8GB しかないところで /export に 2GB 程度のところで (そのことを忘れていて) src とか pkgsrc を展開したら、inode が足りなくなってしまった。VMWare 的には disk は後からでも増やせるらしいが、NetBSD の方が対応出来るかな .. 無理 ? src は単に時間を測りたかっただけなのだけれど。(20090907 追記) 時計は眠り(sleep)から醒めた時に NetBSD 側の方が合せてくれない のが問題、ということらしい。 ( つっこみ )
|
最近の日記 2024年07月03日 ・kicad oddity 2024年05月08日 ・comparison on ./buildsh tools 2024年05月06日 ・py-setuptools (python 3.11.9) ・make release took 1 hours and 10 min ・qemu invocation for 10.99.10 2024年05月05日 ・Windows 10 version ・serial connection ・bc bench 2024年05月04日 ・Trial on 10.99.10 ・another version (later trial) to succeed | ||