トランジスタの試聴結果の計算方法を変えてみました。

新しい方法では、以下のようにスコアを計算します。得られた数値は「勝率」になります。

• 「良い」と判断されたら1点とする。
• 「良い」と判断されなかったら0点とする。
• 平均点をスコアとする。

このようにすると、「良い」と判断されたときの偏差は (1 – score) そうでないときには (0 – score) とできるので、ここから分散が

((1 – score)^2 x (勝ち数) + (0 – score)^2 x (負け数)) / 総比較数

と計算でき、標準偏差が得られます。標準偏差が得られれば、信頼区間が計算できます。

一般的な信頼区間の計算方法は以下のとおりです(95% 信頼区間の場合)

信頼区間 = 1.96 x 標準偏差 / sqrt(総比較数)

この計算ができるように結果集計スクリプトを修正しました

https://github.com/naokiiwakami/listening_test/tree/fa6c17847b93b8834b890676cd8debfd4ad6e63f

このスクリプトを元に計算した試聴結果

やはり聴いた印象どおり、2N5087 と 2N5210 以外ははっきりした差がないようです。

この時点でトランジスタを何にするか決めても良いのですがもうすこし興味がわいたのとせっかく試聴試験のフレームワークができたのでもうちょっとだけ追求してみようと思います。

前回の試験で 2N3904 を入れ忘れたので、それを加えて再試験をしました。結果はこちら

$ analysis.py round2_result.txt
data/1_2SC828.wav        6       {'win': 20, 'lose': 8}
data/3_BC547 F.wav       -3      {'win': 11, 'lose': 17}
data/5_2SC3311.wav       3       {'win': 17, 'lose': 11}
data/6_MPSA18.wav        -1      {'win': 13, 'lose': 15}
data/7_2N4401.wav        3       {'win': 17, 'lose': 11}
data/8_2N5087.wav        -11     {'win': 3, 'lose': 25}
data/9_KSD5041.wav       0       {'win': 14, 'lose': 14}
data/A_2N3904.wav        3       {'win': 17, 'lose': 11}

前回圧倒的に悪かった 2N5210 は除外しました。BC547 はフェアチャイルド製とオンセミコンダクタ製のものでサンプルをとったのですが、それほど違いがないようなので今回はフェアチャイルド製だけを使いました。

今回は 2N5087 が際立って悪くなりました。試験中に「変な音」のサンプルが一つ混じっていることに気付いたのですがどうもそれがこのトランジスタだったようです。

他は僅差で違いがわからないものも多く、違いがあるかな、と感じてもどちらが良いかという判断がつかない場合が多く、試験はかなり難しく感じました。

スコアの傾向が前回とやや違うことを考えると、2N5087 以外のスコアに本当に差があるのかどうかよくわかりません。それを言うには統計的に有意な差があるかどうかの計算をする必要があります。

あとで答え合わせ的に 2SC828 を基準にトランジスタの種類を見ながらききくらべてみました。いくつか特徴的なものの印象です。

• 2SC3311 は 2SC828 とそっくりです。私にはききわけがつきません。
• 2N3904 は2SC828 より少し重い感じ
• BC547 は 2SC828 より明るい音に感じます。少しばたばたレベルが動く感じがしますがそれが良いか悪いか決められず、このトランジスタは試験のたびにスコアが一番動いていました。
• KSD5041 は、ノイズレベルが他のトランジスタよりかなり高く、また聴いた印象も他とやや違いました。レベルのばたつきが非常に少なく（波形を分析しても同様のデータが見られます）、聴いた感じは低音から高音までびっちり詰まっている印象。これを楽器に使ったらどうなんだろう、という点がよくわかりません。スコアもいつも平均的でした。測定目的ならこのトランジスタが一番向いていると思います。

実際の音に興味のある人のためにデータを以下に置いておきました

https://gaje.jp/resources/noise_data_4s.zip

ノイズ源トランジスタの候補について以前の記事に書いたのですが、

https://gaje.jp/2014/01/14/2915/

廃止品となってしまった 2SC3311 の在庫払拭がそろそろ近づいてきたので、トランジスタ選びの試験をいよいよ開始しました。

続きを読む →

下記のリンクが役立ちました。

http://stackoverflow.com/questions/307305/play-a-sound-with-python

私は Windows を使っているので、winsound でうまく行きました。ものすごく簡単これだけです。

#!/usr/bin/env python

import winsound

winsound.PlaySound("ex1.wav", winsound.SND_FILENAME)

以前の投稿に書いたように、AVI Dragon は debugWire インタフェースの SPI ピンに干渉するため、SPI を使ったアプリケーションをデバッグするには、これらのピンを切断する必要があります。さらに、リセットピンも干渉していることに気づきました。今開発しているアプリケーションでは、Arduino からデバイスにリセット信号を送っているのですが、Dragon を繋いでいるとこの機能が無効になってしまいかなり開発がやりにくくなっていました。そこで、前回作った切断回路に改良を加え、リセットピンも干渉からはずせるようにし、さらに回路をブレッドボードから基板に移しかえ、お助けデバイス「ドラゴンのしっぽ」を作りました。いい感じで動作しています。

続きを読む →

AVR Dragon を使うと debugWire インタフェースを通して実機上でデバッグが可能です。debugWire は AVR ISP プログラミング用の 6ピンのコネクタを共用します。詳しくは下記のリンクに説明があります。

http://www.atmel.no/webdoc/avrdragon/avrdragon.section.zrr_osd_lc.html

ところが、AVR Dragon を使うと、開発対象のアプリケーションの SPI 機能がうまく働きません。

続きを読む →

AVR Dragon を使い始めましたが、忘れてしまいそうなことをメモ

できること

• ブレークポイントでプログラムを止める。（デバッグ実行時にはランモードとストップモードがある。）
• ステップ実行
• メモリ、レジスタ、プログラムカウンタ等プロセッサ内部の状態をモニタ。（ストップモード時のみ）
• プログラマとしても使える。ただしデバッグ中はプログラマ機能は使えない。
• ワッチポイントの設定ができるかどうかは調査中。できないような気がする。

利用のためのメモ

• チュートリアルはAtmel公式のドキュメントが結局一番わかりやすかった
  http://www.atmel.no/webdoc/avrdragon/index.html
• Dragon とターゲットを繋ぐ方法は複数サポートされているが、ATTiny* と繋ぐには debugWire を使う。debugWire は ISP プログラミングのための6ピンコネクタがそのまま使えるので便利。
• Dragon はOCD (On Chip Debugging) デバイスとしてもプログラマとしても使えるが、両方同時には使えない。OCD 時にはターゲットプロセッサのヒューズビットも変更する必要があるので、開発環境全体でモード変更する。AtmelStudio の場合デバッグ実行を開始するとソフトが面倒を見てくれる。デバッグモードから通常モードに戻るには debug -> disable debugWire and close ただしデバッグ実行中でないとこれはできない。
• Dragon と Arduino が同じ USB ハブに繋がっていると干渉する。具体的には、Dragon を使っていると Arduino のシリアルポートインタフェースが死んでしまう。お互い別の USB ポートに繋ぐこと。

アナログ式のノイズジェネレータは、トランジスタの EB 間に耐圧 (Vebo) を超える逆方向電圧をかけ、その結果生じるツェナー電流の交流成分を増幅する方式が一般的です。Analog2.0 のノイズジェネレータもその方式を使っています(こんな回路です)。

このノイズ源としてどんなバイポーラトランジスタを使ってもたいていノイズは発生するのですが、聴いた感じの良し悪しは、型番によってけっこう違います。良いノイズ源として有名なのは 2SC828A ですが、とっくに廃止されていて今やレア部品です。そのため Analog2.0 では、設計当時の現行品で評判が良かった 2SC3311 を推奨しています。しかしこのトランジスタもついに廃止になり入手できなくなりました。以前からやらねばと思いつつ先延ばしにしていた後継トランジスタ探しを始めなくてはなりません。

続きを読む →

今やっている実験の一環でこんなコードを走らせています:

   if (digitalRead(pinDeviceReadReady) == HIGH) {
    Serial.println("DATA READY");
    spiSend(0x20); // command "read request"
    readBuffer.deviceId = spiReceive();
    Serial.println(readBuffer.deviceId);
    readBuffer.wireId = spiReceive();
    Serial.println(readBuffer.wireId);
    readBuffer.length = spiReceive();
    Serial.println(readBuffer.length);
    for (int i = 0; i <= readBuffer.length; ++i) {
       readBuffer.data[i] = spiReceive();
       Serial.println(readBuffer.data[i]);
    }
  }

where

inline void spiSend(uint8_t data)
{
  // wait for device ready to write
  while (digitalRead(pinDeviceWriteReady) == LOW);
  SPI.transfer(data);
}

inline uint8_t spiReceive()
{
  while (digitalRead(pinDeviceReadReady) == LOW);
  uint8_t data = SPI.transfer(0);
  return data;
}

実際の動作パタンは以下のようになりました。赤線は DATA READY をあらわすインジケータの出力で、青線はそれを受けて起動される SPI 転送クロックです。見てわかるように、かなり大きな遅延が出ています。

遅延は、デバッグのためにSPI転送の間に挿入されている Serial.println() が原因のようです。Serial.println() の実装は見ていませんが、どうもこの行の実施には 100μS から 150μS  ぐらいの所要時間がかかるようです。

Serial.println() 行を取り除くと、大きな遅延は見られなくなりました。

でも波形を拡大してみるとまだ遅延があるようです。

これはおそらく DATA READY インジケータを読むための digialRead() による遅延か SPI.transfer() の実施に遅れがあるためと思われます。この実験では今すぐ除去する必要はないのですが、3μS ほどの遅延があることは頭に入れておいたほうがよさそうです。

日本語 Windows で Arduino IDE を使うと、エディタのフォントに MSゴシックが使われていて、見づらいことこの上ありません。そろそろストレスに耐えられなくなってきたので、見慣れた Consolas フォントに設定変更しました。少しだけ面倒だったので備忘のためやり方をこの記事に残しておきます。

この IDE は、メニューの
ファイル (File)  > 環境設定 (Preference)
から、フォントサイズなどある程度の設定変更ができますが、フォント自体は一見変更できないかのようです。でもできます。変更するには、設定ファイル preferences.txt を直接編集します。このファイルは、Preference ダイアログの下のほうにある　”More preferences can be edited directly in the file” あるいは「以下のファイルを直接編集すれば、より多くの設定を行うことができます」という記述のあるところのリンクから簡単にたどり着けます。

preferences.txt ファイルを Notepad などのエディタで開いて、2行修正を入れます。

修正を入れる２行：

editor.antialias=false
editor.font=Monospaced,plain,12

修正後：

editor.antialias=true
editor.font=Consolas,plain,12

これで IDE を再起動するとフォントが変わります。ソースコードがぐっと読みやすくなりました。日本語コメントがあると読めなくなるので要注意。