リライアビリティーの問題がありそうなのでググってみたら、このような記事がヒットした。
http://www.digi.com/support/forum/4787/using-the-xbee-at-115-200-baud-updated-16-march-2010
Vinculumの方で対応できないか検討してみるが、相性のようなものが存在するのでアウトの場合は仕方がない。
現状では何故かファームウエアの書き換えが行えない（リセットをかけようが何をしようが撥ねられる）ので、ディベロッパー側で対応が成されていたとしても手持ちのデバイスの信用性は低いと思われる。
2013年12月02日
XBeeが115200baudでは安定運用が出来ないという噂
posted by Yasuski at 16:37| XBee
2013年05月07日
XBee/Midiの導入方法（追記ありの改訂版）
先のトピック「XBeeへの乗換え」で紹介した無線ユニットXBeeをWirelessMidi通信に導入するためのメソッドの備忘録。
元ネタはこちら。Adafruite系のアダプターの使用を前提としたWirelessMidiシステムの構築方法が紹介されているが、若干説明不足な部分があったので補足を加えたメソッドを以下に記していく。
準備するソフトウエア：
FTClean：FTD製品のドライバーをデリートするためのアプリ。
midiDriver：midiの通信速度に対応したドライバー
X-CTU：XBeeとの通信を行うためのアプリ
準備するハードウエア：
AdafluiteのXBee関連モジュール。
XBeeProModule Series1 x 2 (1set)
XBee Adaptor Kit x 2
USB FTDI TTL-232 cable
このうち、電波法の関係からXBeeModuleは日本国内での調達が必須となる。
その他、ソフトウエアを作動させるWindowsXP/7の搭載されたPCが必要。
PCにハード＆ソフトウエアをインストールする前に、Adafruiteのアダプターキットを組み立てておく。
PC上の作業は、まずFDT関連のドライバーを削除することから始める。
ダウンロードしたFTCleanを展開し、インストール。 事前にPCに接続されたUSB機器は取り外しておくこと。 アプリを起動後、このような画面が現れるので、
消去対象を確認後、ファイルをデリートする。
デバイスをプログラムするためのアプリX-CTUをインストールする。
PCのUSBポートにUSB FTDI TTL-232 cableを接続する。 デバイス・ドライバーにはダウンロードしておいた専用ドライバーを指定し、インストールを行う。
USBケーブルにXBeeモジュールを取り付けたアダプターキットを接続する。コネクターの取り付け場所＆方向に注意。正しく接続されると、グリーンのLEDが点滅を始める。
X-CTUでデバイスが取り付けられたCOMポートを指定し、アプリとの接続を確認する。デフォルトの通信速度は9600Baud。 接続に成功すると以下の画面が現れる。
接続が完了したらTerminalのタブをクリックして+++を入力する。
OKが表示されたらすかさずコマンド AT を入力。
再度 OK が出たら ATBD コマンドを打ち込んで、現在設定されているBaudRateを確認する。 デフォルトの状態では 3 など一桁の数字が表示される。
次にBaudRate/31250kHzに相当する 7A12 をセットする。 コマンドは、ATBD7A12 となる。
最後に ATWR コマンドで書き込みを確定し、Baudrateの変更が完了する。
書き込み完了後、PC Settingのタブに移動し、BaudRateを 38400Baud に指定して再接続を確認する。
次にModemConfigurationのタブをクリックし、XBeeの状態を読み込む。
Midi通信に必要な設定ポイントを以下に示す。
CH：通信を行う周波数チャンネルの設定。トラフィックの多そうなデータストリームは事前に分離しておく。
DL：接続先のアドレス 4桁の数字で設定
MY：自前のアドレス 4桁の数字で設定
RP：受信状態を示す赤色LEDの点滅スピード
通信はPierToPierで行われるが、ボトルネックの存在を無視する限りチャンネル固定で多対多の通信が行える。この場合、デバイス設定は2通りなので、個別のデバイスを指定してプロトコルを送信するような細かい芸当は出来ない。
自作MIDIデバイスとの組み合わせの他、市販の機器に組み込んで運用試験を行なっているが、今のところ動作は安定しているようだ。
2013年5月4日追記：
X-CTUにて、ファームウエアの書換えが最初の一個を除いて全く行えない問題の解決になるか？
中古品を買った場合はファクトリーリセットが必須。
その後、BD=Interface Data Rateを直接ModemConfigurationの項目からイジると、何故か再接続不能になるという深刻なバグの存在が発覚した。
同じプロセスでデータを変更しようとした他のXBeeが同様のトラブルに見舞われたことから、このバグには再現性が有ると判断している。
Data Rateの変更は、必ずTerminalからATコマンド、ATBD7A12 を使って行うこと。
2013年5月7日追記：
再接続不能に陥っていたXBeeの復旧が偶然成功した。
Webを検索して得られた「Write後に"接続先が見つからない"というアラート
が出た状態でRst端子をGNDに落とす」という方法でシステム・リセットを行う。
不調となっていた2体のXBeeのうち、1体はRestoreが成功するが、もう一体は何度リセットを行なっても通信速度がデフォルト値の9800bpsに戻らず、Restoreが叶わない状態が続く。
1日作業を放置した後、試しに通信速度を40000bpsに設定して再度接続を試みたところ、すんなりと認識された。 ファームウエアVer.A5では、ModemConfigurationのInterfaceDataRateから接続スピードを5-38400bpsに選択すると、何故か見当違いな値に設定されてしまうようだ。
その後、ATコマンドを使って通信速度を7A12に設定し直し、再度X-CTU側の通信速度を31250bpsに変更して接続を確認。 アドレスの書き換えを行なってみたところ、無事保存された設定で動作している模様。
今回は偶々ドンピシャの値で不明だった通信速度を探し当てられたのが幸いだった。 不具合の出ているXBeeに電源を投入した状態でパイロットLEDが点滅している場合、「デバイスは死亡していない」可能性がある。 早まって廃棄処分にする前に通信速度の設定を疑おう。
元ネタはこちら。Adafruite系のアダプターの使用を前提としたWirelessMidiシステムの構築方法が紹介されているが、若干説明不足な部分があったので補足を加えたメソッドを以下に記していく。
準備するソフトウエア：
FTClean：FTD製品のドライバーをデリートするためのアプリ。
midiDriver：midiの通信速度に対応したドライバー
X-CTU：XBeeとの通信を行うためのアプリ
準備するハードウエア：
AdafluiteのXBee関連モジュール。
XBeeProModule Series1 x 2 (1set)
XBee Adaptor Kit x 2
USB FTDI TTL-232 cable
このうち、電波法の関係からXBeeModuleは日本国内での調達が必須となる。
その他、ソフトウエアを作動させるWindowsXP/7の搭載されたPCが必要。
PCにハード＆ソフトウエアをインストールする前に、Adafruiteのアダプターキットを組み立てておく。
PC上の作業は、まずFDT関連のドライバーを削除することから始める。
ダウンロードしたFTCleanを展開し、インストール。 事前にPCに接続されたUSB機器は取り外しておくこと。 アプリを起動後、このような画面が現れるので、
消去対象を確認後、ファイルをデリートする。
デバイスをプログラムするためのアプリX-CTUをインストールする。
PCのUSBポートにUSB FTDI TTL-232 cableを接続する。 デバイス・ドライバーにはダウンロードしておいた専用ドライバーを指定し、インストールを行う。
USBケーブルにXBeeモジュールを取り付けたアダプターキットを接続する。コネクターの取り付け場所＆方向に注意。正しく接続されると、グリーンのLEDが点滅を始める。
X-CTUでデバイスが取り付けられたCOMポートを指定し、アプリとの接続を確認する。デフォルトの通信速度は9600Baud。 接続に成功すると以下の画面が現れる。
接続が完了したらTerminalのタブをクリックして+++を入力する。
OKが表示されたらすかさずコマンド AT を入力。
再度 OK が出たら ATBD コマンドを打ち込んで、現在設定されているBaudRateを確認する。 デフォルトの状態では 3 など一桁の数字が表示される。
次にBaudRate/31250kHzに相当する 7A12 をセットする。 コマンドは、ATBD7A12 となる。
最後に ATWR コマンドで書き込みを確定し、Baudrateの変更が完了する。
書き込み完了後、PC Settingのタブに移動し、BaudRateを 38400Baud に指定して再接続を確認する。
次にModemConfigurationのタブをクリックし、XBeeの状態を読み込む。
Midi通信に必要な設定ポイントを以下に示す。
CH：通信を行う周波数チャンネルの設定。トラフィックの多そうなデータストリームは事前に分離しておく。
DL：接続先のアドレス 4桁の数字で設定
MY：自前のアドレス 4桁の数字で設定
RP：受信状態を示す赤色LEDの点滅スピード
通信はPierToPierで行われるが、ボトルネックの存在を無視する限りチャンネル固定で多対多の通信が行える。この場合、デバイス設定は2通りなので、個別のデバイスを指定してプロトコルを送信するような細かい芸当は出来ない。
自作MIDIデバイスとの組み合わせの他、市販の機器に組み込んで運用試験を行なっているが、今のところ動作は安定しているようだ。
2013年5月4日追記：
X-CTUにて、ファームウエアの書換えが最初の一個を除いて全く行えない問題の解決になるか？
中古品を買った場合はファクトリーリセットが必須。
その後、BD=Interface Data Rateを直接ModemConfigurationの項目からイジると、何故か再接続不能になるという深刻なバグの存在が発覚した。
同じプロセスでデータを変更しようとした他のXBeeが同様のトラブルに見舞われたことから、このバグには再現性が有ると判断している。
Data Rateの変更は、必ずTerminalからATコマンド、ATBD7A12 を使って行うこと。
2013年5月7日追記：
再接続不能に陥っていたXBeeの復旧が偶然成功した。
Webを検索して得られた「Write後に"接続先が見つからない"というアラート
が出た状態でRst端子をGNDに落とす」という方法でシステム・リセットを行う。
不調となっていた2体のXBeeのうち、1体はRestoreが成功するが、もう一体は何度リセットを行なっても通信速度がデフォルト値の9800bpsに戻らず、Restoreが叶わない状態が続く。
1日作業を放置した後、試しに通信速度を40000bpsに設定して再度接続を試みたところ、すんなりと認識された。 ファームウエアVer.A5では、ModemConfigurationのInterfaceDataRateから接続スピードを5-38400bpsに選択すると、何故か見当違いな値に設定されてしまうようだ。
その後、ATコマンドを使って通信速度を7A12に設定し直し、再度X-CTU側の通信速度を31250bpsに変更して接続を確認。 アドレスの書き換えを行なってみたところ、無事保存された設定で動作している模様。
今回は偶々ドンピシャの値で不明だった通信速度を探し当てられたのが幸いだった。 不具合の出ているXBeeに電源を投入した状態でパイロットLEDが点滅している場合、「デバイスは死亡していない」可能性がある。 早まって廃棄処分にする前に通信速度の設定を疑おう。
posted by Yasuski at 22:45| XBee
2013年03月14日
midimanのUSB/midiInterfaceにXBeeを組み込む
データのボトルネックによってmidi信号をハンドリングしきれない現状を打破するために、急遽楽器受け専用のデバイスを製作した。
有線入力を受け付けられるように、Bchはそのまま残し、使い勝手が悪そうなAchを無効化してWiFi入力とした。
具体的な改造方法は、
1）フォトカプラーPC900の4番Pinをフローティングさせて、基板側にXBeeのTxを接続する
2）ロジックIC、74HC244の4番pinをフローティングさせて、基盤側にXBeeのRxを接続する
3）電源ラインをUSB端子から直に引く
以上3点とシンプル。
74HC244は表面実装なので、ICの足を折らないように注意すること。自分は油断してICを削る羽目に陥った。オープン状態になった足は配線でグランドに接続しておく。
テストの結果、受信は問題無く動作は安定している。送信の状態はミニ鍵盤側の受けが（元から）不調気味だった為に判断できず。
XBeeのバッファー設定を変更しているので、それが安定に寄与しているのかもしれない。
3月18日追記:
試しにPC側からの「送り」ポートとして"MidiPortA"をkymaConnectで設定したところ、取り溢しが発生。kymaから送っている外部シーケンサー用のSync情報がボトルネックを発生させていることが確定した。CoreMidi内部で処理する分に問題はないが、有線/無線共にレガシー規格でのハンドリングは回避すべきとの結論が出た。
有線入力を受け付けられるように、Bchはそのまま残し、使い勝手が悪そうなAchを無効化してWiFi入力とした。
具体的な改造方法は、
1）フォトカプラーPC900の4番Pinをフローティングさせて、基板側にXBeeのTxを接続する
2）ロジックIC、74HC244の4番pinをフローティングさせて、基盤側にXBeeのRxを接続する
3）電源ラインをUSB端子から直に引く
以上3点とシンプル。
74HC244は表面実装なので、ICの足を折らないように注意すること。自分は油断してICを削る羽目に陥った。オープン状態になった足は配線でグランドに接続しておく。
テストの結果、受信は問題無く動作は安定している。送信の状態はミニ鍵盤側の受けが（元から）不調気味だった為に判断できず。
XBeeのバッファー設定を変更しているので、それが安定に寄与しているのかもしれない。
3月18日追記:
試しにPC側からの「送り」ポートとして"MidiPortA"をkymaConnectで設定したところ、取り溢しが発生。kymaから送っている外部シーケンサー用のSync情報がボトルネックを発生させていることが確定した。CoreMidi内部で処理する分に問題はないが、有線/無線共にレガシー規格でのハンドリングは回避すべきとの結論が出た。
posted by Yasuski at 05:07| XBee
2013年02月26日
XBeeにトラブル発生
新たにRocktron/AllAccessにインストールを試みるも、中古で購入したXBeeの送信が不調で受け側のMidiInterfaceとペアリングが出来ない。
原因特定のため正常なXBeeと比較検討した後、不調が発覚したデバイス2個の初期化を行った。
初期化を行うと通信速度がデフォルトの9800bpsに戻ることに注意。 ATコマンドで再度midi規格の通信速度＂7A12＂に設定し直し、デバイスを一度取り外してリセットを行う。 通信速度を暫定の38400bpsで再度接続した後に、識別番号のプリセットとシリアル通信の設定を確認する。
ひとまずこれで、midi回路のWiFi化は終了。 明日は、AC電源不要の完全スタンドアロン化の一環としてバッテリーの導入を目指す。
原因特定のため正常なXBeeと比較検討した後、不調が発覚したデバイス2個の初期化を行った。
初期化を行うと通信速度がデフォルトの9800bpsに戻ることに注意。 ATコマンドで再度midi規格の通信速度＂7A12＂に設定し直し、デバイスを一度取り外してリセットを行う。 通信速度を暫定の38400bpsで再度接続した後に、識別番号のプリセットとシリアル通信の設定を確認する。
ひとまずこれで、midi回路のWiFi化は終了。 明日は、AC電源不要の完全スタンドアロン化の一環としてバッテリーの導入を目指す。
posted by Yasuski at 01:24| XBee
2013年02月25日
MotorMixのWiFi信号ラインを複線化する
WiFiデバイスの複線化は、XBeeが合計4個も必要となってしまう「あまりCPの良くない設計」ではあるが、Kyma側から外部機器へ送信するSync信号が常にトラフィックを占有することを考えると、これ以外の選択肢は無いものと思われる。
参考までに、写真はデータの受信を失敗している画像。
今回新たに追加するXBeeペアの設定は、従来のものから送受信のチャンネルを変えるだけ。Pacarana側を基準に、受け側を"C"／送り側を"D"とした。 これらの新たな送受信ペアを受け側、送り側、各々の信号ループに挿入する。
当初はMotorMix側の受信が上手くいかずに焦ったが、不調の原因は迂闊にもオープン状態になっていたXBeeのRx端子にあった。インピーダンスが高い状態で放置されたC-MOS ICの端子が、ノイズを拾ってバタついているようだ。 Rx端子を隣のV＋端子に20kの抵抗でプルアップした結果、不具合は収まった。
複線化は目論見通りある程度は功を奏したようで、スイッチングが無視される局面は確かに激減した。
ただし、Wirelessゆえの不安定さを完全に払拭するには至っておらず、偶に入力を無視される事があるので過信は禁物。
参考までに、写真はデータの受信を失敗している画像。
今回新たに追加するXBeeペアの設定は、従来のものから送受信のチャンネルを変えるだけ。Pacarana側を基準に、受け側を"C"／送り側を"D"とした。 これらの新たな送受信ペアを受け側、送り側、各々の信号ループに挿入する。
当初はMotorMix側の受信が上手くいかずに焦ったが、不調の原因は迂闊にもオープン状態になっていたXBeeのRx端子にあった。インピーダンスが高い状態で放置されたC-MOS ICの端子が、ノイズを拾ってバタついているようだ。 Rx端子を隣のV＋端子に20kの抵抗でプルアップした結果、不具合は収まった。
複線化は目論見通りある程度は功を奏したようで、スイッチングが無視される局面は確かに激減した。
ただし、Wirelessゆえの不安定さを完全に払拭するには至っておらず、偶に入力を無視される事があるので過信は禁物。
posted by Yasuski at 00:37| XBee
2013年02月18日
WirelessMidiData送受信の複線化
WirelessMidiの動作試験を数ヶ月行っているが、このBlogの記事にあるように、過大なDataTrafficの影響でMortorMixの動作がすこぶる不安定だ。
この現状を解決するためにはやはりDataStreamの複線化を考える必要がある。
ということで、今週中に作業を貫徹する予定。
この現状を解決するためにはやはりDataStreamの複線化を考える必要がある。
ということで、今週中に作業を貫徹する予定。
posted by Yasuski at 14:19| XBee
2012年10月01日
MotorMix＠midiOutポートの切り替え機能を追加する
MaximのQuadタイプのアナログSWシリーズのうち、MAX314は左右のバンクでSWの動きが反転しているので、COM端子を直結するだけで容易にトグル動作を実現できる。
ICは単電源でも動作するのでmidi工作などデータを扱う用途に便利なデバイスといえる。 これをMotorMixのmidi出力の直前にインサートし、midi出力端子と内部に設置したXBeeへのデータ送り用フォトカプラーを切り替える仕組み。
MAX314のLogicコントロール端子は全て並列に接続し、入力信号の切替えスイッチMAX4544と連動させている。
ICは単電源でも動作するのでmidi工作などデータを扱う用途に便利なデバイスといえる。 これをMotorMixのmidi出力の直前にインサートし、midi出力端子と内部に設置したXBeeへのデータ送り用フォトカプラーを切り替える仕組み。
MAX314のLogicコントロール端子は全て並列に接続し、入力信号の切替えスイッチMAX4544と連動させている。
posted by Yasuski at 00:31| XBee
2012年09月28日
WirelessMidiSystem＠受信ユニットの製作
XBeeを使った、WirelessMidiシステムの受信ユニットを製作した。
今回はPICやAVR等でUSB/Midiシステムを自作するよりも市販品を購入した方が安価なこと、Kyma対応システムの構築が喫緊の課題ということから、Pacarana接続の実績があるM-Audio/Unoを選択した。
搭載されているMCUはカスタムチップなので、ミスで入出力ポートを破壊すると「終わってしまう」可能性がある。安全マージンを考えた結果、MidiOutの信号をフォトカプラーで受け、その出力をXBeeに送ることにした。
今回の製作では有線のmidi入力は不要。余った信号受けのフォトカプラーは、そのままmidi出力用のコンバーターに転用できる。
ちなみに、このボードに使用されている6N139は6番pinが出力。 まず、端子を基板の根本で切断して持ち上げ、MCUヘの配線を外す。
次に、基板側のランドにXBeeの受信ラインを繋ぐ一方、フローティングした端子をXBeeの送信ラインに接続する。
フォトカプラーの出力はオープンコレクターなので、このままでは動作しない。XBeeAdaptor側でRX端子とVCC端子の間を抵抗値220～470Ω程度でプルアップしておく。
その後、Roland製のUSB/Midiコンバーターの改造を行ったので、こちらのメソッドも記録しておく。
現時点でこのユニットはPacarana側が対応していないが、Kyma系のラインを外れた汎用入出力として使用できる。 外部アプリにPacarana経由で機器を接続する場合、Pacaranaに接続したUSB/Midiコンバーターからの入出力はKymaのSound（Object）上に設定が必要となり、プログラムの構造が煩雑になってしまう。 回路の簡素化のためにはPCに直接接続するWiFi/Midiデバイスが必要だ。
基盤を見たところ、こちらのMCUもカスタムチップなので、安全のためフォトカプラーの出力端子をフローティングして入力用に再利用する。 フォトカプラーPC410は5番pinが出力なので、これをフローティングして対処する。表面実装チップは足の造りが華奢なので配線には細心の注意を払うこと。
midi端子側の手当は「青＆茶」と「赤＆黄」を配線して、MCUからのmidi出力をフォトカプラーに接続する。これで、midi出力の直結が完了した。
ちなみに、試作段階では安価な中華製の＄5コンバーターを使っていたが、バッファーの容量不足が原因と思われるエラーが頻発していた。
Roland製のデバイスに換装後、エラーの発生は確認していない。
今回はPICやAVR等でUSB/Midiシステムを自作するよりも市販品を購入した方が安価なこと、Kyma対応システムの構築が喫緊の課題ということから、Pacarana接続の実績があるM-Audio/Unoを選択した。
搭載されているMCUはカスタムチップなので、ミスで入出力ポートを破壊すると「終わってしまう」可能性がある。安全マージンを考えた結果、MidiOutの信号をフォトカプラーで受け、その出力をXBeeに送ることにした。
今回の製作では有線のmidi入力は不要。余った信号受けのフォトカプラーは、そのままmidi出力用のコンバーターに転用できる。
ちなみに、このボードに使用されている6N139は6番pinが出力。 まず、端子を基板の根本で切断して持ち上げ、MCUヘの配線を外す。
次に、基板側のランドにXBeeの受信ラインを繋ぐ一方、フローティングした端子をXBeeの送信ラインに接続する。
フォトカプラーの出力はオープンコレクターなので、このままでは動作しない。XBeeAdaptor側でRX端子とVCC端子の間を抵抗値220～470Ω程度でプルアップしておく。
その後、Roland製のUSB/Midiコンバーターの改造を行ったので、こちらのメソッドも記録しておく。
現時点でこのユニットはPacarana側が対応していないが、Kyma系のラインを外れた汎用入出力として使用できる。 外部アプリにPacarana経由で機器を接続する場合、Pacaranaに接続したUSB/Midiコンバーターからの入出力はKymaのSound（Object）上に設定が必要となり、プログラムの構造が煩雑になってしまう。 回路の簡素化のためにはPCに直接接続するWiFi/Midiデバイスが必要だ。
基盤を見たところ、こちらのMCUもカスタムチップなので、安全のためフォトカプラーの出力端子をフローティングして入力用に再利用する。 フォトカプラーPC410は5番pinが出力なので、これをフローティングして対処する。表面実装チップは足の造りが華奢なので配線には細心の注意を払うこと。
midi端子側の手当は「青＆茶」と「赤＆黄」を配線して、MCUからのmidi出力をフォトカプラーに接続する。これで、midi出力の直結が完了した。
ちなみに、試作段階では安価な中華製の＄5コンバーターを使っていたが、バッファーの容量不足が原因と思われるエラーが頻発していた。
Roland製のデバイスに換装後、エラーの発生は確認していない。
posted by Yasuski at 19:31| XBee
MotorMixにXBeeを組み込む
MotorMixでPC上のアプリケーションと連携を行う場合、ホストアプリケーションから送信されるデータを受け、それを送り返すフィードバックループを形成する必要がある。
そのため、Midiデータストリームは閉鎖ルーティンとなるが、このループ内に他のmidi機器を接続した場合、後述するMotorMix独自のシリアル通信プロトコルが特殊なために、下流に接続した機器のmidiアウトにMotorMixのデータが反映されず、データに混乱が生じてしまう。
現在は3rdParty製の機能拡張、"KymaConnect" によってmidiループの取扱いが楽になったが、以前は送信元となるCapyのmidi出力を並列化し、ループに挿入するスイッチマトリックスにMarge機能を持たせることで、他のmidi機器との共存を可能としていた。 今はKymaConnectによって接続が簡略化されているが、複数の有線midiルーティンを現場で設定する手間はできるだけ省きたいのが人情だ。
そこで登場するのがWiFi/Midiデバイス。一対多のデータ送信が可能＝送信データが並列化される一方、受信側は自動的に複数の発信元のデータをMarge出来る。WiFi/Midiを採用することでmidiルーティンの単純化に貢献できるはずだ。
MotorMixはMidiに準拠した独自のプロトコルで運用されている。具体的にはMidi/ch#1を専有して、スイッチ&フェーダー類の状態を反映している。 送信側のデータ長はスタンダードなmidi信号と異なり、5バイト単位で送信しているが、通常のMIDI機器はこのようなイレギュラーな信号は入り口で堰き止めてしまう。従って、MotorMixは閉鎖されたMidi接続ループの中に組み込まなくてはならない。
WirelessMidiの場合、送信される信号は受信対象全体に配信される一方、受信データ群はハブとなる受信デバイスに自動的に纏められる。 これは、MidiThruやMidiMixer機能を持ったハードウエアを使用する必要が無くなる事を意味する。 しかも結線から開放されるので言うことなしだ。
以下、MotorMixの改造メソッドを記していく。
回路構成は、MidiReceiveのフォトカプラー出力と、MCUの間の配線にXBeeの受信ポートを割込ませる一方、MidiTransmit信号を別途用意したフォトカプラーで受け、データをXBeeに送る形となる。
現時点では入力系はアナログスイッチによって切り替えているが、
MidiOutに関しては手当を行なっていない。最終的にはアナログスイッチで切り替え可能な構造に改良し、有線システムとの共存を図る予定。
以下、改造に必要なデバイスは：
１）XBeeで構築したmidiI/Oシステム一式 （USB/Midiインターフェイスを含む）
２）フォトカプラー（midi出力の復調用）
３）74HC14等のロジックIC （信号ライン監視用のインジケーターを追加する場合に必要）
４）MAX4544等のアナログスイッチ（入出力信号の振り分け用）
５）XBee取り付け用のソケット
６）ユニバーサル基板
７）LED接続用の抵抗
８）電源平滑用の電解コンデンサー
といったところ。
次に、改造の手順を記す。
まずは本体の加工。 WiFi関連のインジケーターの設置場所はLCDの右隣がベストだろう。
バックパネルのSerialNumberの場所に入力切替用のスイッチ用の穴を開ける。
内部に設置する基板は両面テープで固定するタイプのM3ネジ対応スタッドで固定する。
midi入力のフォトカプラー出力端子は基板のこの部分なので、プリントされた信号ラインをカットしてワイヤーを2本引き出す。
引き出した受信ラインは、アナログスイッチICに接続する。左側のラインをアナログスイッチのCOM端子に、フォトカプラーからのラインをNOに接続。NCにはXBeeからの受信ラインを配置する。
IN端子はLEDと抵抗でプルアップし、スイッチを介してGNDに接続する。押しボタン式のLED照光スイッチはバックパネルに配置する。
midi出力は、midiOut端子から新たに用意したフォトカプラーに接続し、出力をXBeeのTX端子に送る。
この部分にアナログスイッチ×２を介在させることで、有線midiとシステムを同居させることが可能。（現時点では未対応）
電源に関しては、モーターフェーダーの駆動時にスパイクノイズが発生し、WiFiシステムがダウンする現象を確認している。 対応策として、電源ラインに100uF程度のパスコンを追加した。結果、動作は安定した。
当初はXBeeの送信系が不調でバグ潰しに苦労させられた。XBeeは華奢なデバイスっぽいので、取扱には注意が必要。 間違えて、送信するmidiデータを反転させていた事も完成が遅れた理由の一つ。 送受信は基本「非反転」で問題ない。
映像記録は正常な信号をジェネレートするMotorMixのmidi出力。
ボトルネックの発生には至らず、スムーズに送信が行われている。
そのため、Midiデータストリームは閉鎖ルーティンとなるが、このループ内に他のmidi機器を接続した場合、後述するMotorMix独自のシリアル通信プロトコルが特殊なために、下流に接続した機器のmidiアウトにMotorMixのデータが反映されず、データに混乱が生じてしまう。
現在は3rdParty製の機能拡張、"KymaConnect" によってmidiループの取扱いが楽になったが、以前は送信元となるCapyのmidi出力を並列化し、ループに挿入するスイッチマトリックスにMarge機能を持たせることで、他のmidi機器との共存を可能としていた。 今はKymaConnectによって接続が簡略化されているが、複数の有線midiルーティンを現場で設定する手間はできるだけ省きたいのが人情だ。
そこで登場するのがWiFi/Midiデバイス。一対多のデータ送信が可能＝送信データが並列化される一方、受信側は自動的に複数の発信元のデータをMarge出来る。WiFi/Midiを採用することでmidiルーティンの単純化に貢献できるはずだ。
MotorMixはMidiに準拠した独自のプロトコルで運用されている。具体的にはMidi/ch#1を専有して、スイッチ&フェーダー類の状態を反映している。 送信側のデータ長はスタンダードなmidi信号と異なり、5バイト単位で送信しているが、通常のMIDI機器はこのようなイレギュラーな信号は入り口で堰き止めてしまう。従って、MotorMixは閉鎖されたMidi接続ループの中に組み込まなくてはならない。
WirelessMidiの場合、送信される信号は受信対象全体に配信される一方、受信データ群はハブとなる受信デバイスに自動的に纏められる。 これは、MidiThruやMidiMixer機能を持ったハードウエアを使用する必要が無くなる事を意味する。 しかも結線から開放されるので言うことなしだ。
以下、MotorMixの改造メソッドを記していく。
回路構成は、MidiReceiveのフォトカプラー出力と、MCUの間の配線にXBeeの受信ポートを割込ませる一方、MidiTransmit信号を別途用意したフォトカプラーで受け、データをXBeeに送る形となる。
現時点では入力系はアナログスイッチによって切り替えているが、
MidiOutに関しては手当を行なっていない。最終的にはアナログスイッチで切り替え可能な構造に改良し、有線システムとの共存を図る予定。
以下、改造に必要なデバイスは：
１）XBeeで構築したmidiI/Oシステム一式 （USB/Midiインターフェイスを含む）
２）フォトカプラー（midi出力の復調用）
３）74HC14等のロジックIC （信号ライン監視用のインジケーターを追加する場合に必要）
４）MAX4544等のアナログスイッチ（入出力信号の振り分け用）
５）XBee取り付け用のソケット
６）ユニバーサル基板
７）LED接続用の抵抗
８）電源平滑用の電解コンデンサー
といったところ。
次に、改造の手順を記す。
まずは本体の加工。 WiFi関連のインジケーターの設置場所はLCDの右隣がベストだろう。
バックパネルのSerialNumberの場所に入力切替用のスイッチ用の穴を開ける。
内部に設置する基板は両面テープで固定するタイプのM3ネジ対応スタッドで固定する。
midi入力のフォトカプラー出力端子は基板のこの部分なので、プリントされた信号ラインをカットしてワイヤーを2本引き出す。
引き出した受信ラインは、アナログスイッチICに接続する。左側のラインをアナログスイッチのCOM端子に、フォトカプラーからのラインをNOに接続。NCにはXBeeからの受信ラインを配置する。
IN端子はLEDと抵抗でプルアップし、スイッチを介してGNDに接続する。押しボタン式のLED照光スイッチはバックパネルに配置する。
midi出力は、midiOut端子から新たに用意したフォトカプラーに接続し、出力をXBeeのTX端子に送る。
この部分にアナログスイッチ×２を介在させることで、有線midiとシステムを同居させることが可能。（現時点では未対応）
電源に関しては、モーターフェーダーの駆動時にスパイクノイズが発生し、WiFiシステムがダウンする現象を確認している。 対応策として、電源ラインに100uF程度のパスコンを追加した。結果、動作は安定した。
当初はXBeeの送信系が不調でバグ潰しに苦労させられた。XBeeは華奢なデバイスっぽいので、取扱には注意が必要。 間違えて、送信するmidiデータを反転させていた事も完成が遅れた理由の一つ。 送受信は基本「非反転」で問題ない。
映像記録は正常な信号をジェネレートするMotorMixのmidi出力。
ボトルネックの発生には至らず、スムーズに送信が行われている。
posted by Yasuski at 15:14| XBee
2012年09月22日
XBeeへの乗換え
帰阪後にWirelessMidiの開発を再開した経過のまとめ：
1）AdafruitにWiFi関連の製品 XBee を発注。H8/WiPortとは別のMethodでWiFi/midiにトライする計画だが、こちらは純粋にmidi信号をやり取りするスタンスなので、別個midiインターフェイスを用意する必要がある。
2）一方、PICを使ったBaudRateConverterの製作だが、焼き込み用のデバイスが届いたものの、PCとの相性が悪いのか要求されたリセットが掛からず、今のところ使用不能。 既に購入していたTop2005+はWin7との相性が悪く使用不能だったが、これをXP搭載のラップトップから起動して書き込みにトライしたところ、無事Firmwareを焼き込めた。動作の確認は行なっていない。 使用したPIC12F683はバッファーが64biteと猛烈に少なく、データの取りこぼしが心配。 反面、H8の512biteが多すぎるという話もあるが、今後実用レベルで遅延とエラーのトレードオフをすり合わせる必要があるだろう。 今回はとりあえず手持ちの10個分にデータを書き込んでおいた。
3）WiPortとH8の接続が上手くいかない原因を考えた。
a）一番疑わしいのはBaudRateの設定ミスなので、まずH8の出力が正常かどうかをUSB/Serialを使って判定する。 ちなみに、H8同士で38400baudの通信は全く問題なく行えているので、midiプロトコルは正常にやり取りされている。
b）WiPortとH8のロジックレベルが不一致な可能性もあるので、他の機器と直結してトラブルの再現を試みる。 ただ、間にPhotoCouplerを噛ましても状態に違いはなかったので、信号ラインに挿入しているLevelShifterの用法に問題がある可能性も否定出来ない。
c）WiPortとBaudRateConverterを実装したPIC直結でデータの転送が行われているかどうかを実証する。
検査の第一段階としてH8をUSB/Serialに接続し、HairlessMidi経由でデータストリームを目視してみた。
その結果は、、、残念なことにTerminalには正常なデータが読み込まれていないことが判明した。 H8同士を直結した状態では問題が発生していないので、この結果には大変困惑している。 H8から出力されるデータのBaudRateに誤差が生じている可能性が大きくなったが、H8同士の互換性は証明されているので、単純に通信速度の問題なのかもしれない。
この時点でWiPortには見切りをつけ、並行して開発していたXBeeによるWifi通信に注力することにした。
1）AdafruitにWiFi関連の製品 XBee を発注。H8/WiPortとは別のMethodでWiFi/midiにトライする計画だが、こちらは純粋にmidi信号をやり取りするスタンスなので、別個midiインターフェイスを用意する必要がある。
2）一方、PICを使ったBaudRateConverterの製作だが、焼き込み用のデバイスが届いたものの、PCとの相性が悪いのか要求されたリセットが掛からず、今のところ使用不能。 既に購入していたTop2005+はWin7との相性が悪く使用不能だったが、これをXP搭載のラップトップから起動して書き込みにトライしたところ、無事Firmwareを焼き込めた。動作の確認は行なっていない。 使用したPIC12F683はバッファーが64biteと猛烈に少なく、データの取りこぼしが心配。 反面、H8の512biteが多すぎるという話もあるが、今後実用レベルで遅延とエラーのトレードオフをすり合わせる必要があるだろう。 今回はとりあえず手持ちの10個分にデータを書き込んでおいた。
3）WiPortとH8の接続が上手くいかない原因を考えた。
a）一番疑わしいのはBaudRateの設定ミスなので、まずH8の出力が正常かどうかをUSB/Serialを使って判定する。 ちなみに、H8同士で38400baudの通信は全く問題なく行えているので、midiプロトコルは正常にやり取りされている。
b）WiPortとH8のロジックレベルが不一致な可能性もあるので、他の機器と直結してトラブルの再現を試みる。 ただ、間にPhotoCouplerを噛ましても状態に違いはなかったので、信号ラインに挿入しているLevelShifterの用法に問題がある可能性も否定出来ない。
c）WiPortとBaudRateConverterを実装したPIC直結でデータの転送が行われているかどうかを実証する。
検査の第一段階としてH8をUSB/Serialに接続し、HairlessMidi経由でデータストリームを目視してみた。
その結果は、、、残念なことにTerminalには正常なデータが読み込まれていないことが判明した。 H8同士を直結した状態では問題が発生していないので、この結果には大変困惑している。 H8から出力されるデータのBaudRateに誤差が生じている可能性が大きくなったが、H8同士の互換性は証明されているので、単純に通信速度の問題なのかもしれない。
この時点でWiPortには見切りをつけ、並行して開発していたXBeeによるWifi通信に注力することにした。
posted by Yasuski at 11:07| XBee
