電装工芸日記
- 舞台照明機器の製作とか -
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
RaspberryPi pico はとても面白いマイコンです。少なくとも私好みです。RaspberryPi のブランドですが、RaspberryPi の廉価版、簡易版ではなく、Arduino の親戚と思った方が自然な存在感です。想定される用途、ソースコードを書いてから実行に至るまでの流れが Arduino のそれととても似ています。
純正の開発・実行環境は MicroPython と呼ばれるシステムですが、MicroPython からの派生品である CircuitPython を使うことで自由度が更に広がるようです。MicroPython がスタンドアロンでの実装を主眼としているなら、CircuitPython はPCなどの周辺機器を作ることを強く意識しているように思います。MicroPython、CircuitPython のどちらもとても良く整備された開発・実行環境だと思いますが、CircuitPythonの方が私の趣向に合っている気がします。実際、CircuitPython の存在を知って pico に興味を持ったのは事実です。
pico のプロセッサはarm系32bit133MHzです。Arduinoは、高速化高機能化が進んではいますが、基本はAVR系8bitマイコンです。処理能力は pico に格段の優位性があります。その余裕を使って Python を動かしているとも言えますが、C/C++の開発環境を使えば攻めた造りも出来そうな気がします。また、pico は ArduinoIDE と呼ばれる Arduino の開発環境でもコーディング出来るので、Arduino に親しんだ方がシームレスに使えるメリットもあります。ArduinoIDE を用いてこれらのデバイスの開発環境を一本化するのもアリですね。
#RaspberryPi
純正の開発・実行環境は MicroPython と呼ばれるシステムですが、MicroPython からの派生品である CircuitPython を使うことで自由度が更に広がるようです。MicroPython がスタンドアロンでの実装を主眼としているなら、CircuitPython はPCなどの周辺機器を作ることを強く意識しているように思います。MicroPython、CircuitPython のどちらもとても良く整備された開発・実行環境だと思いますが、CircuitPythonの方が私の趣向に合っている気がします。実際、CircuitPython の存在を知って pico に興味を持ったのは事実です。
pico のプロセッサはarm系32bit133MHzです。Arduinoは、高速化高機能化が進んではいますが、基本はAVR系8bitマイコンです。処理能力は pico に格段の優位性があります。その余裕を使って Python を動かしているとも言えますが、C/C++の開発環境を使えば攻めた造りも出来そうな気がします。また、pico は ArduinoIDE と呼ばれる Arduino の開発環境でもコーディング出来るので、Arduino に親しんだ方がシームレスに使えるメリットもあります。ArduinoIDE を用いてこれらのデバイスの開発環境を一本化するのもアリですね。
#RaspberryPi
LTC Generator は29.97fpsも25fpsと同等の誤差でした。30fpsと24fpsも同等に収まればPICのファームウェアは完成とします。
比較に使っている時計はカタログスペックで月差±15秒。１日あたり0.5秒の誤差とみなせます。基準にするには十分でしょう。
「卓がLTCとして認識するか」を早々に確認したいですね。これが一番重要です。
#タイムコード
比較に使っている時計はカタログスペックで月差±15秒。１日あたり0.5秒の誤差とみなせます。基準にするには十分でしょう。
「卓がLTCとして認識するか」を早々に確認したいですね。これが一番重要です。
#タイムコード
LTC Generator のタイマーを修正してみました。
８時間経過で約１秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の１を表す単位なので比率だと0.00003)、１日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。
秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。
#PIC #タイムコード
８時間経過で約１秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の１を表す単位なので比率だと0.00003)、１日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。
秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。
#PIC #タイムコード
LTC Player には外付けスイッチが欲しい。
RaspberryPipicoはUSBキーボードやマウスを簡単に作れるとのこと。
てことは、picoでキーボードシステムを構築しといてもいい。USBのHIDはもちろん、UART、I2Cなども使える様にしとけば便利だと思われる。チャタリングを含めたセンシングのマトリクスと通信まで作っておくのです。
picoについて調べてみましょう。
#RaspberryPi
RaspberryPipicoはUSBキーボードやマウスを簡単に作れるとのこと。
てことは、picoでキーボードシステムを構築しといてもいい。USBのHIDはもちろん、UART、I2Cなども使える様にしとけば便利だと思われる。チャタリングを含めたセンシングのマトリクスと通信まで作っておくのです。
picoについて調べてみましょう。
#RaspberryPi
LTC Generator は24時間カウントの関数をPythonで書いてみました。限りなく本チャンに近いモノです。
期待通りの動作をします。卓への接続テストはまだですが、オシロスコープには波形が出ます。
ただ、24時間で約40秒の遅れが出ます。１時間あたり約1.7秒ですから無視出来ません。
時間のクリックカウントはPICで行っていますが、TMR1のコンペア値が１個多いと仮定すると辻褄が合います。そういえば、TMR2でコンペアと同様の機構と思われるPWMを作る場合は折り返しで１カウント余計にかかるハズ。データシートには記載が見受けられなかったけど、TMR1のコンペアモードでも同様なのかもしれません。
コンペアの定数値を変更して改めてテストしましょう。
#PIC #タイムコード
期待通りの動作をします。卓への接続テストはまだですが、オシロスコープには波形が出ます。
ただ、24時間で約40秒の遅れが出ます。１時間あたり約1.7秒ですから無視出来ません。
時間のクリックカウントはPICで行っていますが、TMR1のコンペア値が１個多いと仮定すると辻褄が合います。そういえば、TMR2でコンペアと同様の機構と思われるPWMを作る場合は折り返しで１カウント余計にかかるハズ。データシートには記載が見受けられなかったけど、TMR1のコンペアモードでも同様なのかもしれません。
コンペアの定数値を変更して改めてテストしましょう。
#PIC #タイムコード
オレメモ
windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew
２回くらいやった方がいい。
#パソコン
windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew
２回くらいやった方がいい。
#パソコン
今後のこともあり、移動時間にPICのI2Cを勉強し直してみました。
これまではイマイチ理解出来なかったのですが、ボチボチ使い方がわかってきました。わからなかったのはハードウェアとソフトウェアの棲み分けとソフトウェアの手順です。
I2Cの規格を頑張って説明するのはありがたいのですが、一番知りたいソフトウェアの手順がボンヤリした文書ばかり。ちょっと複雑な手順を踏むので突っ込んだ理解が望ましいのはわかるのですが、その説明で力尽きしまうのか、どとのつまりどうすればいいの？に応えてくれる資料が少ないように思います。特に、I2Cの特徴的な要素である「ACK」を扱うのがハードウェアなのかソフトウェアなのかが見えないのです。
正直、Pythonなどではライブラリを使うだけで済んでしまいますので、いくらPICマイコンでもそこまでローレベルの機構まで理解しないといけないのか不思議です。
わかったことは、設定さえしてしまえばソフトウェアの手順はUARTと大差ないことです。
マスタが送信する場合はスレーブアドレスを先頭にしたバイトリストをハードウェアモジュールに渡す(PICではバイト単位で渡す)。
マスタが受信する場合はスレーブアドレスを送り、返信されたバイトデータを取り込んだら取り込み済みのフラグを立てる。
スレーブは、自分のアドレスを設定しておけば自分向けの通信かハードウェアが判断してくれるので、マスターの要望に従って受信値を取り込むか返信値を投げる。
データの終りのストップコンディションは、マスター/スレーブ・送信/受信の立ち位置で違うけどフラグを立てるだけ。
波形をコマンド操作で作るワケじゃありませんし、前後関係で調整することもありません。規格はザックリ概要がわかっていれば十分なのに、ソフトウェアの手順の説明がボンヤリしているのはイマイチ理解不能なワケです。
#PIC
これまではイマイチ理解出来なかったのですが、ボチボチ使い方がわかってきました。わからなかったのはハードウェアとソフトウェアの棲み分けとソフトウェアの手順です。
I2Cの規格を頑張って説明するのはありがたいのですが、一番知りたいソフトウェアの手順がボンヤリした文書ばかり。ちょっと複雑な手順を踏むので突っ込んだ理解が望ましいのはわかるのですが、その説明で力尽きしまうのか、どとのつまりどうすればいいの？に応えてくれる資料が少ないように思います。特に、I2Cの特徴的な要素である「ACK」を扱うのがハードウェアなのかソフトウェアなのかが見えないのです。
正直、Pythonなどではライブラリを使うだけで済んでしまいますので、いくらPICマイコンでもそこまでローレベルの機構まで理解しないといけないのか不思議です。
わかったことは、設定さえしてしまえばソフトウェアの手順はUARTと大差ないことです。
マスタが送信する場合はスレーブアドレスを先頭にしたバイトリストをハードウェアモジュールに渡す(PICではバイト単位で渡す)。
マスタが受信する場合はスレーブアドレスを送り、返信されたバイトデータを取り込んだら取り込み済みのフラグを立てる。
スレーブは、自分のアドレスを設定しておけば自分向けの通信かハードウェアが判断してくれるので、マスターの要望に従って受信値を取り込むか返信値を投げる。
データの終りのストップコンディションは、マスター/スレーブ・送信/受信の立ち位置で違うけどフラグを立てるだけ。
波形をコマンド操作で作るワケじゃありませんし、前後関係で調整することもありません。規格はザックリ概要がわかっていれば十分なのに、ソフトウェアの手順の説明がボンヤリしているのはイマイチ理解不能なワケです。
#PIC
LTC Generator は入荷した修正基板を用いてプリアンプが完成。+4dB(1.23Vp-p)の波形を出しています。
まだPythonプロンプトのレベルですが、シリアルでデータを送ると波形が変化します。Pythonからデータを送る場合、バイト毎ではなく、配列にバイナリを格納してpyserialに渡すのが良さそうです。
タイミングが正しいかは確認出来ませんが、PICからの送信要求も受信出来ています。これを受けてデータを送る段取りです。
本業が詰まっていますのであまり長い時間は出来ませんが、１日0.5課題くらいの気持ちで少しずつ行きましょう。
明晩は仮のLTCデータを送出するPythonプログラムを書いてみます。
あらかじめ2-3秒分の配列データを作っておいて送信要求があれば１フレーム分送出する物ですが、卓に接続してLTCがカウントされれば最大の山場を越えます。
#PIC #タイムコード
まだPythonプロンプトのレベルですが、シリアルでデータを送ると波形が変化します。Pythonからデータを送る場合、バイト毎ではなく、配列にバイナリを格納してpyserialに渡すのが良さそうです。
タイミングが正しいかは確認出来ませんが、PICからの送信要求も受信出来ています。これを受けてデータを送る段取りです。
本業が詰まっていますのであまり長い時間は出来ませんが、１日0.5課題くらいの気持ちで少しずつ行きましょう。
明晩は仮のLTCデータを送出するPythonプログラムを書いてみます。
あらかじめ2-3秒分の配列データを作っておいて送信要求があれば１フレーム分送出する物ですが、卓に接続してLTCがカウントされれば最大の山場を越えます。
#PIC #タイムコード
DI-1MUSEはコンデンサを替えて24時間経過。
音が鈍ったというか、明瞭感が弱くなっています。コンデンサを替える前と大差ない印象。
先行して替えたコンデンサでも24時間経過で一度鈍くなり48時間経過で戻る現象がありました。コンデンサのエージングはそういうものなのかもしれませんが気分は萎えます。
追記
確実ではないのですが、ピンクノイズを当てた直後は音が鈍るものの、通常の音源を数時間当てると音が戻るようです。通常の音源を３時間くらい当てて再チェックしたところ、昨日のイイ感じに戻っていました。
この話だけですとピンクノイズは余計なことに感じますが、ピンクノイズを当てて通常音源を当てると明瞭なだけでなくまろやかさも加わりますので、エージングには良いように思います。
音源100時間、ピンクノイズ100時間、音源100時間の設定で続けています。現在ピンクノイズ30時間。
#音の世界
音が鈍ったというか、明瞭感が弱くなっています。コンデンサを替える前と大差ない印象。
先行して替えたコンデンサでも24時間経過で一度鈍くなり48時間経過で戻る現象がありました。コンデンサのエージングはそういうものなのかもしれませんが気分は萎えます。
追記
確実ではないのですが、ピンクノイズを当てた直後は音が鈍るものの、通常の音源を数時間当てると音が戻るようです。通常の音源を３時間くらい当てて再チェックしたところ、昨日のイイ感じに戻っていました。
この話だけですとピンクノイズは余計なことに感じますが、ピンクノイズを当てて通常音源を当てると明瞭なだけでなくまろやかさも加わりますので、エージングには良いように思います。
音源100時間、ピンクノイズ100時間、音源100時間の設定で続けています。現在ピンクノイズ30時間。
#音の世界
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131