ノイズ源に使うトランジスタ

DSC00098_2ここしばらくノイズの音源に使うトランジスタについて、廃止品になってしまった 2SC3311 の後継として使うものを探していました。

色々と比較した結果、BC547 というトランジスタを使うことにしました。理由は以下のような感じ

  • これが一番大事、ノイズ音源として性格が良いこと
  • 発生するノイズレベルが2SC3311 に比較的近く、回路変更なくそのまま差し替えて使えそう
  • 一般的に広く使われているトランジスタで、セカンドソースもあり入手が比較的容易。
  • 廃止品になる気配が今のところない。

前回の記事までは未加工のノイズを聴いて選んでいましたが、それではあまり差がわからず、ノイズ用トランジスタなんてどれも一緒なんじゃないの、と感じましたが、ちょっと考え直して、レゾナンスのかかったVCFに通してみました。ノイズをレゾナンスのかかったフィルタで強調するのは、ノイズジェネレータの重要な使い方のひとつです。

これがトランジスタによってかなり挙動の違いが出ました。音の性格が違うので試聴試験による聴き比べで優劣を決めるのは難しく、実際にシンセサイザーを操作してみて、「気持ちよいポジションが探しやすいか」を基準に選びました。

音の良し悪しはやはり人の好みなので、絶対の正解はないと思います。他にも良いトランジスタがあるかもしれません。

BC547 のデモ音:

ノイズ源トランジスタの評価その3

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

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

  • 「良い」と判断されたら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

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

sustained_scores

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

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

ノイズ源トランジスタ比較その2

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

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

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

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

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

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

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

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

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

 

ノイズ源候補トランジスタの試験を開始

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

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

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

Continue reading “ノイズ源候補トランジスタの試験を開始”

Python で wav ファイル再生

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

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

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

SPI / RX 衝突試験

spi_rx_collision_test通信ドライバでの SPI と RX の衝突試験をしました。通信ドライバはいつでも RX 信号を受け取る可能性があります。それはホストがデータの受け渡しをするため SPI 通信をしている最中でも起こります。RX 信号の処理は他の処理を中断して即行わなくてはいけないので外部入力割り込みハンドラで実施しています。このハンドラの処理がやや複雑なので、バグによりもう一つの複雑な処理である SPI 通信で使われているレジスタを壊してしまう可能性があり、実際にそういうバグがいくつか出ました。バグは全て修正されて、負荷試験が通せるようになりました。試験では、負荷生成ドライバがシリアルデータを送り続けている一方、受信ドライバのホストのタイミングを調整して RX 信号と SPI が頻繁に衝突するようにしました。パケット一個おきに衝突が発生しています。負荷試験は10時間走り続け、通信エラーなし、セッションは固まったり暴走したりすることなく続いています。

ドラゴンのしっぽ

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

Continue reading “ドラゴンのしっぽ”

AVR Dragon と SPI インタフェースの干渉を防ぐ

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

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

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

Continue reading “AVR Dragon と SPI インタフェースの干渉を防ぐ”

AVR Dragon について

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 を推奨しています。しかしこのトランジスタもついに廃止になり入手できなくなりました。以前からやらねばと思いつつ先延ばしにしていた後継トランジスタ探しを始めなくてはなりません。

Continue reading “ノイズ源トランジスタの候補”