2018年07月20日

Open.Theremin@左手に拠るSequencerの制御を考える

音量をオフっている期間が一定時間を過ぎるとSequencerのstepカウンターがリセットされる機能を思い付き、これを追加した。

スイッチの代わりに、音量がゼロの状態をトリガーにする仕掛けだが、スタートスイッチとして一瞬は働いたものの、長押し(音量ゼロの)を判定するタイマーのリセットが、カウント一巡で再トリガーが掛かる事案を解消できず、構想は失敗に終わった。

やはり、単純なスイッチを増設するのが正道だと思うが、もう少し構造を検討してみようと思う。

で、こちらも左手関連の技術で、テンポを変える機能を考えた。

これは、ある閾値を超えた時に左手のValueをStapRateに換算し、テンポを送らせていく機能だが、左手のセンシングのレンジが異様に狭いことが発覚。これによりVolumeAntennaをセンシングしたデータの処理に関する根本的な問題が発覚してしまい、本来の機能を実装する以前のレベルで修正を行うことになった。

と、紆余曲折があったものの、なんとか実装を完了することが出来た。

WS001382.JPG

実際の運用方法は簡単で、左手をアンテナからある程度の距離に離すと、テンポが徐々に緩くなるリタルダンドの機能が実現する。 自動演奏のテンポを意図的に揺らすことが可能になったのは割と大きな進歩かもしれない。
posted by Yasuski at 17:35| AudioElectronics

Open.Theremin@Sequencerのデータ入力にCS#V規格を新設する

CSVならぬ、C#SVなる珍妙な規格を思いつく。

これは、2biteの処理がややこし過ぎて自分の実力では導入が難しく、だったらカンマの代わりに#で音階を区切ることで、半音高い表現をする目論見。

要は、”n” とか ” p " などの音楽系としては使い慣れない文字を可能な限り排除したいだけ。

実際の使い方は、休符を入れて、

@,c,c#d,d#e,f,f#g,g#a,a#b,c

といった記述になる。 

'、'の代わりに '#'を検知すると、sharpのフラグを立てて、条件分岐を行う仕掛けで、とりあえずはまともに動作している。

WS001381.JPG

オクターヴ上は大文字のCに、その上は、nnっぽく数字の0から9と o,p,q (A#からCまでに該当させる)を使うことにする。

結局はこの規格もなんかややこしそうだが、概念的には「普通」に近いので、慣れればなんとかなるかもしれない。
posted by Yasuski at 08:46| AudioElectronics

2018年07月17日

Open.Theremin@CSVファイルのインポートを可能にする

CSV形式で記述された波形データを外部から取り込めるように、SDカードからのデータ読み出しルーティンに細工を行った。



テストベンチでの動作は確認できているが、楽器上での運用試験は未了。
posted by Yasuski at 19:40| AudioElectronics

2018年07月15日

SDカードにデータをハンドリングする

早朝ギニアからのアフリカンポップを聴きながら始めたコーディングは途中の小休止(居眠り)を挟んで、ようやくSDカードとのデータのやり取りのメソッドが確立しつつある。

SDカードのデータ型はcharなので、MCUとデータのやり取りを行う際に「翻訳」が必要になるが、一度に1biteずつしかデータを読み出せないところが大変に不便な仕様である。

WS001367.JPG

で、これを解消するためにはcharのArrayを組んで、そこに文字列を読み込ませたものを数値に変換するのだが、

WS001368.JPG

このメソッドを探すのに5時間ほど掛かってしまった。

日本語のサイトは殆どアテにはならず、最終的にTeensyのコミュニティーの記事に頼ることになったが、SDカードを使用する場合はその殆どがデータロガーシステムや映像系等だったことから、求める情報にたどり着くまでに時間がかかってしまった。

もちろん、英語の語彙の問題もあるわけだが、何故か日本語で検索しても埒が明かないという、結構ツライ体験をしたのだった。 やはり、嫌でも英語の理解は重要ということか。

画像は、立ち上げからSDカードのマウントを行った後、パラメーター群の初期値を読み込んで、Arpeggiatorのループが開始される模様。 

WS001363.JPG

後半に記録されているArpeggiatorのステップの変移は、読み込んだSequenceのステップ数がそのまま反映されている。

WS001364.JPG

昨日はこの「立ち上げ」に至らず往生したのだが、これは単にハードウエア単位の設定を間違えていたという凡ミスだった。

WS001366.JPG

作業が遠回りになった原因は、SDへのアクセスがままならない時期に予め実験でダブルクオートで変数を囲う形で変換のシミュレーションを行っていたことで、これを文字列を扱えるように改変する過程で思考が硬直してしまい、無駄な時間を過ごすことになった。

その後、シーケンサーの辻褄が合わないところを修正した。 

WS001369.JPG

何故かstep数が過大にカウントされていたが、3個多いという法則性があったので、問題なし。 

WS001365.JPG

これで、適当にフレーズを書き込んでも、勝手にステップを合わせてくれるようになった。

このまま上手く行けば、EEPROMを使わずに外部記録装置に設定を保存できるようになるわけだが、波形の記録から、ゆくゆくはバックトラック音源の再生など、さらなる機能拡張の可能性を確保できたのは大変有意義なことだと思う。

これから、各パラメーターの項目を地味に書き連ねていく作業に入るつもりだが、この気温の所為でそろそろ脳が沸騰してきた。
posted by Yasuski at 17:02| AudioElectronics

2018年07月14日

Open.Theremin@ピッチテーブルの扱いについて。

 @xx none
Char/1biteを#nnに対応させるテーブルを作った。
 cc 24nn 
 ics 25nn
左がSDカードに記述するノート、中央がスケッチ
 dd 26nn
上に抽象化された記号、右が実際の音程。
 jds 27nn
抽象化されている記号は実際には数値化されている。
 ee 28nn
例えば、c は0.25、cs は pitch1 * 0.25 と
 ff 29nn
なる。 pitch1 = 1.0600; で、これはcの半音
 kfs 30nn上の音程を意味している。
 gg 31nn 
 lgs 32nn 記述のメソッドは、スペースやカンマを用いずに
 aa 33nn 連続して行う。xxは休符。連続した音列は持続音
 mas 34nn となる。
 bb 35nn 
 CC 36nn 最終的には、数曲のシーケンスを格納して呼び出せる
 ICs 37nn ような仕掛けを実装する予定だ。
 DD 38nn 
 JDs 39nn 
 EE 40nn 
 F    F 41nn 
 KFs 42nn 
 GG 43nn 
 LGs 44nn 
 AA 45nn 
 MAs 46nn 
 BB 47nn 
 nC2 48nn 
 oCs2 49nn 
 pD2 50nn 
 qDs2 51nn 
 rE2 52nn 
 sF2 53nn 
 tFs2 54nn 
 uG2 55nn 
 vGs2 56nn 
 wAA2 57nn 
 xAs2 58nn 
 yB2 59nn 
 zC3 60nn 
posted by Yasuski at 13:19| AudioElectronics

SDカードにデータをトランスファーする方法(その3)

SDはキャラベースのファイル名でデータを管理するので、データをEEPROMに記録する場合に対応するアドレスをロータリーエンコーダーを回して順送りで呼び出していたようなことは出来そうにない。

混乱を避けるためファイルには関連するパラメーター群の数値を一気に記述せずに、対応するパラメーター毎にファイルを作る方法を考えている。 例えば、オシレーターのチューニングの場合、Memoryアドレスに対応する4つのパラメーターを別々に記録することになる。

つまり、記録を行う毎にファイル名を記述した条件分岐を設定する必要があるということで、これは結構な手間になる。

SDメモリー側には、予め対応するパラメーター分のファイル群を準備しなければならない。

パラメーターのアップデートに関しては、EEPROMで行っていた時よりも簡略化が出来るかもしれないが、何れにしても実験段階で記録装置の構造を詰めておかないと大混乱に至ってしまうだろう。

記述の煩雑さは、この例を見れば一目瞭然。

WS001360.JPG

検証用のシリアル通信が各所に挿入されているとはいえ、フォントサイズを4つ縮小しても、画面からはみ出してしまう。

WS001359.JPG
posted by Yasuski at 06:35| AudioElectronics

SDカードにデータをトランスファーする方法(その2)

単純に数値を変換するのであればあまり問題は無さそうだが、これをコード名などの抽象化されたものを扱う場合にどう処理すればよいのかが、イマイチ判然としない。 チューニング用のテーブルを作って、対応する数列をチョイスするような条件分岐を作り、それをシーケンス用のテーブルに登録することになるのだろうが、これは相当ややこしい。

作業の取っ掛かりとして、まずはチューニング表を作ることにしたが、5オクターヴもあれば十分だろうか。C4=60nnと同一の仕様にしたら概念が統一されて混乱が少なくなるだろう。 で、事前にあれこれ調べてみたが、Charを扱う場合は2biteになったとたんに処理がややこしくなるので、ASCIIキャラ1個につきnnを対応させるような独自表記で誤魔化したほうが良さそうだ。 データを1biteに抑えれば処理が簡単なので、無理くりではあるが独自規格の対応表を作ることにした。 一般的にはアプリ作って自動化するのが正解なのだろうが、いちいちIDEを開いて数列を撃ちこむよりは遥かに楽なので、アプリの製作には格別拘らなくても良さそうだ。

で、試しにラフな条件分岐を作って実験を行った。

WS001355.JPG

何故か理由は判らないが、Arrayの末尾に2つ空データを返していたので、その差分を引いて修正を行った結果がこれ。

WS001354.JPG

謎の空データが2つ追加されていた問題は、コピペ元が小数点のキャラクター分をアレイに追加していたのを失念していたこと、データを落としこむためにforで廻す際に、文字列の長さから1を引くのを忘れていたこと(1から16ではなく0から15になる)が原因と判明した。

WS001358.JPG

処理の違いを確かめるためにキャラクターを個別にダブルクオートで区切った場合と、

WS001356.JPG

羅列した文字列をダブルクオートでラップしたものを比較してみたが、同じ値が帰ってくるようだ。 ASCIIコードに準じてスペースやカンマは文字列として認識される。

WS001357.JPG

次のステップは、アドレスを読みだすシーケンサーを加えて、データをドライヴ出来るかどうか実験してみよう。 forを回している「n」が、そのままアルペジエーターやシーケンサーのstep数の設定に使える筈だ。
posted by Yasuski at 02:41| AudioElectronics

2018年07月13日

SDカードにデータをトランスファーする方法

microSDHC16GB class10 UHS-1の価格が1000円を切っていたので、これを評価用に購入した。

Teensy3.5/3.6にはmicroSDのソケットが標準装備されているので、これを使った実験を行いたい。 本当は1G程度でも十分すぎる位なのだが、最近は容量が小さくて速いものはまず商品化されていない。 SDカードの使用用途を考えると当然なのではあるのだが、、、。

SDカードのデータ型はキャラクターなので、数値を記録する場合はデータ型の変換が必要になってくる。

いろいろと調べてみたところ、まずSDカードにデータを送信する前準備の手段としてこのような記事を見つけた。

データを送る場合は、

dtostrf(write_var, 16, 14, outstr);

のように、データをWrapせねばならんようだ。

次に受けの方だが、Arduinoにはstring.toFloat()という便利なものがあるものの、これは下桁が丸められちゃうマヌケな仕様なので、別の方策を探すことになった。

で、見つけたのがこの方法で、

char inChar[inData.length() + 1]; //determine size of the array
inData.toCharArray(inChar, sizeof(inChar)); //put readStringinto an array
read_var = atof(inChar); //convert the array into a float

といった手段を取ることで、文字列のデータアレイから浮動小数点の結果を引き出している。

目的達成のための手段がはっきりしてきたので、ここからスケッチを書いていったのだが、 シリアル表示の関数 printIn は小数点以下2桁で丸めが行われてしまうために、浮動小数点を扱う動作の確認ができない。

その後、小数点以下がまともに表示されるprintfという関数を見つけたが、これの実装がどうやっても上手く出来ず、暫くの間悩まされることになった。 

折衷案として読みだしたデータを1000000000000000倍に拡大する手段を思い付いて、問題は解決した。

WS001352.JPG

が、、、若干の誤差が出るのが少々気持ち悪い。 果たして、これは「仕様」なのであろうか???

WS001351.JPG

SDカードはEEPROMのようなアドレス指定ではなく、ファイル名の指定でパラメーターを保持することになるのだろうか? 波形データ等大きめなファイルも格納できるので、ちゃんと仕組みを作ると相当便利になると思う一方で、データがぶっ飛ぶと全てが終わる。 その辺のリスクの重さは実際に運用してみないと判らないだろう。

データアレイは、sizeof( )を使うと自動でキャラクターの数を測って、文字列の長さが異なってもちゃんとデータを読み込んでくれる。これをシーケンサのステップ数の自動計測に応用できれば、パターンの作成がとても楽になると思う。

SDカードでデータの保持が行えるのであれば、ネット上に波形編集アプリ等の管理系サービスを展開するのが今風なのかもしれない、、、。
posted by Yasuski at 13:58| AudioElectronics

2018年07月08日

Open.Theremin@デバッグのまとめ

昨日の流れはデバッグ作業が中心だったのでその内容をまとめておく。

まず、記録不能だったアドレスを修正した。これは機能を削っていた部分を復活した際に、別の該当する部分のラインをコピペして、アドレスの修正を多なっていなかったために発生した不具合だった。

Screen Shot 2018-07-08 at 8.53.45.png

次に、用法上の問題で、ついオーヴァーレベルになってしまう波形編集のヴォリューム設定ノブのデータ出力を右シフトして、変化を鈍化させる手当を行った。これは、ロータリーエンコーダーのアクセラレーション機能が過剰に作用する弊害で、微調整が必要な項目には手当を行うべきということで、他のCHのパラメーターにも調整を行っておいた。

Screen Shot 2018-07-08 at 8.55.45.png

バックパネルに追加したMAX5541の接続が怪しいので、ハンダメッキなどの手当を行っておく。

実際に追加機能を利用した演奏方法を探っているが、やはり事前のプリセットが勝負どころというか、波形の選択が全てを決することが解りつつある。これは、プリセットを含めて全容を考え直す必要があるということだが、こればかりは、実際に運用を行った結果をフィードバックするしかない。

所謂楽器とガジェットの境目は、この用法の確立という点に掛かっていると自分は思っているので、機能の開発と同時に実践的な用法の発見を行うことを忘れないようにしていきたい。

追記:

ピッチデータのEEPROMの格納領域を拡大して、リアルタイム処理の負荷を軽減する事を目指した。

今いじっているプログラムは基本構造がTeensy3.2の仕様に準拠していて、限られたEEPROMの容量に合わせて記録するデータを圧縮していたが、その分リアルタイムの処理に負荷が掛かる構造だった。

Screen Shot 2018-07-08 at 8.51.41.png

Teensy3.6はEEPROMの格納領域が2倍もあるため、この処理に掛かるピッチ係数をEEPROMへの記録時に計算して登録してしまえば、その分リアルタイム処理負荷が軽減される筈。

ということで、データ幅をint16_tからfloat64_tに変更して記録を行うように、EEPROM関連のコードを書き換えた。

Screen Shot 2018-07-08 at 8.49.36.png

メモリーが足りなくなった後半部分ではセコく立ちまわっていたようだが、基本的には混乱を避けるために「足りないメモリー状況下であっても、余裕を持たせて大雑把にメモリーアサインを展開」していたことがラッキーだったようで、該当するメモリー領域の拡張はすんなりと行えた。

実験の結果、CodeMemoryMode選択時で感じていた処理の遅れによるザラザラ感が軽減された。
posted by Yasuski at 02:03| AudioElectronics

2018年06月24日

死亡したTeensyを復活させる方法

USBによる接続が不可能となったTeensyを復活させる方法を見つけたので備忘録を書いておく。

原因は定かではないが、一種のシャックリのようなものと思えば良いらしく、接続が絶たれただけでMCU自体は死亡していないようだ。

対処法はMAC系のプラットフォームを使用する場合が簡単なようだ。 まずはArduinoを起動して、なんでも良いからスケッチのコンパイルを行い、Teensyの書き込みソフトを起動する。 次に、故障したMCUのリセットボタンを押しながらUSB端子を接続すると、あら不思議、何故かデバイスの認識が行われ始める。

これで、死んだと思って放置していたTeensy3.5と3.6の2個ずつ、計4つのデバイスを復活できた。 ここで断捨離をやらかしていたらこの発見はなかったわけで、とにかくゴミと思われるものであってもある程度は保持する必要があるのだな、、、と痛感させられた次第。
posted by Yasuski at 01:07| AudioElectronics

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月18日

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

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年04月08日

Open.Theremin@動作検証用の新型機の製作を失敗する

バックパネルの結線チェックを行った後に通電したが、一部LEDが点灯するのみで動作しないことが判明。

不具合を整理すると、

1)まずテルミンの根幹部分でもあるアナログオシレーターが何となく機能していそうな挙動を示すものの、波形がえらく汚く、ゼロポイントを検出するどころではない。 
2)Volumeが600kHz/Pitchが230kHz辺りに居るが、これは計算とは大きく違う。 
3)起動時にピポパ音が聞こえないことから、DACは全く動作していない。 
4)RGBロータリーエンコーダーのうち上側のLED配列がおかしい。 
5)下側のエンコーダーは全く発光せず。 

以上、不具合はプログラムミスを含めてハード/ソフトにまたがるものと判明している。 

対策が最も容易なものはLED配列の修正で、これは端子の設定を修正すれば良さそうだが、全く点灯しない下側の方はハードウエア面の不具合の可能性があり、ロジック・アナライザを使ってTeensyの動作をチェックすることになる。 

同様にDAC関連の端子もロジック・アナライザを使ってチェックする。MAX5717は動作が確認されていないので、実績があるMAX5541の方を優先的に検証したほうが良いだろう。 

オシレーターは基板をバラして発振状態を確認することになるが、こちらは事故を起こさずに検証を行うための基台を新たに製作した方が良いだろう。
posted by Yasuski at 06:35| AudioElectronics

2018年02月21日

OpenTheremin@Toslinkデバイスの実装を行う

IMG_7915.JPG

専用のアルミアングルを製作して、Toslinkデバイスを基板に固定した。 取り外しが手間なので、信号分岐用のポートを増設したほうが良いだろう。

IMG_7907.JPG

アングルを取り付ける際にクリアランスが問題となったが、ポリカーボネート製のナットを削ってギャップを解消している。
posted by Yasuski at 12:29| AudioElectronics

2018年01月31日

OpenTheremin@OverloadModeの波形を観測する

先に録画したTransitionにOffsetを掛ける音声の波形を表示してみた。



複雑な倍音構成がシームレスに変化していくのが判る。
posted by Yasuski at 22:36| AudioElectronics

2018年01月15日

またもや機材車のエンジンにトラブルが発生する

夕方になって買い物に出かけるつもりがVWの6気筒エンジンにトラブルが発生、エンジン関連の警告灯が点灯してパワーが上がらない。エグゾーストパイプから異臭がするのは生ガスを吹き出している証拠。

出立を諦めてクルマに診断用のデバイスを接続して故障箇所を探るってみると、1気筒目がミスファイアを起こしている模様。フードを開けてイグニションコイルユニットを引き抜くと恒例のイグニッションコイル折損事故(3回目)な事が判明する。

とりあえず、工具を持っていそうなJAFを呼んで、折れた部分の引き抜きを依頼するも、サービスカーは狭い部分に届くプライヤーを持ちあわせておらず、当てが外れる。 結果、自力修理、もしくはディーラーまでクルマを牽引というアレな状況に。

折損するVWのイグニションコイルは明らかに欠陥品だが、何故か日本のディーラーはそれを認めず有償修理扱いという鬼畜な対応なので、出来れば自力で修理を行いたい。

こんなこともあろうかと1年半前に輸入していたスペアを活用する絶好の機会が到来したのだが、プラグホール奥に鎮座する折損部を引き抜かないことにはスペアパーツは役に立たない。

で、JAFのおっちゃんと協議した結果、歯医者が持っていそうな返しの付いた工具で対応できるのでは?との示唆を貰う。

ナルホドその手があったかと、ひとまずJAFにはお帰り頂いて、在庫している自転車用チタンスポークの折れ曲がった部分をダイヤモンドルーターで研磨、折損部のクリアランスにねじ込んで折れたパーツを引き抜くための工具を自作した。

チタンスポークは激硬いので強度的には問題なさそうだったが、押し込んだ工具を回転させるのが難しい。トルクを加えられるように、スポークのストレート側を折り曲げて持ち手に加工した後、折損部の一番奥に至るまでスポークを押し込み、これを回転させて詰まった折損部を引きぬくことが出来た。

心配だった代替パーツの互換性は問題なさそうな感触だったので、町内を一周してエンジンの動作を確認しておいた。

まだヤバそうな死亡が確定しているパーツがあと3本残っているので、保険のために改めて代替用のパーツを発注しておいた。製作した治具は使い易いように再加工して、故障判断デバイスのケースに入れておく。

今回は、合計で20K程の節約ができた計算だが、そもそもリコール扱いのパーツをなんで自腹で揃えにゃならんのかと微妙に納得いかないのがトホホ。
posted by Yasuski at 04:20| AudioElectronics

2018年01月10日

MEMSなスピーカーが発売されるらしい

これとMEMSマイクを組み合わせて、ホースから開放されたトーキングモジュレーターを造りたいのだが、とりあえずセンサーの構造を考えてみると、、、

usoundmoon630.jpg

細い棒の先に防滴構造に加工した振動体を取り付けたものを口盆内に挿入し、マイクはその同軸上に設置することになるのだが、、、センサーの支持構造に工夫が要りそうだ。

posted by Yasuski at 05:49| AudioElectronics

2017年11月10日

目玉スイッチの作り方@直径6mm編

目玉スイッチに仕込んだLEDが不良だったので、アクリル製のガワを破壊して、再組立てを行った。

その際、製作のステップを考えなおしたので、その備忘録。

1)まず、直径6mmの透明アクリルパイプを5mm長に切断する。 サーキュラーソウで切断を行う場合は、ピックアップが難しい(ノコ刃の隙間に切り出した部材が入り込む)ので、材の厚みギリギリに刃の深さを調整すること。

2)表面実装LEDは0805サイズのものを使用する。 耐熱両面テープでLEDを固定した後、水平に極細の配線材をハンダで接合する。

3)切り出したアクリルパイプの切断面を研磨した後、側面に配線を通すため1mm径の穴を貫通させる。

4)タクタイルスイッチのシャフトには予めOリングをはめ込んで、アクリルパイプ取付け時のクリアランスを確保しておく。

5)瞬間接着剤を使って、タクタイルスイッチの上面にLEDを固定する。

6)固定したLEDの配線材をアクリルパイプの配線用の穴に通す。 線材は、LEDの上面を交差する形でまとまる。 座りの良い所で、パイプを固定して、瞬間接着剤を滴下する。

7)パイプの固定を確認した後、LEDの通電テストを行う。 問題がなければ、アクリルパイプの上面に薄く瞬間接着剤を塗布し、目玉を取り付ける。

以上、作業時間は慣れれば15分程度。 予めアクリルパイプを切り分けておくと、作業時間は更に短縮できる。

タクタイルスイッチは、シャフト長が異なる製品をまとめたサンプル用のパッケージをebay等で調達するのがお得。
posted by Yasuski at 00:22| AudioElectronics

2017年11月04日

OLED簡易オシロスコープの製作@組立工程を進める

OLED簡易オシロスコープを構成する部品の実装を行っている。

まずは、LED(RGB)をトップパネル裏から両面テープ越しに固定する。

IMG_7777.JPG

ボディー側には、左右両端に取り付け穴を空けた後、Hirose/6pinコネクターを取り付ける。 オシロスコープは信号ラインに挿入する形で接続するので、端子間の配線は直結としつつオーディオ信号と電源を分岐させる。

IMG_7778.JPG

オーディオ信号は入力バッファーを介してオシロスコープに入力するので、Quad/Dualタイプのオペアンプを増設する必要がある。

基板との配線は、ブレッドボード用の配線材を流用する。

IMG_7779.JPG

各端子には丸ピンを配置している。

当初は、GFRPの厚板でVR取り付け用のシムを、

IMG_7780.JPG

GFRPの薄板でOLEDの保護パネルを製作していたが、、、

IMG_7783.JPG

クリアランスと視認性の問題が発覚したために、素材を再び吟味することになった。

IMG_7781.JPG

検討の結果、それぞれ素材をGFRPの薄板と透明アクリル板に変更している。

IMG_7784.JPG

GFRP製のシムには、カットシート(紙製)を貼り付けた。

IMG_7785.JPG

Hirose/6pinは取り付け穴の加工が難しい。

IMG_7786.JPG

心配していたプラグとの干渉は発生しなかった。

プログラム側の変更点は、OLEDのドライヴ速度を高速化するためにライブラリのdigitalRead(Write)をdigitalRead(Write)Fastに書き換えている。

残るは、タッチスイッチとオペアンプの実装だが、タッチスイッチの製作には欠品している部品の調達が必要。
posted by Yasuski at 07:04| AudioElectronics