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

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



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



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

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



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

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



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



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



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



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

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

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



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

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

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

ParadisAvalonに、KrivoMicroPAFピックアップを装着する

このピックアップは高さが6mm程と非常に薄いのが特徴で、強力な磁力を持つネオジウム磁石を使うことによってロープロファイルを実現しているのだという。　弦とボディーのクリアランスが極端に小さいParadisAvalonにボディー加工無しでマグネティック・ピックアップを取付けるには薄いピックアップを選ぶしかないのだが、PAFを模した音質を実現していることを評価した。

当初は代理店経由で購入したこちらの仕様のピックアップを搭載しようとしたのだが、、、何故か１／２弦の音をまともに拾うことが出来ない。　



音質はフェイズが反転したハーフトーンのような感じで、信号レベルが低いのに歪を伴っている点が謎だ。　このままでは使い物にならないので、１／６弦の方向を変えてみるも状況に変化はない。　

試行錯誤の結果、ピックアップを裏返した状態で正常っぽい状態の稼働を確認できたが、



それでもどこか歪っぽい音質が気になった。　この薄さをもってしてもフロント位置へのマウントは叶わず、今回は折衷策でミドル・ポジションに固定している。　この位置にピックアップを配する利点はハーモニクスが拾える点で、音質面の不満を感じことない。

再生できない場合、ダウンロードは🎥こちら

後日、ピックアップをフローティングさせて弦の上側からのセンシングをチェックしたところ、クリアランスを十分に取らないとまともに音を拾えないことが判明した。　感度が高すぎるのだろうか？　あと、グランドが浮き気味なのか、盛大にノイズを発することがあった。　ピックアップのボディーを強く押さえるとノイズはひとまず収まったが、グランドラインの接触不良が疑われる。

実は、製造元のサイトにも微妙に違うヴァージョンのピックアップが在庫していたので、



こちらも購入することにした。　同じメーカーの同じ銘柄の筈なのだが、露出しているポールピースが一列で外装にはロゴが入っている。



で、何故か表側の配置でもトラブルは発生せず、正常に音を拾えているようだ。

再生できない場合、ダウンロードは🎥こちら

本来このピックアップはシールド線をピックガードの下を通す設計なので、このままでは配線の取り回しが気になる。

試しに車載レーダーの取り回しに使ったクリップで



線材を固定したが、ひとまずはこれで問題なさそうだ。　仮設置の現在はエンドピンに引っ掛けたジャックから音声を出力しているが、最終的にはギターの電装部にシールド線を引き込むことになるだろう。



手造りピックアップは非常に個体差が大きい事がよく判る体験だった。

HighSierraのアップデート時にGPU通電のキャンセルが無効化してしまった場合の対処法

MBP2011y上の故障したGPUの通電を阻止して、起動時に発生するスタックの回避を行う作業の流れを以下に示す。

一連の作業は、MacRumorsに公開された記事を参考にしている。



1）SMC Reset
　　シャットダウン時に、leftShift + Ctrl + Option + Power for about 15 secs
2）PRAM Reset
　　起動と同時に、Command + Option + P + R　を押し続けて起動音を2回確認
3）Boot in Safe Mode
　　シャットダウン（強制）後に、Command + S　で再起動。
4）Manually type　後にリターン
　　nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
5）Manually type　後にリターン
　　nvram boot-args="-v"
6）Manually type　後にリターン
　　reboot
7）再起動時に修復モードを選択、Apple Logo　が確認できる
　　Command + R
8）メニューバーからUtilitiesを選択して、Terminal　を起動
　　
9）Manually type　後にリターン　（何故かコマンドが受け付けられず）
　　csrutil disable
10）Manually type　後にリターン
　　nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
11）Manually type　後にリターン
　　nvram boot-args="-v"
12）Manually type　後にリターン
　　reboot
13）Boot in Safe Mode
　　Command + S　で再起動。
14）Manually type　後にリターン
　　/sbin/mount -uw /
15）Manually type　後にリターン
　　mkdir -p /System/Library/Extensions-off
16）Manually type　後にリターン
　　mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/

この16番目の操作の結果、“Directory not empty”　と表示されて、操作が撥ねられるケースが報告されていて、今回も同じ現象を確認している。

この場合の対処法は、該当するファイルの強制消去で、、、

17）Manually type　後にリターン
　　rm -rf /System/Library/Extensions-off/AMDRadeonX3000.kext
18）Manually type　後にリターン
　　touch /System/Library/Extensions/
19）Manually type　後にリターン
　　reboot

現状では、verbose mode　で起動するので、これが気になる人は、、、

20）修復モードを選択して起動、Apple Logo　を確認
　　Command + R
21）メニューバーからUtilitiesを選択して、Terminal　を起動

22）Manually type　後にリターン
　　nvram boot-args=" agc=0"
23）Manually type　後にリターン
　　reboot

以上で作業は完了。

多重故障から発覚した鉛フリーはんだの耐久性について

テルミンのLowerEncoderのプッシュスイッチを押した途端に電源が死亡するという謎トラブルが発生、電源の破壊に引きずられたのか、FPGAがついでに死亡するという最悪の事態に発展した。

取り急ぎ、代替基板の製作を行うつもりだが、破壊の原因が不明なのが大きな不安要因だ。

検査の結果、直接的な原因と思われたRotaryEncoder/VCO基板に問題は発見できず、原因の究明には時間が掛かりそうだ。　PLL関連のパーツとMCUは無事生き残った模様だが、もしかするとMCUの端子が過電圧で死亡している可能性もある。　過去に何回かMCUが破壊された原因は、FPGAの損傷から誘発された結果なのかもしれない。

ほぼ丸一日を費やして故障したテルミンの修理を完了したが、多重故障のお手本と思われるケースに遭遇するのは貴重な体験故、修理の経過を備忘録として記録しておく。

謎の電源バーンアウトでご臨終となったMCUボードをストックしてあった基板＆部品で再建した。通電後のmidroSDを読み込む過程は、LEDによるチェックポイントの表示を見る限り問題なくクリア、制御系も正常に動いている風なのだが、、、何故か全く音が出てこない。VCOのセンシングも行えておらず、何処か根本的なところで失敗を仕出かしている可能性が高い。

試しにオシロスコープで出力波形を確認すると、Pitch側のオシレータが停止しているようだ。アンテナに手を近づけても反応が全く無く、念の為に行ったアンテナの導通チェックでいきなりの断線を確認。原因は、度重なるコネクタの増し締めによるハンダの疲労と思われる。以上が最初に発覚した故障ケースその1。

修理したアンテナを本体に繋ぎ直し、スペアナでオシレーターの発振を観測したところ、ディテクターから正常な差分の発生を観測出来た。が、依然として音が出る気配は無い。試しにDACボードをテスト用のものに載せ替えて確認してみたが、依然として不具合を解消出来ず。

FVCによるオシレーターの差分が検知不能ということは、オーディオクロックそのものが怪しいとまずは考えるべきで、MCKが接続されているD19をオシロスコープで観測すると、何故か1kHzというへんてこな周波数を検知した。

オーディオクロックの不良が明らかになったことで、関連するパーツの中で実装が怪しいSMDパッケージのX'talユニットをチェックした結果、ハンダ不良が疑わしいポイントを2箇所見つけた。怪しい部分を再加熱して導通を確保した後、クロックの発振が正常になった。　その後、FVCの動作を確認。　以上が故障ケースその２。

やっとDACから音声を出力出来るようになった、、、と安心したのもつかの間、何故か音が1chしか出てこない。不具合の原因は明らかに物理っぽいのだが、故障の原因と思われるファクターを潰すつもりでソフトウエアのバグをチェックしてみたが、やはりこちらに問題はなさそう。

「物理原因」といえば、表面実装の電解コンはハンダ付けの不良が発生するケースが多い印象がある。該当する出力ラインのOSコンをチェックすると、これが見事な天麩羅ハンダで音声信号系の断線はこの部分で発生していたことが判明、接合をやり直してひとまず正常化に一歩近付けた。　以上が故障ケースその３。

これですべての問題が解決された筈だったのがOP3が出力されない問題が浮上、あからさまにアンプのセッティングが怪しく思われたので、アンプの入力に正しい設定を行った後にOP3の出力を確認した。　本件は故障とは違うケースだったがアンプのセッティングが勝手に変わっていたのが不思議というか不気味だ。

今回遭遇したケースでは多重故障の影響で原因を絞り込むことが出来ず、延べ時間20Hあまりを掛けて問題を解決しなければならなかった。　諸々のトラブルが発生した直接的な原因は「衝撃と腐食に弱い鉛フリーはんだ特有の症状」が集積したものと判断している。

本件は、特にライヴ演奏等の移動による酷使を想定した器材の信頼性が、経年劣化により著しく低下する可能性を示唆している。　鉛ハンダの使用が禁止された以降に生産された機材にはなんらかの予防措置を行うべきなのだが、対象が広過ぎるためにその実行は難しい。

ちなみに、航空宇宙産業等の過酷な運用環境が想定されている製品には鉛フリーはんだの使用が禁忌となっている模様。

http://sma.jaxa.jp/TechDoc/Docs/JAXA-JERG-0-043C_N1.pdf

ESP32のセットアップについて

昨日はフットコントローラーに内装したESP32側に設定した「ホスト側から出力設定のコールを受けるまでmidiストリームが出力されない仕様」を失念していたために、ソフトウエアの検証に延々と嵌ってしまう愚を犯して5時間ほど無為に過ごしていたのだが、検証の過程でADCの入力域の調整が必要になったため、以下のコードを参考に対策を行った。

typedef enum {
ADC_0db,
ADC_2_5db,
ADC_6db,
ADC_11db
} adc_attenuation_t;

/*
* Set the attenuation for all channels
* Default is 11db
* */

void analogSetAttenuation(adc_attenuation_t attenuation);

/*
* Set the attenuation for particular pin
* Default is 11db
* */

void analogSetPinAttenuation(uint8_t pin, adc_attenuation_t attenuation);

要はピン毎にアッテネータの値を設定できるということで、この機能を使えば無駄にオペアンプを増設する必要がなくなるかもしれない。



また、コールなしでは出力が沈黙してしまう仕様が使い辛かったので、立上り時に出力値の選択が行えるようにデフォルト値を設定しておいた。

FPGA用IDEのライセンシング

毎年忘れてしまうので、メモ。

まずはサイトにアクセスして指示を仰ぐと、「Licence Key発行のための必要なPhysical Address情報をコマンドプロンプトを開いて獲得しろ」と書かれているので、例示されたコマンドを打ち込んでそれを実行する。　

コマンドプロンプトに表示された12桁のアドレスを送信すると、折り返し認証ファイルが添付されたメイルが到着する。

ローカルフォルダに添付ファイルを保存した後、Help MenuからLicense Debugを選択してファイルの位置を確認、旧ファイルを新しくダウンロードしたファイルで上書き＆再スキャンで、更新が完了する。

PurpleとVioletの発色の違いを考える

「これ以上むやみにハードをいじらない」という宣言を早々に撤回した形になってしまうが、手持ちの1/2号機の赤味が強過ぎるLEDの輝度を調整した。　視認性の向上だけではなく、実際に赤が焼き切れてしまった事例から、早めの手当が必要との判断でもある。

作業の内容は、電流を調整して赤の輝度を抑えつつ、不足気味だった青の輝度を上げるため、LEDにシリーズ接続している抵抗値を従来の390Ωから赤1kΩ／青150Ωに変更しつつ、Orange/Lavenderのラインに設置している抵抗に追加していたバイパス抵抗（かつて色味の調整のために追加していた）を除去する。　



厳密な最適値はまともな実験プラントを作って割出す必要がある（ブレッドボードでは誤差が大きくなってしまう）が、以前にも言及したようにLEDの順方向電圧はバラつきが大きく、最終的には現物合わせが必要になってしまうだろう。

実際、1号と2号には全く同じ抵抗値を設定しているにもかかわらず、PurpleとViolet（Lavender)の色味の誤差が激しい。Violetの発色には抵抗の代わりにダイオードの順方向電圧を利用した降圧を行って色味の調整を行っているが、Violetの発色に抵抗値を最適化すると閾値の競合が発生してPurpleの赤味が勝ってしまう現象が発生する。　

個体差によっては気にならないレベルの発色になる場合もあるが、変動幅が大き過ぎるために予測は難しい。　製作の効率を上げるために最大公約数的な調整のメソッドを確立したいところだ。

OLEDオシロスコープの製作

The code is here.

Spresenseに関する愚痴

世間というかGoogleで検索しても何故かネガティヴな情報が出てこない、というかそもそも話題が殆ど流れていないSpresenseに関しての個人的な見解というか愚痴をつらつらと書いていく。



最近になってようやくオンライン上にあるSpresenseのディベロッパー向けマニュアルが充実してきたので中身を検討していたが、Timerやカウンタの機能が単純化されていて、外部トリガでカウンタの値をキャプチャするようなMCUに有りがちな使い方が想定されていない印象を受けた。

ハード的にチップの構成はどうなっているのかを知りたいのだが、アップロードされているPDFの内容が相変わらず適当過ぎるのが解せない。

まあ、家電屋系半導体のアプリケーションノートは昔からあんな感じだったので、このスタイルは伝統でもあるのだろう。NXPやSTMの分厚いマニュアルからするとペラ過ぎるSONYのアレがその傾向を象徴している。

確かに、あの2000頁もあるユーザーズマニュアルを「読みこなせ」とか言われてしまう現状は異常とも言えるのだが、そのレベルの難解で複雑な代物の解説が「たったの52p」というのは異様を通り越して非常にマズイのではないか。　しかも、発売から半年経った現在も末尾にRevの履歴が一切かかれてないのがこれまた凄い。　

https://www.sony-semicon.co.jp/products_en/spresense/PDF/CXD5602GG_technical_manual.pdf

pinの対応表を見ると、カウンタ関連の外部トリガが見当たらないので、これは自分の想定する用途には「使えない」ハードウエアである可能性が高くなった。　拡張ボードはわざわざUnoに寄せてきてるのでポートが足りないし、現状でサードパーティーが何かを出してくる気配は殆ど感じられない。



デジタル化以降のWalkmanの失敗を見ても判るように、何処かピントがズレているのではないか。　オープンソースを謳うのであれば、ハードウエアの仕様公開は一番先にやるべきことなのに、どうも其辺のメーカーとしての思惑が解らない。　至極使い難いツールを出してくるのも同様で、STMの便利そうなツールを試した後はなおさらそう感じてしまう。

製作例は初歩的なものしか上がってないようだ。　ハイレゾとかあまりよく解らない価値観のものをプッシュして来るのが企画屋のプレゼン的な雰囲気で、これまたMakerっぽい人らの嗜好とは少しズレている気がする。　　今後はトラ技の記事等から製作例が出てくるのだろうか。　ちなみにトラ技はどちらかというとGPS系の記事に注力しているように見える。

相変わらずTimer周りが気になるので、製作環境となるNuttXの構成を調べたところ、対応するチップ別に端子が設定されているコードを見つけた。



で、肝心のCXD5602を探して見つけたのがこれ。



つまり、外部からTimerを直接制御する端子は存在しないようだ。

これで諦めが付いたので、とりあえずSpresenseを実験機として購入してみよう、、、と、なんとなくというか何度目かの結論に至る。

Timerが３つあるので、それらをフリーランさせたのをGPIO設定した端子からattatchInterruptでカウンタの値をキャプチャすれば、なんとかFVCを構成できるかもしれない。　

タイマーの数や仕様をケチったのは、省電力化をメインに考えたためなのだろうか、、、と、先に読んだ記事から思い当たった。　

SONYはこれをNXPやSTと競合するような汎用性の高いMCUとしては開発していない可能性がある。つまり、顧客として想定しているユーザー層が先行しているMCUメーカー達とは全く違うのではないか。　ただ、そのターゲットとしているであろう対象そのものの形が明確に見えてこない。　AI云々をメインに言い出しているのも対象が茫洋としすぎているためにあまり印象が良くないが、実際のところは車載用のパターン認識システム等に応用したいのだろうか。　カメラとGPSという組み合わせからは、それっぽいベクトルを感じる。

Spresenseを自分の楽器に応用するためには、ロータリーエンコーダーとLED周りで16本、スイッチ類の表示用LEDを含めた入出力が6本以上、周波数入力に端子が2つと、合計24本の端子が要る。　だから出来ればpinが一杯取り出せるボードが欲しいところなのだが、現時点では端子拡張系の製品を出してくる気配がどこからも感じられないのが残念だ。　



あまり使い手の無さそうなマイク端子群をデジタル入出力として使用できないか、購入前にGPIO周りの仕様を検討なければならない。　



なんにせよ、アナログ入力固定な端子群を設定しながら「Unoと共通仕様でシールドを使えます」とか言っちゃう辺りの適当さが不思議な設計思想ではある。

開発はRTOSの使用が大前提となるが、それ以前に動くのがUbuntuだけとかシロートには敷居が高過ぎるのだが、去年の後半にまずはOSの使い熟しからトライすべく、実験的にOSの導入を試みたものの、開発環境を導入するどころではない状態が継続したまま半年以上の時間が過ぎた今はもう3月だ。

タイマーカウンタのセットアップ

CubeMXは、このようにタイマーカウンタをセットアップするためのコードを吐き出してくれる。



Arduinoで記述していたこの部分のコードがそれに相当する。



データブックを引かなくてもさっさとコードを吐き出してくれるのはとても便利だ。

dueScope2基板の設計

OLEDパネルをピギーバック形式で実装するスタイルに設計を変更した。

4ch分の入力を切替えられるようにアナログスイッチを導入し、プリアンプを3ch分、バイアス電圧ラインにバッファーアンプを追加している。



回路はほぼ完成形で、新たに見つけた製作記事にも対応できるように端子類を整理している。

描画が妙にトロいのはOLEDの仕様？なのか？？？　それでもDueではマトモに動かせている一方で、Teensyとの相性は最悪だ。　フォーラムではSPIからI2Cに駆動方式をスイッチしたほうが良いのでは？という意見もあったが、ボードの単価はDueの方が圧倒的に安くなる（コピー品を使うが問題は無さそう）ので、ことオシロに関してはDueを選択すべきだろう。



先に紹介した「しなぷすさんによるオシロの製作記事」は素晴らしい内容で、基本的なオシロスコープの機能をほぼ網羅している。　今回は駆動の作法が違うOLEDが使えるようにプログラムを改装しているのだが、これがなかなかの難物で描画が妙なことになってしまう。



オリジナルの設計ではモノクロの64×128という画素数が少ないデバイスを使用しているが、今回採用する予定のOLEDは120×160のカラーで、アスペクト比が異なるのが問題で、文字の表示域に制限が出来てしまう。

また、デバイスに送るコマンドの文法が異なるため、項目毎にコマンドの翻訳を行うことになるのだが、項目が存在しない＝翻訳できないコマンドの処理が難しい。　例えば、モノクロ液晶ではテクストの反転コマンドが存在するが、カラーデバイスの場合はテクストの色みを変える等に表示方法の仕様を変更する必要が出てくる。

いろいろとコードをいじくり回した結果、ひとまずは画像のような感じになっていて、描画に関しては表面上の辻褄を合わせることが出来ているのだが、



テクストの表示を行うエリアがスコープの表示によって潰されてしまうため、パラメーターの入力が発生した時点で規定時間だけテクストをオシロ画面に上書きする仕掛けを追加しなければならない。

同時に、RGBロータリーエンコーダーを使用したClickEncoderの導入を画策しているのが無理筋で、オリジナル回路のスイッチ類をClickEncoderに置き換えるのに苦労している。　オリジナル回路は4つのタクトスイッチを使って項目の選択とパラメーターの増減をこなしているが、これをロータリーエンコーダーで代用する場合に項目の切り替えがどうやっても上手く行かない。

試行錯誤の結果、ClickEncoderには擬似的なスイッチ機能を持たせ、これによって生成されたロジック信号を端子から出力し、元来はタクトスイッチが接続されていた端子に物理で突っ込むという原始的な方法に転換しつつある。　

Arduinoは端子の通信速度が激遅く、それを解消するためにポートの直アサインを行っているのだが、液晶ディスプレイ等を駆動するためにLibraryを使用する場合、端子を共通化するためのArduinoの胡乱な仕掛けがボトルネックになってしまう。　その「共通化」の影響を少しでも減らすためにdigitalWriteFast等の関数を使うことになるのだが、Dueの場合ある時期からこの手の関数が使えなくなって仕舞っていた。

で、新しく見つけたのがリンク先のライブラリで、これの御蔭でDueでも出力の高速化を行えるようになった。　

digitalWriteFastをLCDとの通信に使うことで少しでも動作速度を改善する狙いがあるのだが、



OLEDディスプレイの場合はどうもドライバ側にボトルネックがあるように思える。　極端に遅い描画速度を検証するために、比較用の液晶ディスプレイを購入した方が良いかもしれない。

現在、インターフェイスの実験を行うために、入力信号用のプリアンプを組み込んだ試作ボードをユニバーサル基板上で製作しているが、完成には二三日掛かりそう。

dueScopeの製作

とりあえず、ClickEncoderの機能は実装できた模様。



Rateもキッチリと切り替わっている。　

今回のテストではRGBロータリーエンコーダーを使用していないので、LEDの点灯テストは未了。



一時期対応できなかったスタートアップの画像もちゃんと読み込めるようになった。



Teensyでは何故か欠けてしまっていたドットを復活させた。



過大レベルを入力すると若干ドットの取りこぼしが発生してしまうが、Teensyと比較すると格段に良好。



Dueの動作は速攻で描画が始まるTeensyとは違っていて、バッファーに一旦貯め込んだデータを逐次出しているように見える。　殆ど同じ内容のプログラムでどうして差が出てしまうのか？現時点でその原因は解らないのだが、TeensyのForumで見つけたトピックによると「Teensyが扱う32bit幅のデータがミスマッチしている」可能性が示唆されていた。　Teensy専用にライブラリを書き換える必要がありそうだ。

その後、運用法を考えた結果、Dueにピギーバックさせるのが良さそうということで、oledディスプレイを填め込んで実装できる基板を設計した。



入力には簡単なバッファーアンプを追加している。　回路は構造が単純単純なので、ユニバーサル基板に手組で製作を行う場合でも再現性は高いと思う。



Dueのタイマー系の構成について、詳細を記した資料を見つけた。

https://github.com/ivanseidel/DueTimer/blob/master/TimerCounter.md

2011 MacBook Pro 8,2 のAMD製GPUが死んだ場合の対症法

元旦の日付が変わって間もなく、2011年製MBP17吋のカーソルがフリーズ、再起動後のOS立ち上がりでグレイの画面に固定されてしまう現象が発生した。

以前、15吋（これも2011年製）のGPUが死亡してそのままジャンクと化したケースを体験しているが、これで自宅のi7搭載のMacbookが全滅してしまった。

なんとか対症法はないものかとWebで記事を漁ったところ、

Force 2011 MacBook Pro 8,2 with failed AMD GPU to ALWAYS use Intel integrated GPU (EFI variable fix)

というトピックを発見した。

対症法を要約すると、故障したGPUを切り離して起動する手法で、障害の発生によって途中で起動プロセスがスタックしていたOSを強制的に立ち上げている。　記事に紹介されていた実際の手順を引用すると、、、

First of all, it is possible to successfully boot a MBP to OS X while still using the failed GPU, after you remove the AMD drivers by booting in command line mode (CMD+S) and entering these commands:
1) fsck -fy (to check a disk)
2) mount -uw / (mount a root filesystem with read/write permissions)
3) sudo mkdir /AMD_Kexts/ (make a directory to store the AMD drivers in case you'll need them in future)
4) sudo mv /System/Library/Extensions/AMD*.* /AMD_Kexts/ (move the AMD drivers)
5) sudo rm -rf /System/Library/Caches/com.apple.kext.caches/ (remove the AMD drivers cache)
6) sudo mkdir /System/Library/Caches/com.apple.kext.caches/ (just in case OS X will be dumb and will not recreate this directory, I am creating it for OS X)
7) sudo touch /System/Library/Extensions/ (to update the timestamps so that new driver caches - without AMD drivers - will be definitely rebuilt)
8) sudo umount / (umount a partition to guarantee that your changes are flushed to it)
9) sudo reboot

といった作業のプロセスを経て、OSを正常に（近い状態で）立ち上げることが出来るようになった。

この他、起動時にNVRAMの内容をその都度書き換える方法もあるが、立ち上げ時に毎回儀式が必要になる手間を考えると、OSの起動プロセスを直接編集した方が良さそうだ。

とりあえず主要なアプリケーションの動作を確認できたので、この手当で暫くの間は誤魔化せそうだ。

追記：

17吋でアップデータを走らせたらブルースクリーンが出た、、、。

nvramの書き換えで起動したら取り敢えず処理が開始されたが、全くもって予断が許されない状況に、、、。





アップデート終了後に、なんとか起動することができたが、先に紹介した回復のメソッドは無効化されてしまった模様。



MountainLionでは4つだったAMD関連のkextファイルが、HighSierraでは十数個に激増した。　

動作もHighSierraの方が不安定で、画像のリフレッシュが完全に行われず、描画の安定度が著しく低下した。



さらなるアップデートで情況が改善される保証はないので、暫らくの間はこのままで様子を見た方が良いだろう。



外部接続の主要なハードウエアはなんとか動作している模様。



17吋に関しては動作速度に問題は発生していないが、15吋の方は速度の低下が著しい。　速度が速いSSDの外部ドライヴを接続した場合も情況が改善しなかったことから、マザーボードの本格的な故障が疑われるものの、いまのところ原因は不明。

LEMOの8pコネクターをアンプに取り付ける

数年ぶりに行うライヴ演奏からのフィードバック。　



なかなかやる気が出なかったのを思い切ったのが運の尽きで、丸一日がこの作業に費やされることになった。



嵩張るスピコンを排除するために、フォン端子を使ったスピーカーケーブルをアンプに増設しようとしたが、丁度よいサイズの取り付け穴を開けられず、作業が長引いてしまった。　スピコン端子には2ch分の信号線を仕込んでいるので、サテライトスピーカーを一個プラスする情況ではこちらを使用する。



製作するスピーカー用のケーブルは10m。スピコンのケーブルは6m程だったので、長さが足りずに現場で微妙な状況に陥ることが多かったが、これでキャパの広い場所でもある程度は対応できるはず。

作業の過程で電源が短絡するトラブルが発生したが、原因はなんとebayで購入したLEMO製の8pケーブルそのものにあった。



よく見るとなんだか変な構成のケーブル＝所謂変態仕様なブツだったことが判明。



その内実は、単線×３本とシールド線２組、それとグランドラインで合計８端子という、なんだかよく解らない構成の代物。



このシールド線のグランドが短絡の原因だった。



代わりに在庫していたジャンクの12芯シールドを使ってコネクターを改造した。



パワーアンプ系の配線など大電流が流れるラインには2芯を撚ってそれに充てている。

LEMOのデザインはNeutrikとはまた違った雰囲気を持つ。



サテライト化した4chデジタル・パワーアンプ＆＃1chスピーカーユニット。



オーディオ的には、滅茶苦茶な設計である。



これは本体っぽく見える電源部。



日付が変わる前に、なんとか音を出す事ができた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

久しぶりにSignalHoundの整備を行う。

本家のサイトで新しいアプリケーションのDLが可能だったので、コレを試す。







なんちゃって受信機の機能が上がっている他、以前のヴァージョンとは格段に遣い易くなっている。

残念ながらWindowsのみ対応なので、OSX環境下ではParallelsを起動して動かすことになる。　

偶にコレを使ってThereminのオシレーターの周波数を調整しているが、デジタル系ラインの調整と確認には別にロジアナが必要。

https://www.silvertone.com.au/content/bitscope-bs10u-micro-oscilloscope-analyzer

基板が届いた

24Vトランス電源の製作＠トランスをボディーに組み付ける

ダイオードブリッジを追加して、トランスをボディーに組み付けた。



トップパネルに電圧設定用の端子を追加しなければならないが、場所の選定を思いきれない。



裏面はこんな感じ。　これから配線を行っていく。



整流後の平滑を行う電解コンデンサーは既にブロック化していたが、



これをバラして、ラグ板上に組み直す予定。



3端子レギュレーターは電圧調整が可能なLM317系を使用するが、電圧調整を行う半固定抵抗の設置場所が決まらない。



ケースの蓋はご覧のように白いスプレーが吹かれていてみっともないのだが、これがなかなか落とせない。