Raspberry Pi I2C clock-stretching problem

The I2C slave that I’m developing has been failing intermittently.  I finally noticed this was a known bug in Raspberry Pi that mishandles clock stretching.

I2C slave may delay response by holding SCL low.  However, when the slave does it, the I2C master in Raspberry Pi gives very short clock for the first bit of the next byte.  The symptom can be seen as following picture.

10678616_689709434441211_7585444260259589843_n

More detail explanation can be read in this link:

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html

In order to workaround this, I set data rate in I2C slave module higher.  The communication rate is 400 kbps, but I set the data rate 1000 kbps.  It worked for me.  Here is the setup of I2C slave module.

I2Cslave

 

Eagle 5 と Eagle 6 を混在して使う (Windows)

Analog2.0 を含め、今までのプロジェクトは CadSoft Eagle を使って回路図・基板レイアウトの設計をしています。最新のバージョンは 6.5 あたりですが、ライセンスの関係でいまだに  ver. 5 を使っています。バージョン6での大きな変更点として、データファイルの形式がバイナリからXMLに変わったことがあります。データがテキストですと、バージョン管理ソフトとの相性がよく、今まで苦しんでいた履歴管理がぐっと楽になる可能性が高いです。ですが、古いプロジェクトは「データファイルを変更せずに」参照できないといけません。なので、Eagle 5 と Eagle 6 の混在環境を作ってみることにしました。今まで混在環境を長く維持できたことないんですが、どうなることやら

Continue reading “Eagle 5 と Eagle 6 を混在して使う (Windows)”

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

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 でうまく行きました。ものすごく簡単これだけです。

ドラゴンのしっぽ

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 ポートに繋ぐこと。