colpitts oscillator の周波数変動について

colpitts oscillator の温度変化に対する周波数のドリフトを観測したいのだが、安定して稼働する状態記録装置が無い（ソフトオシロは1時間で落ちる）ので、人力タイムプラスで確かめるしか無さそうだ。

体感的には、朝イチと昼過ぎと日没後に調整が必要になる感じで、その間に発生した室温のドリフトは10℃位か。何れの場合もチューニング機構がアウトレンジすることはなく、修正に要する回転角はその都度45度程度（バラクタの容量変化カーヴが対数なので、VRの機械的な動きはアテにはならないが）に収まっていることから、深刻なレベルの変動は発生していない模様。

楽器から発音される音階は元の周波数変動から拡大されているので、オシレータそのものの安定度はそこそこ稼げている感触がある。

より深刻度の高い周波数ドリフトは、アンテナに指が接触した際に発生する。　ドリフトが収斂するために費やされる時間は数分程度で、その間ノブによる修正は可能だが、ドリフトが収斂するまでは常にチューニングを余儀なくされてしまうのが問題だ。

透明な熱収縮チューブ等で絶縁することが好ましいが、結露の問題が発生するかもしれない。アンテナをエポキシ樹脂にドブ漬けするのも一つの案だ。

一方、チューニングを行うVRを含めたバラクタ周辺の特性にも考慮する必要があるが、VRから供給される制御電圧には200kと4.7uFで時定数が組まれている。

ツールで計算した結果、カットオフは0.1Hzとなったが、



ここからゆっくりと放電が開始されると解釈すべきで、放電が完了するのは8.6秒後となった。



Cを0.1uFに設定した時のリザルトは



0.2秒程で、こちらの方がVRのレスポンスに優れる。



つまり、現状ではCに溜め込まれた電荷が放電を完了するのに8秒強掛かっているということで、修正を行ったつもりがラグを計算に入れると別の方向に狂いが生じてしまうことになる。

dacHandler専用のピッチ変換ボードのデザインを行う

dacHandlerを仕込んだFPGAを24pinのDIPパッケージにまとめた基板を作って配布する案を思いついた。



基板には、X'TALとPLLの組み合わせによるオーディオクロック生成パートを実装するが、付加機能を実装しない場合は単純にQFN32からDIP24pinへのピッチ変換基板として機能する。　何れにしてもJTAGポートはDIPのラインとは別に引出した方がよいだろう。



基板の表側には dacHandler のpin配列を表示する。。



裏面にはFPGAのpin配列を表示して、FPGA単体のDIP変換基盤としても使えるようにしている。



割付10枚で発注が可能かを確認しなければ。

LaVoixski＠不具合への対策・処理速度の高速化を目指す

LowerEncoderでOp3/ChebyshefTransformerModeを選択した際に、２VoiceModeのみUpperEncoderのLEDが反応しないケースが発生した。　一時的に表示系をいじって、microSDから読み出されたプリセット値を観測したところ、何故かアウトレンジな”４”を読み出している。　switch で default: を設定していない場合、該当しない数値を入力すると”空の値”を結果に返してくるようで、これが原因でLEDの表示が正常に行われなくなってしまったようだ。



対症療法としては、switchに”default”を設定するか、読みだしたプリセット値にリミッタを掛ける方法が想定されたが、今回はリミッタを掛ける方式を採用した。

次に、WCK内に設定した複数のtimerで、音階制御・表示系のサブルーチンにアクセスする頻度を制限する試みを行っている。



アクセスの頻度を落すことはレスポンスの低下に繋がるが、今回の手当によってLCDのチラツキを若干ではあるが抑えられる結果となった。

一方、ブレッドボードを組み直した機会に新調した高速タイプのFPGAに合わせて、DACとの通信ルーティンにセットした遅延素子、dsb のダイエットを行ってみた。

今回の改変では、dsb × 8 + (dsb × 8 × 32) = 264 ステップの解消を試みている。



大まかに、オーディオの転送 1ch 辺り 264 × 1.1ns ≒ 300ns 、4ch の合計で 1.2us 程の遅延が解消された計算になるが、ここまで減らしても大丈夫だった。



ただし、厳密には dsb 一発で MCU が消費するクロックのサイクルが判らないので、実質的な遅延時間は仮定している値の数倍（5〜6us程度）までを想定すべきだろう。　何れにしても、WCKの1サイクルが21us程度（48kHz時）なので、そこそこ大きな余裕を稼げることになる。

DACへの転送ルーティンを高速化してLoop内のタスクに割り振られた処理時間が増えた結果、データの取りこぼしが改善されて、波形表示の解像度に若干の向上が見られた。





高周波の領域は物理の影響が大きく、PCBの配線にはそれなりのノウハウが必要になるのだが、残念ながら自分はこの辺りの経験値を殆ど持ち合わせていない。　ヒントになりそうなのは「業務用短波ラジオ」の配線パターンで、



出来るだけその雰囲気をなぞることを意識している。

不調なPacaranaの代わりにCapyを復活させた

11月16日は久々のギグに参加する予定があり、これに合わせてPacranaを起動してライヴシステムを組み直そうとしたところ、アプリを立ち上げた途端に温度超過のアラートが出て電源が落とされる現象に悩まされた。



原因は温度管理を兼ねたファンコントローラにありそうだということで、ハンダのクラックを想定してリフローを行ったが、問題は解決せず。



仕方がないので、該当する部品の発注を行いつつ、手持ちの機材でなんとか出来ないかと、死蔵していたCapybaraを復活させることになった。



CapybaraにはアナログI/Oが装備されているがレベルの管理は行えず、外部に卓が必須となるのだが、今回はRMEと組み合わせることになった。



問題は、手持ちのmidi系デバイスの殆どがWireles化されていたことで、デバイスからの信号をCapyは直接受けることが出来ない。



rtp-midiに関しては信号をmidiインターフェイスにアサインし、そこから有線でCapyに繋げることが出来たが、この回線にMotorMixを絡ませようとしても、MidiThruが行えないmidiインターフェイスがMotorMixからの出力を堰き止めてしまう。



この問題を解決するには、midi信号をミックスするMidiMergerが必要となるが、5VトレラントなMCUとして手持ちのTeensy3.5が使えそうだ。　midi受けには在庫していた6N137を、出力のレベルシフトには74LVC1G34を使用することにした。



当初はMergeが上手くいかなかったが、単純にポートの接続を間違えていたことが原因で、配線を修正してからは呆気なくMergeを行うことが出来た。



ArduinoのMidiライブラリはデフォルトでThruがオンな仕様で、受けた信号をPortAに集約することで自動的にMergeが行われる。　完成したMergerはCapyに組み込みたいところだったが、ここは時間切れでバラック構造で折衷することになった。



会場では、このような形でシステムを展開していた。





ギグを行った過程で感じた設置の手間とインターフェイスのハンドリングの困難さから、やはりWifi化は必須と判断し、在庫していたXBeeを投入することにしたのだが、、、最新の設定アプリはmidi信号のBaudRateに対応しておらず、、、



結局は旧いWindows対応のアプリを使うことになった。



アドレス3927は、受け側なので、これをMidiMergerの入力のうち1chに接続する。通信帯は”C"に設定している。　対するアドレス3721は送信側で、これをCapyの出力にバッファを介して接続する。

注意すべき点は近接するXBeeとの混信を避けるために通信帯をDchに設定していることで、この変更を失念してしまうと通信が行えなくなってしまう。



パーツの実装密度を上げるために、個別に展開していたフォトカプラをDualTypeのものに変更した。



ブレッドボード上にXBeeを含めた入力系を集約しているが、ここにLEDで入力信号の確認を行う仕掛けを追加する予定。

LaVoixski@VolumeAntでTransitionをコントロールする

Sequencerの駆動時に、ピアニッシモで主旋律が出てくるのは何かと不都合なことが判ったので、Transitionとの兼ね合いを考えて、音列を再配置することにした。



残念ながらあまり効果は無かったが、左右の音量のバランスは改善された模様。

LaVoixski@シャックリ対策について

とりあえずのシャックリ対策で、「計数がゼロを跨いだ時」のデータを堰き止める「関所」を作っている。

実は既に、GPTの32bitカウンタには関所を設けていたのだが、、、



bitShiftにより「データを切り取った」あとの手当を失念していたので、ここにも桁上りが発生した際の対策を施すことにした。



行った手当によって、低音域に発生していた音色の荒れが収まった。　が、肝心のシャックリが発生する頻度に関して、軽減出来てはいるものの何故かゼロにはならない。

この結果から、複合的と考えていた原因が「物理の問題」に収束しつつある、、、。

追記：

ノイズ対策を行う過程で、LPFやチェビシェフ変換、それと出力のリミッターの処理を行うプロセスを、音声出力のバンク毎に離散させるべく、ソフトウエアの改変を行っている。



要は、L/R/C/Solo 4出力の音響処理を、WCKの「表／裏」に対応する偶数／奇数チャンネル毎にデータを分散させて扱う構造を徹底することが目的だ。　



これは、そもそもサブチャンネルの安定動作を担保するための施策だったのだが、組み換えは上手くいっているようだ。



追記２：

ArpeggiatorMode選択時にPitchHold機能をアクティヴェイトすると、何故か2VoiceとChordEditの両モードだけでPitchの更新が行えないバグが発覚した。

不具合が発生する原因を精査した結果、PitchHoldのトリガーに転用しているStep表示カーソルのX軸に於ける閾値設定と、両VoiceModeのプリセットに選択しているフレーズのStep数とのミスマッチが原因と判明している。

不具合への対策として、閾値を20から30に拡大することで対応したが、、、



この場合 ”Step数” が多くカーソルの動きが細かくなるフレーズを選択したときの影響が懸念される。

いまのところ実用上問題は無さそうに感じているのだが、引き続き稼働試験を行っていく。

追記２：

トリガーを駆動するスレッショルド値をStep数から自動設定する構造を採り入れてみたのだが、、、



不感帯が生じるようで、結果は微妙だった。

追記３：

リザルトを整数に丸めたら、若干動作が改善された模様。



何れにしても「慣れ」が必要な機能で、ピッチの揺れに対して至極敏感にならざるを得ない。　単純にロックして仕舞った方が遣い易い気がしてきたが、ArpeggiatorのGUIが表示されないモードに逃げて、機能をロックする「抜け道」が存在する。

LaVoixski@デモジュレータ出力について

グリッチ・ノイズが発生するタイミングでデモジュレータからの出力波形を観測したところ、グリッチが発生する原因となりそうな波形の乱れは認められなかった。　



どうやらブレッドボード上の回路、もしくはソフトウエアの構造に問題がありそうだが、これから原因を精査していくことになる。　ただ、DDSを使った試験運用に於いてグリッチの発生は一切認められておらず、デモジュレータ回路との組み合わせに問題がある可能性を捨てきることは出来ない。

現時点でデモジュレータの出力からデータ化される周波数の下限は大凡700Hzで、オシレータが発音する音階はA0辺り。



上限は1.4kHz程に設定されている。　オシレータが対応する発音周波数はD7辺りだが、これらはあくまでも再生が可能な周波数であり、演奏が可能な実用域ではないことに留意しなければならない。



その実用域だが、ベストな状態に調整した結果が、5オクターヴ＋低い方に1オクターヴといったところか。

最低限界近くの音階のコントロールが容易なことは、映像で証明されている。　一方、高域側では倍音の相互干渉によってビートが発生するケースが認められる。　不快な音色の発生を回避するためには、音源の選択とレベルの設定を慎重に行わなければならない。

LaVoixski@オシレータのノイズ対策について

TransitionModeを使ってノイズのサプレッション効果を検証した。



こちらは、5/4Voiceの順番で発音を切り替えた後、Arpeggiatorを駆動するヴァージョン。



何れの場合もシャックリが発症している。

整理したフィルター群は、生データの取り込みからデータアレイを駆動するステージまで段階毎に配置しているが、現在は徐々に掛かりを浅くしていく方向で再調整している。



物理面では基板とグランド電位の結合を強化したものの、物理的に結合がゆるいブレッドボードの問題が影響しているのだろうか、、、シャックリが完全に収まらない。　現在は基板の適当な場所から取っているグランドポイントをオシレータ直近に変更すべきかもしれない。

追記：

今日も調整を繰り返しているが、低域再生時の波形を安定させるにはフィルター効果をさらに増強する必要がある。



グリッチを除去する為の手法として、オシレータ回路のグランド電位との結合を強化する物理対応の他に、データを切り取る領域を最適化する方法がある。

有感領域の最適化はオシレータの物理チューニングと緑ノブ＝Pitch調整モードによるオフセットの増減のコンビネーションで行うが、この際にピッチの可動領域とのトレードオフが生じてしまう。そこのバランスを取って合わせ込むための調整になるのだが、楽器の試作段階ではアンテナの形状や容量などの個体差の物理要因が絡むために、確固としたセオリーを構築できないのがもどかしい。

Pitch側オシレータのグランド電位を強化した結果得られた御利益で、再調整が必要なレベルで周波数の可動領域が広くなったが、、、



シャックリの完全な抑え込みには至っていない。



これは音声出力の波形だが、デモジュレータの段階で不具合が発生している可能性がある。



こちらは、正常な波形。

LaVoixski@GPTのノイズ・サプレッションについて

以前使っていたCortexM4／K66のイメージで、IMXRT系のInputCaptureにもノイズ・フィルターが搭載されていると思っていたのだが、、、



GPT Control Register (GPTx_CR) には該当する項目はなく、つまりフィルターはソフトウエア側で実装するしかないことが判明した。

ノイズ・フィルターに関しては、以前と比べてPitch/Volumeセクション共々大幅に簡略化しているだが、、、





簡易な構造で良いので、低域の周波数帯域の条件判定で作動するフィルターを追加すべきかもしれない。

一方、設計を間違えていたことが発覚したコンプレッサーを新たに作り直すことになった。





工業用の16bitDACを駆動していた時は2の補数を扱っていなかったために単純な構造で済んでいたのが、オーディオ系のDACに切替えた際に「負極側の信号」にもコンプレッションを掛けなければならなくなった。

今回の改定では閾値の設定を整理するために、増幅度の傾きを決定する閾値を変数に書き換えている。

追記：

ピッチ側に頻発するシャックリ状の不具合が発覚しているのだが、仮組みの環境でアースラインの導通に不具合が発生している可能性がある。　アースポイントを変更する実験を行ってみよう。

追記２：

トップスイッチのLEDをRGB化する際に、接続するポートを考えている。



現状は、SequenceStart のみを表示しているが、これにDAC_Mute と Distortion/ LevelSW を追加する可能性がある。

LaVoixski@Volumeゼロ時の音漏れに対応する

VolumeAntの値がゼロのときに音漏れが発生してしまう現象は、オーディオ信号のスケールを24bitから32bitに変換する過程で生じている案件と思われるが、データを弄るよりも単純な手法／ゼロ・レベル判定時にDACのMUTE回路を起動することを思いついた。



若干のスイッチ感があるものの、微弱なレベルでのオン・オフは許せる範囲と判断している。

LaVoixski@ノイズフィルターの整理を行う

ヴォリューム・コントローラに仕込んでいたノイズ・フィルターを切り替えるスイッチャーを排除する一方で、、、



余ったリソースを活用するために、オーディオ出力に噛ませるWaveShaperを復活させて、歪成分をマイルドに丸める機能を実装した。



32bit幅のカウンタは16bitのそれと比較して吐き出すデータにノイズが少ない印象があり、CortexM4時代に挿入していたノイズ・サプレッサーの排除を試してみたところ、やはり聴感上の差異は認められなかった。

ついでにメモリ不足から使用を諦めていた出力のWaveShaperを復活させて、オーヴァーレベル時の挙動をマイルドに加工することを目指す。

次は、波形を乗り換える際の辻褄合わせを行っている機構の排除を検討しているが、こちらはより構造が複雑なので、改装には手間が掛かりそうだ。

追記：

波形の不連続面に辻褄合わせを行う機構を削除したが、音質の変化は認識出来なかった。



ループ内の足し算・割り算が減っているので、処理の負荷はそこそこ軽くなった筈なのだが、今ひとつ実感が湧いてこない。

ついでに、処理の負荷が高そうなエンヴェロープを刻むケースを録音してみた。



電池駆動なのでノイズっぽさが軽減されているが、それでも何かがおかしい。

LaVoixski＠オシレータの調整を行う（その４）

オシレータの周波数を調整するVariCapのコントロール電圧と容量の関係はノンリニアなlogっぽいカーヴ（メモリがそれ）を描いているのだが、



VariCapと周波数を決定するCが直列に接続されているところが盲点で、、、



Cの値を増やして得られる周波数の変化は、ある程度の値から頭打ちになってしまう。

また、変化の傾きが急峻なポイントでチューニングのバランスを取ってしまうと、VariCap周りの回路に印加されたノイズがピッチの揺れとして現れる可能性が出てくる。



つまり、傾きが急になり始める辺りでバランスが取れるように、オフセットを調整する必要があるのだが、今回の調整ではアンテナ側のCを減量する方向で作業を進めた。

具体的には、一旦アンテナ側のCを取り外して、容量の小さなものにリプレイスする作業を行った。
　
Pitch側のペアは、まずアンテナ接続の330pFを220pFにリプレイスした後に、リファレンス側のCを減量して合わせ込みを行った。　当初の感触では330pF＋150pF程度と予想していたのだが、結果は330pF＋100pFという値に落ち着いた。　

Volume側は、アンテナ接続の150pF＋470pFから150pFを取外し、新たに33pFを追加してバランスを取ることになった。リファレンス側は150pF＋560pFに固定されている。

何れのバンクもチューニング用VRのセンシティヴな動きをするポイントを外せたお陰で、低域の発音が幾分か改善されたようだ。　



暫くの間はこのチューニングで様子を見ることにするが、バラック状の建付けからのノウハウの蓄積は難しく、次回の製作に獲得した数値を活かせるかどうかは微妙なところか。

追記：

その後、運用試験を始めているが、ゼロ・ヴォリューム時の音漏れが気になる。　アナログ回路がブレッドボード上で完全にセパレートされている環境で確認された事象なので、これは明らかにソフトウエア側の問題だが、現時点で下手に本体を弄っても事故が誘発される危険が大きい。　従って、ソフトウエアの更新は現状のオシレータ＆デモジュレータと音源をセパレートした環境で行うことにしている。

LaVoixski@ID-292に搭載したオシレータとソフトウエアのマッチングを行う

ID-292にはMCUを実装せず、ブレッドボード上に構築した音響システムに、ID-292から引出したデモジュレータからの出力を接続してテストに臨んだ。

レンジのミスマッチは、b_shift_p = 2;　／　b_shift_v = 3;　と設定することで解決できた。



音質が歪みっぽいのが気になったので、非線形系のプリセットに設定した増幅度を変更することになるかもしれない。

オープン環境の設定はこんな感じになっている。



意外だったのが最適化後の最低周波数で、特にPitch側の500Hzという高めの値は予想していなかった。



発振周波数の変化域は700Hz程度とオーディオ的な観点からはプアな性能だが、カウンタの分解能のお陰で十分な性能を確保することが出来そうだ。

LaVoixski＠オシレータの調整を行う（その３）

MCUを実装しない状態で、オシレータの調整を行った。



思惑通り、オシレータの周波数を下げることで、グリッチの発生を回避することが出来ている。

オシレータの周波数を決定するCの値は、Pitch側：Ant.330pF／Ref.330pF＋220pF＋100pF≒330pF＋330pF　Volume側：Ant.150pF＋470pF／Ref.150pF＋470pF＋560pF　となったが、これでもRef.側に高めの周波数が設定されている。

発振周波数の実測値は300kHz前後で、Pitch/Volume間の周波数マージンは30kHz程しか稼げなかった。

オシレータの周波数が変移する挙動を見る限り、アナログ楽器的には論外な性能ではあるが、インターフェイスとしてはなんとか合格するレベルを達成できたようだ。

一方、ディテクタによる周波数検知の下限は70Hz程度が実用域で、サバを読んで100Hzと考えるべきか。上限は1kHz強なので、こちらは問題はなさそう。

現状、MCU側で設定している周波数の下限は35Hz程度だが、これを100Hzに再設定して調整を行う予定だが、ブレッドボード上に展開している実証回路にID-292からのディテクタアウトを引き込んで調整を行うのが最も安全な方法だろう。