スマイルデコーダR4でのVVVFスケッチその後 [ds-DCCデコーダ]
トレジャー様のBlogの信号機の記事で据え置き型動力車用デコーダをご紹介いただいています。信号機のセンサに方向を持たせるというアイディアは私には思いつきませんでした。
据え置き型動力車用デコーダの元の、セラコン付け忘れた昇圧型ポイントデコーダですが、少し前のS88基板を注文した時にセラコンも乗るようなパターンの基板（K1)もついでに頼んで受け取っているのですが、そういえば、動作確認していません・・・。ほかに先にやることが多くて。
それで、スマイルデコーダR4のVVVFスケッチその後ですが、いろいろとやっておぼろげにわかってきました。なんか二つ悪い現象があるようです。以下のどちらもDSmainR5+スマイルデコーダR4の組み合わせで起きます。デコーダ開発ボードでは起きません。
その１：CV47を５のドレミファインバータ京急にすると、その後、書き込みを受け付けなくなる。
その２：ほかのCVも通電させて何回も書き換えているとそのうち書けなくなる。通電をやめて少し経つとまた書き込めるようになる。
それで、もともとのやあさん様のスケッチと比べると大きな違いは、Setup部分の処理の大きさで、元のDSDCCDecoderスケッチは、DCC.Init後にすぐにDCCループに入るのですが、VVVFスケッチはInit後に、VVVF部分の配列のコピー（京急だけ他よりも3倍長くかかる）とメロディーの初期化を行ってからループに入ります。
波形などで確認したわけではないですが、DSmainR4に比べ、DSmainR5はダイレクトモード時の電源OffOn後のパケット送信のタイミングが早いのではないかなあと思いました。（DSDecR1の時も最初の頃にCV書けないのがArduinoProMiniのリセット時間の問題だったような気がするし）
と考えると、Setup時に京急に切り替えた後は、Setupに時間がかかりDCCループに入るまでの時間が長くなり、ダイレクトモード時の書き込み？を取りこぼして、Ackが返ってこない（モーターが回らない）。ただし、その２については説明できません。通電時間が伸びると書き込めなくなるなら、温度でクロックが遅くなるのかなあとセラロック（ただしムラタ）の仕様を見てみましたが、温度上昇でクロックもちょっと早くなるようでした。まあ、タイミングが微妙にずれているに違いないとか勝手に推測しています。
で、Setupの時間が怪しいので、Setup時のVVVF配列へのコピーをやめて、VVVF音を計算するところで毎回、Kasoku配列（ROMに入っているところ）を読むように変えたら、京急に変えたあとも、Writeを受け付けるようになりました。ということで、ここは正解っぽいです。
ただし、Writeが受け付けないことも時々あるので、もう少しSetup部分を短くして確認していこうと思います。具体的にはPWMDacSynthの初期化をループ内のメロディー部分に移動しようかと思ってます。
か、DCC.InitをSetupの一番後ろに持っていくかかなあと思います。
ある程度、安定して動くようになったら公開いたします。
据え置き型動力車用デコーダの元の、セラコン付け忘れた昇圧型ポイントデコーダですが、少し前のS88基板を注文した時にセラコンも乗るようなパターンの基板（K1)もついでに頼んで受け取っているのですが、そういえば、動作確認していません・・・。ほかに先にやることが多くて。
それで、スマイルデコーダR4のVVVFスケッチその後ですが、いろいろとやっておぼろげにわかってきました。なんか二つ悪い現象があるようです。以下のどちらもDSmainR5+スマイルデコーダR4の組み合わせで起きます。デコーダ開発ボードでは起きません。
その１：CV47を５のドレミファインバータ京急にすると、その後、書き込みを受け付けなくなる。
その２：ほかのCVも通電させて何回も書き換えているとそのうち書けなくなる。通電をやめて少し経つとまた書き込めるようになる。
それで、もともとのやあさん様のスケッチと比べると大きな違いは、Setup部分の処理の大きさで、元のDSDCCDecoderスケッチは、DCC.Init後にすぐにDCCループに入るのですが、VVVFスケッチはInit後に、VVVF部分の配列のコピー（京急だけ他よりも3倍長くかかる）とメロディーの初期化を行ってからループに入ります。
波形などで確認したわけではないですが、DSmainR4に比べ、DSmainR5はダイレクトモード時の電源OffOn後のパケット送信のタイミングが早いのではないかなあと思いました。（DSDecR1の時も最初の頃にCV書けないのがArduinoProMiniのリセット時間の問題だったような気がするし）
と考えると、Setup時に京急に切り替えた後は、Setupに時間がかかりDCCループに入るまでの時間が長くなり、ダイレクトモード時の書き込み？を取りこぼして、Ackが返ってこない（モーターが回らない）。ただし、その２については説明できません。通電時間が伸びると書き込めなくなるなら、温度でクロックが遅くなるのかなあとセラロック（ただしムラタ）の仕様を見てみましたが、温度上昇でクロックもちょっと早くなるようでした。まあ、タイミングが微妙にずれているに違いないとか勝手に推測しています。
で、Setupの時間が怪しいので、Setup時のVVVF配列へのコピーをやめて、VVVF音を計算するところで毎回、Kasoku配列（ROMに入っているところ）を読むように変えたら、京急に変えたあとも、Writeを受け付けるようになりました。ということで、ここは正解っぽいです。
ただし、Writeが受け付けないことも時々あるので、もう少しSetup部分を短くして確認していこうと思います。具体的にはPWMDacSynthの初期化をループ内のメロディー部分に移動しようかと思ってます。
か、DCC.InitをSetupの一番後ろに持っていくかかなあと思います。
ある程度、安定して動くようになったら公開いたします。
2016-03-21 01:45
コメント(2)
トラックバック(0)
＞CVについて
DCCの仕様書では、リセットパケットを受け取ってから20ms以内にDCCパケットを受信して処理をするようにしなければならない、としてます。
どれくらい起動に時間がかかるか分かれば、リセットパケットを起動完了する時間分＋余裕分まで投げ続けて起動待ちする処理にしようと思います。R4より厳し目になってるので、リセットパケットを流す時間を長めにしたいと思います。バックマンのデコーダも何故かCV書き込みができないケースがあるので、この時間をどうするかが鍵となるような気がします。
ちなみに500msくらいあれば大丈夫でしょうか？
＞暴走について
個人的に気になっているのが、暴走する条件があることです。どうも条件がよくわからないのですが、その原因はオーバーフローか、アンダフローが起きているような気もします。
by Yaasan (2016-03-21 14:37)
コメントありがとうございます。
＞CVについて
まずは初期化の時間をはかってみます。ので、お待ちください。
＞暴走について
暴走ですか。パラメータを割り算の分母にも入れているので、計算結果がヘンテコになる可能性はあります。（ヘンテコ（分母０）になったときの安全ルーチンは入れてませんし）。EM13では一時間ぐらい運転すると暴走／動作せずになったことがありますが、VVVFスケッチでは私は暴走したことないですが、優しく運転しているので、今度、耐久試験をしてみたいと思います。
by fujigaya2 (2016-03-21 22:01)