Archive for 7月, 2015

思わぬバグに慌てた一日だった。今回のは結構広範囲に影響するので、気が重い。

思えば、去年、それまで動いていたテストプログラムが失敗するようになったのは、このバグによるものだったようだ。いつもと動きが違うのだから、時間を掛けて原因を調べるべきだった。それを、短時間で何とかしようとして小手先の誤魔化し(失敗しないようにテスト条件を変えた)で済ませたのが悪かった。疲れた。

  •   0
  •   0

昨日の朝、何の気なしにコンビニのレジの奥を見て驚いた。煙草の種類(番号が付けられている)が200を超えていたのだ。あんな狭いところにそれだけの数が置けることにも、一店でそんなに多くの種類に対応していることにも、そして、煙草の種類がそんなに(それ以上)あることにも。

同じ煙草でも、大きさ違いが数種類あるようだったから、実際には百程度になるのかも知れないが、それでも多い。果たして店員さんは、全部の名前が分かるのだろうか。客も、あんなに細かい棚から希望の煙草の番号を見分けているのだろうか。そういう努力を、もっと有益なことに使えばいいのにと思った。

  •   1
  •   0

先に書いたように、全く気のせいと思いつつも、スピーカー接続用の丸端子をアンプの出力端子によりフィットさせるため、小さくて薄い物に替えた(厚さ: 1mm → 0.8mm)。Amazonで166円(送料無料)だったのにも、後押しされたような気がする。

実物を見ると、圧着部の筒が随分細くて(直径2mmくらい)、本当にケーブルが入るのかと心配したが、最初に使ったY端子と同じ径だったので、入らないことはないことが分かり、替えてみることにした。なお、薄くはなったのだが、残念ながらそれほど柔らかくなったようには感じなかった。

今回は半田でなく圧着にした。径は丁度良かった。ただ、圧着工具が安物なので、力いっぱい握ってもちゃんと圧着されているのか分からず、心許ない。もう少しきつく締めたい感じだった。一応、引っ張っても抜けなかったのだが、後日、圧着工具を買い替えて付け直したくなるかも知れない。。。

IMG_2179_サイズ変更-1

小さい端子にしても、まだアンプの背面に余裕がないので、端子の直線部分を手前に90°折り曲げた(本当は良くないらしい)。

IMG_2181_サイズ変更

IMG_2180_サイズ変更-1

音を聴いてみると、低音は問題ないが、高音が強くなった気がする。一番最初に聴いた時の、耳が痛くなった感じに近い。疲れか気のせいなのか、今一つ圧着や接触が良くないのだろうか。それとも、逆に接触が良くなったせいだろうか。後で特性を測定してみよう。

てな訳で、今回はちょっと失敗だったかも知れない。

(7/30 20:48) やはり、音が少しおかしい。今日は何となくくぐもった感じで、耳が少し痛い。基本的には悪い音ではないのだが、「あと少し」という感じだ。圧着が良くないのかも知れないので、ケーブルの先端部分に半田を流し込んで、丸端子との接続を確実にした。

IMG_2186_サイズ変更

聴いてみると、何となく改善した気がする。馴染みの音に戻った気がする。ただ、寝不足のせいか、耳の調子は悪い感じだ。

(7/31 19:38) 今朝、音がおかしかった原因を推測した。圧着不足による接触不良で導通特性が非線形になって高調波ひずみが発生し、特に高域でひずみが顕著になったせいではないだろうか。それで高音が強く感じたり耳が痛くなったのではないだろうか。これを測るのは困難だし、もう半田付けしてしまったので、検証のしようはない。

  •   0
  •   0

自分でも理由が分からないのに、異常に何かにこだわることがある。今、二つのことにこだわっている。

一つは、通信帯域制限プログラム(の制御部)の累計送信データ量取得方法、もう一つは、アンプとスピーカーを接続する端子だ。

通信帯域制限プログラムはもう完成の域なのだが、どうしてか、累計送信データ量取得にawatchを使わない方法を模索している。前に書いたようにnetstatコマンドではなぜか値が4倍になる。値を4で割ればいいが、それが正しい確証はないし、0に戻るのが4倍速いし、休止からの復帰時に0になる問題もある。

そこで、日がな検索しまくったところ、前にも書いたwmicコマンドでWin32_PerfRawData_Tcpip_NetworkInterfaceというクラスのBytesSentPersecという値を取得すればいいことが今日分かった。名前やドキュメントからは送信速度(毎秒の値)のように思えるのだが、実際の値を見ると累計値のようだ(MSのドキュメントに書いてないので、そう信じるのにはちょっと勇気が要る)。そして、これは4倍にはなっていない。ただ、休止からの復帰時には0になってしまう。そこで、送信も受信も0なら再取得するようにすることを考えている。別のクラスの別の値(NetConnectionStatus)を取ればネットワークインタフェースの状態を取得できるのだが、取得に時間差が生じるため、正確な状態は取れないと考えたのだ。

素直に考えれば、送信データ量と状態を同時に取れるawatchコマンドを使うのが最適なのだが、一個でもサードパーティーのコマンドを減らしたいという大義なのだろうか、純正のwmicコマンドが使いたくてしょうがない。そんなことに大きな意味はないのに、本当に不思議だ。今まで知らなかったwmicコマンドを活用したいという、単なる技術的な興味なのかも知れない。

次に、アンプとスピーカーを接続する端子ももう完成しているのだが、実は、丸端子の板厚が厚い(1mm)ため、アンプの端子にフィット(密着)していないのではないかと心配して、小さくて薄目(0.8mm)のものを注文して今日届いたのだ。まだ開けてないので結構楽しみだ。ちなみに、調べたところでは、板の強度は厚さの自乗あるいは三乗に比例するそうなので、1mmから0.8mmになっただけでも、約36%~50%程度柔らかくなるはずだ。果たして目論見どおり行くのだろうか? そもそも、今の丸端子がアンプの端子にフィットしていない証拠すらないし、音や特性が悪くなってなどいないのだ。それなのに、ここまで凝るのはやっぱり理解できない。

まあ、ひとことで言うと、マニアなのだろう。

  •   0
  •   0

先日から作っていた通信帯域制限プログラム(の制御部)。できたとは書きつつ、細かく動作を確認すると、うまく動いていない部分があって、その対処に結構苦労した。今回は、それらについて書く。

1. 休止後の復帰の検出

復帰直後は、ネットワークアダプタの累計送信データ量が0になる。それをそのまま使うと、制御が誤動作してしまう。0だったら少し待ってから再取得する手は簡単で有効なのだが、本当に0の場合にも再取得してしまうし、何より美しくない。それで、どうにかして復帰したことを検出しようとしたのだが、うまく行かなかった。

ところが、原点に立ち返って、awatchが出力する情報を調べたところ、復帰直後はネットワークアダプタの状態が「非稼働」になっていることが分かった。そこで、累計送信データ量を取得する前にアダプタの状態を確認して、「非稼働」の場合には少し待ってから再取得するようにすることにした。それで、この問題は解決した。

2. ネットワークアダプタの累計送信データ量が0に戻る件

累計送信データ量は32ビット整数に保存されるので、約4Gバイトのデータの送信ごとに0に戻る。それもそのまま使うと、制御が誤動作してしまう。これは、前回よりも値が小さくなっていたら、累計送信データ量に4Gバイトを加算するようにすればうまく行った。

3. 累計送信データ量が32ビットに収まらない。

上では「4Gバイトを加算する」と書いたが、整数でバイト単位の演算を行うとオーバーフローしてしまう。そこで、累計送信データ量をMバイト単位の浮動小数点数で保存・処理するようにした。

4. 再起動後の累計送信データ量の処理

2に似ている問題で、最初は2と同じ処理でいいと思っていたのだが、そうではなかった。プログラムの稼働中に再起動した場合には、(累計送信データ量に4Gバイトを加算するのではなく、)再起動前の累計送信データ量を再起動後の累計送信データ量に加えるようにする必要がある。

ここで、再起動したことを検出するのにも苦労した。Windowsでは、起動してからの稼働時間を簡単に取得できないためである。そこで、再起動の可能性がある場合(累計送信データ量が前回よりも小さくなっていた場合)には、wmic nteventコマンドでWindowsのイベントログから最後の起動日時を取得して、それが前回の処理日時以降だったら、再起動したと判定するようにした。

いろいろ苦労はしたが、今まで知らなかった知識が得られておもしろかった。

おまけ(デバッグ中の制御プログラムの画面):

tlim-20150727-1

たまに(送信量制限を超えた場合)ダイアログも出るが、基本は文字ばかりで味もそっけもないw 今でも、TVや映画でのハッカーの映像はこんなのなんだろうか?

  •   0
  •   2

先日からAOSBOX Coolを試しているのだが、たった一週間でいろいろな問題が噴出してきた。

  1. スタートパックのアカウントでは、「独自の暗号化パスワード」の指定ができない(トライアルではできる)。問い合わせたが、一週間経っても再現・解決せず。やる気があれば、すぐに再現できると思うのだが。
  2. PC側で削除したファイルも、サーバ側には残り続ける。それでいいこともあるが、混乱の元になることがある。管理も面倒そうだ。
  3. PCの入れ替え(再インストールなど)ができない。その場合、システムだけ替えたのに全体をバックアップし直しになる。これは大変痛い。
  4. ファイルの復元に時間が掛かり過ぎる。約3-5時間掛かるというが(実際、数十分では復元が開始すらしなかった)、一体何をしているのだろう。テープだってそんなに掛かる訳がない。人がHDDなりテープをどこかに取りに行くのか? それを待つ間はPCを待機させなくてはならないので、不便。
  5. バックアップデータをいい加減に考えているフシがある。1バックアップ/アカウントなので、新たなバックアップを始める時には古いバックアップの削除をするのだが、それ以外に「凍結」というオプションがある。こうすると、古いデータがサーバに残り続けるので、何となく嫌な感じがする。それに、サーバのストレージは無料ではないのだから、みんなが凍結ばかりしていたら、後で問題が起こるはずだ。
  6. バックアップ対象ファイルのスキャンが重くて遅い。
  7. 設定変更後に、プログラムがハングすることがある(数回あった)。その時は強制終了しないと駄目で、何ともお粗末。
  8. その他、プログラムに細かいバグが多い(例: 表示は「バックアップ停止中」なのに、バックアップが継続している)。ちゃんとテストをしていないのかも知れない。
  9. サポートは、丁寧ではあるが技術的な知識は全くないので、結構イライラする。ちょっとした問題を問い合わせても、お決まりの「PCのメーカー、機種、OS、プロバイダ、契約、・・・をお教え下さい」で辟易した。そんなことを教えたって、結局何にも使われないことは明らかなのだ。
  10. バックアップ対象を選択しようとしたら、「おまかせ」でない、任意のフォルダ指定ができなくなっていた。

これは駄目なパターンかも知れない。それで、パスワードの件でまともな回答が来るまで、AOSBOXの評価は止めることにした。そして、Backblazeを我慢して使い続けるという案が浮上してきた。上記1-7の問題はないし、サポートさえ使わなければいいのだから(これはOCNと一緒だな)。

「駄目かも」というより、もう終わっている感がしてきた。まあ、今週前半が峠だ。(11:37)

さっき、ちょっと試したいことがあってやろうとしたら問題10が見つかって、はっきりした。AOSBOXはクソだと。回答を待つまでもなく、使うのは止めることにし、アンインストールした。(21:52)

(7/28 19:23) ようやく独自の暗号化パスワードが設定できない件に対する回答が来たが、例によって、それは「仕様」だと。トライアル版ではできて、サポート窓口すらその手順を教えてきたのに、今になって製品版ではできないなんて詐欺だ!

(7/30 23:31) 仕様を修正するか返金するように言ったら、前者には触れずに、後者は買ったところに言えとのこと。これ以上は時間の無駄なので、終了。AOSは全く誠実さのない会社だった。

(20:24 問題9を追記, 21:51 問題10を追記)

PS. という訳でnaokiさん、まだ希望はありますよ。

  •   8
  •   1

プロバイダの意味不明な利用制限(アップロードは30GB/日まで)に(仕方なく)従うため、Traffic Management ControllerとTCP Monitor Plusの組み合わせを使っていたのだが、問題があることが分かった。Traffic Management Controllerがハングすることがあるのだ。終了せず中途半端にプロセスが残っているので、性質が悪い。

それで、仕方なく自分で解決することにした。

とは言え、実際に帯域制限をするプログラムを作るのは大変なので、帯域制限をする部分はNetBalancerのコマンドライン版(nbcmd.exe)を使うことにし、誤差があってうまく使えないNetBalancerの制御部(指定された条件に従って帯域制限を開始/解除する)の代わりを作った。

ここで苦労したのが、現在までの累計送信データ量の取得だ。はじめは、TCP Monitor Plusの生成する値(定期的にiniファイルに書かれる)を使っていたのだが、競合(TCP Monitor Plusが書いている時に読み出すと、値がおかしくなるかも知れない)が気になったのと、無駄にGUIプログラムを動かしておくのは気に入らないので、別のプログラムを探した。

調べたら、Windowsのnetstatコマンドの-eオプションでできることが分かったのだが、なぜか、実際の約4倍の量が表示される。会社のPCでも同じだった。検索した限り誰も指摘していないのを見ると、全然使われていないのではないだろうか。あるいは、何か数字がでたら、それをそのまま信じているのか。netstatの他にはWindows PowerShellにその機能があるのだが、Windows 7では使えない。

更に調べたところ、AdapterWatch (awatch.exe)というプログラムが使えることが分かった。GUIプログラムだがコマンドラインでも使える。累計送信データ量の値は問題なさそうだったので、それを利用するプログラムを作った。基本動作は以下のとおり。

  1. awatch.exeを定期的に実行して、累計送信データ量を求める。
  2. 累計送信データ量がしきい値を超えていたら、nbcmd.exeで帯域制限を開始する。
  3. 日が変わったら、nbcmd.exeで帯域制限を解除する。

今朝未明から作り出したのだが、さっきできた。明日、日が変わったら帯域制限を解除する動作が正しいかの確認ができれば完成だ。

(7/25 8:20 加筆)

PS. 作っている途中で、Traffic Management Controllerが休止からの復帰後に誤動作する原因が分かった。復帰直後は、Windowsの出力する累計送信データ量が0になり、それで変な値が出ていたようだ。作者も多くのユーザーも、休止モードを使っていなかったのだろう。信じられないことだ。(7/25 8:10)

PS2. 制御プログラムのデバッグをしていて気付いたのだが、NetBalancerの誤差は、Kの単位の内部的な食い違いによるものかも知れない。Kは1000の場合もあるし、1024の場合もある。情報関連では1024が多いが、決まっている訳ではない。誤差は、タスクトレイの表示が"29.5GB"の時にメインウインドウの表示が"27.5GB"だったのだ。1000のGBを1024のGBに変換すると、

29.5*1000*1000*1000/(1024*1024*1024)= 27.5

ではないか! 今日一日動かして確かめてみて、そうだったらNetBalancerに戻ろうか。。。(7/25 10:42)

PS3. 制御プログラムの改良をしていて気付いた。自作なら、帯域制限ルールを自由に作れる(例: 適応的にできる)ので、NetBalancerは使わない方向にしようと思う。

適応的ルールの例: 帯域制限時の送信速度を固定値にするのでなく、しきい値に達した時、その日の残り時間と制限値までの残り容量から決めるようにする。こうすれば、制限値を過不足なく使い切ることができそうだ。

(7/25 13:01)

PS4. 適応的帯域制御を常時行う(例: 5分ごとに速度を再計算する)ようにして、可能な限り制限値を使い切れるようにしてみたら、意外に簡単にできた。我ながら、これは素晴らしいと思う。(7/25 15:46)

  •   0
  •   0

先日付けたばかりのバナナプラグなのだが、若干抜けやすいのが気になっていた。ケーブルの長さ方向に差し込むから、ケーブルを強く引っ張ると抜ける。普通に使っていれば完全に抜けることはないが、知らないうちに接触不良になりそうだ。実際、気づいたら数mm抜けていることがあった。また、構造上、接触面積が小さい気がする。そもそもバナナは嫌なのだ。よく、こんなものをありがたがって使う人が居ると思う。

そこで、Amazonで半田が付く丸端子を探した。すると、真鍮製で付きそうなのを見つけたのだが、その後、思わぬ発見があった。先日買って半田は付かないと思っていた丸端子がAmazonに載っていて、そのページを見たところ、スズメッキだと書いてあったのだ。

スズメッキなら付く!(半田は鉛とスズの合金なので) 先日駄目だったのは、こてをくっつける時間が短くて温度が低かったせいだろう。

それで、早速交換した。Y端子同様、上下方向に余裕を持たせるため、接続部を90°手前に曲げた。さらに、接続部の輪が大きいため、プライヤーでつぶして平たくして、半田付けしやすくした。それでもまだ面積が広いので、なかなか付かなかった。大量の半田を流し込んで、ようやく付いた。今回は温度を上げ過ぎてしまい、ケーブルの被覆が若干溶けてしまった。温度が高く冷えずらかっため、冷えたか確かめる時に指先を軽く火傷した。そして、1本だけうまく付かずに曲がって付いてしまったものがある。

IMG_2168_サイズ変更

アンプSP192ABに接続した。これならケーブルに力が掛かっても抜けない。改造Y端子に比べると接触面積が広く、断線も大丈夫そうだし、気のせいかすっきりしている。

IMG_2171_サイズ変更

IMG_2170_サイズ変更

これで接続関係は概ねOKだ。「概ね」というのは、一点、電源アダプタのプラグ(アンプ側)が抜けやすいのが気になっている。深く差し込めば大丈夫そうだが、使っているうちに抜けてしまわないかと、ちょっと心配している。

→ メーカーに問い合わせた。(7/23 7:58)

回答が来た。ジャックの径が少し大きかったようで、近日中に対処してくれるとのこと。聞いて良かった。(7/23 20:17)

これは広義の故障と言え、原因は先日推測したように検査漏れ(不足)だった。やはり、故障率は高そうだ。(7/23 23:55)

PS. 結局、秋月から買った部品(バナナプラグと抵抗)は全部無駄になった。でも、やってみなければ分からなかったことなので仕方ない。いい経験だ。

  •   0
  •   0

俄然おもしろくなったので、明日にするつもりだった、アンプ(SP192AB)単体の特性をRMAAで測定した。比較のため、旧アンプのPM-17SAも測定した。なお、SP192ABはスイッチング電源なので、その可聴帯域外の雑音を測定しようと思い、サンプリング周波数を192kHzにした。なお、PC側の入力は、オンボード(Realtek, HDオーディオ)のアナログライン入力で、お世辞にも性能がいいとは言えず、その影響/制限を受けている可能性はある。いつか、もっとまともなADCで測定してみたい。

IMG_2152_サイズ変更

(PM-17SAの測定風景)

IMG_2153_サイズ変更

(SP192ABの測定風景)

測定の結果、大きな違いはなかった。大きな違いがあったのは、高調波ひずみ(THD + Noise (at -3 dB FS))だった。これが聞き始めに感じた耳の痛みに関係しているのかも知れない。とは言え、ひずみは環境騒音に紛れて聞こえないレベルなので、実際には関係ないと思う。(← 負荷抵抗を付けていた場合)

そして、SP192ABの優秀さ驚いた。あんなに軽くて小さくて定価が約半分(5万円も安い)の物が、大きくて重いPM-17SAと同等の性能だったのだから。しかも、雑音レベルやダイナミックレンジで勝っているのは、全く予想外だった。もしかすると、PM-17SAは経年劣化のために雑音が増えているのかも知れない。

以下に主要な結果とコメントを載せる。

Summary (まとめ)

[PM-17SA]

負荷抵抗なしの場合:

Frequency response (from 40 Hz to 15 kHz), dB
-0.97, -1.41
Good
Noise level, dB (A)
-74.9
Average
Dynamic range, dB (A)
74.8
Average
THD, %
0.0083
Very good
THD + Noise, dB (A)
-68.2
Average
IMD + Noise, %
0.069
Good
Stereo crosstalk, dB
-71.2
Good
IMD at 10 kHz, %
0.047
Good
General performance
Good

負荷抵抗ありの場合:

Frequency response (from 40 Hz to 15 kHz), dB
-1.00,
-1.44
Good
Noise level, dB (A)
-76.2
Average
Dynamic range, dB (A)
76.3
Average
THD, %
0.0070
Very good
THD + Noise, dB (A)
-69.7
Average
IMD + Noise, %
0.054
Good
Stereo crosstalk, dB
-69.4
Good
IMD at 10 kHz, %
0.042
Good
General performance
Good

[SP192AB]

負荷抵抗なしの場合:

Frequency response (from 40 Hz to 15 kHz), dB
+0.68, +0.25
Good
Noise level, dB (A)
-79.1
Average
Dynamic range, dB (A)
79.1
Average
THD, %
0.011
Good
THD + Noise, dB (A)
-71.3
Average
IMD + Noise, %
0.037
Good
Stereo crosstalk, dB
-72.8
Good
IMD at 10 kHz, %
0.034
Good
General performance
Good

負荷抵抗ありの場合:

Frequency response (from 40 Hz to 15 kHz), dB
+0.57,
+0.14
Good
Noise level, dB (A)
-80.3
Good
Dynamic range, dB (A)
80.3
Good
THD, %
0.040
Good
THD + Noise, dB (A)
-65.6
Average
IMD + Noise, %
0.058
Good
Stereo crosstalk, dB
-70.9
Good
IMD at 10 kHz, %
0.067
Good
General performance
Good

※総合評価は同じだ。が、"Good"の数ではSP192ABが勝っている。特に、高調波ひずみ率ではわずかに負けるものの、ノイズやダイナミックレンジでSP192ABが勝っているのは驚きだ。電源がACアダプタ+スイッチング電源なのが却っていいのかも知れない。

Frequency response (周波数特性)

[PM-17SA]

fr

[SP192AB]

fr

※SP192ABは20Hzで0.75dB程落ちているが、その程度の差は判別不可能だし、僕のスピーカーでは再生できないので、全く問題ない。

※負荷抵抗あり。

Noise level (雑音レベル)

[PM-17SA]

noise

[SP192AB]

noise

※どちらも充分ローノイズだが、PM-17SAは50Hz(電源雑音)とその高調波が多い。SP192ABはスイッチング電源だが、その高周波雑音は全く問題ない。

※負荷抵抗あり。

Dynamic range (ダイナミックレンジ)

[PM-17SA]

dynamics

[SP192AB]

dynamics

※雑音レベルと同様。

※負荷抵抗あり。

THD + Noise (at -3 dB FS) (高調波ひずみ+雑音, フルスケール-3dBで)

[PM-17SA]

負荷抵抗なしの場合

thd

負荷抵抗ありの場合

thd

[SP192AB]

負荷抵抗なしの場合

thd

負荷抵抗ありの場合

thd

※高調波ひずみに関しては、PM-17SAがわずかに良い。これが大きく違う。SP192ABは高調波ひずみ(3,5,...kHz)が多い。これが音の違いの一因になっているのかも知れない。それでも、振幅は-75dB程度なので、問題のないレベルだ。25kHz以上の雑音は、DACかPCのオンボードサウンドの特性によるものかも知れない。

SP192ABの高調波ひずみ(3,5,...kHz)が多かった原因は負荷抵抗であることが分かった。負荷抵抗を外したら、特にSP192ABが良くなった。負荷抵抗のインダクタンス成分が良くなかったのだろうか。(7/22 4:53)

更に、25kHz以上の雑音はPCのオンボードサウンド入力の特性によるものであることが分かった。PCのスピーカー出力を測定しても同じ雑音が出たからである(下図参照)。 (7/22 5:47)

[Realtek スピーカー出力]

thd

Intermodulation distortion (混変調ひずみ)

[PM-17SA]

負荷抵抗なしの場合:

imd

負荷抵抗ありの場合:

imd

[SP192AB]

負荷抵抗なしの場合:

imd

負荷抵抗ありの場合:

imd

※同等だ。が、SP192ABの7kHzの山の幅が少し広いのと、15kHz付近に山があるのが気になる。60Hzで7kHzが変調されているのだろうが、これが音の違いの一因になっているのかも知れない。とはいえ、振幅は-90dB程度なので、聞こえないレベルだ。

SP192ABの7kHzの山の幅が少し広いのと、15kHz付近に山がある原因は負荷抵抗であることが分かった。負荷抵抗を外したら、特にSP192ABが良くなった。(7/22 4:53)

Stereo crosstalk (クロストーク)

[PM-17SA]

cross

[SP192AB]

cross

※SP192ABが勝っている。PM-17SAはツインモノ構成なのに、意外な結果だ。

(7/22 4:56 負荷抵抗がない測定結果の追加と記述の修正, 5:49 25kHz以上の雑音の原因を記載, 7:10 若干修正)

  •   0
  •   0

先日無理にこしらえたY端子はすぐに断線しそうだったので、仕方なくバナナプラグに替えた。休みだから届くのは明日だろうと思っていたら、秋月は意外に早く今日届けてくれた。しかも、部品の包装が美しくてちょっと感動した。ビニル袋には皺一つなく、部品には傷一つない。当たり前のことなんだろうけど。また何か頼みたくなった。

IMG_2145_サイズ変更

(左から: +用、-用、負荷抵抗)

交換の前に気になっていたのは、プラグが挿さるかだ。端子の穴が小さく見えた(直径3mmくらい?)ので、普通のプラグでは駄目かも知れないと心配していたのだが、運良くきっちりと挿さった。

それで、早速、Y端子を外してバナナプラグを取り付けた。もちろん半田付けなのだが、結構苦労した。まず、取り付け部分が小さくて(端子は直径2mmくらいだろうか)、良く見えない。老眼で焦点が合わないのだ。昔の僕なら全然問題なかったのに、忸怩たる思いだった。どうしようもないので、仕舞には眼鏡を外して至近距離で接続部を見ながら半田付けした。もちろんRoHS対応の半田じゃないので、鉛の蒸気を吸い込みまくりだ。でも大丈夫だ。中高生の頃には吸い込みまくりだったけど、まだ何ともないから。

あと、半田ごての出力が少し小さいので(電子用のため)、なかなか半田が流れず、ケーブルがうまく付かなかったが、こてを当てる時間を長目にしたら、何とか付いた。カバーを付け忘れたり、カバーやケーブルの被覆を過熱させて溶かすことがなかった点は、昔より上達したと言える。

IMG_2146_サイズ変更

(出来上がり)

IMG_2147_サイズ変更

(全景)

アンプにつないで音を出してみた。ちゃんと出た。もちろん、以前との違いは分からない。ただ、音が小さく感じたのは、換気扇を回していたからだろう。

IMG_2148_サイズ変更

アンプの背面はかなりすっきりした(参考: 元の状態)。これなら断線することはなさそうだ。

明日にでも、負荷抵抗を使って、アンプ単体の特性を測ってみたい。

PS. もちろん、僕は今でも反バナナプラグ派だ。これは背面が狭いアンプに合わせるための、緊急措置である。

  •   0
  •   0