記事一覧

BOSSのDI-1を改造する?・・・1個目

 マイコン関係のネタが続いたので息抜きにアナログ機器をいじる。
 ここしばらく検討していたBOSSのダイレクトボックス「DI-1」の改造です。
 専門外の分野ですが、安価で使い勝手はいいけど音がイマイチと話を聞く製品です。もし少しの改造で音を良く出来るならと思い立ったワケです。

 さて、どうしよう。

 オペアンプを良質な物に替えるのはアリでしょうね。現在はM5218というNJM4558系の物が使われていますが、これをJRCのMUSES02あたりに換装したら良いのでは?ってのが一番最初に出てきたアイデアです。

 ですが、回路図と基板を見たらどうでしょう。インプットとアウトプットのコンデンサを変えたくなる。決して悪い物は使われていませんが、どうせならオーディオ用とされる良質な物に替えてもいいかと。
 あと、インプットコンデンサの容量が小さくないかと思ったり。現在は0.01uFのフィルムコンデンサです。一般的なギターアンプやベースアンプのインプットコンデンサには1~4.7uFが使われることが多いのにナゼ?って感じです。ここの容量が小さいとノイズやDCはカットしやすいのですが低音が減衰するように思います。また、フィルムコンデンサは高域の特性はいいのですが低域は減衰しやすいと聞きます。楽器系はハイインピーダンスなので通常のラインレベルと同じに考えてはいけないのかもしれませんが、このコンデンサを少々大きくして試してみる価値はあります。オーディオ向けの1uF無極性コンデンサを試す予定です。このコンデンサの先にあるFETが原因かもしれませんけど。

 まずはコンデンサを替えてみて、効果が見えたらオペアンプも替えてみましょう。
 MUSES02は評判の良いオペアンプですが高価。いきなり試すには気が引ける貧乏性です(笑)

Raspberry Pi ・・・20枚目

 RaspberryPiを使ったウェブカメラがようやく終わりました。
 もちろん今後のバージョンアップなどの作業が続くと想いますが、すべての機能が求められた内容で動いてくれました。
 一息です。

 RaspberryPiは応用の幅が広い。呆れるほど様々なことができる。
 Pythonを主に使っていますが、繰り返し構文の遅さに問題を感じるものの、スクリプト言語の感覚でなんでも作れる。
 さらに、PythonのソースコードをC++に書き直すことは容易い。Cythonを使う手もありますが、C++のつもりでPythonを書けば移植は簡単。C++でコンパイルすれば実行速度は10倍近くを期待できる。Pythonで試作してC++で書き直すってのが開発の段取りとしていい感じです。

Raspberry Pi ・・・19枚目

 websocketを使って思ったのですが、これでDMXのパケット送ったらどうかと。513バイト×44回/秒=約22kB/秒。10Baseだってこのデータが送れないことはないでしょう。
 8ユニバースくらいを送れる手軽な簡易DMX-Etherがあったらいいかなと。出来る限りデータを軽くしてwifiでも送れたら便利だし。wifiだとタイムラグが出そうだけど、タイムラグがあっても無線で多拠点間通信出来たらありがたいこともあると思う。もちろんケーブル接続ならタイムラグは軽微でしょう。
 なによりも、RaspberriPiが使えることにメリットがある。なんといっても安価。低消費電量だからバッテリー駆動だって夢じゃない。
 ま、アイデア段階ですけどね。

Raspberry Pi ・・・18枚目

 RaspberryPiはSDカードにシステム入れて使うのが普通です。

 ただ、SDカードは規格がややこしい。俗に言う相性問題もあってさらにややこしい。どれを使えばいいんだと正直思う。

 SDカードの規格名称は次の感じです。

 ハードウェアの様式を表す:ノーマルSD、SDHC、SDXC
 読み書きの速さの性能を表す(?):Class、UHS
 ランダムリードライトの速さを表す(?):アプリケーションパフォーマンスクラス A1、A2

 ハードウェアの様式ですが、物理的な接続方法と対応容量の違いです。原則上位互換なので、より新しい規格のホストデバイスはそれより古い規格のSDカードも使えますが、古い規格のホストデバイスでは新しい規格のSDカードは使えません。容量はノーマルSDは128MBから2GB、SDHCは4GBから32GB、SDXCは64GBから2TBまでとなっております。

 読み書きの速さの性能ですが、ClassとUHSがあります。どちらも表したいことは同じで、Classでは表しきれなくなったのでClassの上位にUHSが定義されました。それぞれ数値が高い方が速度が速いことになっています。ただし、これはシーケンシャルリードライト(メモリをアドレス順に連続して読み書きする)の場合です。Class4のカードの方がClass10よりも体感的に動作が速かったという報告も耳にしますが、これはランダムリードライトの性能に影響された結果です。これは製品の個性ですが、Class4となっているSDカードの方がランダムリードライトに関しては性能が高かったのです。

 ディスク類の読み書きではアドレス順にデータを読み書きする「シーケンシャルリードライト」とアドレスを無作為に指定してデータを読み書きする「ランダムリード」があります。一般的にシーケンシャルリードライトがそのディスクの読み書き速度の最大値ですのでカタログスペックとして表されます。
 映像撮影などではシーケンシャルリードライトの性能が高いと良いとされ、スマホなどのユーザーが無作為な操作する端末ではランダムリードライトの性能が高いと良いとされます。どちらの性能も良いのが望ましいのですが、案外そうもいかないのが現実だったりします。

 そのためでしょう、最近はアプリケーションパフォーマンスクラスというランダムリードライトの速さを表す尺度も出てきました。速さの絶対値ではなくClassやUHSなどのシーケンシャルリードライトの速度に対するランダムリードライトの比率みたいな感じです。今のところA1とA2の製品があります。
 この値が良ければ、というか、現時点ではこの値が表示されているかで判断して良いと思われます。カタログスペック(シーケンシャルリードライトの程度)を上げるためにランダムリードライトを犠牲にしたと思われる?SDカードも少なくないようですので・・・。

 つわけで、RaspberryPiの様にランダムリードアクセスが重要と思われる装置にはアプリケーションパフォーマンスクラスの高さを優先に選択した方が良さそうです。

Raspberry Pi ・・・17枚目

 例のウェブカメラは何とか一通りの機能が搭載できました。
 オーダーもらってから約1年半。副業ですから使える時間は限られ、実質1ヶ月半の作業でしたが、長かった・・・。
 「ここまで作れたら何でもいけるぜぇ!」って勘違いしそうなくらい様々な要素を盛り込んだ装置です。

 難儀したのは、RaspberryPiのカメラで撮った画像をCV2で処理して字幕を入れて動画や静止画として保存する処理と、9軸センサを用いた姿勢推定でした。
 まとまったのが奇跡と思える要素ですが、なんとかなってよかった・・・。

 当初は位置推定も9軸センサで行うつもりでしたが、光学式の高価で大きなモノを使わないとドリフトを押さえ込むのが不可能なのがわかり断念。装置を吊り下げるワイヤーをプーリーに通しロータリーエンコーダーで回転量をカウントして数値化。これはカラースクローラーでも使う方法なので応用できで何とかなる。
 ウェブソケットは実装したところ凄く簡単でした。今回はPythonとPythonの間で使いましたが、Javascriptとも通信できるのでウェブとの連携にも使えます。シリアルコンソール並みに単純なテキスト送受信するだけの機能ですが、単純なデータを低負荷で簡単に扱えることは応用範囲が物凄く広いことにもなるので今後様々な用途に応用できそうです。

 とまぁ、書き出したらキリはないのですが、CMSエディターやスクローラーを作った時と同じくらい様々な勉強ができました。施主のアオリをのらりくらりとかわしつつ、私の作業の遅さをジックリと待ってくださった依頼主の担当さんに感謝です。

久々に風邪をひく

 丈夫というより鈍感なので体調を崩すことは滅多にありません。
 なのに久しぶりに風邪をひく。38度越えで喉がガラガラ。
 葛根湯を飲んで一晩寝る。
 ・・・治る。

 野外現場で雨に打たれて体を冷やしたのが原因でした。
 皆さんも変に体を冷やさないように注意してくださいね。

Raspberry Pi ・・・17枚目

 RaspberryPiのシステム設定をしていてしくじった話。

 シリアル通信を使う際、/dev/serial0に/dev/ttyAMA0を割り当てて使った方がいいらしい。
 デフォルトでもシリアル通信は使えるのですが、シリアルコンソールをディセーブルにして/dev/ttyAMA0を/dev/serial0として使った方が制限が少なくていいらしい。

 手順です。

@ シリアルコンソールをディセーブルにしユーザーが/dev/ttyAMA0を使える様にする
$ sudo raspi-config
  5.Interfacing optons ....
   P6.Serial -> Yes
    [ダイアログ] Would you like a login shell to be accessible over serial? -> No
    [ダイアログ] Would you like the serial port hardware to be enabled? -> Yes

・この設定の後、/boot/config.txtの末尾に次が追加された。
  start_x=1
  enable_uart=1

@ Bluetoothをディセーブルにする
・Bluetoothチップを無効にしてUART0をシリアルポートとして使用する。デフォルトではUART0がBluetoothに割り当てられているらしい。
$ sudo nano /boot/config.txt
  以下を末尾に追加
  # disable Bluetooth
  dtoverlay=pi3-disable-bt
  # SoCのUART0がGPIOヘッダーのpin8,10に接続される。
  # デバイス名は/dev/ttyAMA0になる。このデバイスのエリアスとして/dev/serial0が割り当てられる。
$ sudo systemctl disable hciuart
  ※ Bluetoothと接続するデーモンを停止する。
$ sudo reboot

 この設定でシリアルコンソールをディセーブルにしなかったためにシリアルが正常に動作せず時間を無駄にした。

Raspberry Pi ・・・16枚目

 RasberryPiの電源管理で悩む。

 電源を入れたら起動し切ったらシャットダウンしたい。
 そんだけのことと思われがちですが、電源を入れて起動するのは簡単でも電源を切ったらシャットダウンすることが簡単なようで難しい。電源が無くなったら適正にシャットダウン動作ができないからです。
 さてどうしよう。。。

 簡易UPSを搭載します。
 最近は電気二重層と呼ばれるアホみたいに容量の大きなコンデンサが小さく安くなりました。
 通電中にこれに電力を蓄えておき、電源を切ったらこの電力を使ってシャットダウンをするのです。電源入力を信号と見立て、トランジスタなどを通してGPIOでセンシングして無電源なれば終了動作をするバッチみたいなのをデーモンとして動かしておけばOKです。
 某サイトの情報を参考に自分なりにアレンジしたのですがいい感じ。12.5F5.4vの電気二重層コンデンサでRaspberryPizeroが2分くらい動きます。シャットダウンには十分な時間です。
 これはいい。

 ですが、、、今度は再起動が問題になりました。
 簡易UPSには余裕があるので完全に電力が無くなるまでにかなりの時間がかかります。「かなりの時間がかかる」くらいにしないと安全なシャットダウンは難しいので仕方ありません。RaspberryPiが無電源と思ってくれるくらいまで電圧が下がれば再投入で起動しますが、無電源と思う電圧が意外に低く、簡易UPSが仇となって単に電源を再投入しても起動してくれません。何か別な手段を考えないといけません。
 シャットダウンした後でも電源が通じている場合、GPIO3(5番ピン)をオープン(またはHi-Z)にしてからGNDに落とすと再起動します。GPIO3をI/Oとして使わないなら再起動した後もGNDにしたままでも大丈夫みたいなので、この特性を利用します。
 単に2SCトランジスタを入れます。エミッタをGNDに、コレクタをGPIO3に、ベースに10KΩくらいかまして電源入力端子に接続します。無電源ならHi-Zになり、電源が入ればGNDに落ちます。2SC1815で試してOKでした。往年の名機も廃番なので今なら2SC2712でいいでしょう。

 ・・・更に問題です。
 GPIO3はI2Cで使う端子。
 起動端子として使った後にI2Cに切り替えるのは難しい。
 I2Cをあきらめて古式ゆかしいシリアル通信でなんとかするしかありません。

そうか!I2C

 RaspberryPiとPICをI2Cで通信することも勉強中です。

 ここでヒトツ注意点がありましたのでメモ。

 PICのデータシートを読む際「読み取り」「書き込み」という言葉が地雷です。これらの言葉はI2Cにおける「マスター」からの視点です。

 今回はRaspberryPiがマスターでPICがスレーブですから、「読み取り」はPICからRaspberryPiにデータを送る操作、「書き込み」はRaspberryPiからPICにデータを送る操作です。

 PIC側を強く意識してしまうと逆に考えてしまう感じが注意点って話しです。

 私だけかもしれませんが。。。

Python:0x0017

 ホール管理の増員で時間があったのでPythonでWebSocketを使う方法を勉強してました。

 なんというか簡単みたいですね。こんなんでいいのってくらい。
 Pythonでの基本的な構造の記述はほんの数行。

 サーバーとクライアントの関係が前提ですが、その間で簡素な数値や文字列をちょろっとやりとりできます。
 何か難しいことがあるのかと思ったら、物凄く簡単にソケットとなるサーバーを設定し、クライアントからは送る取り出すの操作をするだけ。
 ネットには簡単なものを装飾しすぎて複雑にして本質が読み取り難くなった情報が多いので、そもそものところを理解するのに遠回りを強要されたりする。今回はシンプルにわかりやすい説明をしてくれるサイトに巡り会ったので助かったけど。

 どうやら、Pythonでのプロセス間通信もこれを使った方が簡単らしい。これまで使わなかったのが勿体無いくらい。

ページ移動

過去ログ