引越し先はこちら:Endress trail neo ”https://endresstrail.livedoor.blog/”
]]>
前回に引き続いて、NagodenさんのBi-Di Multiplexユニットをいじっていきます。すでに基本的な動作の確認は出来ていますので今回は拡張用に用意されているI/Fの中でI2Cの動きを見てゆきたいと思います。
まずI2Cとは何ぞやというところからお勉強です。いつもお世話になっているWikiさんによりますと「アイ・スクエアド・シー」または「アイ・アイ・シ」と呼び名がいくつかあるらしいです。フィリップス社で開発されたシリアルバスの一種で2本の信号線だけでバリバリ使えるそうです。さらに重要な点があって、接続する機器はマスターとスレーブという役割に分けて、それぞれにI2C用のアドレスを決めておく必要があるようです。規格上は最大 112 個も繋げられるみたいです。細かい規格等はネット上に色々ありますので、詳細は
そちらで確認しつつ、早速Bi-Di MultiplexユニットのI2C I/Fの方をみてゆきたいと思います。
■MultiplexユニットのI2C I/F用 コネクタ(赤い囲いの部分)
MultiplexユニットのI2Cは写真の赤で囲った部分が接続用のコネクターになっています。ここには4本ピンが引き出されていますが、内2本が5V電源とGND、他2本がI2Cのシリアルデータ (SDA) とシリアルクロック (SCL)に当たるようです。
■MultiplexユニットのDIPSW(赤い囲いの部分)
もう1つの重要なポイントI2C用のアドレスですが、Nagodenさんからの使い方メモによると
・I2C 接続して呼び出すと4つ分の在線状況とアドレスを12バイトで返します。
・DIPSW ボードでアドレスを設定します。 I2Cではアドレス11h〜20hまでとなっているようです。
アドレス:11h〜20h これは何を意味するの?ですが多分16進数表記だと思います。詳しくはこのサイトの早見表でアドレスが設定できる範囲を把握しました。写真の赤囲いのDIPSWの切り替えでアドレス:11h〜20hを選択できる様です。ただ、Multiplexユニットを作成してまだDIPSW切り替えパターンとアドレス:11h〜20hのマッピングが仕様通りに当てられているかよくわからなかったのでMultiplexユニット自体のI2C:アドレスがどうなっているか確認するのにこのサイトを参考にしてarduinoUnoにi2c_scannerのスケッチを書き込んで実際に確認してみました。
■i2c_scannerとMultiplexユニットの接続
ちょっと強引な配線になっちゃいましたが、MultiplexユニットのSDA、SCL、5V、GNDをi2c_scanner化したarduinoUnoの各対応するポートに接続して、arduinoIDEのシリアルモニタで観測すると確かにアドレスらしき応答を返してきました。
■i2c_scannerによるI2c アドレスの結果
DIPSWを適当に切り替えてみるとi2c_scannerのアドレスも変化していたので、DIPSWの可変機能も有効だということがわかりました。
i2c_scannerでI2Cのアドレスの決め方や、MultiplexユニットのI2Cも機能していそうな事が分かったので、次は実際にI2Cの通信動作を確認してみたいと思います。確認方法はNagodenさんからI2C確認用サンプルスケッチを提供していただいているので、基本的にはNagodenさんが行っていたBIDIの表示機(IFボードでのI2Cの実験)と同じ事をやります。ついでに前回チャレンジした激安バッチモンのLCDパーツの使い方の勉強を兼ねて、Railcomからのアドレス表示をやってみることにしました。Webで調べてみるとバッチモンとはいえ表示用ライブラリーはあるし結構利用されている方もいるみたいですので、もしかしたらちゃんとした一般的なものだったのかもと思いつつ、使い方で詳しいサイトをみつけたのでこの内容を斜め読みして、I2C確認用のサンプル スケッチを改造してみました。
■ 黄色枠がTM1637LCD Display表示用に追加したコード
改造した部分はシリアルコンソールに出力する箇所にTM1637 Displayも表示する部分を付け加えてます。チョット改造する部分で面倒だったのはMultiplexユニットからI2C I/Fを通してマスタ側兼レシーバとなるarduinoUnoで受ける際にDetector4局分のDCCアドレスが重畳された状態で受け取る形になるので、LCDに表示する際はアドレスを分離して時間間隔を空けて(1000ms)順番に表示させる感じにしてみました。
■I2C接続実験の接続構成
接続方法はI2Cレシーバとなる赤いarduinoUnoもどきをマスタ役として、先に改造したスケッチを書き込んでいます。Multiplexユニットはスレーブ役になる様にしてI2C接続させています。arduinoUnoもどきには激安の例のLCDを接続して、Bi-Di MultiplexユニットからI2Cを通して流れてくるDCCアドレスを繰り返し表示しています。
■I2C接続時の動作状態を確認する動画
奥のクモヤ145と手前のDD13のアドレスが赤いarduinoUnoに接続したLCDに繰り返し表示してI2C接続間でDCCアドレスデータが正常に流れてきていることが確認できます。途中コマンドステーションのSWをON/OFFさせてDCCアドレスの表示を待機表示になったりもしますが、これは正常な表示だと思います。
まだアドレスを表示させるだけの機能しか確認していないのですが、NagodenさんのBi-Diシステム I2C接続が可能になっているのでI2Cを搭載した他の機器との今後の連携にも夢が膨らみますね。
昨年のちょうど今頃、世の中がコロナ禍に突入してから1年以上経ちました。MECYの周りでも結構な煽りを受けて色々と大変な状況になってしまい、鉄道模型活動に腰を据えて取り組めていなかったのですが、今年のGWはステイホームで少しうち込めましたので、少しずつ再開してゆこうと思ってます。
復帰第1号のネタはなごでんさん絶賛開発中のBI-Di(Railcom)Detector とMultiplexユニットになります。Bi-DiについてはMECYはまだ勉強中で詳しいことは何も知らない素人同然の身の上です。詳しくはDesktopStationさんのRailComの紹介資料を参照していただければ、概要は理解できると思います。
MECYが今回取り組んだのはなごでんさんが開発したBI-Di(Railcom)Detector とMultiplexユニットの試作品を組み立てて動かしてみるところまでです。
まずBI-Di Detectorで何?、Multiplexユニット何なの?ですが、BI-Di DetectorはNMRAのDCCの規格の中に「BI-Di」 (昔の名前で「Railcom」)が決められていてこれが、BI-Di対応のDecoderから車両のアドレスをDCC信号の中に忍ばせておいて、Detectorで読み出せるものと大まかに理解しています。 さらにDCC信号に流れてくるアドレスを見える化してくれるのが、DesktopStationさんのBiDiDisplay(railcomdisplay)にあたると思います。Detectorは閉塞区間ごとに電気的にレールギャップを設けて設置する使い方が基本になると思いますが、Multiplexユニットははなごでんさんの独創的な発想のもので、4局で独立していたDetectorを一旦纏めちゃうものと思っています。MultiplexユニットがDetectorを4個までとしているのは多分マイコンで処理する能力の余力をみてのことだと思います。そしてこのMultiplexユニットにLCDの表示器をつければ4局分のBi-Di Displayに早変わりしてくれるそうです。他にもI2CやS88用か〇×△□netかもしれないモジュラージャックなど多彩なIFも将来の拡張にそなえて装備されています。
ではいつもの長いくだりはこれぐらいにして、さっそくMultiplexユニットの組み立て編です。
Detectorはほぼ完成品を提供していただいたので、配線接続用のピンコネクターを付けるくらいでメインで作るのはMultiplexユニットになります。
■BI-Di Detector
■Multiplexユニットの基板
■Multiplexユニットの部品
現状試作品とのことですので今後仕様変更などがあるかと思いますが、取り合えず基板のパターンにしたがって、付属の部品をハンダ付けしていきます。まず直感的に一番はじめに手をつけないといけないかつ最大の難関とおもったのが、基板のほぼ中央に位置すATMEGA328P-AUらしきパターンとゴマ粒大のセラロックです。こいつらは結構難敵で初期の頃のスマイルデコーダを手ハンダで作っていたハンダ苦行を思いおこさせます。とは言えNext18コネクタよりは目が粗いので慎重に作業すればなんとかなります。
■見た目はうまくいった様にみえるATMEGA328P-AUとセラロック
でATMEGA328P-AUとセラロックを付けてみました。ここから結構はまったのですが、無垢のATMEGA328PなのでブートローダとMultiplexのファームウェアを書き込む必要があるのですが、スマイルコネクターは装備されていないので、一般的なArduinoのファームウェア書き込み手順にのっとって、書込み機器化したArduino unoもどき改のスマイルライターからISP端子に結線を施してしてファームウェアの書込みをおこないました。
■よくある?ファームウェア書込みの繋ぎ方
ここで1発で書き込みが出来れば幸せになれるのですが、大概は下記の様なあまりみたくないエラーが出てきます。
■書き込み失敗の不幸のお知らせ
こいつがでてくるということは大抵CPU周りの細かい足のハンダ不良が常なので、丁寧にCPUの足先を何度もハンダコテで馴染ませる地味な作業を繰り返しました。ここは2回くらい繰り返してなんとかクリアしました。
■部品を全てハンダ付をおこないMultiplexユニットの組み立ては完了
部品のハンダ付け作業自体は早い人であれば2〜3時間位の作業量かと思います、MECYの場合はハンダ不良の影響でファームウェアの書き込みに手間取ったので半日を要しました。(マスプロ版は多分マイコンは基板に実装されると思われますので、今後はMECYの様なハマリは無いと思います。)
Multiplexユニットも出来たし次はDetectorを繋いで動作確認でもと思いましたがここで、LCDの準備が必要です。
なごでんさんの推奨ではGroveの4DigitDisplayです。秋月電子でも売っていました。これを4局分買わないといけないのですが、秋月で1個760円するので、一か八かでAliExpressで見つけた「TM1637 4ビットデジタルledディスプレイモジュール」を1個お試しで取り寄せました。怪しいAliExpressだと入手までに1ケ月くらいかかりますが、価格が$0.44で送料をいれても$1.90程度なので非常に魅力的です。コロナで店舗が無くなって存在しているのか怪しいaitendoでも「4桁7セグLED表示器 [M7SEGX4R1637]」
でほぼ同等品と思われるものもあるみたいですので、勇気のある方はお試しください。
■上:怪しげなAliExpressのTM1637 4ビットデジタルledディスプレイモジュール
下:なごでんさん推奨 Grove 4DigitDisplay
テストの機材設置状況はポイントで分れた先にレールのギャップを取り、そこに個別に配線をひきだして2局のBI-Di Detectorにつなげています。DetectorからさらにMultiplexユニットに繋いで、Multiplexユニットから相対するCHに推奨品/バッチモン品のLCDを繋いでいます。その他DCCコマンドステーションはDsAir2のUSB×PC接続してています。ポイント駆動はTRAINO情報室さんのリレーデコーダで動かしています。
配線だらけになってしまうので、配線ミスでショートさせない様に気を付ける必要があります。特にレールギャップを車両がまた
いでその先でDCC極性があべこべにならいない様に気をつけました。(設置中に何度もミスってショートさせてます。)
■かなり配線が込み合い見苦しいですが、これでもBi-Diをやるには最低限です。
■Detector とMultiplexユニットの動作状況
テスト車両はDD51 (adress=51)とDE10(adress=10)ESUのデコーダ(+OPENSOUND入)を搭載しています。
ポイントを渡ったレールギャップ先にDetectorがあるので、車両が進入するとMultiplexユニットを介してLCDに車両アドレスが表示されることを確認できました。怪しいバッチモンのLCDもそれなりに表示してくれました。
Bi-Diの機器が充実してくると思いますが、線路上に複数の車両を留置したり、待機させるヤード系のレイアウトなどにはDC方式では実現が難しい車両アドレス毎の識別や運転管理が、DCCとBi-Diで実現できるところまでもう少しのところまできていると思います。今後こうご期待です。
JUGEMテーマ:鉄道模型
DsAirの裏機能(別に隠してないかも)にDCアナログモードがあります。いわゆるDCCコントローラの対極的な立ち位置であるアナログモードのPWMコントローラの様に動かせるモードです。このDCアナログモードもDsAirの至れり尽くせり機能で「dsair_wifi_specification」に規定されていますので、「Smile wifi Throttle」のソフトに仕込んでやれば、DCアナログのwifi Throttleにも早変わりします。
ソフトの実装自体はDCCアドレスやファンクションを組み合わせる必要がなくなるので、面倒な複数アドレス仕分け等の処理がなくなってかなりシンプルにできました。また第3のスロットルとしてVR可変抵抗器があります。これがまた2つ装備されていますが、ここに機能を割り振っていなかったので、DCアナログモードの操作スロットルとしてみました。
◆買ったばかりでDCC改装前のキハ40で試走してみました。
サウンドが無いので物足りですが、DCアナログモードでもスムーズに走らせることが出来ました。
DCC玄人志向の方々からみると邪道かもしれませんが、DCアナログモードあれば便利な機能です。
]]>JUGEMテーマ:鉄道模型
ESP32ベースでソフトを組んでいる「Smile Wifi throttle」ですが、これ他にないだろ〜!と思いきや・・実は世界に目を向けてみるとすでに作っている方がいらっしゃいました。
https://model-railroad-hobbyist.com/node/35652
http://www.scalemodelanimation.com/Articles/WiFi_Throttle_RE-Apr2019.pdf
DCCのプラットフォームはJMRIなので、「Smile Wifi throttle」が親機としている「DsAir2」とは異なりますが、ベースとなるデバイスはESP32なので「Wifi throttle」というカテゴリではお仲間です。
もうすでに完成なさっているみたいです。
脱帽です・・・
]]>JUGEMテーマ:鉄道
マルチロータリスロットルを装備している「Smile Wifi Throttle」ですが、機能を都度増やし続けているため少しずつですが、動作のもっさり感が気になってきました。何かサクサク感にもってゆく為の抜本的な手立てがないか日々考えていました。実はESP32、2つのCPUが載っているらしいです。ですがなぜかユーザが作成するソースコードは1個のCPUでしか動いていないらしく、徐々に増加するソースコードをもう一つのCPUに処理を分散させてやれば理論上はサクサク動いてくれるハズです。ということでレスポンス向上の奥の手として残していたESP32のマルチタスク化に挑戦してみました。
ESP32のマルチタスクをネットで調べるといくつか参考になる記事を見ることができます。今回参考にさせていただいたのは次のサイトです。 ”ESP32 ( ESP-WROOM-32 ) » Arduino – ESP32 のマルチタスク ( Dual Core ) を試す’’
参考に閲覧した内容から、今回やることのイメージは次になります。
?「Smile Wifi Throttle」のスケッチの機能(主に関数単位)を整理して2スロットル分毎に分割する。
?分割した1スロットル分の一方を使っていなかったCPU0側へ処理する様にコードを書き換える。
-----------------「Smile Wifi Throttle」マルチタスクのスケッチ構成イメージ--------------
void タスク名(void *pvParameters){
while(1){
← 分割したスロットル2の処理部分を記述
}
}
void setup(){
xTaskCreatePinnedToCore( ←マルチタスク化の構文通りに追加する
タスク名,
"タスク名",
スタックメモリサイズ,
NULL,
タスク優先順位,
タスクハンドルポインタ,
Core ID
);
}
void loop(){
← 分割し残したスロットル1処理の部分を記述
}
先人様の記事からESP32のマルチタスク化はESP32のソフトの仕様上問題なく出来そうなのですが、1つ気になる点があります。
それはデフォルトで使用していないCPU0側は、ESP32のシステムタスクが動いるらしいという事です。つまりCPU0はESP32のシステムタスク処理専用であって、ユーザ作成のタスクを処理する余裕はあまりないかもしれないという点です。なのでここは一発賭けに近いですがやってみるしかない感じです。
次に適当にスケッチを上記の形に2つの処理ループ構成にして、”スケッチビルト”⇒”ボード書き込み”まではなんとかできました。
ここまではそこそこ順調でしたが、いざ「Smile Wifi Throttle」を動かしてみると・・・
◆マルチタスク化したスケッチ:DsAirとの認証 が待ち状態までは正常そうです。
◆マルチタスク化したスケッチ:DsAirとの認証 スタートでWifi Throttleモードへ移行中です。
◆マルチタスク化したスケッチ:DsAirとの認証後、 ああ!文字表示がおかしい この後表示は消えて再起動しました。
マルチタスク化後の結果ですが、写真の様にDsAirに接続する途中で再起動が起こりまくります。この状態では使える代物ではありません。恐らくWifiが動きまくるのでCPU0にタスクを振ってもCPU0側のパワー不足でWifi Throttleモードが起動できず、力尽きて再起動していると思います。Wifiの動作を止めればマルチタスク化したスケッチでも動くかもしれませんが、それでは「Wifi Throttle」になりませんよね。マルチタスク化作戦ははあえなく撃沈し残念な結果となりました。
教訓:「ESP32は普通にシングルタスクでコーデングするに限る」です。
]]>JUGEMテーマ:鉄道模型
「オニコン格闘記のその3」です。オニコン格闘記と題していますが、ソフトをいじっている期間が途中保留になった期間も含め長期に渡るので、やってきた事を忘れないように備忘録的な視点で書いています。
前回まではオニの2つの角である「ろーたりーえんこーだ」を退治できる目途がつきました。今回はオニのパンツの縞模様の様にやたらに多いボタンについてです。オニコンに装備されているボタン数ですが、まず1番の見た目で特徴となる10連装の10キーと、「ろーたりーえんこーだ」付近のサイドに4つと「ろーたりーえんこーだ」にもスイッチ兼用で装備されています。併せて利用可能なボタン類は16個になります。よくもこれだけの数を付けれたなと思いました。ふと渡された回路図をみてみると。。。なんと全てが抵抗分割のアナログスキャン方式で設計されていました。これはオニです。普通タクトスイッチはデジタルプッツシュ式が一般的というかアナログスキャン方式はあまり使われないと思います。確かにアナログスキャン方式はモジュールPINへ繋ぐ数が少なくて済むメリットはありますが、あまり使われないのそれなりの理由があるわけで、例えば抵抗分割の設計が難しいとかアナログ値の読み取りでソフトを組むのが面倒などデメリットもあります。でももうブツは出来上がってしまっているので取り合えず数のまとまった10キー部分から手を付けることにしました。
まずはアナログキースキャンの理解を深めるため下記のサイトを参考に抵抗分圧の理想的な値を机上で検討してみました。
参考サイト抵抗分圧器を使った、多くのスイッチのセンシング「https://synapse.kyoto/tips/ResDiv/page001.html」
机上で出来上がっているブツの回路構成をみて考えてみましたが抵抗で分圧している値を計算してみると、抵抗値の配分が微妙に均等でないことが気になりました。どうやって決めたんだろ?この点をハード設計した方に問い合わせたところ、どこかのArduinoの機器でつかわれている回路図を転用してきたとの回答でした。あ〜!5V電源のマイコンの回路を転用してしまっている。ESP32は3.3V電源のCPUです。当然搭載されているA/Dコンバータの特性も違ってきます。上手く動かせるのかな…
机上で考えていてもラチがあかなさそうなので、もう現物合わせでやってみるしかないと思い。10キーボタンを押したときに繋がれたピンのADCから値を返す動作確認用の下記スケッチを作って実際に動きを確かめてみることにしました。
------------------------- -------------------------------
/********************************
*BUTTON keyscan
*******************************/
int readButtons1(){
int PushBtnNo;
int inSW1 = analogRead(25); //keyscan read SW1 -> GPIO-25
int inSW2 = analogRead(26); //keyscan read SW2 -> GPIO-26
int inSW3 = analogRead(27); //keyscan read SW3 -> GPIO-27
int inSW4 = analogRead(14); //keyscan read SW4 -> GPIO-14
int inSW4 = analogRead(15); //keyscan read SW4 -> GPIO-15
int inSW5 = analogRead(13); //keyscan read SW5 -> GPIO-13
//Side Btn SW
if (inSW1 < 800){
Serial.print("BUTTON_SW34 ");
Serial.println(inSW1);
PushBtnNo = 34; //BUTTON_SW34;// 実測値= 0.780V 0
return PushBtnNo;
}
if (inSW1 < 1300){
Serial.print("BUTTON_SW3 ");
Serial.println(inSW1);
PushBtnNo = 3; //BUTTON_SW3;// 実測値= 1.180V 0
return PushBtnNo;
}
if (inSW1 < 1700){
Serial.print("BUTTON_SW4 ");
Serial.println(inSW1);
PushBtnNo = 4; //BUTTON_SW4; // 実測値= 1.500V 448
return PushBtnNo;
}
if (inSW2 < 800){
Serial.print("BUTTON_SW56 ");
Serial.println(inSW2);
PushBtnNo = 56; //BUTTON_SW56; // 実測値= 0.780V 0
return PushBtnNo;
}
if (inSW2 < 1300){
Serial.print("BUTTON_SW5 ");
Serial.println(inSW2);
PushBtnNo = 5; //BUTTON_SW5; // 実測値= 1.180V 0
return PushBtnNo;
}
if (inSW2 < 1700){
Serial.print("BUTTON_SW6 ");
Serial.println(inSW2);
PushBtnNo = 6; //BUTTON_SW6; // 実測値= 1.500V 448
return PushBtnNo;
}
//Main Btn SW
if (inSW4 < 110){
Serial.print("BUTTON_SW7 ");
Serial.println(inSW4);
PushBtnNo = 7; //BUTTON_SW7; // 実測値= 0.11V 0
return PushBtnNo;
}
if (inSW4 < 680){
Serial.print("BUTTON_SW8 ");
Serial.println(inSW4);
PushBtnNo = 8; //BUTTON_SW8; // 実測値= 0.680V 448
return PushBtnNo;
}
if (inSW4 < 1550){
Serial.print("BUTTON_SW9 ");
Serial.println(inSW4);
PushBtnNo = 9; //BUTTON_SW9; // 実測値= 1.435V 912
return PushBtnNo;
}
if (inSW4 < 2500){
Serial.print("BUTTON_SW10 ");
Serial.println(inSW4);
PushBtnNo = 10; //BUTTON_SW10; // 実測値= 2.210V 1200
return PushBtnNo;
}
if (inSW4 < 3450){
Serial.print("BUTTON_SW11 ");
Serial.println(inSW4);
PushBtnNo = 11; //BUTTON_SW11; // 実測値= 2.830V 1456
return PushBtnNo;
}
//Main Btn SW12-SW16
if (inSW5 < 110){
Serial.print("BUTTON_SW12 ");
Serial.println(inSW5);
PushBtnNo = 12; //BUTTON_SW12; // 実測値= 0.11V 0
return PushBtnNo;
}
if (inSW5 < 680){
Serial.print("BUTTON_SW13 ");
Serial.println(inSW5);
PushBtnNo = 13; //BUTTON_SW13; // 実測値= 0.680V 448
return PushBtnNo;
}
if (inSW5 < 1550){
Serial.print("BUTTON_SW14 ");
Serial.println(inSW5);
PushBtnNo = 14; //BUTTON_SW14; // 実測値= 1.435V 912
return PushBtnNo;
}
if (inSW5 < 2500){
Serial.print("BUTTON_SW15 ");
Serial.println(inSW5);
PushBtnNo = 15; //BUTTON_SW15; // 実測値= 2.210V 1200
return PushBtnNo;
}
if (inSW5 < 3450){
Serial.print("BUTTON_SW16 ");
Serial.println(inSW5);
PushBtnNo = 16; //BUTTON_SW16; // 実測値= 2.830V 1456
return PushBtnNo;
}
//Rotary Btn SW
if (inSW3 < 850){
Serial.print("BUTTON_SW1&2 ");
Serial.println(inSW3);
PushBtnNo = 120; //BUTTON_SW1&2; // 実測値= 0750V 912
return PushBtnNo;
}
if (inSW3 < 1300){
Serial.print("BUTTON_SW1 ");
Serial.println(inSW3);
PushBtnNo = 1; //BUTTON_SW1; // 実測値= 0.1520V 0
return PushBtnNo;
}
if (inSW3 < 1700){
Serial.print("BUTTON_SW2 ");
Serial.println(inSW3);
PushBtnNo = 2; //BUTTON_SW2; // 実測値= 1.480V 448
return PushBtnNo;
}
//Btn No Push
Serial.println("BUTTON_ERRORR");
Serial.println(inSW1);
Serial.println(inSW5);
PushBtnNo = 0; //ERRORR;
return PushBtnNo;
}
現物の確認方法は、ボタンを押した時につながっている先のピンのADCの値を読んで戻す値をシリアルデバックのログに表示させて1つ1つ確認してゆきました。
この時点ではとりあえず10キーを押した時はそれなりの値が読めそうなことがわかりました。だだしこの後、オニが立ちはだかって奈落の底に落ちていくことになります。。
]]>JUGEMテーマ:鉄道模型
前回、Smile Wifi Throttleに装備している2つのスロットルから2列車を動かしてみましたが、主/副スロットル切り替えの操作が結構忙しく使いずらい感じがしたので、少し改良してみました。今までは主/副スロットルの切り替えを左サイドの上下2つのボタン同時長押でスロットルの主⇔副を切り替ていましたが、今回はこの長押しを止めてOnePushで切り替えができるようにしてみました。これでボタン操作が少しやり易くなり、主/副スロットルの切り替えがスムーズなると思います。これだけではつまらないので併せて禁断の機能も盛り込んでみました。禁断の機能とは何かといいますと、主/副スロットル操作の準並列処理の機能になります。並列処理の前に準が付いているのでチャントした並列処理ではありません。これはDsAirの通信IF規格の都合で500ms毎に1操作コマンドしか送信できないため順列処理で送信することが基本であるところを、主/副スロットルからのコマンド送信を自動的に交互に送信するように工夫して疑似的に並列処理チッツクにしてみたものです。ただこの機能で動かすとプログラム上、主/副個別で使い分けたいDCCアドレスやファンクションコマンドを正確に管理していくのが難しくなるため結果、コマンド送信が不安定になりやすく最悪コントロールが不能に陥るノーコントローラになってしまうリスクがあるので禁断の機能としています。この機能は実験的な要素が強いキワモノ系です。
◆主/副スロットル手動切り替えモード(簡単One Push化)
◆主/副スロットル 準並列処理モード
(終盤力尽きて倒れました)
主/副スロットル手動切り替えモード(簡単One Push化)は2つの車両を交互に動かす範囲で使うのであれば切り替え操作がスムーズになり結構使い易くなったと思います。
禁断機能の準並列処理モードについては懸念していたとおり、各々の操作レスポンスが悪くなってしまいました。DsAirの通信IF規格外の禁じ手を使い2スロットルの切り替え操作を省く代償なので止むを得ないところです。
今後チューニング(MECYのやる気次第ですが)でどれだけ向上するのかわかりませんが取り合えず2スロットル準並列処理はかろうじて動いたという結果になりました。
]]>
JUGEMテーマ:鉄道
「オニコン格闘記のその2」です。前回まではESP32がオニぽいというところまで分かってきました。今回はオニのESP32に2つの角であるロータリーエンコーダをどのように退治したかについて語りたいと思います。
ロータリーエンコーダについては以前にYaasanさまのUSBスロットルのスケッチを改良したことがあるのでこれを転用すれば楽勝と踏んでいたのですが、色々と調べていくうちに、開発環境が同じようなarduinoIDEといってもATMEL系のマイコンとESP32とではどうもソフトの細かいレベルでみてゆくと別物らしく、USBスロットルのスケッチを転用できないことがわかってきました。つまり全てが1から作りこむ必要があるということになります。これはオニだ!絶望しました。。。
1度はESP32のオニのこん棒に叩かれて死にましたが、めげずに"ESP32” と”ロータリーエンコーダ”のワードでネットを彷徨っていると、なにやらESP32にはパルスカウンタというものが実装されておりESP32独自の方法になりますが、なんか使えそうな感じであることがわかりました。
以下参考にさせていただいた記事になります
ESP-WROOM-32のパルスカウンタの使い方(arduino)
https://qiita.com/wanko_in_lunch/items/a508d8da78961c855d7f
一見すると難しそうな処理をいくつもやってそうなコードですが、複数のユニットで使い分けもできそうなので、最適と思いオニコンの2つの角であるロータリーエンコーダに合うようにコードを改造して、クルクルと回してみるとそれなりの動作をする事が確認できました。
まずはオニの角までは退治できました。
鬼ヶ島での格闘はまだまだ続きます。
]]>
JUGEMテーマ:鉄道模型
コツコツと機能と作りこんできた「Smile Wifi Throttle」の機能の概要についてです。
成り行きで機能を追加してきていますので、これが最終形ではありませんが、現時点で動かせる機能は下記になります。
システムの概要:
運転用スロットル機能と、各設定/管理用のWeb画面の2つの機能を使い分けて拡張性を考慮した構成。
Wifi Throttle単体でDsAirに接続しコントローラとして機能する。
機能の概要:
1.装備している2スロットルを各々個別で車両を制御できる。
2.Web設定画面から1スロットルあたり5車両(2スロットル合わせて10車両)のDCCアドレスの登録ができる。
3.Web設定画面からスロットルの1ノッツチ当たりの速度変化量の増減(1−40)を変更することができる。
4.装備している10Keyの機能割り付けを可変にしてファンクションキーを”F0〜F39””まで操作可能。
5.装備している10Keyの機能割り付けを可変にしてポイント(DCC Accessory)を”1 - 2044”(実質無制限)まで
操作可能。割り付けの切替設定はWeb設定画面で行う。
6.Web設定画面からDsAir接続のための認証設定/変更を行う。
賛否はありますが、2スロットル装備しているので2列車を相手に運転することができます。ですが現状使用を想定していたボタンが諸事情で使えないため、生きているボタンを使いまわす必要に追われ、長押ししたり、2つのボタンの同時押しなど無理やりな割り振なのと、機能も可能な限り搭載したので操作が複雑になりかなり使いずらいものになっています。
機能満載にしてしまった弊害なのか、ボタン位置のアレンジにセンスがなためか、ボタン操作がかなりアクロバテックなので今ある機能をフルに動かそうとすると相当な熟練を要するコントローラとなっています。
◇オープンサウンド化したDD13とC58のサウンドの競演を綺麗にきめたいところだったのですがコントローラの操作の複雑さに
翻弄されています...
自分で作っておきながら思うのもなんなのですが、慣れないと操作が難しいです。ボタン配置やスイッチ類、機能の見直しを行ってシンプルなものに原点回帰する方が吉なのかもしれません。。
]]>JUGEMテーマ:鉄道
オニコンこと「WifiThrottle」格闘記です。
前回はオニが突然降りてきたところまでのお話でした。ここからは格闘編です。
MECY的にオニコンと名付けた理由ですが、取っ掛かりの印象が次の状況だったためです。まず明確なハードの仕様がなかったことがあります。降りてきた時はもう出来上がっている現物とサポート基板の回路図とベースボードに関連する頼りないネット上の情報だけというもので、完全にお任な状態。。出だしからオニだなと思いました。そのため降りてきた直後は完全にお手上げ状態でした。しばらく放心状態でしたが、そのままでは何も進まないので気を取り直してまずは自分なりに調査を始めました。
何はともあれベースボードの実体を知らないと話が始まらないのでしばしネットをさまよい製造元?販売元?と思われるサイトを発見しました。
http://www.lilygo.cn/down_view.aspx?TypeId=11&Id=83&Fid=t14:11:14
但しここから分かったのは大雑把なボードの仕様とPINの並びとMade in中華らしいということだけ。オイオイこれだけかよ。。少し目まいを感じつつ、慣れない英文を眺めているとESP32 のキーワードがありました。ESP32?さてこれはなんでしょう?ということで次はESP32を調べてみました。ESP32をキーワード検索すると沢山出てきました。
まずはWikipedia でESP32をみてみると
ーーーーーーーーーーーーーーーーーーーーー
ESP32シリーズは Wi-FiとBluetoothを内蔵する低コスト、低消費電力なSoCのマイクロコントローラである。 TensilicaのXtensa LX6マイクロプロセッサを採用しデュアルコアとシングルコア版のバリエーションがある。 ESP32は上海に拠点を置くEspressif Systemsが開発をしTSMCの40nm工程で製造・・
ーーーーーーーーーーーーーーーーーーーーー
メインボードに載かっていると思われるマイコンについてある程度具体的な情報を得ることができました。
◇高性能な?マイコンを搭載したメインボード
スペックをざ〜とみると32ビットのディアルマイコンで240 MHz動作可で wifi Bluetooth対応で・・なんか凄い高性能。
ソフトの開発環境もArduino IDEのオプションらしい「Arduino IDE with the ESP32 Arduino Core」が利用できるみたいです。この時点では少しやる気が出ていました。この先、中華マイコンのオニの洗礼と苦行の連続に打ちのめされることになるのですが・・
]]>
オニコン格闘記シリーズとは別に「Smaile Smile wifi Throttle」試作機の使い勝手や活用例など使用者目線で書いて、時には自分で直していきます。
1回目は初めて自分で試走させてみた「wifi Throttle」の操作性で特に気になった部分を改良したので、どの程度操作が良好になったかその確認をしてみます。
話は遡りますが、先日参加したDCC電子工作連合の運転会で初めて「wifi Throttle」を自分で操作して車両を動かしました。ソフトを開発している時は試走させるまでの時間がなかったので、見だけ君でDCC信号の出方だけ確認したまま運転会に持ち込んでいました。試走車両はHoトラムウェイDD13にオープンサウンドのディーゼルサウンドを書き込んだESUのデコーダを搭載し、「wifi Throttle」から操作してどの様に動くのか確かめていました。
しかしながら、一通りの操作は出来るつもりでソフトを組んで持ち込んだつもりながら、超高性能なESUのデコーダがこれまた正確な動きをするもので、MECYの適当なソフトの作りこみに正直な反応をしてしまい、スロットルからの速度停止の操作が効いていない動きをしている事に気がつきました。微妙に微速したまま止まらないという現象です。この部分はスロットルを回しすぎて指定の速度範囲を超えてもリミッタを効かせてオーバレンジさせない様にしてたのですが、時間が足りなくそこの作りこみが適当すぎました。ああ全然止まらない!ブレーキ感がない!これは致命的だなと思いました。早速オニコンソフトを改良しました。
今回改良を入れた部分です。
1.確実にSpeed ゼロ指令をDsAirに送る様にしました。
2.非常停止機能とボタン割付を追加しました。
スロットル操作からの走行→停止、非常停止ボタン押しですぐに停止か確認してみました。
今回はポイントの操作も確認したかったのでKATOユニトラックの電動ポイントにへのへのもへじ様のTRAINO-A100 Relay Decoder(リレーデコーダ)を繋いでwifi Throttleからリレーデコーダを操作できる「DCC Accessory」モードも動かしています。
◇DsAir+フィーダ分配器+リレーデコーダ+KATOポイントの接続状況
◇ESUのデコーダを搭載したトラムウェイのDD13で試走させてみました。ついてにポイント操作テストもやってみました。
ソフト改良の結果、車両が確実に停止する様になりました。非常停止ボタンもいい感じでブレーキ感が出ていて実車が入替機だったDD13で運転する時にはぴったりな動きをする機能が追加できたなと思いました。ポイント操作もwifi ThrottleからDsAirを介してワイヤレスでも操作可能な事が確認できました。
オープンサウンドを書き込んでいるESU Decoderはサウンド ONの場合、動力サウンドの抑揚で動力の加減速が変化しスロットルの動きに対してダイレクトの動力と速度が同調しなくなるので、ここぞとばかりに停止させたい時などは非常停止ボタンはかなり有効な機能であることも再認識しました。
”非常停止ボタン” ⇒”ブレーキボタン”の方が実情に合った呼び方なのかもしれないとも思いました。
]]>
JUGEMテーマ:鉄道
年も押し迫ったこのタイミングで突然冬眠から目覚めました。
今年は激暑で夏バテになって特に何もせず過ごしていましたが、11月末に突然小箱が送られてきましたその中にオニが入っておりました。
小箱の中身は・・・巷で「WifiThrottle」と呼ばれているものです。
◇表面から 10個のボタンとファーストスロットルそのサイドに4つのボタンが鎮座しています
◇裏側にもセカンドスロットルと長持ちしそうな大き目な電池が…
正式名称は「Smile Wifi Throttle」になる予定です。ですがMECYの中では「オニのコントローラ」略してオニコンと名付けました。なぜオニコン?かといいますと。まずロータリーのツマミが2つあります。これは世の中で多分他にない=オニです。次にボタンが沢山あります。サイドに4個+正面に10個おまけで2個(ロータリーのツマミ押し込みのボタン)もあります。これもボタンが多い=オニです。極めつけはスマイラーさんの一言「これが動くソフト作って」=オニです。
ここからこのオニコンとの格闘がはじまりました。
]]>JUGEMテーマ:鉄道
MECY(メックワイと呼んでください!)です。みなさん〜呼びかた間違ってましたよ!と勝手なことをいってスミマセン。このように入るのも、先日開催されたオープンサウンドデータミィーテング後の打ち上げ会の席での一コマです。オープンサウンドデータミィーテング当日は本会〜二次会〜三次会へと多くの方がなだれ込み大変な盛り上がり様で相当に酔っぱらってしまいました。酔っ払いのいグダグダ話を聞いてもまったく面白くないと思うので、ここから少し当日の様子をお伝えしたいと思います。
MECY(メーシじゃなくメックワイです!)が会場に到着したのが11:30〜を少し回ったところです。すでに会場の準備が始まっていました。
◇オープンサウンドミィーテング準備中の様子1
◇急いで机イス、レール敷きなど会場設営の手助けを始めました
本会が始まってしまうと手が回らなくで聴かせるサウンドが撮れなくなると思われたので試運転の状況も少々
_
会場準備も完了し、いよいよ13:00から会場です。
オープンサウンドデータミィーテングはいきなり車両を走らせる前にオープンサウンドデータはなんぞや?の講義から始まるセミナー形式の形でスタートしました。
◇みなさんオープンサウンドデータの講義には真剣なまなざしでした
講義の合間にデモ車両の走行・視聴を挟みつつ、サウンドクリエータの方のサウンドデータ作成時の苦労話やテクニックの話題など貴重なお話も聞くことができました。また来場者の方とサウンドカーを手に取ってDCC化の改造のポイントやNext18アダプタ、ExpBoardの意見交換など活発で熱気に満ちた有意義な1日でした。
当日は60名余りの方にご観覧いただきました。ここに御礼申し上げます。
]]>
JUGEMテーマ:鉄道
今巷で話題沸騰(たぶん)のオープンサウンドですが、第一弾はSLのサウンドが公開されています。作例の動画などを拝見すると完成度が高くレベルの高い良い音だと思います。以前MP3デコーダでSLサウンドを色々といじっていたことがあるのでSLの音はさまざまな音が出てるのはわかっていましたが、このオープンサウンドのSL版はそれを相当なレベルまで忠実に再現されているので感心していました。だた感心しているだけては本当の良さは分からないので、オープンサウンドのSL版を実際に試して味わう必要があると思いったのが今回のネタです。
そこでオープンサウンド化するタネ車は当然ながらC11となるところなのですが、C11の模型となると手頃なのはテンショウドウのプラ製ですがそこそこなお値段です。イモンなどはとんでもなくもっての外な値段がしています。ということで予算面でタネ車はどうしようと考えていましたが、ふと考えてみると別にC11という形式にこだわらなければ、実車のサイズは多少違いますが同じタンク機関車のC12からの派生車であるC56でもいいんでね〜のと思いはじめました。しかもそこそこお手頃なお値段となっているKATOのC56もあります。ということでKATOのC56をDCC化する検討から始めました。
しかしただ単純にテンショウドウのC11の様にサウンドデコーダをポン付けできる様な8pinソケットなのどの装備はKATO C56にあるわけはないので、それなりに高いハードルが屹ています。まず本体の分解がかなりの高難易度です。今回の殆どの作業と労力がこれに注がれていくといっても過言でないほど大変でした。まず初めて分解するのに構造がわかってない状況からスタートするので、正解となる分解の順番なども判る筈もなく殆ど手探りで進めなければなりませんし、KATOの車両設計が優秀過ぎて、プラ車体部分はネジ止めなどは極力使われていないく、かなりキツメで精度の良いはめ込み構造もシロウトの分解には難儀そのものなので部品を破損しないように慎重に当たりを探りながら進めて全て分解できるまで3日掛かりました。(一度諦めて、1日休んでますが・・)まるで難航不落の城攻めの様な感じでした。
◇3日掛かって大方分解したところ。
◇本丸のモータまで辿りついたところ。モータターミナルの絶縁処理だけしてすぐ組み立て直しです。
なにも全て分解しなくてもとお思いですが、DCC化するためにはモータとダイキャストフレームを分離絶縁するために避けて通れない工程です。足掛け3日掛かって分解しても結局やりたいことはモータターミナルシューの当たりに絶縁テープを張るだけです。
せめて8pin対応にした設計にしておいてくれればとKATOに強く思うところです。
次に要のモーター部分の絶縁処理を済ませて組み戻しつつ、平行でNext18アダプタ化の準備もしておきます。今回使用したのはあやのさんから頒布されているNext18 Adapter Boardです。MECYが求めた時は基板しかなかったのですが、現在はアセンブリされている物も頒布されているそうなのでそちらを利用した方が神技ハンダ作業をしなくてもいいので断然いいと思います。
◇Next18 Adapter Boardの生基板とNext18アダプタ。
◇細かくて良く見えないNext18コネクタピンを基板へ神ハンダ付けしました。
Next18アダプタが出来たら、所定の長さと色別のリード線を引き出しておきました。
テンダ側はバック進行時のライトも点燈する構造なので、その分のライト用配線も施しておきました。RAIL給電系の配線もテンダから取る形なので、テンダ内部は配線は結構込み合います。
◇テンダ部分の配線処理の準備中。スピーカは28mmの円形スピーカにドロップ館のフタをエンクロージャに転用します。
テンダにデコーダとスピーカを配置し、機関車側にはモータ系とライト系の配線分を必要な長さ分引き出しておきます。機関車本体が仮組み状態で、テンダから引き出したリード線とモータのターミタルとライト基板へハンダ付けして配線を纏めておきます。今回はキャブライトも点燈させるためLEDテープを利用して追加で配線もしておきました。
◇仮組直しの状態。ここでデコーダや動力部分の動作テストをしながら各部を調整しました。
◇仮組の上面から。28mmスピーカがテンダをほぼ占拠しています
ここまで順調に来ているように見えますが、結構手間取っていて配線の取り回しをやり直したりしてさらに1日掛けてしまいました。でもなんとか組戻して外観までは元に戻せました。
◇ほぼ外観は復元して追加した配線がチョット目立つくらいで収まりました
構造と分解の仕方がわからなかったので一度ロッド部分も全分解してしまったので、組み戻し時にバランスが崩れて走行がおかしくなる心配がありましたが、試験走行で特に分解時の悪影響は残らず問題はありませんでした。
◇試験走行の動画を撮ってみました。
28mmスピーカとドロップ館フタのコラボが音響効果にMAXに効いているのか結構爆音な機関車が出来上がりました。最高音量にして動かしているとあまりの音の大きさに近所の犬が反応して吠えるので少しボリュームを絞りました。
C56の分解過程で一度挫折仕掛かっており完成まで到達できるのか一時不安になりましたが、苦労した甲斐がありました。
ESU Loksound5 Microとオープンサウンドの組み合わせは最高です!
----------------------------------------------------------------------------
2019/08/26 追記
◇ナンバープレートをC56 110にしました。 廃線になった三江線で走っていたナンバのようです。
或る運転会でMAX音量にして爆音を轟かせてきました
]]>