2018年05月31日

Open.Theremin@WCKのエッジのタイミングでDACへのデータ転送処理を行う

DAC周りのコードの検証を行う過程で徐々に判明して来ている問題は、データ出力のタイミングが相当にルーズだったことで、WCKのアップエッジで波形読み出しのタイミングを図っていた筈が、場合によってはクロックのダウンエッジを超えたところまで処理を引きずっているケースを観測できた。

例えば、Pitch/Volumeの値を観測する処理ループの先頭に設置したマーカーの出力端子D01から、予想外のタイミングでヒゲが発生している。 これは、WCKのアップエッジを切欠にattatchInterruptによって開始されたWavetableの処理がWCKのダウンエッジよりも早いタイミングで終了し、アンテナの状態をセンシングするループにルーチンが移行したことを示している。

Screen Shot 2018-05-31 at 18.39.12.png

このままの状態では、WCKのタイミングで出力信号を取り込むadatEncoderへの安定したデータストリームを確保することが難しく、プログラムが予想外の挙動を示す可能性がある。 問題の解決法として考えられるのは、WCKのアップエッジだけではなくダウンエッジのタイミングに合わせて処理を固定する手法で、これによりDACへのアクセスに必要な処理を分散出来るようになるはずだ。 

Screen Shot 2018-05-31 at 19.45.54.png

同様に、wavetable読み出しのルーチンの先頭にDACへのデータ送信ルーチンを配置する。

Screen Shot 2018-05-31 at 19.46.28.png

こちらは、コードを書き換えて、WCKのエッジのタイミングで各DACにデータ転送処理を行うルーチンを配置した後に観測した波形。 D01にはMAX5717に出力するLDAC信号をアサインしている。 MAX5541への送信ルーチンにはNOP命令を追加して、処理のタイミングに余裕をもたせた。

Screen Shot 2018-05-31 at 19.35.22.png

これはMAX5717へのデータ送信ルーチン。

Screen Shot 2018-05-31 at 19.36.05.png

こちらがMAX5541へのデータ送信ルーチン。MAX5717への送信ルーチンと比較すると、CSクロックの幅が広いことが判る。

Screen Shot 2018-05-31 at 19.36.18.png

MAX5541のデータ送信のタイミング。

データが確定した後、それを取り込むSCKのアップエッジまでのタイミングを40ns超に調整している。

Screen Shot 2018-05-31 at 19.40.01.png

これがMAX5717のデータ送信ルーチン。 高速で運用するクロックがスパイク状に見える。
SCKのデューティーサイクルはもう少し改善する余地がある。

Screen Shot 2018-05-31 at 19.43.44.png

posted by Yasuski at 21:13| open.Theremin

OpenThereminOnTeensy@テストベッドの調整とコードのデバッグを行う

ソフトウエア評価用に作ったテストベッドにMCUを組み込んだところ、静電容量が変動した影響でリファレンス側オシレーターのチューンが狂ってしまった。 

IMG_7957.JPG

変動はPitch/Volume双方ともが20kHz程上にズレていて、これは最大で8pFが限界のGiga-Trimの可変範囲を超えている。

ということで、チューニングのやり直し。

まさかMCUがここまで影響するとは思わなかったが、ダミーでもよいのでMCUと同程度のマスのものを基板に搭載してチューンを行う必要がありそうだ。

確認のために数回の通電を行ったが、立ち上げ時の動作も怪し気な雰囲気だ。観測ポイント設定用に伸ばした結線が悪さをしている可能性もあって、原因の判定が難しい。

能動的な対策としては、外乱による変動をキャンセルするためにオシレーター部を電磁シールドで覆うのが正道で、通信機器の基板でよく行われている手法ではあるが、これは一寸大げさだろう。 実験機に搭載したオシレーターの回路構成がアンテナ側とリファレンス側で異なる(片方はVariCapによる補正が効く)のが情況を余計にややこしくしている。 手元にある最新の基板(ただし修正箇所が存在する)ではVari-Cap搭載型を組み合わせているので、調整が少しは楽になるかもしれない。

いろいろと挙動が怪しいMCU搭載DACでVari-Capを駆動する方式だが、手動で補正を行う形式に変更したほうが良い感触がある。

結局、20pFコンデンサの値を追加することでオシレーターのチューニングを完了したものの、依然としてMCUの挙動が怪しい。 試しにロジック・アナライザで特定箇所の波形を測定したところ、オーディオ関連の信号処理が全く行われていないようだ。 LEDのドライヴに関しては問題なく行えているので、プログラム全体のおおまかなステップはこなされているようだ。

稼働実績のあるコードとの差分を中心に精査したところ、まずは不要なFTM3を稼動状態にしているのを発見したため、これを停止した。 構成をシンプルにするために、チューニング機構はフル手動に変更し、不必要な条件分岐を極力減らすことにした。 不具合の発生は変数宣言の段階で何かポカをやらかしている所為なのだろうか? 特に基板独自の仕様を定義した部分が疑わしい。

システムに通電しながらシリアル信号を読む手法はMCUの破壊を誘発する可能性があるため、LEDのマーカーを使ってモード切り替えの推移を観察することにしたが、この部分に問題はなさそうだ。 次に、DACのサブルーチンにマーカーを組み込んで出力を観察してみたが、LEDが点灯せずアクセスを確認できない。

念のため、ロジック・アナライザでMCUの各デジタル出力を計測すると、こちらも出力を確認できず。 コードを再検討してクロックソースに同期させてデータを出力する為の条件分岐を行う箇所が怪しいと判断し、ここに動作検証用のフラグ出力を追加して波形を観測しながら判定を行う構造をよりシンプルに改装した結果、チップセレクトの出力を確認できるようになった。

ところが、DACにデータを送信するためのシリアルクロックの出力が認められない。データストリームの波形も平坦なままで、これは何かがおかしい。 そこで、不具合が予想されるDACへのデータ送信ルーティン内のクロックとデータの記述を調べ直したところ、ADAT系のデータラインとの混同を発見した。 

これは、稼動状態にあるシステムからコードを移植する際にピンアサインが異なる部分の記述を間違えたのが原因で、混同したデータラインを修正することで、問題を解決できるはずだ。

コードを修正した後にロジック・アナライザでDAC出力のデータ・ストリームを確認した。

Screen Shot 2018-05-31 at 9.24.20.png

一番上の信号がD18に入力されているMCK/44.1kHzで、現状は半波長の間にオーディオ出力の処理を行っている。

残りの半波長では、アンテナのセンシングをループで行っているが、この間に何回処理が行われているか現時点では不明。 アンテナのセンシングを行うループ内に、オーディオ出力の処理を割りこませることは可能だが、何れにしてもadat出力(現時点では機能をキャンセルしている)とDACとの併用は難しいと思われる。

16bitシングルCHのオーディオストリームに費やされる時間を計測した画像。

Screen Shot 2018-05-31 at 9.21.14.png

二発目の処理はOverDriveモードを有効にした時点で稼動状態となる。

和音設定の変更で全体の処理が重くなると、WCK半波長分の処理スペース後半にDACへのデータストリームが追いやられることを確認している。

処理に余裕を持たせるため、OverDriveモードのデータストリームををWCK後半に移すことも考えるべきか。

こちらは、データストリームとSCK(シリアルクロック)との関係を測定したもの。

Screen Shot 2018-05-31 at 9.23.21.png

データ確定からSCKのアップエッジまでのマージンは約10nsと出た。 処理ステップの消化時間からクロックをフリーランさせた結果がこれで、MAX5717/5719ではギリギリのタイミングとなるが、、、

WS001293.JPG

MAX5541に至っては明らかに速過ぎる、、、。

WS001289.JPG

辻褄を合わせるためには、 __asm__ volatile ("nop");  等を使用した遅延処理が必要で、最終的には現物合わせで調整することになる。
posted by Yasuski at 13:24| open.Theremin

2018年05月30日

TeensyでWDTを試す

WDTに関する記事を見つけたので、これを参考にしてクロックソースをテストベッドに組み込みたい。

https://bigdanzblog.wordpress.com/2017/10/27/watch-dog-timer-wdt-for-teensy-3-1-and-3-2/
posted by Yasuski at 05:58| AudioElectronics

2018年05月20日

Open.Theremin@テストベッドに基板を移植するも断線が疑われる

基板を移植後に、MCUを搭載しない状態でテストベッド用の基板を装着してみたが、

IMG_8041.JPG

WCKをアサインしているはずの端子に信号が上がってこない。

Screen Shot 2018-05-20 at 20.34.58.png

信号ポートのch0/1にディテクターアウト、ch2にWCKをアサインしている筈なのだが、、、。

断線の可能性が高いので、再度バラして道通をチェックすることになった。

追記:


FPGAから出力されるクロックソースは、MCUからの起動信号("H"で起動)が必要なことを失念していた。確か、前にも別基盤で勘違いをやらかした記憶があるが、確認したところ端子の断線も無くひとまず問題は解決した模様。
posted by Yasuski at 21:06| open.Theremin

2018年05月19日

Open.Theremin@今更ながら回路の配線ミスを発見する

基板設計時の思惑を忘れてポカをやってる案件がまたもや発覚した。

リファレンス側のオシレーターを使ってディテクターとして使用するD-FFのクロックをチョッピングしているのを忘れて、そこにアンテナを繋ぐという無茶をやらかしていた。

実験の結果、10回転VRを用いてもチューニングのスイートスポットが狭い感触だった。 製品化する場合はクリティカルなポイントを探した後に上下の変化幅を調整することになるが、機械的な構造によって調整幅に影響が出ることになりそうだ。

ロータリーエンコーダーの切替え機構の不備もそうだが、異なるプラットフォームのために設計した基板の機能を切り貼りしてたのが仇になってる感じ。

試しにリファレンスとアンテナに対応するオシレーターを入れ替えてみたが、これが何故かメタメタな波形で使いものにならない。 

原因はアンテナ端子の接続ポイントを間違えるという凡ミスだったが、全てのVari-Cap駆動系オシレーターの配線をミスっているので、既存の基板には修正が必要。

WS001269.JPG

修正箇所はプリントパターンを2箇所ルーターで削って、コイルとアンテナ端子を接続するだけ。 リファレンス側にはアンテナを繋がないので、問題は発生しない。

WS001270.JPG

誤配線を修正後、

WS001276.JPG

正常な発振を確認した。 



最新版の基板にも修正を反映しておいた。

antPortPitch.png

antPortVol.png

otot409e.png
posted by Yasuski at 16:13| open.Theremin

2018年05月18日

Open.Theremin@Vari-Cap調整用のVRを装着したケースに基板を移し替える

MCUの死亡を機にデジタル信号検証用に作ったトリマー用のVRを実装した筐体に基板を移し替え、素の状態でオシレーターの再チューニングを行うことにした。 予想通りリファレンス側の周波数が高めに出ていたので、これを下げる方向で再調整を行うことになる。

今回は再分解の手間が掛かってしまうが、予め基板裏にコンデンサーの時定数を調整するためのポートを設定しておけば、リード付きのコンデンサーを取り替えて気軽にチューニングを行える。 該当するSMDコンデンサーのランドには予めリード線用のスルーホールを設置してあるので、基板裏側のランドに丸ピンタイプのソケットを追加する。

一連の不毛な作業で思わぬ寄り道をしてしまったが、ここは一旦仕切り直してMCUが未実装な状態でアナログ側のチューニングに臨むのが正解だろう。
posted by Yasuski at 23:35| open.Theremin

Open.Theremin@新型基板の開発が頓挫中

新型テルミン開発の現状を箇条書きでまとめると、、、

1)アナログ部は概ね正常に動作している模様だが、D-FFによるディテクターの働きが正常かどうかはオリジナルの回路を実際に測定して確認する必要がある。

2)オーディオクロックの発振は正常に行われているが、MCUの動作を検証するシリアルモニターによる検証方法が、MCUに入力するクロックソースが別電源なために実行できないという問題がある。

3)起動時に音声が出力されない。テルミン以前の純粋な音声再生ルーティンが機能していない。

4)キャリブレーションモードへの移行を判定するモードスイッチは正常に動作している模様。

5)ただし、モードの移行をスイッチの押し時間で判定するタイマーがオーディオクロックによってドライヴされているため、ソフトウエア開発時の検証が出来ない。

6)実際に電源を投入して運用を行った状況ではロータリーエンコーダーの切り替えが出来ておらず、DACの出力電圧が変化しない。

7)オシレーターがチューン不能なため、ピッチ判定機能の検証が行えない。

8)手動でオシレーターをチューンした場合も、Volume側のLEDドライヴ(音声出力を判定している)が行えていないことが判る。音声が出力されない問題も絡んでくるのがポイントで、チューンの状態を確認できない。

9)電源とUSB通信端子の併用は、MCUの破壊をもたらす。

以上、判明している不具合をまとめてみたが、稼働までの道程は遠そうだ。

追記:


MCU2個目が死亡。

もう呪われているとしか思えないが、どうも通信の途中にUSBケーブルを引っこ抜いて死亡させるという愚を犯していた気がする。

毎度、書き込み時の情況はモニターしていた筈なのだが、偶に通信が遅延してそれを認識せずにやらかしていた感あり。

で、モードの切り替えだが、LEDの表示のみが働いていたようで、モードの切り替えを確認するLEDマーカーを追加しても反応しないことから、理由は判らないがなんらかの機能不全が発生している模様。

基本的には稼動状態だった旧システムからコードを移植しているだけなんだが、何故不具合が発生しているのか全く見当がつかない。
posted by Yasuski at 17:15| AudioElectronics

Open.Theremin@またもやMCUをぶっ壊してしまう

テルミンの筐体を乗り換える前に、MCUに内装されているDACのコントロールを暫定的に復活させて、オシレーターの可動域を再チェックすることにした。

とりあえず、リファレンス側の周波数が修正されたが、肝心のロータリーエンコーダーが動作不良っぽく、トリムが全く効かない。

マイコン独立で動作確認したところ、ロータリーエンコーダーの機能は生きているようだ。電源を並立駆動させてMCUを飛ばす不手際を再度やらかさないようにしなければならないが、LEDの点灯には外部電源が必要なのとMCKの供給がFPGA経由なのでクロックを噛ませた状態でソフトウエアの検証を行えない。

で、外部電源とUSB経由のプログラミング&シリアル通信でソフトウエアの状態を監視する作業を半日やってみたが、先ほどまたもやMCUをぶっ壊してしまって今日の作業は終了。 どうもTeensyはMacと相性が悪いのではないかという疑惑が頭をもたげてくる。

今日明らかになった問題点はキャリブレーションモードに入れない状況で、モードの切替が出来ないために、チューニングが一切効かなくなるという重篤な状態なのだが、MCUがRGBエンコーダーのクリックを受付けなくなった矢先にご逝去されたという状況がヒントになるかもしれない。 つまりプログラム単体ではなくハード由来のバグの可能性をも示唆しているのだが、現時点では有効な解決策が見えてこない。

ちなみに、RGBエンコーダーの機能を切り替える条件判定の部分でstatusを読んでいたが、ここでプログラミングをミスっていることが判明。 modeを読んで条件分岐を行わないとpotは切り替わらないのだが、この部分では本来は追加したキャリブレーション専用のスイッチを押してチューンを行うつもりだったことを思い出した。
posted by Yasuski at 01:02| open.Theremin

2018年05月17日

Open.Theremin@スケッチを専用基板に対応させる

昨晩からスケッチの精査を開始しているが、まずはプッシュスイッチの状態を判定するために設定した時定数にミスが発覚、これを修正する。

WS001267.JPG

次に、ロータリーエンコーダの2面設定を廃止し、単純化を行った。 以降、キャリブレーションは純アナログ方式で行うことになる。

WS001266.JPG

続けてコードの検討を行っていくと、Wavetableの参照後にローカルで音源のミックスを行っている箇所が怪しい。 ローカルの音声処理は、後々のことを考えて24bit幅に統一することが望ましい。 中間出力のデータはノーマル系とサチュレート系の処理を個別に行っておく。

WS001265.JPG

ミックス時の非線形リミッターは16bit幅から24bit幅に処理幅を広げているが、最終的にはこれをDACに合わせてbitshiftを行い辻褄を合わせる。 こちらも、サチュレート系の音声は分離して処理を行っている。

WS001268.JPG

その後、ソフトウエアをMCUに書き込んで通電したところ、無事キャリブレーションモードに入ることが出来た。

ただ、DACへの電圧供給を止めた影響でリファレンス側のオシレーターに周波数変動が発生してしまった。 ここでアンテナ側のチューンをやり直してもVRTを接続した時点で調整が無効になりそうなので、VRTが装着された別のシャシに回路を積み替えてチューンを行ったほうが良いだろう。

posted by Yasuski at 06:46| open.Theremin

2018年05月16日

Open.Theremin@オシレーターを調整した後にディテクターの動作を確認する

Vari-Capへのコントロール電圧が0Vの状態で物理的な手段で調整を行った。

調整箇所はオシレーターの時定数を決定するCで、Pitch側は100pFに24pFを追加、Volume側はデフォルト値の150pFを100pFに交換し、20pFを並列に配置した。

調整後の波形は歪んだ感じの妙なスプリアスが出てしまうが、

Screen Shot 2018-05-16 at 4.02.07.png

Screen Shot 2018-05-16 at 4.08.16.png

ディテクターの出力をオシロスコープで観測する限り、差分の出力は正常に行われている模様。



で、少々心配なレベルで出力波形がナマッている。 

WS001264.JPG

H/Lの判定は入力端子のヒステリシス設定によるので、結果は実機で検証する必要がある。 MCU側の動作がかなり怪しく、ハード/ソフト両面からの検証を行わなければならない。

とりあえず現時点では制御電圧がゼロの状態で調整を行っているが、ベストな方法は1/2VCCの制御電圧をVari-Capに印加した状態で行うべきだろう。 

WS001155.JPG

プログラム側の調整が完了した時点でオシレーターの基本発振周波数を設定するVRTを接続した後に、改めて調整が必要。
posted by Yasuski at 07:01| AudioElectronics

2018年05月12日

Open.Theremin@アンテナ接続時の周波数変動を調べる

アンテナ接続・アリ/ナシの比較を行った。

Screen Shot 2018-05-12 at 4.39.48.png

Pitch側が約14kHz、Volume側が約10kHz周波数がダウンするようだ。

Screen Shot 2018-05-12 at 4.34.26.png

未だにこのオシレーターの特性をよく判っていないのだが、過渡的な変化を追う限り、アナログ的な用法(直に音を拾う)には向かない印象がある。 スイートスポットでリニアな部分を拾って制御信号に変換するイメージ。 LのQが高いのはダメというのが通説なのだが、SMD系でQの低いコイルは存在するのだろうか?

ハニカム巻きコイルの実装は不可能ではないが、ケースを選ぶのと、相互干渉が問題になりそうだ。

今回行った測定で得られた諸々の周波数変動をまとめると、

1)アンテナ接続時の変動がPitchが14kHz / Volumeが10kHz 
2)TrimCapによる可変域が6~7kHz 
3)Vari-Capの可変域が約10kHz

というリザルトが得られた。

アンテナの長さはPitch/Volume共に50cmだが、アンテナのシェイプの違いが原因で変動値に差が出たと思われる。
posted by Yasuski at 12:25| open.Theremin

Open.Theremin@VariCapに直接コントロール電圧を入力して周波数の変化を観測する

VolumeAnt側のリファレンス用オシレーターのVariCapに直接コントロール電圧を入力して周波数の変化を観測した。

IMG_8036.JPG

制御電圧は0~3.3Vのフルスケールで大凡10kHzの変化幅が得られるようだ。



周波数の変化は大雑把に468kHzから478kHzだったので、アンテナ側はマージンを考えて、非接触時に473kHz辺りの周波数になるようにCの修正を行えばよいだろう。

実際に部品の展開を観た感じでは、リファレンス側の周波数を下げる方向で考えたほうが良いかもしれない。

ついでにPitch側の周波数を修正したが、更にVolumeの下側までLの定数を増やして再調整すべきだろう。



Antenna側のオシレーターに装着されたTrimCapを操作して、周波数の変化幅を測定した。

0~8pFのスケールで実測値7kHz/実効値6kHzといったところ。

このオシレーターに使用した部品の組み合わせでは、1pF辺り800Hz+の変化が得られるようだ。



計測の結果、Volume側がAnt接続側を32kHzアップ=-40pF、Pitch側がAnt側を27kHzダウン=+34pFする必要あり。

周波数は、この辺のCの時定数をいじって調整することになるが、Cの値を減らす方に手間が掛かってしまう。

32294546_1853512138012569_3068609749076410368_n.jpg

C5を100pFに減らして、C2で調整 & C25に33pFを追加といった形になるか。
posted by Yasuski at 03:27| open.Theremin

2018年05月07日

Open.Theremin@AnalogDiscovery2で出力波形を観測する

オシレーターの出力周波数をスペクトラム・アナライザで計測した。

Screen Shot 2018-05-06 at 16.28.48.png

Volumeオシレーターの周波数はリファレンス側が高く、、、

Screen Shot 2018-05-06 at 16.25.47.png

Pitchオシレーターはアンテナ側が高いことが判明した。 

PitchオシレータではLの並列化を行って発振周波数の調整を行ってみたが、周波数が高過ぎる結果となった。

Lを直列にするかCの値を増やして発振周波数を250kHz前後にシフトした方が良いだろう。

Screen Shot 2018-05-06 at 16.00.52.png

ディテクターに相当するD-FFによる差分をPWMに変換する回路は正常に動作している模様。

Screen Shot 2018-05-06 at 0.38.13.png

予備のSCKアウトはロジックレベルを5Vに変換した後の波形を観測したが、波形の鈍りが酷く、バッファアンプの追加が必要。

キャリブレーション・モードに入れない問題はMCUを解析モードに設定してシリアルデータを観測しなければ解決しない雰囲気だが、キャリブレーションという行為自体の必然性に疑問が生じてきているので、純アナログ的なチューニング方法に転換することを考えたほうが良さそうだ。
posted by Yasuski at 07:57| open.Theremin