最近OSR-CDIを搭載する車両が一気に増えてきていて、自分でもどれくらいの車両がこれで走っているのか想像が付きませんです。
OSR-CDIは部品を買い集めると、結構な割合で部品が余りますので、結構譲渡されて横展開されて行っている様です。
車種もRDからRZ、AC-CDIを採用したTZR、変わったところではCZなんていう車種まで。
最近は初期型の3MAでも動作させている方もおられます。面白いですね。
春のTOTでも複数の車両が利用しており、秋は更に増えそうな気がします。
多分機能的にはジールトロニックや他の社外CDIの方が色々ついていて良いのでしょうけど、OSR-CDIの場合は頑張れば増産できること、壊れても予備を使えば良いか、という気楽さはあるのかも知れません。
設計図もファームウェアも全部公開されているので、悪いところは自分で修正できるメリットはあると思います。

最近ひとつ気になっている事は、気軽に「譲ってくれ」と言っているところを見かける事です。
自分は最近言われませんけど、他の人が他の人に言ってるのを見ます。
OSR-CDIは「ちゃんと」組み立てるのはそれなりに大変な労力が伴います。
その人同士の繋がりは他人からははかり知る事は出来ませんので、見かけたとしても特に何か言う事もありませんが、その辺理解した上で交渉してほしいなぁとは常々思っています。

さて。
OSR-CDI Version1.3.0の基板ですが、ようやくまぁ何とかというレベルになりました。

少し比較してみます。
Version1.2.1cの基板
IMG_2662

Version1.3.0-1
IMG_2663

Version1.3.0-2
IMG_2664

Version1.3.0-4
IMG_2665

と色々としております。

前回のNo3の基板で、もう十何枚程作成されているという方からアドバイスを頂き再度修正。
改変は多岐に渡りますが全部細かい話です。

どれくらい細かいかっていう話。

OSR-CDI Version1.2.1cの基板のトランジスタランドパターンです。
IMG_2666
スルーホールとランドの幅がスレスレです。
最近品質の上がったElecrowのお陰で何とか形にはなってますが、これでは歩留まりが悪いだろうと思って少しランドの幅を広げました。
また形も少し工夫しました。
IMG_2667

悪くはないのだけど、思ったよりハンダがしやすい訳でも無く。
またランドとスルーホールのサイズ比は良くなったけど、逆にハンダがブリッジしやすくなっていた。
色々過去の基板を眺めて、丸形では無く方形だと綺麗にランドが形成されている事が判明したので、これを試す。
IMG_2668
この形で試して貰ったんだけど、ありがたい駄目出しを頂く。
ブリッジしやすいとのこと。
方形にした事によって、ランド間の距離が短い部分が増大したのが原因だろうと思う。

そして今回。
ランド幅を元に戻しつつ、ブリッジしやすい要因を排除した形がこれ。
IMG_2669
結局大して進化はしていないのだけど、ハンダしてみるとVersion1.2.1cよりはマシ。

IMG_2672


IMG_2673
ブリッジも一か所も無く一発OK出来たので、これを最終版にしようと思います。
どれもこれも作れない事はないのですが、色々な人が作りますから簡単に出来る方法を追及してみました。

USBのハンダもやりやすくなりました。
IMG_2674


Version1.3.0aです。
IMG_2670

IMG_2671

基板の作りやすさ改善は、色々な人達が作る上での品質を引き上げる事に役立つと思います。



ファームウェアの方は既にVersion1.2.1cの基板に入れて長らく走っているので、まぁ問題無いでしょう。

Wincdi側にも手が入っています。
osr-cdiv131a

配線して走って今回のTOTから始まったVersionアップ作業は終わりになります。
Facebookのヤマハ2スト電装友の会でお伝えしている通り、暫くこれでFIXしたいと思います。

今後不具合やどうしても直さないといけない合理的な理由があれば修正しますが、大きな機能追加や改変は無いと思います。
とか毎回言っているので信ぴょう性は無いんですが・・・。



今回肝心のファームウェアの対処は、壊れかけたウオタニコイルのワークアラウンドです。
恐らく二次側が絶縁仕掛けていたんでしょう。
点火後に大きなノイズが発生し、それがピックアップ信号に紛れ込んでいました。
それに対しては、サイリスタを通して点火した後、300マイクロ秒程ピックアップ信号を無視するという制御をいれたところ、ノイズの影響は受けなくなりました。
このノイズはその300マイクロ秒の中で発生しており、それ以上は持続はしていなかった事になります。

通常の正常な電気系を持つ車体では問題にならない事に対しての対処であって、通常は不要の物です。

この対処をいれるかどうかは、本当に逡巡しました。
他のパーツの不具合をCDI側でフォローすると、そもそもの原因の発見が遅れます。
動くけどなんか調子悪い。
それが果たして良いことなのでしょうか。
なにか問題があればバッサリと動かない方が良い場合は非常に多いです。
実際世の中にある多くの制御系はそのように作られています。
何かおかしいから点検しろとアラームを上げます。

今回は、この対処を入れるべき理由が沢山あり、同じく入れないべき沢山の理由を上回った結果、入れ込む事にしています。

一番目の理由はレースで使っている人がいること。
レースは理屈じゃありません。走っている最中何かあっても走り続ける事が使命です。
例えば激しいレースをやっている最中、ウオタニコイルの断線が発生してノイズが発生したとしても、後1週、後半周走れればそれでよい、等の選択肢しかありません。
今回2019春のTOTではウオタニコイルの不具合を2台程見ました。
であるならば、その為の前対処を入れておく事も必要でしょう。
但し、もうタコメータが暴れる等の「目に見えるアラーム」は上がらなくなります。

二番目の理由は「今回の制御追加にはサイドエフェクトが全くない」ことです。
既にファームウェアには一行のIF文さえも追加したくはありません。
条件分岐はそれだけ制御の時間が増えますし、ソフトウェアの複雑さが上がります。

今回は幸いな事にサイドエフェクトが全くありません。
点火の為のサイリスタのゲートに導通している時間が300マイクロ秒であり、この時間後にピックアップ信号が来ていたとしても無視する処理ですから、なんら条件分岐が足されておらず、時間的にも非常に余裕があるところで一行追加しただけです。
これは動作的に合理的にも思えますし、ソースコードの美しさを損ないません。
他にも色々ありますけど、そんなこんなでファームウェアの修正は入れました。

そんなこんなで近日Version1.3.0のリリースを行います。
β版が既に出ていますので、それをそのまま名前を変えて正式版にするだけですけど。