hira のすべての投稿

WR250X ETC 取り付け、ウインカーリレー改修、エアフィルター交換

WR250X の ETC 取り付けに伴う困難

最近、地元のバイク乗りと仲良くなり、ツーリングに出かける事になったのだけど、自分のバイクには ETC車載機を取り付けて無いので、高速に気軽に乗れない
それと、近年、ETC専用ゲートなども増えたし、スマートインターでの利用を考えると、ETCが無いと、色々と不便でもある
※大月の隣、上野原IC は、最近 ETC専用になった
自分は、バイクでは、あまり高速の利用はしないのだが、日帰りで少し遠出する場合には、使う必要性も出てくる

我々くらいの年齢のバイク乗りになると、峠だけに集中したツーリングはしないw
普通に、高速を使って、ゆったり走って、時間を節約し、明るいうちに戻ってくるものだw

そこで、以前に ZRX1200R(廃車している)に付けていた ETC車載機を、WR250X に移植する事にしたのだが、WR250X 乗りならご存じだが、このバイクには ETC車載機を組み込むスペースがほぼ無い

普通、外装に ETC車載機を入れる小さなバッグを取り付けて、その中に入れるとか、アンテナ一体式の車載器をハンドル付近に取り付けるなどの方法を採用するようだが、どう考えてもスマートとは言えないし、車載機が直で見えるのは良くないと思っている

エンジンの近くなら、何とか取り付け出来そうなスペースもあるが、熱で、壊れるかもしれず、どうしようか、考えた挙句、灯台下暗しと言うか、意外な場所にギリギリスペースがある事に気がついた

以前に、バッテリーを、LiFePO4 系リチウムバッテリーに交換したのだが、純正の鉛シールドバッテリーに比べて小さいので、その余ったスペースを利用して ETC 車載機を置く事が出来るのではないかと考えた

実際、やってみると、多少、サイドカウルの収まりが悪くなるものの、十分許容できる事が判った
バッテリーケースは、車載器に少し当たるので、一部削った

ただ、ETC カードを取り出す際は、サイドカウルを外す必要があるのだが、サイドカウルは、ネジ1本で止まっているだけなので、意外と簡単だし、バイク専用の ETC カードを用意しておけば済む話でもある


ウインカーリレーの修正と ETC の電源

以前に ウインカーを LED 化した

ウインカーの LED 化

この記事では、上手くいっている事になっているが、実際には、エンジンを始動して、アイドリングしている状態だと、点滅が少し速くなる
(ハイフラッシャー的な・・)アクセルを少し開けて回転を上げると、通常の点滅になる
※アイドリング時、発電電圧が少し高くなるものと思うが、これは、レギュレーターの仕様と関係しているし、かなり微妙な症状だと思う

直そう、直そうと思っていたが、面倒だし、点滅はしていたので、そのままにしていた・・・

今回、ETC 取り付けで、電源をどこから取るか、色々考えたが、配線図を眺めると、ウインカー、ヘッドライト、が同一の電源になっていて
+電源が、ウインカーリレーの片側に来ている
※配線図は、サービスマニュアルに記載されているが、英語版のマニュアルは、ネットで見つける事が出来る

そこで、そこから、電源を取る事にして、ハーネスを調べたが、メインハーネスから分岐しているコードが短く、ハーネスから分岐させるのは、難しいと判った、それに、ハーネスを切ったり貼ったりするのは、何だが気が進まない・・・

そこで、ウインカーリレーを分解して、+側の端子の根本に直接コードをハンダ付けして、取り出した
ウインカーリレーから、1本コードが出ているが、そんなに邪魔にならないし、いつでも綺麗に外せる
※このライト系電源は、ウインカーを LED 化して、さらに、ヘッドライトも LED 化しているので、電力的に十分な余裕がある(15Aのヒューズがあるライン)
※ETC 車載機の電源ラインには 1A のヒューズが付いている(実際の消費電流は、もっと少なく、0.2A も食わないと思う)

ウインカーリレーを改造したので、ついでに、点滅速度の改善も行った、今まで、内部回路に 470K オームの抵抗を直列に入れていたが、100K オーム足してみた
すると、今度は、アイドリング時でも、点滅速度が速くなる事は無くなった
※もし、同じように改造をするなら、560K とかにすれば良いだろうと思う


アンテナとインジケーターの取り付け

電源が何とかなったので、アンテナとインジケーターをかなり適当だが取り付けた、今後、もっとちゃんと固定しようと思う

配線は、左のカウルを外して、燃料タンクの下とフレームの隙間に通して、主要な部分は、タイラップで固定した

アンテナの角度は20度なので、目分量で、少し斜めに取り付けてある

インジケーターは、キーONで、赤と緑が点滅して、カードの読み取りが正常なら、緑の点灯になる

ETC車載機は、何年も、通電もしない状態だったので、取り付け後、上野原から談合坂を走ってみて簡単なテストを行ったが、問題無かった~


ついでにエアーフィルターの整備

そーいえば、エアーフィルターを数年は掃除していなかった、さぞかし汚れているだろう・・・

WR250 は、何故か、エアーフィルターが、スポンジによる湿式になっていて、一般的な「紙」による交換式では無い
まぁ、湿式は、灯油などで洗って、何度でも使えるのだけど

とりあえず、エアーボックスを開けてみた・・・

加水分解して、ボロボロになっていて、元の姿が無い・・・
この状態だと、インジェクションとはいえ、相当に薄い状態だったものと思う・・・
そして、埃を吸い放題・・・

しかし、心配いらない、こんな事もあろうかと、以前にちゃんと新品を買っておいたw、スポンジに塗るオイルも専用品を買っておいたー

ボロボロになったスポンジを取り除くのが、それなりに大変だったが、新品に交換したー
スポンジに塗るオイルは、ハチミツみたいな粘度で、ネバネバしていて、どの位染み込ますのか、要領が判らなかったが、多くも無く、少なくも無く、まんべんなく塗りたくった
※社外製紙式エアーフィルターは販売されているようだが、かなり割高のようだー


DELTA DPS-1200AB-4G サーバー用電源

今度は 1000W(1200W) の電源を購入

800W は、もう一息足りないなぁーと思っていて、ヤフオクを巡って、1000W クラスも販売されている事に気がついた
多くの場合、1000W 以上は、200V 用が多い中、100V でも使える電源を見つけた
※この電源は、200V なら 1200W まで出力できるみたいだ
電源は中古で、送料がかかるのだが、それでも激安だー、有り難い~
通常、サーバーは冗長接続なので、二台セットで売られているのも嬉しい

  • メーカー:DELTA ELECTRONICS, INC.
  • 型番:DPS-1200AB-4G
  • 80 PLUS PLATINUM
  • INPUT: 100-127V~/ 12.47A
  • AUTORANGE INPUT (47-63Hz)
  • OUTPUT: (1000W MAX) +12V / 82A +12VSB / 2A
  • INPUT: 200-240V~/ 7.08A
  • OUTPUT: (1200W MAX) +12V / 98A +12VSB / 2A
  • 効率: 50% Load - 94%

使い方を捜索する

まず、使い方(結線)が不明なので、ネットで色々探すものの、ドンピシャリの情報は探せていない
そこで、色々と想像しながら、試行錯誤した

ネットにある情報は、DP-1200FB のもので、この電源とは異なるようだー、ピンアサインも異なる

ピンアサインのデータシートは見つけたので、ダウンロードして、ピンアサイン名から想像してみる・・・

Output Pin Assignment

PIN Signal Name PIN Signal Name
A1 GND B1 GND
A2 GND B2 GND
A3 GND B3 GND
A4 GND B4 GND
A5 GND B5 GND
A6 GND B6 GND
A7 GND B7 GND
A8 GND B8 GND
A9 GND B9 GND
A10 +12V B10 +12V
A11 +12V B11 +12V
A12 +12V B12 +12V
A13 +12V B13 +12V
A14 +12V B14 +12V
A15 +12V B15 +12V
A16 +12V B16 +12V
A17 +12V B17 +12V
A18 +12V B18 +12V
A19 SDA B19 A0
A20 SCL B20 A1
A21 PSON B21 12VSB
A22 SMB-ALERT B22 CR_1
A23 RETRUN_S B23 12LS
A24 +12VRS B24 NC
A25 PWOK B25 NC

通常電源は、エッジコネクタに接続されて、正しい手順を行わないと有効にならないようになっている
この電源は、+12VSB があるので、メインが有効になっていない場合でも、別系統の 12V/2A が使えるハズだー
これは、PC の ATX 電源にある 5VSB と同等な利用を想定しているのだと思うが、電圧は 12V となっている

又、電源の状態を詳しく知る手段として、I2C による通信ラインが用意されている(SDA、SCL、A0、A1)
※A0、A1 は I2C のアドレスを変更するオプションのようだ
電源の I2C コマンドは、この電源では無いが(DPS-550AB-11D)、別の資料を見つける事が出来た

とりあえず、100V を接続してみて、12VSB の電圧を測ってみた、3.3V が出ている
100V を接続して、エッジコネクタがオープンでも、コンセントにある緑のインジケーターが点灯して、ファンがゆっくり回転している
ファンの音は 800W の電源に比べて、少しうるさいように感じた(中古なので、ベアリングが痛んでいるのかもしれない)

まず、何らかの方法で、電源を有効にしないと、駄目なようだー
DP-1200FB の説明では、12VSB と PRESENT 端子を 22K の抵抗で接続すると有効になるとある
しかし、この電源には、「PRESENT」端子は無い、試しに「12VSB」端子の隣にある「CR_1」とを 22K の抵抗で接続してみたら、12VSB から 12V が出力された

ここで、「PSON」を GND に落としてみたが、メインの +12V は出力されていない・・・

気になるのは、「RETURN_S」と、「+12VRS」だ、仮に、電源が 100% 近くの出力を行う場合、100A 近くの電流が流れる事になる
そうすると、電源ラインの微小な抵抗でも、電圧ドロップが起こり、電圧が低下してしまう
通常、このような高電流の電源は、電圧をセンスして出力電圧を補正する別端子があるものだ
※0.01 Ω の抵抗でも、100A だと 1V 電圧が低下してしまう

しかし、この端子は関係無いようだ・・・
この端子は、冗長接続の場合に使うのかもしれない・・・(調査が必要だー)

どうも、色々やっても、電圧が出力されない・・・

後は、I2C 通信でコマンドを入れないと駄目なのかと思ったが、ネットで情報を調べると、同じ電源で出力が出ないと試行錯誤を繰り返した人のブログを見つけた
不意に、B24、B25 (この端子は、データシートでは「NC」となっている)に 1.8K の抵抗を繋ぐと、出力されるとあった、試してみると、ファンが高速に回り、確かに出力される
試しに、30W くらいの電力を引っ張ってみたが問題無い

うーーん、納得いかないが、とりあえず、この方法でとりあえず何とかはなるようだー
ただ、出力に合わせて、ファンの回転が制御されていないし、やはり正規の方法は、I2C でコマンドを送るのだろうと思う


内部を観察する

  • 2台のうち、1台は、中に埃が溜まっていたので、エアーダスターで掃除した
  • 流石高級電源、ケースのエッジのバリが無く、ケースのエッジを触って怪我をする事が無いと思う、細かい部分に気を使っている
  • この電源は、ブリッジレス、インターリーブ PFC を採用しているようだ、それらしいコイルが2個ある
  • ブリッジダイオードもあるが、小さい(10A を流せるような物ではない)ので、多分 +12VSB 用に使っているのだろうと思う
  • 制御基板の部品が見えないが、800W の物と同じような感じなので、フルデジタルであろうと思う
  • 全ての負荷で、高い効率を維持するには、デジタル以外では難しいと思える
  • PFC の出力電圧は、隙間が狭く、計れないのだが、同じように 330V なのでは無いかと思う
  • 構成は、800W の物とほぼ同じに見えるが、800W の電源の方が洗練されているようだ(800W 電源の方が時代が新しい)
  • 12VSB もあるので、800W より、さらに密度が高く、隙間が少ない

まとめ

今回、電源を出力する事は出来たものの、イレギュラーな方法なので納得はいっていない
I2C を接続して、「PMBus」プロトコルと言うのがあって、それで電源を制御出来るらしい
次はそれを試してみる事にする


80 PLUS 規格

230V Internal Redundant

80 PLUS 規格 10 % 20 % 50 % 100 %
80 PLUS BRONZE 81 % 85 % 81 %
80 PLUS SILVER 85 % 89 % 85 %
80 PLUS GOLD 88 % 92 % 88 %
80 PLUS PLATINUM 90 % 94 % 91 %
80 PLUS TITANIUM 90 % 94 % 96 % 91 %

HSTNS-PD41 の中身

Hewlett Packard
Enterprise 800W
80 PLUS PLATINUM
型番:HSTNS-PD41
INPUT:100V-240V~ 9.4A-4.5A 50-60Hz
OUTPUT:+12V 67A MAX
安全規格:IS 13252(Part 1)/IEC 60950-1

制御基板で判る部品

  • UCD3138 Highly Integrated Digital Controller for Isolated Power with 3 Feedback Loops and 8 DPWM Outputs
  • dsPIC33F High-Performance, 16-bit Digital Signal Controllers

UCD3138 は、Texas Instruments(TI)が開発した、分離型電源向けに高度に統合されたデジタル制御用プロセッサです。6-mm × 6-mmの小型パッケージに、32ビットARM7TDMI-Sプロセッサ、高精度データコンバータ、複数のプログラマブルなハードウェア制御ループ、通信インターフェースを統合しており、サーバー、通信機器、高電力DC-DCモジュールなどに適しています。

主な特徴:

  • 3つのフィードバックループと8つの高解像度DPWM出力(250-psパルス幅分解能)を備える。
  • 14ビットDAC、16MHz EADC(最小1mV/LSB解像度)、12ビット267ksps一般用途ADCを内蔵。
  • 高効率制御:同期FETのソフトオン/オフ、動的フェーズシェービング、動的周波数調整、モードスイッチングをサポート。
  • 全分離型トポロジー(PSFB、LLC、フルブリッジ、PFCなど)をサポート。
  • 保護機能:サイクルバイサイクル電流制限、過電圧/過電流/過熱保護、入力電圧フィードフォワード制御。
  • 開発支援:Code Composer Studio™、Fusion Digital Power Studio GUI、評価ボード(UCD3138PFCEVM-026など)を提供。

dsPIC33F は、Microchip Technologyが提供する16ビットのデジタル信号コントローラ(DSC)ファミリです。高性能なDSP機能を搭載しており、40 MIPS(3.0–3.6V)で動作し、産業用温度範囲(-40°C ~ +85°C)に対応しています。このファミリは、高速な17×17ビット乗算器、40ビットALU、2つの40ビット飽和積算器、40ビットバイ方向バーレルシフターを備え、1サイクルで乗算・積算(MAC)を実行できるため、リアルタイム信号処理に最適です。

主な特徴:

  • 40 MIPSの高性能CPU
  • DMA(Direct Memory Access) 機能を搭載
  • 12ビットまたは10ビットADC(複数のサンプルアンドホールド対応)
  • CANインターフェース、UART、SPI、I²Cなどの通信インターフェース
  • ペリフェラルピン選択(PPS) 機能により、ペリフェラルのピンマッピングを柔軟に設定可能
  • 28ピンから100ピンまでのパッケージ選択肢
  • 12KB~256KBのフラッシュメモリ、16KB~64KBのRAM

大雑把に見える部分で、目立ったのは、デジタル制御電源である点だ。(電源で、このような贅沢な構成は観た事が無い)
負荷がダイナミックに変動する機器で、全負荷に対して、最大の効率を達成しようとすると、従来のアナログ回路だけでは、難しい事がある。
デジタル制御なら、色々な状況を判断して、最適な制御を導入する事が出来る。
又、出力先が故障した場合などにも、即座に対応でき、安全対策も、十分行える。

しかし、恐ろしい程コンパクトに作られている、これで 800W もあるのは、本当に驚きでしかない・・・


PFC 部分の推定

  • 当然ながら、ダイオードブリッジは無く、多分パワー MOS-FET によるブリッジレスとなっているものと思う
  • インターリーブ構成になっていると思われたが、スペースの都合だろうと思うが、そうはなっていないようだ(インターリーブにすると効率が若干良くなり、熱的に有利になる)
  • PFC の出力段にある、平滑コンデンサがかなり大きく、電源のスペースをかなり取っている(制御基板の上にある黄色い物体)
  • PFC で、入力を 100V~240V とかにすると、PFC の構成上、出力は、大抵 380V~400V 位の直流になる
  • この電源の出力段にある、平滑コンデンサの端子を測った処、330.8V だった

出力段の構成

  • 多分、PFC 段から 12V を得るのに、トランスがあるハズだが、それが、思った以上に小さい
  • スイッチング周波数が、かなり高いのだろうと思うが、効率の向上と、飽和しないようにするには、コアの材質が重要だと思う
  • 多分、この分野で、大きな技術革新があるものと思う
  • 高周波、大電力でも使えるトランスに使えるコアは、一般的な汎用品には無いと思うので、コア材の企業と提携して、特別な物を調達しているのだと思う
  • 終段の降圧用トロイダルコイルも、かなり小さい、巻き線の太さはそれなりに太く、さらに、二重にしているようだ
  • 一般的な常識では、このサイズだと、良くて150W 位だと思うが、800W・・・、凄いの一言だ・・・

まとめ

壊すつもりで分解すれば、もう少し色々な事が判ると思うが、とりあえず、この位で・・

この素晴らしい電源は、応用範囲が広く、超高性能なので、色々と応用を研究したい~

サーバー用電源を流用する

最近のサーバー用電源

最近知ったのだけど、サーバー用電源が中古で安く流通している。

  • 800W の電源ユニット(非常に小型)
  • 出力は 12V 単出力で 67A
  • このユニットは入力 100V~240V、9.4A~4.5A
  • より高出力なユニットでは 200V 専用とかもあるので、購入の際は注意
  • 80 PLUS PLATINUM の認証を取っている
  • 通常2台で販売されている(冗長性を得る為、複数台で運用するのが普通なのだろう)
  • 超高品質で、贅沢な回路構成で高品質な部品を使って製造されていると思われる
  • 長時間の運用でも、故障しない事が前提なので、色々と細かい部分にこだわっている
  • 電源コネクタは、「Common Slot PSU 規格」らしい(ピンアサインを探したが現段階で見つからなかった)
  • 電源ユニットは世代があり、この一つ前の世代の電源ユニットのエッジコネクタ仕様は、ネットで探せた
  • しかし、この世代のエッジコネクタの仕様は見つからなかった・・・
  • 多くの人が、電源出力を変更する事で、利用範囲を広げる改造をしているようだ(13.8V 出力など)
  • エッジコネクタには、電源と通信する I2C 信号ラインなど、電源をモニターする通信ラインが備わっているようだ

とりあえず、出力を許可させる

  • 写真のようにエッジコネクタの左3本をショートすれば、常に出力が出るようだー
  • このやり方は、YouTube で観たものの受け売りなので、注意
  • 出力は 12.3V だった

何故、この電源に注目したか?

  • PFC(力率改善回路)部分が主要な目的
  • 1000W クラスの電源を使用する場合、力率改善要件がある
  • PFC 回路は自分で製作する場合、色々とハードルがある
  • 一つは、昇圧コイルが必要で、特殊な仕様なので、コアの材質や巻き線など、汎用品の入手が難しい
  • また、高効率を目指すと、回路が複雑化して、設計や試験に時間がかかりそうで、色々調べては、思案していた・・
  • 100W 位なら、単純な回路でも良いだろうが、1000W(100V/10A)となるとかなり回路を工夫する必要がある
  • この電源は、高効率なので、PFC 回路もかなり上等な仕様だろうと思う
  • 多分、ブリッジレスのインターリーブ PFC とかだと思う(そうしないと、効率が上がらない)
  • PFC の出力は、通常 400V の直流とかなので、その後に、インバーター回路を作って、色々実験したい
  • 最初に行いたいのは、600W 位のコンデンサモーターのインバータ化
  • 又、3.3V、5V などの降圧コンバーター(20Aクラス)を製作して、PC用電源にするのも良さそうだー

まとめ

今後、内部解析や、応用例を投稿していく予定でいるのだが・・・

ncurses ライブラリを使う

ncurses ライブラリとは?

  • ncurses は curses から派生した亜種?で、元は curses ライブラリと同等と思われる
  • そもそも curses ライブラリは、シリアル接続されたターミナル(VT100など)と通信を行う事を前提にしている
  • テキストベースのアプリケーションを構築する場合、文字の操作は、固定されたアドレスに行う操作でなければ柔軟性が低い
  • curses ライブラリは、そのような操作を最適化して、シリアルターミナルに差分を送る事により行う
  • アプリケーションからは、単なる配列に対するアクセスでしかなく、ターミナル独特の性質を隠蔽出来る
  • これによりダイナミックな文字の書き換えを必要とするアプリケーションを実装しやすくする
  • 代表的なアプリとして、vi や emacs などがある
  • このライブラリは、40 年前には既に存在していて、UNIX マシンに、シリアル接続したターミナルで使えていた
  • その当時は1台の UNIX マシンに4台くらいのターミナルを接続してマルチユーザーで利用するのが当たり前だった
  • ターミナルは VT100 互換の制御コマンド(エスケープシーケンス)を実行出来る事が前提となる
  • 当時、このライブラリの存在を知って、テトリスを作って遊んでいた
  • curses ライブラリは、ターミナルの能力を識別する為に、UNIX システムのターミナル情報を参照する

今、何故、curses ライブラリが有用なのか?

  • 組み込みマイコンの場合、シリアル通信で、PC 上のターミナルエミュレータと通信する場合が多い
  • 組み込みマイコン側に curses ライブラリを移植する事で、アプリケーションの柔軟性が向上する
  • ただ、curses ライブラリはかなり大きく、高機能で、全ての API を移植するのは現実的では無い
  • 又、ターミナルの機能を参照する仕組みが、UNIX システムとかなり親密で、そこを移植するのもハードルが高い
  • curses を使って何かアプリを作る場合、ほとんどの場合一部の機能しか使わない事が多い
  • テキストベースのアプリケーションを組み込みマイコン側で動かすのは、色々とメリットがあり、欲しい機能ではある

まずは、本家でアプリを実装して、必要な API を最適化する

  • とりあえず、clang64 環境で、ncurses ライブラリを使ってみる
  • そこで、curses で使う API を最適化して、その API だけ、組み込みマイコン側に実装すれば良いように思う
  • 画面の差分をシリアルで転送する場合、VT100 の一部のエスケープシーケンスだけしか利用しない

clang64 に ncurses ライブラリをインストール

 % pacman -Ss ncurses
clang64/mingw-w64-clang-x86_64-ncurses 6.5.20250927-2 [インストール済み]
    System V Release 4.0 curses emulation library (mingw-w64)
 % ls -l /clang64/lib/libncur*
-rw-r--r-- 1 hira hira 692K 10月  5 00:44 /clang64/lib/libncurses.a
-rw-r--r-- 1 hira hira 127K 10月  5 00:44 /clang64/lib/libncurses++w.a
-rw-r--r-- 1 hira hira  84K 10月  5 00:44 /clang64/lib/libncurses++w.dll.a
-rw-r--r-- 1 hira hira 127K 10月  5 00:44 /clang64/lib/libncurses++w_g.a
-rw-r--r-- 1 hira hira 692K 10月  5 00:44 /clang64/lib/libncursesw.a
-rw-r--r-- 1 hira hira 157K 10月  5 00:44 /clang64/lib/libncursesw.dll.a
-rw-r--r-- 1 hira hira 914K 10月  5 00:44 /clang64/lib/libncursesw_g.a
  • ncurses ライブラリは「libncursesw.a」をリンクします。
  • 末尾に「w」が付加しています、これは、ワイド文字列をサポートしています
  • さらに「++w」は、curses ライブラリ API を C++ から便利に使う為にラッパークラスのようです
  • 今回は、組み込みマイコン側でも簡単に実装出来るようにするので、あえて C++ バージョンを使いません
LOCAL_INC_PATH := /clang64/include
NCURSES_PATH := $(LOCAL_INC_PATH)/ncurses
  • ncurses のヘッダーは「ncurses」ディレクトリに集約されています
  • コンパイル時、上のように、システムインクルードパスを追加します
#include <ncurses.h>
#include <locale.h>
  • ncurses でワイド文字列を扱う場合、ロケールの設定が必要なので、ヘッダーをインクルードします

   setlocale(LC_ALL, "ja_JP.UTF-8");
  • 通常、UTF-8 を使うと思うので、上記のようにロケールを設定しておきます

簡単なサンプル

int main(int argc, char** argv)
{
    setlocale(LC_ALL, "ja_JP.UTF-8");

    initscr();

    int ym;
    int xm;
    getmaxyx(stdscr, ym, xm);
    keypad(stdscr, TRUE);
    noecho();

    const char* str = "漢字";
    int x = (xm - sizeof(str)) / 2;
    int y = ym / 2;

    nodelay(stdscr, TRUE);

    int xx = -1;
    int yy = -1;
    while(true) {

        if(xx != x || yy != y) {
            clear();
            mvprintw(y, x, "%s", str);
            refresh();
            xx = x;
            yy = y;
        }

        auto ch = getch();
        if(ch < 0) continue;

        if(ch == 0x1b) {
            break;
        }

        switch(ch) {
        case KEY_UP:
            y--;
            break;
        case KEY_DOWN:
            ++y;
            break;
        case KEY_LEFT:
            x--;
            break;
        case KEY_RIGHT:
            ++x;
            break;
        default:
            break;
        }
    }

    endwin();
}
  • このサンプルでは、矢印キーで、中央に表示された文字列を動かします
  • ESC キーを押すとアプリを抜けます
  • curses での、ダイナミックな表示では、画面を全部消去して、全てのオブジェクトを描画します
  • そうする事で、色々なオブジェクトをダイナミックに表示する事が簡単に行えます
  • curses では、描画を最適化して差分をターミナルに送るので、シリアル通信の転送量を最適化します
    nodelay(stdscr, TRUE);
  • この設定により、「getch()」関数はブロッキングをしなくなり、キー入力が無い場合に (-1) を返します
  • 描画ループを一定間隔で回るようにすれば、アニメーションを簡単に行う事が出来ます

まとめ

curses を使い、最低限の機能を実装して、何となく使い方が理解出来たと思う。

これで、PC 上で curses API を使ったアプリを実装して、動作を検証できる

次は、組み込みでも動作する簡単なスクリーンエディターを実装して、組み込み用 curses ライブラリを構築してみようと思う

MSYS2 を最新版にアップデートしたら・・

序章

そーいえば、MSYS2 の更新を行っていなかった・・
そこで、通常の手順で更新を行った。

pacman -Sy pacman
pacman -Syu
pacman -Su

この更新で、clang64 コンパイラなどが最新バージョンにアップグレードされた。


glfw3_app をコンパイル

まず最初に行うのは、clang64 対応でコーディングしてあるアプリのコンパイルチェック。

思った通り、エラーが出て、コンパイルが停止・・・

「basic_string」関係のテンプレートでエラーとなっているようだー
※エラーのキャプチャーを忘れたので、状況説明だけ

namespace utils {
    typedef std::basic_string<uint16_t> wstring;
    typedef std::basic_string<uint32_t> lstring;
}

これらを使った複数のコードが通らない・・・

この実装は、7~8年前のもので、自前で、UTF-8、UTF-16、UTF-32 を扱う為に行っていたもので、UTF-8 から UTF-16 や UTF-32 に相互に変換したり、色々なサポート関数を揃えていた。
又、古い Windows の ShiftJIS コードを扱う API にも対応している。

現在は、標準で、「std::wstring、std::u32string」などがあり、又、ユニコードの扱いも標準ライブラリで対応しているので、自分で色々書かなくても良いようになっていると思うのだが・・

  • 標準ライブラリで、これら文字コードを扱う実装がされていると思うが、勉強不足で、どうしたら良いか判っていない
  • かと言って、昔に自分が実装して、一応動いているコードを、最新の標準ライブラリで書き直すのも、色々とハードルが高い
  • そこそこの量があり、現状では、あまりやる気が起きない(動いているコードはそっとしておきたいと思う事もある)

とりあえず、コンパイルが通るように改修

そこで、最低限の修正で、コンパイルが通り、動作するのを確認するまでを行った。

    utils::wstring  --->  std::wstring
    utils::lstring  --->  std::u32string

大まかな修正は、上記の二つだけで、auto なども駆使して、書き換えた。

30分くらいの労力で、コンパイルが通り、動作も確認した。


まとめ

  • 今後、最新の標準ライブラリで、どのような実装になっているのか、調査と学習が必要なようだ・・・
  • 文字列の扱いをどのようにすべきなのかを、考え直す必要性がありそうだ・・・
  • 標準的な窓口として、UTF-8 を使うのか、UTF-32 にするのが良いのか答えが出ていない・・・
  • UTF-8 にすると、マルチバイトを含んだ文字列の部分コピーや、文字数の操作が局所的になってしまう
  • UTF-32 にすると、8ビット系文字列にしか対応していないライブラリなどを使う場合に対処が必要になってしまう

RXマイコン、ポート・マップ・ピン情報を追加

ポート・マップ候補機能

  • C++フレームワークでは、各ペリフェラルを扱う場合、どのポートを選択するかを、簡潔に扱う為に、「ポート・マップ候補機能」を導入しています
  • 今まで、「候補」がどのポートを選択するかを知る為、各ソースコードを参照するようにとアナウンスしていました
  • それを、少しだけ便利にする為、単純に、候補とポートの関係を表にして、各MPUのルートにある、README.md ファイルに集約するようにしました
  • これは、ソースコードの修正とは、異なり、単なるドキュメントの更新なんだけど、分量がかなり多く、又、ピン番号も同時に記入してあるので、それなりに大掛かりな作業でした
  • ピン番号は、良く使うであろう、パッケージだけに絞り、(例えば、64 ピン、100 ピン、144 ピンなど)全てを網羅している訳では無いのだけど・・・
  • パッケージとピン番号の正確性は、ミスもあるかと思うので、実際に配線する前に確認が必要です

各CPUの特徴とリンクなど

現在サポートされ、動作確認済みデバイス:

シリーズ MinV MaxV MHz コア FPU TFU DFPU 動作確認 rx_prog リンカーファイル
RX110 1.8 3.6 32 RXv1 R5F51103/4/5
RX111 1.8 3.6 32 RXv1 R5F51115/6/7
RX113 1.8 3.6 32 RXv1 R5F51136/8
RX130 1.8 5.5 32 RXv1 R5F51305/6
RX140 1.8 5.5 48 RXv2 Yes R5F51403/5/6
RX13T 2.7 5.5 32 RXv1 Yes R5F513T3/5
RX210 1.62 5.5 32 RXv1 R5F52108/B
RX220 1.62 5.5 32 RXv1 R5F52206
RX231 1.8 5.5 54 RXv2 Yes R5F52316/7/8
RX23T 2.7 5.5 40 RXv2 Yes R5F523T5
RX24T 2.7 5.5 80 RXv2 Yes R5F524T8/A
RX24U 2.7 5.5 80 RXv2 Yes R5F524UB/E
RX261 1.6 5.5 64 RXv3 Yes R5F52618
RX26T 2.7 5.5 120 RXv3 Yes V2 R5F526TF
RX621 2.7 3.6 100 RXv1 Yes R5F56218
RX62N 2.7 3.6 100 RXv1 Yes R5F562N7/8
RX631 2.7 3.6 100 RXv1 Yes R5F5631F
RX63N 2.7 3.6 100 RXv1 Yes R5F563NE
RX63T 3.3 5 100 RXv1 Yes R5F563T6
RX64M 2.7 3.6 120 RXv2 Yes R5F564MF/G/J/L
RX71M 2.7 3.6 240 RXv2 Yes R5F571MF/G/J/L
RX651 2.7 3.6 120 RXv2 Yes R5F5651E
RX65N 2.7 3.6 120 RXv2 Yes R5F565NE
RX66N 2.7 3.6 120 RXv3 Yes V1 Yes R5F566ND/N
RX660 2.7 5.5 120 RXv3 Yes R5F56609
RX671 2.7 5.5 120 RXv3 Yes R5F5671C/E
RX72N 2.7 3.6 240 RXv3 Yes V1 Yes R5F572ND/N
RX72M 2.7 3.6 240 RXv3 Yes V1 Yes R5F572MD/N
RX66T 2.7 5.5 160 RXv3 Yes R5F566TA/E/F/K
RX72T 2.7 5.5 200 RXv3 Yes V1 R5F572TF/K

基本的な候補の使い方など

「候補」は以下のようになっています:

    enum class ORDER : uint8_t {
        BYPASS,         ///< ポートマップの設定をバイパスする場合

        FIRST,          ///< 第1候補
        SECOND,         ///< 第2候補
        THIRD,          ///< 第3候補
        FOURTH,         ///< 第4候補
        FIFTH,          ///< 第5候補
        SIXTH,          ///< 第6候補
        SEVENTH,        ///< 第7候補
        EIGHTH,         ///< 第8候補
        NINTH,          ///< 第9候補
        TENTH,          ///< 第10候補
        ELEVENTH,       ///< 第11候補
        TWELVETH,       ///< 第12候補

        USER,           ///< ユーザー設定

        LOCAL0,         ///< 独自の特殊な設定0
        LOCAL1,         ///< 独自の特殊な設定1
    };
  • 現在、ポート候補は、グループ設定の場合と、単独ポートの場合が混在しています
  • たとえば、SCI、CAN、RSPI、IICA などはグループ指定、MTU、TPU、GPT、GPTW、QSPI などは単独で指定可能になっています
  • なので、SCI などで、グループを超えて設定(TXD を FIRST、RXD を SECOND みたいな)事は出来ないです
  • グループ指定は、複数あるポートを一括して行うものです
  • 一般的に、グループ候補の場合、近接するポートを選んでいるので、通常それで困る場合は無いと思います
  • 急遽、ペリフェラルの機能が必要になり、余っているポートをかき集めたり、改造を最小限にする為に、異なる候補を選択するしか無い場合はあるかと思います
  • そのような場合は、「USER」設定を使って、独自に設定する必要があります

SCI ポート候補の選択例

  • 例として RX231、LFQFP64 パッケージの場合
  • SCI5 を使いたい場合

Github RX231 ルート

Port map order / ポートマップ候補

LFQFP64

Peripheral FIRST SECOND THIRD FOURTH
SCI5 / RXD PA2 (--) PA3 (43) PC2 (32) PC2 (32)
SCI5 / TXD PA4 (42) PA4 (42) PC3 (31) PC3 (31)

候補の選択と管理

  • 「Port map order / ポートマップ候補、LFQFP64」の表から、「SCI5 / RXD, SCI5 / TXD」の欄を見ます
  • 実際のハードを吟味して、SECOND の RXD/PA3 (43)、TXD/PA4 (42) が使えそうと判断します
  • SCI の入出力では、「sci_io.hpp」のテンプレートクラスを使います
  • 以下のコードのように、「SECOND」を指定して、sci_io のテンプレートを typedef して型を定義します
  • それの実態を定義して、初期化するだけで、使えるようになります
  • new しても構いませんが、固定されたハードウェアーで、動的にクラスを生成する必要性が無いので、static に宣言します
  • 出来るだけ、new を使わない方法を選択する事が寛容です
  • static に宣言すれば、必要なメモリは、C++ コンパイラが適切に領域を設定して配置してくれます
  • C++ では、static と宣言しても良いのですが、main 関数があるソースに、無名の名前空間で囲んで定義するのが一般的です
  • sci_io クラスでは、定義に、受信、送信バッファの型を伴って定義します
  • バッファは、固定長のリングバッファを使います、「fixed_fifo」テンプレートクラス
  • 以下の例では、それぞれ、512 バイト、256 バイトの大きさで定義しています
#include "common/renesas.hpp"
#include "common/fixed_fifo.hpp"
#include "common/sci_io.hpp"

namespace {
    typedef utils::fixed_fifo<char, 512> RXB;  // RX (受信) バッファの定義
    typedef utils::fixed_fifo<char, 256> TXB;  // TX (送信) バッファの定義
    typedef device::sci_io<device::SCI5, RXB, TXB, device::port_map_order::SECOND> SCI5_IO;

    SCI5_IO sci5_io_;
}
  • もし、あーやっぱり、「RXD/PA3 (43)、TXD/PA4 (42)」じゃなく、「RXD/PC2 (32)、TXD/PC3 (31)」の方が、都合が良いとなれば
  • 候補を、「SECOND」から「THIRD」にするだけです
  • 他は変更する必要がありません
    typedef device::sci_io<device::SCI5, RXB, TXB, device::port_map_order::THIRD> SCI5_IO;

標準入出力の設定

  • 一般的な gcc を使った、組み込みアプリケーションでは、標準入出力とのインターフェースを設定する必要があります
  • この C++ フレームワークでは、syscall.c をリンクする事で、インターフェースを有効にする事が出来ます
  • SCI5 のインスタンスをこの標準入出力と繋げる場合、以下のように定義します
extern "C" {

    // syscalls.c から呼ばれる、標準出力(stdout, stderr)
    void sci_putch(char ch)
    {
        sci5_io_.putch(ch);
    }

    void sci_puts(const char* str)
    {
        sci5_io_.puts(str);
    }

    // syscalls.c から呼ばれる、標準入力(stdin)
    char sci_getch(void)
    {
        return sci5_io_.getch();
    }

    uint16_t sci_length()
    {
        return sci5_io_.recv_length();
    }
}
  • この定義で、SCI5 での入出力は、標準入出力とリンクされます
  • printf や scanf などで入出力を行えます
  • C++ では、C 言語の関数は使わないので、format クラス、input クラスの用意があります

初期化

  • SCI の初期化は簡単で、ボーレート、割り込みレベル、プロトコルを選択するだけです
// 起動時、1度行って、マスタークロックをブーストして下さい
    SYSTEM_IO::boost_master_clock();

    {  // SCI の開始
        constexpr uint32_t baud = 115200;  // ボーレート(任意の整数値を指定可能)
        static_assert(SCI5_IO::probe_baud(baud), "Failed baud rate accuracy test");  // 許容誤差(3%)を超える場合、コンパイルエラー
        auto intr = device::ICU::LEVEL::_2;     // 割り込みレベル(NONE を指定すると、ポーリング動作になる)
        if(!sci5_io_.start(baud, intr)) {  // 標準では、8ビット、1ストップビットを自動選択
            halt_();
        }
// 通信プロトコルを設定する場合は、通信プロトコルのタイプを指定する事が出来る。
// sci_io.hpp PROTOCOL enum class のタイプを参照
//      sci_.start(baud, intr, SCI::PROTOCOL::B8_E_1S);
    }
  • これで、入出力が行える準備が整います
  • 後は、標準入出力を使って、データ通信を行います
    {  // SCI の設定レポート表示
        utils::format("SCI5 PCLK: %u [Hz]\n") % SCI5_IO::sci_type::PCLK;
        utils::format("SCI5 Baud rate (set): %u [BPS]\n") % sci5_io_.get_baud_rate();
        float rate = 1.0f - static_cast<float>(sci5_io_.get_baud_rate()) / sci5_io_.get_baud_rate(true);
        rate *= 100.0f;
        utils::format("  Baud rate (real): %u (%3.2f [%%])\n") % sci5_io_.get_baud_rate(true) % rate;
        utils::format("  SEMR_BRME: %s\n") % utils::str::get_bool_text(SCI5_IO::sci_type::SEMR_BRME);
        utils::format("  SEMR_BGDM: %s\n") % utils::str::get_bool_text(SCI5_IO::sci_type::SEMR_BGDM);
    }

独自ポート設定(ORDER::USER)

  • 以下の例は、候補として「USER」を行う場合の方法です
  • SCI5: TXD/PA3, RXD/PC3 を利用する例です
  • この設定は、初期化 (sci5io.start) を行う前に設定する必要があります(初期化時に、設定された関数が呼ばれます)
  • 又、C++ のランタイムをリンクする必要があります(Makefile に supc++ ライブラリを追加してください)
  • 独自設定の場合、特別なレジスター郡へのアクセスがあるので、独自関数が呼ばれる前に、書き込み保護が解除された状態になっています
    typedef device::sci_io<device::SCI5, RXB, TXB, device::port_map_order::USER> SCI5_IO;
        device::port_map::set_user_func( [=](device::peripheral per, bool ena) {
            // SCI5: TXD/PA3, RXD/PC3 の場合
            using namespace device;

            // セレクターのビット列は、MPC の解説を参照して下さい
            uint8_t sel = ena ? 0b0'1010 : 0;
            MPC::PA3PFS.PSEL = sel;
            PORTA::PMR.B3 = ena;
            MPC::PC3PFS.PSEL = sel;
            PORTC::PMR.B3 = ena;

            return true;
        }
        );

Makefile への C++ ランタイムライブラリの追加:

USER_LIBS   =   supc++
  • この例ではラムダ式を使って簡潔に行っています
  • 詳しくは、「std::function ラムダ式」などで検索して、使い方を参照して下さい
  • これらのサンプルは、「SCI_sample/main.cpp」に具体的なコードが示されていますので参考にしてください
  • ポートの機能設定は、ハードウェアーマニュアルの MPC の解説を参照して下さい
  • MPC に、機能を設定するビット列には特別な意味があります、間違えると、正しく動作しません
  • ポートの独自設定は、設定を合格とする為「true」で戻る必要があります

まとめ

  • 今回の更新は、ドキュメントの追加程度ですが、github に色々な情報を集約するのに都合が良いものでした
  • マークダウンの表は、そこそこ見やすいものなので、多少利便性が向上したものと思います
  • 又、ポートマップの仕組み、具体的な独自設定の方法などをさらに詳しく示しました

2025年7月に関する事

スピリチュアルな話について

この手の話をすると、大抵、非科学的として、取り合わない人がいる、特にコンピュータ関係の仕事をしている人は、その傾向が強い。
ある程度、興味があっても、周りの目を気にして、正反対の態度を取る人もいる。

医者、化学、科学、機械、電気、設計などの仕事に従事する人も、興味を示さない傾向が強い。

逆に、文学、音楽、演劇、芸術、執筆などの職業者は、ある程度興味を示す場合もある。

本来は職業とは関係無く、その人の性質により、興味を示すだろうと思うのだが、計算が得意な人は敬遠傾向が強いのかもしれない。

一番、良くないのは、極端な態度になってしまい、議論をする余地が無くなってしまう場合で、それは、双方不利益だと思える。

たとえば、地球以外の知的生命体は存在するが、光の速度を超える事が出来ないので、地球に到達する事が出来ない、従って、UFOや宇宙人は存在しない。
と言う人は多いのだが、我々がまだ知らない物理法則やテクノロジーがあって、それを使う事で、大きな距離を飛躍出来るかもしれない。
これを言うと、「拡大解釈」だとか、「確率が低すぎる」とか、色々反論してくる人も多い。(知らない知識を確率で示す事は出来ない)
特殊相対性理論を引き合いに出して、長い距離の移動は不可能だと言い切る人がいるが、未知の法則が無い証明については無頓着で、破綻している事に気がつかない。
知らない事を無い事とするのは、論理が破綻している。

他星の知的生命体がいても、地球には干渉出来ないだろうから、都合よく助けてもらえる事も無いと思うし、地球より進んだ文明が現在の経済システムに干渉するような行為は、御法度だろと想像出来る。
地球の出来事は地球人で解決する事が、絶対的な法則であると思える。
但し、地球での出来事が、他の星の住人に何等かの影響が及ぶようなら、干渉もして来るだろうと思える。
地球人のルーツが他星にあるのなら、その他星人が干渉してくる事はあるかもしれない。

今の科学では、人は死んだらどうなるのか?、魂の世界はあるのか?、このような問いに真摯に答える事が出来ない。

これは、自分が小学生の頃の体験なのだが、家族で夕食を取っていた。
6時過ぎ(時計が6時を知らせた)頃、玄関でガタガタと音がした、あ!誰か来た!と思って玄関の方向に目をやると、玄関とガラスのふすま越しに青い羽織を着た人が、スゥーと通って、奥に行ったように見えた。
間取りは、「玄関→ガラスのふすま→食卓」、ガラスのふすまは、曇りガラスのようになっていて、ハッキリ見えない。
母が、アレ?と思って、ガラスのふすまを開ける、玄関は閉まっており誰もいない、奥まで確認したが、人の気配は無い
今のは何?、とみんなで変だねぇーと首を傾げていた。
食事が終わり、かたずけている6時半過ぎ頃、電話がかかって来て、叔母が電話に出る。
そして、叔母の知り合いが亡くなったと知らせがあった、時間は6時過ぎ頃らしい。
あぁ、アレは、祖母の知り合いが、挨拶に来たんだーとなった。(青い羽織も、その時の服装だったようだ)
この件で、自分は、死後の世界や霊について、考える素養が出来たと思う、当時は小学生なので、凄く怖いだけだった。

これら、スピリチュアル系の話は、技術系ブログでは、敬遠され、扱わないのがセオリーとなっている。
地球の科学が全て、目に見える物が全てと信じて疑わない人は、「おまえは、そんなありもしない話を本気で信じているのか?」と言うだろう~。


2025年7月に何が起こるか?

今スピリチュアル系ネット界隈で囁かれているのが、この問題だと思う。
この話のせいで、海外の人が日本への渡航を延期する人さえいると言う。

日本では、夢で見た未来を記述した漫画が基点になっている。
※2011年3月に発生した東日本大震災にも言及していた事で、信憑性が高く、一躍有名になった。

日本以外でも、7月の出来事を警告する人が複数いて、内容的にも奇妙な類似性がある、文化や人種も異なっているのに、偶然で済ますには、何か、釈然としない。

その漫画は、買っていないし、読んでいないので、どのような内容なのか、詳細は知ってはいないが、大雑把に言うと。

  • 2025年7月(5日午前4時18分、これは、夢を見た日付で、発生時刻では無いらしいが錯綜している)
  • 50m級の津波が日本を襲い、かなりの部分が水没する
  • 多くの知識人が、50m級の津波が発生するような地震や地殻の変動は物理的に起こる確率はほぼ無いので、この話はデマとしている
  • 300m級の隕石が落ちる事により発生する津波なら、可能性はあるとしている
  • それでも、超巨大な地震が起きないとは100%言えない

もう一つの可能性

  • 空母タイコンデロガ、1965年の事故
  • 北緯27度35分2秒・東経131度19分3秒(喜界島の南東約150キロ)
  • B43 核弾頭、1発を装着したA-4E攻撃機が海中に転落する事故が発生
  • 現場の水深は約5,000メートル
  • 事故は1981年の国防総省の報告書で明らかにされたが、詳しい場所については1989年に明らかにされた
  • 沖縄近海 A-4 水没事故
  • この事件は、1981年の国防総省の報告書で1メガトンの爆弾が紛失したことが明らかになるまで、公表されないままだった
  • 1981年に一部が公開され、そして、その時点で、「内部では60年後に臨界を迎える」という予測もあるようだが、公開されている資料にはその記述は存在しない(当時はあったが、消されている可能性はある)
  • B43 核兵器は二段式で、最初に核爆弾が起動して、その後、核融合反応で水爆を起動する仕組みのようだ
  • 通常最初の核爆弾の起動は、爆縮型なので、非常に精妙な起動シーケンスを取り、初期の起爆トリガーが正確に行われないと起爆しない
  • まして、5000mの海中で60年経過した核兵器が何等かの理由で点火する事は、通常極めて低いと思われる
  • それでも、100%起爆しないとは言い切れない

地震か、核兵器の爆発か?

  • 現状では、どちらも可能性があり、全く無いとは言えない

未来は固定されていない

  • 一般に、未来は確定している訳ではなく、集合意識によって、変化すると言われている
  • 幾つもの可能性が無数に枝分かれしていて、誰かの思い、行動が、可能性の一つに集約していく
  • 2025年7月の災害は、起こるかもしれないし、起こらないかもしれない
  • それでも、3.11より桁外れに大きい災害が起こるなら、何も対策をしないのは悪手でしかないと思われる
  • 絶対に起こらないから、何も準備をしないと決めて、実際に大きな災害が来たら、「準備しておけば良かった」と思う事だろう

過度に恐れずに、一応備えを

  • 起こらなければ、それに越した事は無いが、備えは、他の災害でも有効となる
  • 地震、火山噴火、台風などの自然災害は、日本で暮す以上どうしても避けられないのだから、普段から備えをする事は重要
  • これらの災害を予測して、準備をする事で、精神が鍛えられ、パニックを避けられるとも思う
  • パニックになったり、自暴自棄になったりしないように、普段から冷静な判断が出来るように精神的な準備をしておく事が必要となる
  • 事前に、何か起こるかもしれないと、心の準備をしておけば、もし起こった際に、パニックにならずに穏やかにやり過ごす事も可能
  • 災害の大きさから考えて、3日くらい電気が止まっても、大丈夫な備えは必要だと思える
  • 水は、1週間位止まっても何とかなるようにしておく必要がある(一人辺り、2リットルペットボトル4本程だ)
  • 電気が止まれば、通信インフラも停止する事が予想されるので、ある程度の現金は用意しておく事が必要だと思える
  • 自家用車を持っている場合は、燃料を満タンにしておく
  • 水、米、海苔、梅干し、カセットコンロがあれば、食事は数日は何とかなる、最低限の食糧と水を確保しておく
  • 電気が止まれば冷蔵庫は数時間で役目を果たさなくなるので、冷凍食品は備蓄にはならない
  • 都会では、電気が止まると、水道も止まると思えるので、事前にお風呂に水を貯めるなどの準備をしておく
  • 山間部で山から水を引いている地域では、電気が止まっても高低差が水圧を作っているので水は止まらないが、塩素消毒はしなくなるので、浄水器は必須
  • 発電機を持っているなら、日頃からメンテを欠かさず、燃料の準備もしておく
  • 暑い時期、エアコンが止まると厳しいので、バッテリーで動く扇風機は必要かもしれない
  • 蚊取り線香も、用意しておく事は重要
  • 要は電気が止まっても、大丈夫な選択肢を用意しておく事
  • 米は長期の保存がある程度可能で、料理も簡単なので、非常に重宝する食料であると思う
  • 現在、米は、価格が高騰しており、入手が困難な場合もあるが、7月に大きな災害があれば、さらに入手が困難になると予想出来るので、ある程度の備蓄はしておく方が良いだろうと思う
  • 米を、布団圧縮袋に入れて、脱酸素剤としてカイロなどを同梱して空気を抜けば、かなりの時間保存する事が出来る

コンロと圧力鍋でご飯を炊く方法

  • 圧力鍋に米を入れます(5合の場合)
  • 米を研ぎます(現在の米は、精米の精度が高いので、簡単に研ぐだけで大丈夫です、無洗米なら洗う必要無し)
  • 5合に対して、水を750cc~800ccくらい入れます
  • 30分位水浸します
  • 中火で炊き(10分くらい)ピンが上がったら3分位で火を止めます
  • ピンが下りるまで蒸して、出来上がり~
  • 海苔、醤油、梅干し、かつお節、ぬか漬け、があれば、美味しく、十分な栄養が取れます

玄米の場合

  • 玄米は、多少時間が掛かりますが、同じように炊く事が出来ます
  • 玄米は、それだけで栄養価が高く、美味しいので、非常食にも良いと思います
  • ただ、よく噛まないと、お腹を下してしまう場合もあるので、日ごろから、食べ方を検証しておく必要があります
  • 少量でもよく噛むので満足感があります
  • 玄米5合を水で洗う
    - 玄米5合に対して、水1リットルを入れる
  • 塩を小さじ三杯程(量は、加減して下さい)
  • 6時間程浸水(最低でも3時間くらいは浸水)
  • 中火で炊き、ピンが上がったら25分炊き、火を消す
  • ピンが下がったら出来上がり
  • 塩を入れてあるので、ゴマをかけるだけでも十分に美味しい
  • 玄米は完全食に近く、足りないのはビタミンC位、海苔で補えます

3.11 の経験談を活用しよう

  • 3.11 で起こった事象に対する知恵は有益な物が多く、それを学び活用しましょう
  • 水分補給は、ペットボトルを用意してあれば十分です
  • 問題は、トイレです(水が無いと、流せないので、お風呂に水を貯めておく事が重要です)

近くの人や、近隣のコミュニティーで協力をして乗り切りましょう~

  • 普段から、近隣住民とコミニケーションを取っておく事が重要です
  • 都会では難しい事もありますが、相互に助け合う事で、困難を乗り切れます
  • 自分が出来る事、出来ない事を理解して、冷静な判断と助け合いが重要です

何も起こらなければ、それが一番良いですー

WR250Xで見知らぬ林道を巡る

google map を観ていて気になった

国道411号線の柳沢峠にある市営駐車場に林道の入り口がある。
※411号、柳沢峠の先、塩山方面は、非常に整備されたワインディングで中高速コーナーの連続なので、わざわざ林道に行くのは一部の変態だけとおもうけどw

google map で確認すると、途中で道は途切れていて、行っても引き返すだけと思っていた。
だけど、航空写真で見ると、どうやら続きが出来ており、どこかに抜けられそうだと思っていた。
※3月の終わりころ、行ってみたら、ゲートが締まっていて、冬季閉鎖だった。
通常、4月末には冬季閉鎖は解除されるので、もう一度トライしてみた。


※どうやら、この林道は「竹森線」と言うらしい~

林道とは言え、舗装されており、コンデションもそれ程悪く無く(かなり綺麗)道幅も普通だ(離合は難しいけど・・)。
ただ、落ち葉、コケなどもあるので、走行には注意が必要なのは言うまでも無い。

林道の峠からは富士山が良く見える

※発電機が映っているが、違法無線の監視を行っていた。

この林道、殆ど車を観ないので、あまり知られていない&利用する人が極端に少ないと思えるのだが、最近開通した部分が非常に綺麗な舗装で、かなり楽しい!

軽量バイクの為にある舗装林道だ!と思える程

峠を越えると、下りになる、それなりに長いし、コーナーも多いし、面白い!
対向車は少ないとは言え「ゼロ」では無いので、ブラインドでは、カーブミラーで確認、スピードのコントロール、など最新の注意は必要。

ある程度降りたらT字路にぶつかり「竹森線」は終了

T字路は、「鈴庫山線」に接続している。
左は、「塩山方面」で、県道207号に接続していると思う(今回、そちらは試していない)こちらの道はかなり新しい~
右は「三富方面」で、国道140号に接続しているようだ。

三富方面は途中分岐がある

この方面にも「峠」があり、やはり富士山が綺麗に見えるポイントがある。
そして分岐がある。
右に上がる道も国道140号に接続している(民芸茶屋 清水の辺りに接続する)が、終盤、細くて、かなり荒れた林道が2キロ位続くので、あまりお勧めは出来ない(軽自動車なら大丈夫だが、乗用車だと難儀するかもしれない)

直進して、ゲートを過ぎると直ぐに道が細くなり、多少荒れている、さらに進むと、途中、舗装されていない道が数百メートルあるが、まぁ何とかなる(リッターバイクとかだと多少キツイかもしれないw)

そして、国道140号に接続する

国道140号から、国道411号に行くには、通常なら、フルーツラインを通って行くのが王道だと思うが、この林道経由で行く事も出来る。
ただ、林道スキー以外にはあまり刺さらないと思うケドw、道が綺麗で長くて楽しい!(途中の悪路はご愛敬w)

久しぶりの県道31号

帰りは、140号を通り、久しぶりに県道31号を楽しんだ~
140号側からの登りは、道幅も広く、中速コーナーも多く、それなりに楽しい。
「太良峠」から下りは、道幅は狭い場所も多く、注意を要するが、広くて綺麗な舗装の区間もあり、かなり楽しめる。
武田神社を過ぎると、街中で、信号も多く、平均速度も下がるけど、ここは我慢して、なるべく空いた道を選んで、国道20号まで出た。

国道137号から県道708号、御坂峠へ

国道20号から、国道137号に入って、セブンとエネオスが合体したスタンドでガソリンを補給した。(6リッター)

国道137号を富士吉田方面に行くと、途中、長いトンネルがあるが、その手前で、トンネルを使わない峠道(県道708号)がある。
県道708号も、峠まで登ると狭いトンネルがあり、抜けると、「天下茶屋」を通り過ぎ、少し降りた処に、林道西川新倉線に分岐する処がある。
ここは、少し進むと、登山客が多く利用する駐車場があり、そこを抜けて進む。
しばらく登ると、ビュースポットがある。

富士山河口湖ビュースポット

通常、午後は、富士山に雲がかかり綺麗に見えない事が多いが、今日は、風が強く寒いくらいで、雲が掛かっていなかった。

何故かゲートが閉鎖されていた・・・

この林道は、富士吉田市内に抜ける事が出来る、しかし「増田誠顕彰碑」の近くにゲートがあり、閉鎖されていた・・・
えーーー、ここまで来てーーー・・・
ゲートの右の隙間を無理やり通れば、250のバイクなら抜けられそうではあったが、失敗した場合、谷に落ちそうだった為、自重して、結局戻る事にした・・・

県道708号まで戻り、県道を下り(そこそこ道が良く、車はいなかったので、楽しい!)
国道137号まで戻り(トンネル出口付近に合流する)市内に行く。
本当なら、もっと速く市内に着いたハズなのに40分くらいロスした・・・

沼津魚がし鮨 流れ鮨 富士吉田店

少し遅いが、朝飯が遅かったので、昼食相当w
値段はそれなりに高いが、ネタが良いので、行ってみたかった。
普段食べた事が無い、白身系のネタを数種類食べた、中々美味しかった~
※4毒(小麦、植物油、乳製品、甘い物)を抜いているので、外食は、かなり限られる。
まぁ寿司も、砂糖はそれなりに使っていると思うけど、「良し」としている。

最後に「北口本宮冨士浅間神社」に参拝

参拝して、折角なので、「御朱印」を賜った。

参拝した時間は4時を過ぎていたが、参拝して大月に戻った。

まとめ

今日は、天気は良いものの、風が強く、少し肌寒かったが、中々充実したツーリングだった。
WR250Xも、タイヤ交換して、安心感があるが、α13は、加重をちゃんとかけなとグリップしない感じがある。
※加重が抜けると滑るようだ、注意しないと・・・

それと、ブレーキの握りに違和感がある。
握ると少し、ギシギシする・・・
マスターシリンダーをOHすれば直るのか?
又は、マスターを交換する事になるのか?
少し調べないと・・・

WR250X のタイヤ交換(中古 α13-SP)

 久しぶりのタイヤ交換

バイクに乗る機会が減った為、前回から2年以上経っている。
α-14 は、スリップサインが出て、そろそろ限界に近く、交換時期となっている。
※何故か、フロントが 110 では無く、120 サイズとなっていた?

中古の α13-SP に組み替え

2年くらい前に、もて耐で使っていた (CBR250RR) タイヤを貰っていた。
ちょっと時間が経ちすぎて、少し硬いが、まぁ街乗りなので問題無いだろうと思ってる。
これから暖かい時期でもあるし、何とかなるだろう~
※最近の流行りは、ダンロップなら「Q5」とかだろうと思うが、前後入れ替えるとそれなりの金額になる。

レースでは、3~4時間くらい使ったら、美味しい部分は無くなっているので、交換するのは割と常識となっている。
「山」はまだ十分あり、どちらかと言うと中心よりサイド側が減りが多い。
リッターバイクなどパワーがあるバイクだと、リアのセンターはそれなりに減るが、250cc の場合は、それ程センターに負担がかからない。

中古とは言え、一応レース用タイヤなので、ちゃんと温めれば、街中でもそれなりに食うと思う。
まぁ、ガチで峠を攻めたりしないので、十分だと思えるw
路面がぬれていたり、急な雨とかだと、多少危ないが、十分注意していれば大丈夫。
※これは当然自己責任の範疇

DUNLOP SPORTMAX α13-SP

前後 サイズ 扁平率 直径(インチ)
フロント 110 70 17
リア 150 60 17

リアが、150/60 だが(標準は 140/70)WR250X の場合、ギリで、チェーンに当たらないので、何とか大丈夫な感じ。
扁平率が 60 なので、多少乗り方を調整する必要があるかもしれない。


 フロントの交換でやらかした・・・

中古で硬たかったので、意外に苦労した。
そして「やらかす」、硬かった為、十分に潰せていないのもあって、フロントを組んだ時、タイヤレバーでチューブを挟み、パンクさせてしまった・・・
※組み終わって10分もしたら「ぺしゃんこ」になってた・・・
組む時、少し空気を入れておけば、避けられたミスだった・・・

しかし、以前にリア側でタッピングビスが刺さってパンクした時、チューブを買ったのだが、フロント・リアのセットだったので、フロントの新品チューブが余っていた。

しかし、フロントのビードが中々上がらない~


関係トルク、組付けの要領

箇所 トルク (N/m)
フロントホイール・アクスルナット 63
フロントホイール・アクスルピンチボルト 23
フロントブレーキ・キャリパーボルト 23
リアホイールアクスルナット 125
  • ディスクローター側のカラーはツバが付いた物、反対側がストレートのカラーなので、間違わないようにする。
  • ピンチボルトは、2本なので、締める場合、均等に少しづつ締める。
  • フロントのアクスルナットを締める時、供回りする場合、右側のピンチボルトを軽く締めて供回りを防ぐ。
  • 左側アクスルナットを決めたら、右側のピンチボルトを緩めて、フロントホークをフリー状態にして軽く上下させ、センターを出す。
  • センターを出したら、ピンチボルトを締める(この工夫で、フロントホークの中心が出て、スムーズに伸び縮みする)

少し走ってみた感じ

組付けが終わって、少し周辺を走ってみたが、少し硬い感じがする。
空気圧のせいもあるかもしれないが、レーシングスピードを維持する訳では無いので、少し強めに入れておいた方が良さそうと思う。
ほとんど寝かしていないので、グリップは判らない、週末、天気が良さそうなので、峠にでも行ってみようと思う。


やり残し作業

  • ブレーキオイルの交換
  • ブレーキパッドの交換(残 1mm くらいしか無い)

250 は軽いので、ブレーキパッドはあんまし減らない、しみったれているが、後 100 キロくらい走ってから交換しようと思う。
※純正パッドを購入済