2022年06月30日

LaVoixski@microSD関連の不具合が発覚する。

システムの構成を大きく改変する過程でチェックを怠っていたmicroSD関連の実働試験を行ったところ、残念なことに複数の問題が発生してしまった。

まず、シーンメモリーを行うとシステムがクラッシュし、再起動を繰り返す症状に悩まされた。

原因はPITフラグに対応するサブルーチンに移設したUpper/Lowerエンコーダの処理ルーチンと思われたので、これを元々配置していたMainLoop内に戻した結果、健全な動作が確認できた。

Screen Shot 2022-06-30 at 19.30.18.png

次に、旧システムのデータを格納したmicroSDを挿入して、新規に増設したエントリーが未了なLPF関連の記録ファイルを対象にセーヴを行なった場合に、システムがクラッシュすることが発覚した。

再起動にセーヴが問題なく行えるのは、クラッシュ前に強制的にファイルが生成された結果だろう。つまり、ファイルの欠損がクラッシュの原因となった可能性が高い。

データファイルの欠損によって発生する不具合は看過できるものではなく、早急にPCでデータを追加する必要がある。 また、旧くなった設定データは混乱の原因となるので、PC上にストアしたmicroSD関連のデータを現状のものに書き換えておくことにした。

Screen Shot 2022-06-30 at 21.12.14.png

posted by Yasuski at 20:32| LaVoixski

LaVoixski@ArpeggiatorWithLFO

ArpeggiatorとLFOを連携した運用例の記録。



Transition系の音源を駆動する 3/4 VoiceMode では、LFOの振幅変化に伴って発生する波形の推移が認められる。
posted by Yasuski at 00:27| LaVoixski

2022年06月28日

LaVoixski@LFOの機能を整理する

mode4/case: 4 で起動する LFO は、ロータリーエンコーダからの出力関数 "LFOB" の中点を境目に、RATE の係数 x1/x2 を切り替えている。 LFO のシェイプは極小/極大方向にノブを回すにつれて鋭くなっていく。 



なお、LFO の波形は divider のスイッチングによって生成される矩形波が基本であり、パラメータ ”LFOB" によってフィルタの深度を調整することで、矩形波の肩特性を変化させている。

Screen Shot 2022-06-28 at 11.56.55.png

LFO の実態はスイッチだが、その機能を応用した ChoppingMode を ArpeggiatorMode の中に仕込んでいる。

Screen Shot 2022-06-28 at 11.57.27.png

microSDに記録したパターンで音声出力にミュートを行う。 この機能によって、通常のテルミンでは不可能な速さでパッセージを刻むことが出来る。 



LFO2 は VolumeAnt からの操作を受け付けない独立した LFO で、Button03 のロングクリックで起動する。 LFO2 は Wavetable 方式で波形を読み出し、VolumeAnt のディテクタからカウントされる Value の代わりに、VCA の出力をコントロールする。

 

LFO2 の出力を停止した状態に固定する Freeze モードは ChordEditMode のために用意された機能で、Button03 のダブルクリックでサンプリングを確定する。 問題は、ダブルクリックの制御が難しいことで、別に専用のスイッチを実装した方がよいかもしれない。

Screen Shot 2022-06-28 at 11.52.48.png

追記:

ダブル・トリプルクリックのセンシングが不安定なのは、Loop 内に button1.tick(); を配置したことが原因だった。 配置場所をサブルーチン pit_flag 内に変更した結果、問題は解決した。

Screen Shot 2022-06-29 at 1.57.59.png

なお、スイッチの感度は現状で以下のように設定している。

Screen Shot 2022-06-29 at 1.41.17.png

6月29日 追記:

MainLoop内に配置していたサブルーチン、upperEnc / lowerEnc と LEDs を、よりセンシングとの連携が取れる pit_Flag 内に移設した。

Screen Shot 2022-06-29 at 18.50.31.png

7月1日 追記:

シーンメモリーを実行するとフリーズが発生する事が判明、upperEnc / lowerEnc と LEDs を、MainLoop に戻した。

あと、混乱を避けるために、flag_Triple の名称を flag_LFO2 に変更している。

Screen Shot 2022-07-01 at 15.01.30.png

Screen Shot 2022-07-01 at 15.01.51.png

Screen Shot 2022-07-01 at 15.02.23.png

Screen Shot 2022-07-01 at 15.02.33.png
posted by Yasuski at 13:13| LaVoixski

2022年06月27日

LaVoixski@Arpeggiator停止時の描画について

Arpeggiatorの停止時に中央の表示領域に描画が行われない「仕様」を、常にArpeggiatorの状態がLCDに反映されるように改良した。

まず、lowerEncoder.ino のシングル・ダブルクリックの設定に、Arpeggiatorが停止状態で該当する編集モードを選択した時のみ、フラグARon3を立てる項目を追加し、、、

Screen Shot 2022-06-27 at 22.22.09.png

次に、lowerSwitchView.ino の描画を行うタイミングの設定項目に、Arpeggiatorが停止状態で該当する編集モードを選択した時のみ、フラグを確認後にピアノロールの描画を行い、フラグを下ろす項目を書き加えた。

Screen Shot 2022-06-27 at 22.22.46.png

以上の作業により、項目を切り替えてもピアノロールの描画が行われるようになった。

が、このままでは項目の「編集時」やシーンメモリーのリコール時に再描画が行われないので、ロータリーエンコーダーの状態が変化した時/リコールスイッチを押した時にフラグを立てる項目を追加する。

該当する箇所は、Arpeggiatorのパターンを選択するmode2 case1: と、、、

Screen Shot 2022-06-27 at 22.37.58.png

ノートを選択するパートmode2 case2: 、

Screen Shot 2022-06-27 at 22.37.49.png

そして、シーンメモリースイッチ click2 で、 

Screen Shot 2022-06-28 at 4.40.42.png

以上の改変により、Arpeggiatorが停止時であっても操作の結果が画面に反映されるようになった。

posted by Yasuski at 23:15| LaVoixski

2022年06月25日

LaVoixski@表示系の改良等

LCDの表示を改良するために思いついた「ロータリーエンコーダーをattatchInterruptで駆動する案」は失敗に終わった。

が、今後の改良を容易にするために、LEDの点灯を制御するルーチンをロータリーエンコーダーのサブルーチンから分離して実装している。

Screen Shot 2022-06-25 at 15.03.45.png

次に、アルペジエータとLFOを同時に使用した際に、Upper & Lower LEDが点滅するタイミングが一致しない症状を緩和するために、Arpeggiatorのステップに合わせて点滅をコントロールするパートを、サブルーチン”muteSwitches”に一元化する方法を試してみた。

点滅のタイミングをコントロールする機能をLFO側と同じ階層に置くことで、ズレの解消が期待される。
Arpeggiator選択時の点滅の乱れに関する問題はそれだけではなく、LEDの点滅が速いパッセージに追い付けず、点灯のタイミングが不等間隔になるといった現象も確認されている。

Screen Shot 2022-06-25 at 15.19.51.png

この改装作業中にLCDが表示されない&ミュートモードを選択すると共にシステム毎落っこちるトラブルが発生したが、これはLCDライブラリの端子を書き換えていたことに起因するケアレスミスだった。

Screen Shot 2022-06-26 at 1.43.08.png

安心したのも束の間で、ライブラリの修正後も度々ミュート時にシステムが落ちる現象が確認された。 このトラブルは、前々からJPEGのアップロードが原因と確定していたが、今回の改変により既に行っていた対処法が無効化されたようで、該当する「じょばロゴ」反転版を廃止する方向で検討を始めた。

Screen Shot 2022-06-25 at 21.05.15.png

最終的には、LEDが発光するタイミングの修正とロゴの表示、どちらの価値観を優先させるのか?という話になってくるが、点滅の間隔がバラつく現象は看過することが出来ず、遺憾ながらロゴの廃止を決定した。



6月26日 追記:

新たに発覚した問題点は、Arpeggiatorを止めた時にLCDの中央及び下方エリアの反応がなくなることだが、その一方でLEDによるUIは健全で、ノブの回転とクリックは操作を受け付けている = ClickEncoder は問題なく動作しているようだ。 

予想されるのは、LCDの表示系にバグが内包されていることで、不具合が発現するのはArpeggiatorを選択している時に限定されるようだ。 LCDの表示領域はエンコーダの状態を反映する上下のエリアと、波形等の描画を行う中央領域に3分割されているが、今回問題が発生しているのは中央と下方領域で、特に下方領域に機能を選択した状態が反映されない点が深刻だ。

そこで、件のコード lowerSwitchView を精査したところ、不具合の発生するポイントは、Arpeggiatorのクロッキングと同期させたLCDの再描画で、フラグ ARon3 の更新が止まると描画が行われない仕様になっていた。

Screen Shot 2022-06-26 at 20.53.10.png

対症療法として、描画を行うタイミングをクロックと同期させる機能を「センターの描画領域」に限定したことで、完全ではないが動作に支障が無いレベルで表示を行えるようになった。

posted by Yasuski at 21:07| LaVoixski

2022年06月22日

LaVoixski@dacHandlerのVHDLを再検討する

分周カウンタの出力 "c4" の記述を間違えて、8番目のD-FFだけ非同期のクロックが分配されていることを発見した。

Screen Shot 2022-06-22 at 8.01.01.png

8番目の出力は使用頻度が低いものの、気持ちが悪いのでファームウエアを書き換えている。

ついでに、TopArchetectureを構成するVHDLの記述を音声チャンネル別のユニット単位にまとめる形に書き直したところ、、、

Screen Shot 2022-06-21 at 19.42.58.png

Screen Shot 2022-06-21 at 19.43.16.png

デフォルトで出力されるピン配置が大幅に変化した。 TopArchetectureの記述を変更したことによる影響は思った以上に大きいようだ。

Screen Shot 2022-06-21 at 20.07.06.png

基板の配線を変更するのが億劫だったので、とりあえず前回出力されたピンに配置を再設定してみたが、懸念していた遅延時間の増大は無く、目立つ影響は無さそうだった。

これは良い機会なので、回路を構成する論理回路の構造を再考したところ、以下のような条件分岐を使ったスイッチが、、、

Screen Shot 2022-06-22 at 0.48.53.png

単純な3入力ANDゲートに置き換えられることが判った。

Screen Shot 2022-06-22 at 0.36.58.png

インプリメンテーション後に回路図を展開すると、件の箇所がANDゲートに置き換わっていることを確認できる。

Screen Shot 2022-06-21 at 22.25.22.png

参考までに、これはANDゲートに変更する前の「スイッチ」の回路図。

Screen Shot 2022-06-22 at 7.53.42.png

当然ながら、出力ピンの配分は劇的に変化した。

Screen Shot 2022-06-21 at 22.55.20.png

変化に合わせて回路の引き回しを変更することになったが、以前よりもスマートに高速信号を扱うラインが整理されることになった。

Screen Shot 2022-06-22 at 0.59.26.png

Screen Shot 2022-06-22 at 5.38.44.png

追記:

その後行っていた試行錯誤の結果、諸々発生するアラートを消し去ることは叶わずに折衷案を採ることになった。 特に高速な信号を扱う回路の性能低下は由々しき事態で、より堅実性を確保する方向で回路の構成を考え直すことにした。

Screen Shot 2022-06-22 at 19.10.27.png

回路をシンプルにするために信号セレクタをより単純な構造のANDゲートに変更したものの、何故か健全だったクロックラインの性能が低下した。アラートが増えた原因は判らないが、セレクタの型をAND型から条件分岐型に戻して、問題を回避することが出来た。

ただし、クロック専用のプライマリなデータパスが8ch分しか存在しないという物理的な枷は如何ともし難く、

Screen Shot 2022-06-23 at 4.13.22.png

問題への対処は困難なのが実情で、扱う音声チャンネル数を半分に減数する方法が一番現実的な対策と考えられる。 

一方、楽器の在り方に視点を変えた場合は、楽器単体としての4ch出力は十分な性能であり、より確実な動作を目指す為に対応するchを減らすという選択肢もありだろう。

Screen Shot 2022-06-22 at 14.01.52.png

TopArchetectureの構造は、入出力端子の配分が綺麗なオーディオチャンネル毎にまとめて記述を行う手法が正解のようだ。 例の如く記述を改変した影響で、IDEから初期状態で出力される端子の配列は激変している。

Screen Shot 2022-06-22 at 23.05.23.png

それに合わせて基板側の配線をやり直すことになったが、予想していたよりも手間が掛からなかった。

Screen Shot 2022-06-22 at 23.38.45.png

その理由は、入出力端子のグルーピングが的確に行われていたことにあったが、これはTopArchetectureに行った記述の変更が影響したものと思われる。

Screen Shot 2022-06-22 at 19.11.36.png

MCUからFPGAに10MHz前後のレートで音声データを転送するライン。可能な限り最短距離の接続を目指す。

Screen Shot 2022-06-22 at 23.51.41.png

基板の幅60mmの別ヴァージョンでは逆サイドのD20/D21に接続している。

Screen Shot 2022-06-22 at 19.10.27.png

MCUから受信する音声データを選択する端子群。 IDEではこのピンに発生する信号の遅延が警告されている。

Screen Shot 2022-06-22 at 23.52.02.png

DACに音声データを送信するライン群は、LRCK/BCK/D1/D2の4本。 扱うデータのスピードは、FPGAに入力される信号と比較して低速なので、余り神経質に配線を行う必要は無さそうだ。

Screen Shot 2022-06-22 at 23.53.18.png

今後望まれる改良点は、実行可能な最高周波数が72MHzと桁違いに低くなることを示すアラートが出ている分周器の構造だが、現状行っているディバイダのカスケード接続を複数の単機能ユニットに分散させる方式がフォーラムの記事によって示唆されている。
posted by Yasuski at 07:39| LaVoixski

2022年06月21日

LaVoixski@FPGAのインプリメンテーションについて

FPGAのエラーを解消しきれないのは、やはりプログラムの組み方の問題なのかも知れない、、、。

Screen Shot 2022-06-20 at 11.57.45.png

回路の内実は単純なスイッチ類とレジスタといった基本的な論理回路を記述しているだけなのだが、各パーツを組む順番が原因なのだろうか?

Screen Shot 2022-06-20 at 11.57.32.png

アラートが示しているのはクロックラインの配線に問題があるということだが、単純なモジュールを並列に展開している回路構成に対して、信号線のパイプライン化?を勝手にやってくれない仕様が残念なところか。

Screen Shot 2022-06-20 at 12.28.04.png

もちろん、自分のプログラミングが稚拙なところに原因があるのだろうが、構成物の中で複雑そうに見えるのは32bit構成のシリアルデータレジスタ位で、その稼働状態を選別するシグナルラインの配線に、、、

Screen Shot 2022-06-20 at 12.29.55.png

ジェネリックなデータラインでクロックを分配するから遅くなるよ、、、と言われても、そのクロックラインを指定する方法が解らないのだ。

Screen Shot 2022-06-20 at 11.58.31.png

FPGAのエラーを解消しきれないのは、やはりプログラムの組み方に問題がある可能性を考えて、基礎的となる論理回路を組む順番を変えてみてが、結果は変わらず。

Screen Shot 2022-06-20 at 15.19.05.png

Screen Shot 2022-06-20 at 15.19.37.png

今回は試さなかった、TopArchitectureとなるdacHandlerを構成する要素の序列を変化させた方がよいかもしれない。

Screen Shot 2022-06-20 at 19.29.57.png

FPGAのIDEが出力したアラートを自分が解る範囲内で解析すると、高速データレジスタを選択するCSに準ずる信号LATCH1〜8が、クロックパスをアサインされないことによる信号の遅延が懸念される一方で、

Screen Shot 2022-06-21 at 7.14.59.png

Screen Shot 2022-06-20 at 14.38.44.png

高速でデータを転送するクロックラインそれ自体の速度は許容範囲内だった。

Screen Shot 2022-06-20 at 14.26.11.png

Screen Shot 2022-06-20 at 14.26.35.png

Screen Shot 2022-06-20 at 14.27.13.png

Screen Shot 2022-06-21 at 7.14.22.png

FPGAのフォーラムでクロックソースの問題を扱っているスレッドを調べてみると、「動くなら気にするな」的な意見が散見される一方、プラットフォームによって異なる作法が要求されるようだ。 「端子を命名する際、戦闘にClockを想起させる”C"を選べ」という意見もあった。

その後、ボードに実装したテスト用のFPGAボードに配線を行った。

IMG_20220620_224249351.jpg

書き込みはWin10のみで可能。 

IMG_20220620_224258554.jpg

新しく採用したFPGAは、ゲートの容量が256から1200に、スピードのグレードは速い方の6になっている。

Screen Shot 2022-06-20 at 14.33.33.png

VMからはファームを焼けそうにないので、妹のラップトップを間借りことになるのだが、Win10は何故かNASの共有ができない。調べてみると、10からはセキュリティが強化されて、旧い機器は接続できなくなっているらしい。

データを移植してトライした結果、とりあえず形だけではあるがファームウエアが焼けた模様。

Screen Shot 2022-06-21 at 4.14.31.png

書き込みをする際に、原因は不明だがBoundaryScanでチップの自動認識が行われなかったことが不安だが、手動でHC1200を選択することで、書き込みそれ自体は完遂している。

Screen Shot 2022-06-21 at 4.16.23.png

ブレッドボードの配線をFPGAに合わせて更新するのは翌日になるが、その前にM7側に出力端子を変更したプログラムをアップロードしなければならない。

posted by Yasuski at 04:08| LaVoixski

2022年06月19日

LaVoixski@dacHandlerのファームウエアの変更/基板のデザインをやり直す

FPGAのゲート容量を256→1200にサイズアップしたお陰でdacHandlerの8ch化が可能となったのだが、ラッチのトリガー入力が増えたお陰で端子の数が足らなくなって仕舞った。

Screen Shot 2022-06-19 at 1.12.11.png

仕方がないので、タイミングドリヴンなLRCKを残してWCKを廃止し、信号の供給源をLRCKに統一することになった。 旧システム上で単純に結線を変更して実験を行っているが、いまのところブレッドボード上では問題なく音声を出力している。

Screen Shot 2022-06-19 at 1.12.25.png

とはいえ、今回使用するのは稼働実績が無いチップ故に事前に動作の検証を行わなければならない。

Screen Shot 2022-06-19 at 1.12.41.png

作業を進める過程で、FPGAにポート指定を行わず初期状態で作成されたピン配列に合わせたライブラリを作成した。 まずは基板に回路を組んでみてからPin配列の調整を行っていく。

Screen Shot 2022-06-19 at 1.36.12.png

ぱっと見では波形が崩れていないので、LRCK信号の共有はアリっぽい。

Screen Shot 2022-06-19 at 1.46.47.png

FPGAチップ側の端子に酸化皮膜が形成されているのか?ハンダ付けがイマイチ乗らず、取り付けに苦労した。

Screen Shot 2022-06-19 at 2.47.09.png

新しくファームを書き込む予定のFPGA周りの配線をやり直している。MCUの端子とFPGAの端子の相対位置を勘案して、配線は最短距離に行うことを目指した。 MCU側で変更が不可なものはPWM/InputCapture/MOSI/SCKで、これらを避けて端子の再設定を行う。

Screen Shot 2022-06-19 at 16.20.10.png

具体的には、PIN7,8,9,11,13,15,33,36,37が選択肢から除外されるのだが、M7の稼働試験の結果を踏まえて、ようやく仕様を固めることが出来た。 

Screen Shot 2022-06-19 at 20.56.13.png

旧い設計の基板によってFPGAの最適化が制限されて仕舞うのは本末転倒だが、2層基板は配線がトリッキーになりがちなだけに、再設計に二の足を踏んでしまう傾向がある。

追記:

ライブラリによって配分されていたLCDのRST/BL端子の存在を失念していたので、プログラム上でアサインの変更を行っておいた。

Screen Shot 2022-06-20 at 1.57.14.png

具体的には、D5/D6にアサインされていたものをD29/D30に変更し、それに伴った周辺回路の構成を検討しなおしている。 FPGAの新規導入に関しては今後何らかの齟齬が発生する可能性が高く、基板を発注する前にFPGAにを使った実証試験を行うべきだろう。

Screen Shot 2022-06-20 at 1.54.53.png
posted by Yasuski at 01:17| LaVoixski

2022年06月17日

新しいアナログ音源チップを発見する

SSI2130という音源チップを見つけた。

Screen Shot 2022-06-15 at 17.40.58.png

純アナログなシンセ音源を構築するには比較的お手軽な素材との感触もあるが問題は出音で、個性を持たせるにはフィルター回路に依存することになるか。 製作のハードルが低めなSSI2131で事前に「素の音質」をチェックするという手もある。

Screen Shot 2022-06-15 at 17.41.48.png

LaVoixskiに実装しているTransition効果をアナログで実現するためには、コントローラとなるMCUからVCO/VCAコントロール用のアナログ出力を10波以上出力しなければならない。 DCを扱う手前サンプリングレートは低めでも良いので転送レート自体が問題にはならないだろう。 DACを廃して、PWM出力とする手法はアリだが、ここで問題になってくるのは分解能で実現のハードルは高い。 手元に余っているMAXIMのDACは超高速転送が可能で取り扱いが楽な一方、CV出力分だけ数を揃えなければならない。 

回路の構成はありきたりなVCO-VCF-VCFといった感じになりそうだが、マトリックスを組めるように要素を分解する考え方もある。

Screen Shot 2022-06-15 at 17.42.44.png

このチップは、4mm角のQFN32というパッケージの仕様が問題で、何故にこの規格を選んだのかよく判らない。 普通の感覚で手組みが可能なQFN32のサイズは5mm角が限度だろう。 Pinのピッチが0.4mmと更に実装の難易度が上がるのは、素人お断り仕様にも思える。 9平方mm分の実装スペースを稼ごうとする価値観と、工作の難易度をアップする行為がトレードオフされる感覚は、イマイチ理解することが出来ない。

試しに、Eagleのライブラリを製作してみたものの、、、

Screen Shot 2022-06-17 at 13.15.22.png

配線の細さが限界に近く、Seeedに発注した場合は事前検査で跳ねられるかもしれない。

Screen Shot 2022-06-16 at 14.09.01.png

CV出力用のDACとしては、パッケージの取り扱いを含めて8ch出力のこれが便利だろう。 

Screen Shot 2022-06-16 at 19.07.49.png

この手のDACを使用する上で問題となるのは複雑な通信プロトコルで、

Screen Shot 2022-06-17 at 11.00.23.png

例のデータヘッダにいろいろと余分なものが取り付く仕様は仕方がないと諦めるべきか、、、。

そういえば、通信規格の単純化が”DacHandler”をFPGAで造ったそもそもの理由だった。

クロックスピードは50MHzとすこぶる速く、

Screen Shot 2022-06-17 at 11.04.53.png

余分なヘッダ分を考慮してもデータレートに起因する問題は発生しないだろう。

既存のシステムを改変してアナログインターフェイスを構成する場合、Wavetableを読み出すDCO分の処理は必要がなくなる。 波形の処理は5ch分のPitchとVolumeやLFO/PhaseShifter/LPFの制御電圧のみとなるが、CVアウトの総計は16~24chは必要となりそうだ。 

波形モーフィングには、新たなパラメータを用意しなければならないが、チェビシェフ変換の項目を転用できるだろう。

posted by Yasuski at 05:08| AudioElectronics

2022年06月15日

LaVoixski@ID-292専用アンテナにエクステを追加する

VolumeAnt.にエクステを追加して、手前にオフセットを掛ける構造に改良を行った。

IMG_20220612_185021586.jpg

PitchAnt.とエクステの接続は強度が不安なアングル材を使わない方式に変更しているが、正式にはこちらの構造が正解。

IMG_20210510_210906174_MP.jpg

VolumeAnt.側のエクステの接合にはアンテナ末端に撃ち込んだM3ネジ仕様の真鍮インサートを使用した。 今回使用したインサートは挿入が浅く、接合部の強度不足を補うためにハンダ付けによる補強を行う必要があった。

IMG_20220612_211330703.jpg

が、それでもM5でタップを切ったイモネジに強度が敵わない。 ただし、硬い真鍮パイプ、特にストレートな素材にM5でタップを切るのは難しく、素材をL字に曲げてタップを切った後曲げ部分を切断する等、工程に工夫を行う必要がある。

タイトなシャシにLCDを実装した場合に発生するEMIの影響は実際にシステムを組むまで予想することが難しいが、オシレータ周りに電磁シールドを行う必要が出てくるかもしれない。

IMG_20220612_211433078.jpg


posted by Yasuski at 11:45| LaVoixski

2022年06月14日

LaVoixski@DAC基板の修正を行う

基板表側ではオーディオラインの変更を、、、

IMG_20220615_223736862.jpg

裏側では、スイッチを制御する信号ラインの変更を行っている。 裏側のジャンパ線はPADのランド間使って接続しているが、作業を行う過程で表裏の導通を確保しきれないポイントが数箇所発生した。 ランド穴の径がかなり小さいために、適正なサイズのドリルの入手が難しく、ランド表裏の被覆を剥がすことで対処することになった。

IMG_20220614_201419818.jpg

VRTはオン状態でグランドに接続される。ここに流れるのはあくまで制御信号で、、、

Screen Shot 2022-06-12 at 9.05.07.png

FETでディスクリートしたアナログスイッチを操作する。

Screen Shot 2022-06-14 at 21.58.18.png
posted by Yasuski at 21:57| LaVoixski

2022年06月12日

LaVoixski@LevelShift関連のセッティングを変更する他

WaveformMixのクリッピングを行うアドレス、#15/#29/#30/#31/#32 の選択時に、減衰装置が作動するように、プログラムを改変した。

Screen Shot 2022-06-11 at 22.33.27.png

減衰装置は本来Transitionエンヴェロープ波形の選択と連動する仕組みだが、クリッピングを行うアドレスを選択した時に限り確実にレベルの変動が発生することから、件のアドレスに於いてはアッテネータを常にオンで固定することにした。

Screen Shot 2022-06-11 at 22.34.11.png

手持ちのトグルタイプなアナログスイッチ(チップのピンコンフィグ右側)の在庫が結構あるので、

Screen Shot 2022-06-12 at 9.22.41.png

DAC/ID292専用基板の配線をそれに準じたものに変更した。 アッテネータ "VRT" の配列は”ON”で減衰する SW1/4 に行っている。

Screen Shot 2022-06-12 at 9.05.07.png

Screen Shot 2022-06-12 at 9.07.33.png

トリッキーになりそうだと思っていた取り回しは、予想よりもシンプルに仕上げることが出来ている。

Screen Shot 2022-06-12 at 9.05.32.png

Screen Shot 2022-06-12 at 9.11.00.png
posted by Yasuski at 01:34| LaVoixski

2022年06月10日

LaVoixski@ID-292版の基板をリファインする

システムの設計上、LCDの使用はもはや必須となったので、

Screen Shot 2022-06-10 at 1.35.38.png

「LCDを導入しない選択肢」を持たせていたID-292タイプの基板を再構成することにした。

Screen Shot 2022-06-10 at 18.35.38.png

ついでに、D2/D38のジャンパ線を直結に変更した。 このラインの信号は極低速度なので、複雑な引き回しを行っても問題が発生することはない。

Screen Shot 2022-06-10 at 18.35.48.png

LCDで使用するデータライン SPI0 は、D11/D13に対応しているので、これらの端子を出来るだけ太いパターンで引き出すことにした。

Screen Shot 2022-06-10 at 13.18.33.png

LCDユニットとの接続は、最終的にはリボンケーブルによるジャンパー配線になってしまうのだが、せめて基板上の信号線をシンプルに設計することを心掛けている。

Screen Shot 2022-06-10 at 13.18.01.png

オーディオ系の高速通信ラインはMCU側のD25/D26、PLL/ICの出力からFPGAに至るCKW、DAT1、ACLK で、これらの配線を可能な限りシンプルなシェイプで行っている。

Screen Shot 2022-06-10 at 13.18.19.png

D25/D26に使用する配線材の幅は、折衷で0.012吋とした。

Screen Shot 2022-06-10 at 13.18.12.png

追記 10.29.22:

FPGAのVHDLを書き換えた結果、全面的に配線を変更することになった。
posted by Yasuski at 14:27| LaVoixski

2022年06月09日

LaVoixski@クリッピング回路について

Distortionスイッチによって駆動される回路の概念図を作成した。

Screen Shot 2022-06-09 at 14.36.01.png

OpAmpの非反転入力に印加するBIAS電圧を1/2VCCからGNDレベルに落とすことで、半波整流と同様の効果を得ることができる。



DPSTのアナログスイッチに速度は要求されないので、より安価なモデルを選択出来る。

Screen Shot 2022-06-09 at 22.06.25.png

また、入力の前段には、オシレータ出力を加算する際に敢えてオーヴァーレベルに加算値を設定する項目に対して、

Screen Shot 2022-06-09 at 21.05.19.png

レベルの変動を軽減するためのアッテネータを設定している。 この部分のスイッチには、時定数を設定したアナログスイッチ(ディスクリート)を使用する。

データ上でクリッピングを行った時の出力波形。

Screen Shot 2021-12-02 at 15.24.17.png

このように、本システムにはアナログとデジタル両方式によるクリッピング回路が実装されているが、アナログ方式によるハーフクリッピング回路には、よりマイルドな方向の変化が期待される。
posted by Yasuski at 21:17| LaVoixski

2022年06月08日

LaVoixski@PCBの高速信号ラインを再設定する

最も高速な信号が流れるポイントを失念していたので、ラインがシンプルになるように修正を行った。

80mm幅の基板は、パーツの配置に余裕があるので、よりストレートなラインで高速信号ラインを構築できているが、稼働試験を行う過程で、予期せぬ齟齬が見つかる可能性がある。

LV80mm0608_22.png

一方、60mm幅の基板は部品の配置がタイトになっているために、高速信号を扱うラインのシェイプに若干の問題が生じることになった。

LV60mmGNDpat0608_22.png

今回の設計では回路構成の決定によって不要になったパーツやポートを撤去して、よりシンプルな配線を目指す。 基板は引き続き、MCUの端子を引き出せる拡張性をキープしているが、ブレッドボード的な使用感は後退することになった。

LV60mm_0608_22.png

FPGAを使ったデータ転送システムのデータラインには周波数400MHz前後のバースト信号が流れる。

Screen Shot 2021-12-02 at 14.31.15.png 

また、FPGAではオーディオクロック(MCK)を分周して、DACに供給するLRCKやBCKを生成している。

Screen Shot 2021-09-30 at 5.54.45.png

オーディオクロック(周波数は約12MHz)はこのラインからFPGAに供給される。

Screen Shot 2022-06-09 at 7.33.13.png

Screen Shot 2022-06-09 at 7.47.53.png

こちらのラインにはMCUから出力されるデータを確定するために同期クロックが乗る。

Screen Shot 2022-06-08 at 10.56.41.png

このラインにはMCUからのオーディオ・データが流れる。 以上はFPGAをDMAの代わりに使うメソッドで、とりあえずは最大で6ch分のアウトプットを想定している。

Screen Shot 2022-06-08 at 10.56.37.png

オーディオのサンプリングレートは44.1kHz固定で実験しているのだが、多分96kHzの運用は不可能だろう。

Screen Shot 2022-06-08 at 11.11.10.png

配線長の影響により、データとラッチ用のクロックの位相のズレが発生する可能性が予想される。 よって、配線の引き回しは慎重に行わなければならない。

Screen Shot 2022-06-08 at 10.49.29.png

posted by Yasuski at 13:06| LaVoixski

2022年06月06日

LaVoixski@基板のデザインをCortex/M7専用に変更する

M7を導入した切っ掛けで激変したシステムの仕様がほぼ固まってきたので、変更箇所を反映したMCU基板二種の設計を始めている。 

まず、試作段階ではジャンパ配線だったBCK/SCK等のオーディオクロック系のデータラインを、PCB上に再配線した。

WXK/LRCKは100kHz以下と周波数が低いので、寄生容量の問題は発生し難いと思われる。

Screen Shot 2022-06-06 at 7.23.50.png

BCKは64FSなので、寄生容量の影響は微妙なところ。

Screen Shot 2022-06-06 at 7.23.55.png

オーディオ/システムクロックは256FSなので、可能な限り配線のラインをシンプルにしている。


Screen Shot 2022-06-06 at 7.24.13.png

ch1/2のデータクロックの配線。

Screen Shot 2022-06-06 at 7.24.43.png

ch3/4のデータクロックの配線。

Screen Shot 2022-06-06 at 7.24.49.png

MUTEスイッチの配線。

Screen Shot 2022-06-06 at 7.24.59.png

こちらは、LCDのクロックライン。 ルーティングが遠回りなので、配線は可能な限り太くした。

Screen Shot 2022-06-06 at 7.25.29.png

LCDのデータライン。 配線が細くなってしまったのが心配。 SPI0を選択せざるを得ない現状は、配線の取り回しに問題が生じてしまう。

Screen Shot 2022-06-06 at 7.25.53.png

基板設計の過程で、配線パターンを基板上に引き回すのと、ジャンパ線でポート間を直結するのと、どちらがまともに信号を伝達できるのかよく判らない問題が浮上している。  

容量が影響した結果発生するリンギングや、EMIによるデータの乱れが懸念されている。 一方、運用面での実績はブレッドボードという非常に不安定な環境で積み重ねているので、PCB化によって発生する弊害は無視できそうではあるが、2層基板で高密度実装を行うための極細配線の採用によって障害が発生する可能性がある。
posted by Yasuski at 08:21| LaVoixski

2022年06月03日

LaVoixski@ID-292基板のDAC周りにミスを発見する

今度はなんと、DAC2に至る電源ラインの構築を失敗しているケースが発覚。

原因は、FMT端子周りの設計を変更する段階で「再配線」に必要となる作業を端折るために”R”をショートモードで挿入したことにあり、電源ラインの予期せぬフローティングを許すというとんでもないミスが発生することになった。

Screen Shot 2022-06-03 at 5.13.47.png

問題の箇所をクローズアップした画像を示す。

元のパターンのままではDAC2に電源が供給されないという、有り得ないレベルのミスだが、初期の設計段階に於いてFMT端子の扱いを電源直結の”H”レベル固定としていたところに、ソフトウエアから制御を行う事を前提に端子を開放した場合を考えて、プルアップのRを追加ところに齟齬が生じた。

Screen Shot 2022-06-03 at 5.15.35.png

つまり、電源ラインが確保されていない状態であっても、チェック機能がスルーされてエラーが発生せず、本来はRで浮かすべきDAC2のMUTE端子に電源ラインが直結された一方で、肝心の電源ラインが孤立する形となった。

画像では、DAC1からDAC2に流れてきた電源ラインが、”20番端子”にロジックレベル”H”を供給する形で接続されていて、本来”24番端子”に接続されるべき電源ラインが浮いて仕舞っていることが判る。 今回のケースでは、回路図上では表面的な「間違い」が認識されず、チェックすり抜けることになった。

こちらが修正版の画像。 FMT端子にジャンパ配線を接続するポートを追加するスペースがないので、MCUからの結線はSMD抵抗チップの端子から直で行う形となる。

Screen Shot 2022-06-03 at 5.57.27.png

このように、DACのパッケージを大周りするパターンで電源ラインを再構築している。 ミスが発生していた基板1枚にパーツを実装してしまったが、、、

Screen Shot 2022-06-03 at 5.56.01.png

部品は取外さずにプリントパターンの切り離しとジャンパー線の追加でなんとか対応出来そうな内容ではある。

追記:

不合理な位置に配置されていた電源カップリング用コンデンサの実装ポイントを、DACの上方に修正した。

Screen Shot 2022-06-03 at 6.29.51.png

しかし、これだけ訳の解らないことをゴチャゴチャとやっていた理由を今となっては全く思い付けないのだが、、、

Screen Shot 2022-06-03 at 12.22.02.png

妙な形で視野狭窄に陥っていたのだろうなあと、薄ら寒い気持ちになっている。 電源ラインの未接続に関する失策はまだ理解できるのだが、パーツを不合理なパターンで配置する理由が全く判らない。

本当に、意味を感じられない行為なのだ。

posted by Yasuski at 06:09| LaVoixski