電装工芸日記
- 舞台照明機器の製作とか -
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
LTC Generator のLTC信号を卓(MA dot2)が認識しました。
ただ、同じ値を送り続けても認識しません。LTCを入力してから認識するまで１秒弱かかるので、カウントを進めずに信号を認識し続ける方法が欲しいのです。
試しに数フレームの繰り返しを組んでみたところ認識し、数フレームの繰り返しを一定回数行ってから抜ける様にしたところ期待する結果を得ました。
最初のCUEポイントのマイナス数フレームの位置で2-3フレームの繰り返し待機をし、トリガが立ったらそれを抜ける考え方で良さそうです。
ともかく、卓が認識したので一安心です。
#タイムコード
ただ、同じ値を送り続けても認識しません。LTCを入力してから認識するまで１秒弱かかるので、カウントを進めずに信号を認識し続ける方法が欲しいのです。
試しに数フレームの繰り返しを組んでみたところ認識し、数フレームの繰り返しを一定回数行ってから抜ける様にしたところ期待する結果を得ました。
最初のCUEポイントのマイナス数フレームの位置で2-3フレームの繰り返し待機をし、トリガが立ったらそれを抜ける考え方で良さそうです。
ともかく、卓が認識したので一安心です。
#タイムコード
LTC Generator は30fpsも他のfpsと同様の誤差でした。時間の勘定に期待値が出たので PIC のファームウェアは一応の完成とします。あとは、卓が認識するかです。
今後はPC側のアプリケーションの製作です。Pythonベースでvlcライブラリを使い、LTCとVLCは同時スタートの疑似シンクです。VLCの現在時からLTCを生成することは難しいからです。途中スタートではLTCの現在時からVLCの開始時を補正して合わせる様にします。
音声ファイルはプレイリストとしてまとめ、スタートタイム、エンドタイム、ボリューム、連続再生、曲間時間などを個別に設定出来る様にします。複数の音声ファイルを並列で再生する用途は想定しませんので、１トラックのわかりやすいモノを目指します。もちろん、LTCのタイムが被らない様にチェックする機能も大切です。
#タイムコード
今後はPC側のアプリケーションの製作です。Pythonベースでvlcライブラリを使い、LTCとVLCは同時スタートの疑似シンクです。VLCの現在時からLTCを生成することは難しいからです。途中スタートではLTCの現在時からVLCの開始時を補正して合わせる様にします。
音声ファイルはプレイリストとしてまとめ、スタートタイム、エンドタイム、ボリューム、連続再生、曲間時間などを個別に設定出来る様にします。複数の音声ファイルを並列で再生する用途は想定しませんので、１トラックのわかりやすいモノを目指します。もちろん、LTCのタイムが被らない様にチェックする機能も大切です。
#タイムコード
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
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