ラベル misc の投稿を表示しています。 すべての投稿を表示
ラベル misc の投稿を表示しています。 すべての投稿を表示

CKLauのブザー音をなんとかしてみる。準備編

 ゴールデンウィークに届きまして、調子良く動いてくれてますCKLauの4ポートHDMI KVMですが、ポート切り替え時に鳴るブザーの音がけっこう耳障りです。

かん高いピーっという音と音量が結構うるさい。なのでこれをマイルドな感じにできないかと開けてみました。


ひっくり返すと赤丸の4箇所にネジがあります。これは2番の+が必要です。左のシールは製造年月表示なんですが、ピンセットで持ち上げたら破れました。でもどうせマークされていないので気にしません。

開けてみると中はシンプルです。


シルクが天地逆ですが、右端にあるのがブザーです。マグネチックブザーというタイプで、型番はTMB12A05。定格は5V/30mAで音圧が85dB以上、周波数2300±500Hz。駆動信号を与えるのではなくて、電流を流してやれば自己励振して発音するようです。周波数低めの音の代替製品があればいいのですが、村田製作所などの圧電ブザーは3.6kHzとか。

自作するならNE555で無安定マルチバイブレータ作って、出力でトランジスタを駆動してスピーカを鳴らすといい音がするかもしれません。

ちなみにこの回路では発振周波数は480Hzくらいになるので、いわゆるA音(A3)の 440Hz よりは高めですが、どうでしょうか。鳴ればいいだけなら圧電スピーカを使うほうが安上がりですね。

その他の方法はというと、ブザーのケースを壊せば音は小さくなるかなとか、穴塞げばいいかなとか。

ついでに KVM スイッチの本体である LSI ですが、写真中央部の四角い QFP チップで、GSCoolink GSV2007 とあります。検索してみると、HDMI 2.0 RX4/TX1 で HDCP非対応のようです。

また左上の USBコネクタ付近の正方形のチップはRealtek RTS5411 USB3.0ハブコントローラです。


裏面。

左上に4つ並んだ IC は中央2つが無印、両側が WCH CH551G で E8051コアの1チップマイコンのようです。また、右上の正方形の IC は WCH CH559L で、これも E8051コアのUSBホストコントローラ。

結構しっかり作られてる感じです。

現在のところ不満点は切り替え時の音だけですが、NE555のマルチバイブレータ自作キットが AliExpress で送料込300円くらいであるんですが、どうしようかなぁ。

CKLauのUSB3.0+HDMIのKVMスイッチ。

これまでのメイン PC(Core-i9 9900K)と新しいメイン予定の PC(Core-i7 12700K)、それにテレワーク用の PC と、PC の切り替えが大変になってきたので、これまで使っていた 2ポートの KVM スイッチから、新しく 4ポートのKVMスイッチを検討することにしました。

現在使用しているのが、corega の CG-PC2KDLMCA という DVI 2入力1出力のものです。これは Amazon で2010年2月に購入したもので、なんと12年も使っていたことになります。

途中、ACアダプタのケーブル断線?で調子が悪くなり、同等仕様のアダプタ(5.3V)を購入しています。サンワサプライの P-VGA-AC4で、5.3V/2.4Aというもの。CG-PC2KDLMCA はもともと ATEN CS1782A のOEMで、ボタンデザインなどがちょっと変わっているだけのものです。サンワサプライからも ATEN OEM の KVM スイッチが出ているので、アダプタも互換なのでした。ただ、ATEN からファームウェアアップデートがあったときに適用できなかった事はありました。もともと DVI-D のデュアルリンクで 2,560×1,600@60Hz の能力があったので、2560x1440@60Hzの IO-Data GigaCrysta EX-LDGCQ271DB にも対応できていました。なにげにすごいやつです。しかも HDMI オーディオも通していたので、モニタ側スピーカ(音はヘロヘロですが)からも HDMI 接続だけで音が出ます。

今では PC のマザーボード出力から DVI がほとんどなくなり、モニタ側の入力も HDMI か DisplayPort のみになってきていますが、幸い信号的には DVI と HDMI はほとんど互換なので、DVI-HDMI ケーブルを用意することで使用できていました。


と、能書きが長くなりましたが CKLau です。Amazon で購入しました。


届いた箱を開けたらこんな感じ。ごちゃごちゃ詰まってます。ケーブルを巻いてあるポリが擦り切れたのでしょうか、ちょっと裂けていますが、問題はありませんでした。


ケーブルはこんな感じ。


アダプタの箱が潰れています。これも箱だけで中身はちゃんとしてました。


上の写真の細長いダンボールの中に本体があります。ちなみにアダプタは USB 出力のもので、5V/2.0Aでした。



表と裏。USB 3.0 の B タイプで、二段重ねのやつです。左端に電源スイッチとアダプタジャック、それに有線リモコン用の USB miniB のコネクタがあります。ちなみに箱から出した写真のリモコンの隣りにある青いスリーブのケーブルが miniB です。

日本だと製造銘板があって、消費電力が明示されているのですが、この製品は Made in China と CE、FCC、RoHS、それに製造年月日を表すシール(ただしマーキングしてないのでいつ製造されたのか不明)しかありませんでした。ついでに言えば、型番もないようです。型式番号がないのにどうやって輸出通してるのかしら。ちなみに、箱には "Model: CKLau-64HUA-3N" と書かれたシールが貼ってありました。それはともかく、あとでワットチェッカーで電力測ります。


ケーブルは HDMI と USB 3.0 が各 4 本。1本にまとめているのではなく、2本ずつ束ねて使うようです。しかも長さが違っています。

HDMIケーブルはコネクタの内側(ケーブル部分のみ)で 140cm、一方 USBケーブルは 170cmと、30cmも違います。これはびっくり。しかも、現在のデスク周りの配置だとメイン PC にぎりぎり届かない感じ。PC を動かしての作業などがあれば確実に届きません。これはちょっとまずいので、急遽ケーブル調達。Amazon Basicsの 1.8m USBケーブルとHDMI 2.0ケーブルを3本ずつ購入しました。なぜ3本ずつかというと、HDMIケーブルが2本セット(1,206円)と3本セット(1,207円)で1円しか違わなかったので、どうせなら3本にしてしまえという、あまり良く考えていない理由。


これをコードプロテクターという名前の、ワイヤ織管ケーブルスリーブで包んでいきます。これも Amazon で購入してたものです。

とりあえずメイン系のタワー型2セット分を新規購入のケーブルで、残り2セットを添付のケーブルで組んでセッティングしてみます。

セッティングが終わってワットチェッカーを見てみると、表示が01。消費電力1Wと出ています。このあたりの数値は精度的にちょっと微妙なところなのですが、PCサスペンド時には04(4W)とか出ているので、でたらめな数値ではなさそうです。

……とここまでやって、計測も終わったからとアダプタをワットチェッカーから抜いても、スイッチは動作しっぱなし。そりゃそうです、USBからも給電されてるのですから。

ともあれ、どうやらちゃんと動いてくれているようです。もともと4K対応ということですから、WQHDごときは屁の河童なのでしょう。

機材もないので、アイパターンのチェックとか CEC の波形確認とかはしていませんが、無事使えましたということで。

あとは、機能としてはホットキーで切り替えもできるし、有線リモコンでもできるということですが、キーボードの向こう、モニタの下に本体を設置しているので、ホットキーは無効、リモコンは使わないので箱の中にしまっておきます。

ともあれ、これで4ポートKVMが動きました。ユーザレポートも少ないようなので、購入を検討されている方の参考になれば。

PaSoRiでe-Taxしてみる。

実は去年もやったのだけれど、PCの環境をクリーンインストールしてしまったので改めて備忘録。

PaSoRi(RC-S380)を使用してWindows PCからe-Taxするための準備と手順をまとめておきます。

  1. PaSoRiを接続する前に、NFCポートソフトウェアをインストールする。
    現在のバージョンは2019年6月17日のVer.5.6.9.0です。
    NFCポートソフトウェアのインストールガイドによれば、NFCポートドライバ、FeliCa Secure Client Ver.2.0、NECポート自己診断、NFC Proxy Serviceの4つのソフトウェアがインストールされます。
    インストールが終わったら、PaSoRiをPCに接続して正常に認識されていることを確認します。
  2. e-Taxを利用するために、PC/SC アクティベーター for Type Bをインストールする。
    現在のバージョンは2017年12月25日のVer.1.3.0.2です。
    PC/SC アクティベーター for Type Bのインストールガイドに従ってインストールします。

e-Tax(WEB版)はChromeやFirefoxなどは対応しておらず、Internet ExplorerもしくはEdgeのみから利用できます。ここではEdgeを使用して進めます。
  1. e-Taxソフト(WEB版)又は受付システムを利用するに当たって
    のページをEdgeで開きます。
  2. 手順1と2を確認したあとで、手順3の「電子証明書の取得」を行います。電子証明書の取得は、マイナンバーカードを使用する場合には公的個人認証サービスから電子証明書を取得します。
  3. マイナンバーカードをすでに持っているものとして先に進みます。マイナンバーカードは居住地の市区町村で交付されるため、引っ越しした場合には作り直す必要があります。
  4. STEP4の利用者クライアントソフトのダウンロードに進み、Windows版ソフトのダウンロードとインストールを行います。JPKIAppli03-03.exeというファイルがダウンロードされるので、これをインストールします。
  5. 利用者クライアントソフトの利用方法(Windowsをご利用の方)で使い方を確認します。まず、インストールされたJPKI利用者ソフトを起動します。
  6. 上記の画面から「自分の証明書」のボタンを押します。すると次のダイアログが表示されます。
    「署名用電子証明書」を押すとパスワードを求められるので、これを入力します。また、「利用者証明用電子証明書」を押すとこちらもパスワードを求められます。パスワードはそれぞれ異なるため、電子証明書の申請時のものをしっかり管理しておきます。電子証明書自体は地方公共団体情報システム機構より発行されますが、その手続きは市区町村窓口にて行いますので、予め申請して取得しておく必要があります。
  7. ここまでやったら、e-Taxのサイトから「e-Taxをご利用になる場合の流れ」の「5 各種ソフト等のインストール及び設定 申告書・申請書の作成・送信」のところから「確定申告書等作成コーナー」をクリックします。
  8. すると、国税庁 確定申告書等作成コーナーに飛びますので、「作成開始」をクリックします。
  9. 別のEdgeウィンドウがポップアップするので、「e-Taxで提出 マイナンバーカード方式」をクリックします。すると、「e-Taxのご利用のための事前準備を行います」というページに飛び、e-Tax Edge用APが必要なのでインストールしてくださいとの画面が出ます。このソフトはEdgeの機能拡張としてMicrosoft Storeからインストールされます。これをインストールし、ダイアログが出てくるので「有効にする」をクリックします。
  10. e-Tax Edge用APをインストールすると最初のページに戻るので、再度「確定申告書等作成コーナー」をクリックし、続いて「作成開始」をクリックします。別ウィンドウがポップアップするので、「e-Taxで提出 マイナンバーカード方式」を再度クリックします。すると「e-Taxのご利用のための事前準備を行います」というメッセージが出てくるので、その下の「事前準備セットアップファイルのダウンロード」をクリックします。
  11. またまた別ウィンドウが開き、「令和元年分事前準備セットアップ」をクリックすると、jizen_setup.exeをダウンロードして実行するように促されます。インストールが終わったら再々度「e-Taxで提出 マイナンバーカード方式」に進みます。右下に「利用規約に同意して次に」のボタンが出るのでクリックします。
  12. 「マイナンバーカード認証」のページに飛びますので、PaSoRiにマイナンバーカードを載せてから「マイナンバーカードの読み取り」ボタンを押します。すると「利用者証明用パスワード」の入力を求められるので、入力します。
  13. OKボタンを押して次に進むと登録されている情報が表示されるので、間違いないことを確認して次に進みます。「令和元年分の申告書等の作成」を選んで「所得税」の確定申告書を作成していきます。

あっちに行ったりこっちに行ったり大変ですが、こんな感じでようやく確定申告書の作成を開始できるようになりました。

SVT-AV1を使ってみる。

昨年Core-i9 9900Kでシステムをひとつ組んで、Windows10 Proでエンコードなどの処理をメインで行うようにしました。Quick Sync VideoによるハードウェアアクセラレーションでH.264のエンコード速度が非常に早くなり、フィルタのかけ方によっては150fpsを超えるような速度でエンコードできるようになりました。

それはさておき、最近ではSVT-AV1(Scalable Video Technology - AOMedia Video 1)というのが話題になっていたりして、rigaya氏のサイトでもguiExを提供されているので、ちょっと手を出してみました。AOMediaというのはAlliance for Open Mediaの略称のようで、MPEG LAによるライセンスを回避してロイヤリティフリーの技術とすることを目的に設立されているようです。

AviUtlにsvtAV1guiEx 0.00 beta2を組み込むところは省きます。そして "-enc-mode 3" で短いソースをエンコードしてみると、9900Kでもエンコード速度は4fpsとすごい値になってしまいました。実時間の約7.5倍です。さすがに結構辛いものがありますが、それはともかく、ビデオエンコード後の音声マルチプレクスを行うMP4BOXで問題が発生。バージョンが古くてAV1フォーマットに対応していないため、MUXできないようです。

ということで検索すると、最新のMP4BOXはGPAC 0.8.0のようです。バイナリはhttps://gpac.wp.imt.fr/downloads/で提供されているので、ここからWindows 64 bitsをダウンロードします。EXE形式のインストーラファイルですが、7zで展開するとファイルが取り出せますので、ここからmp4box.exe、js.dll、libcryptoMD.dll、libsslMD.dllをパスの通った場所(というかmp4boxと同じ場所)にコピーします。

これで mp4box -add [ソース1] -add [ソース2] -new [出力mp4] などとすればMP4コンテナに出力できます。

バジルの種類。

技術とは全然関係ありませんが、どこかにメモしておかないと忘れてしまうので。

バジルについてです。


通称 現地名 英語 学名 メモ
ホーリーバジル ガパオ
トゥルシー
Holy Basil Ocimum tenuiflorum ハーブ茶、炒めもの、
アロマオイルなど
タイバジル
タイスイートバジル
ホーラパー Thai Basil
Horapha
Asian Sweet Basil
Ocimum basilicum ゲンキョワーンとか
シャムクイーンバジル Siam Queen Basil Ocimum basilicum
台湾バジル 九層塔 Taiwanese Basil Ocimum citriodorum
レモンバジル Lemon Basil Ocimum citriodorum サラダとか収穫後、オリーブオイルを
絡めて冷凍保存
マンモスバジル
スイートマンモスバジル
Mammoth Basil
Sweet Mammoth Basil
Ocimum basilicum 松の実、オリーブオイル、にんにく、
チーズとあわせてバジルソースに
ジェノベーゼバジル
スイートバジル
Genovese Basil
Sweet Basil
バジルペーストとか炒めもの
パープルラッフルバジル Purple Ruffles Basil Ocimum basilicum カリフォルニアの赤紫蘇?
酢に漬けると赤くなる
シナモンバジル Cinnamon Basil Ocimum basilicum カリフォルニアの青じそ?
ハーブビネガーなど

風車の速度。

知人と話をしていて、ちょっと風が強いね、あの風車ものすごい勢いで回ってるね、という話から、江東区若洲あたりの風力発電設備のタービンの話になりました。

若洲風車の施設案内によれば、風車はドイツのノルバデックス社製で、モータの高さは地上 60m、タービンブレードの長さは 40m とのこと。

以前に若洲に行ったときに実測したところ、風速 10m 程度で 1 分間に 17 回転。17rpm です。

すると円周は\(40\times 2\times\pi=251\)m。これが17rpmなので、時速になおすと\(251\times 17\times 60\div 1000=256.35\)km/h。地上20m の位置を、ブレードの先端が 250km/h のスピードで通り過ぎるわけです。

記憶によればこのときはそれほど強い風が吹いているというわけでもなかったので、もうちょっと強い風が吹くと簡単に 300km/h 以上になりそうです。

ちなみに風速 25m/s で回転は停止するそうですが、そのときには 30rpm くらい(2秒で1回転)くらいはしてるんでしょうか。計算すると先端速度は 450km/h を超えます。

至近距離でそれだけの速度のものを見ることができるのはここかもしれません。

電気シェーバーの手入れ用オイル。

手入れ用のオイルやグリースはいろんな種類があります。

一般の家庭では、たぶんいちばん身近なものはミシン油でしょうか。あとは潤滑油という分野では CRC 5-56 あたりかも。5-56 は自転車乗り界隈では「緊急時以外は使ってはいけない」潤滑油として有名です。チェーンルブやベアリングのグリースを溶かして落としてしまうので、うちでは一切使っていません。固着したネジやナット部分にスプレーしてしばらく置くと浸透して緩めやすくなるので、そういう用途ではいいでしょう。ただ、揮発しやすいので長期的な潤滑はまったく期待できません。

それはいいとして、電気シェーバー用のオイルです。オイルなのにひげそりのような敏感な用途に使ってもいいんだろうかと思って成分を見てみたら、流動パラフィンと書いてありました。
最も身近な物がベビーオイルである。常温では無色の液体で非揮発性。水には不溶。化学的に安定な物質で、通常の条件では酸化を受けない。成分については固形のパラフィンよりオレフィン系炭化水素に富む。乳化しやすくのびや浸透性に優れる。純度は紫外光の吸光度により計測される。
たしかに、ベビーオイルも「オイル」という名前です。なるほど。それならカミソリ負けしやすい敏感肌でも大丈夫そうです。となると、パナソニック純正のシェーバー用オイルが 50ml で数百円しているのですが、ジョンソンベビーオイルでも兼用できるということですね。

WindowsロケールをUTF-8にして不具合のあるアプリ。


Windowsの設定で UTF-8 をデフォルトにすることができるようになって 1 年以上が経ちますが、ここらへんでどういうアプリに影響があるかを自分の使ってる範囲でまとめてみます。

地域と言語の設定で「システムロケールの変更」をクリックすると、「地域の設定」ダイアログが出ますが、そこに「ベータ: ワールドワイド言語サポートでUnicode UTF-8を使用(U)」という項目があります。これは昨年の11月14日のInsider Previewで出てきたようです。/.Jより、Windows 10のInsider PreviewでシステムロケールをUTF-8にするオプションが追加されるによれば、
  • 圧縮 (zip形式) フォルダーにファイル名がUTF-8で保存されるようになった。これに伴い、シフトJISに含まれない文字を使ったファイル名も普通に保存できるようになった。
  • コマンドプロンプトのコードページが既定で65001(UTF-8)になった。このときのWindows標準コマンドのメッセージは英語になる。
  • メモ帳のテキストエンコーディングがUTF-8になった。なお「ANSI」を選んでもUTF-8で保存されるので、シフトJISでの保存はできなくなる模様。
  • GetACP()の戻り値も65001になる。WideCharToMultiByteなどでCP_ACPを指定したときも、UTF-8に変換される。
だそうです。

影響のあるアプリ

明らかにメニューやダイアログが文字化けして正常に使用できないものです。
  • TeraTerm: ダイアログ、メニューバーなどほぼすべての日本語部分が文字化けする。ソースレベルでリソースファイルが ShiftJIS となっている。
    追記(2019/5/14): teraterm\lang\Japanese.lng を UTF-8 に変換してやればGUIの文字化けは解消される。
  • Python 2.7: コンソールでの文字の扱いでおかしなことになる。例: print "あ" で止まる。
  • Python 3.6: Python 2.7 と同様におかしなことになる。例 print("あ")
  • Python 3.7: Python 2.7 と同様におかしなことになる。例 print("あ")
  • cmd.exe: フォントがデフォルトの Consolas だと文字化けする場合がある。現在は修正されている?ただし、dir /?などのヘルプ関連はすべて英語になる。これは PowerShell も同様。
  • Becky! 2: 表示はできるが、自動振り分けで失敗する。
  • 筆王 Ver.23: スプラッシュスクリーンは表示するが起動しない。インストールも失敗する。
Python については、PYTHONIOENCODING=utf-8 を環境変数に設定してやればよいという記述も見たのですが、どうもうまくいきませんでした。どちらも IDLE が起動しません。コマンドラインから起動してみると、
UnicodeDecodeError: 'CP_UTF8' codec can't decode byte 0x8c in position 23: No mapping for the Unicode character exists in the target code page.
というエラーが出るので、ダメ文字関連(ShiftJISの2バイト目が '0x5c' の文字 - 'ー ソ 十 表'など)でしょうね。特にメニューに「表示」などが使われるとてきめんです。

影響のないアプリ

外見上は影響がないように思えるのは以下のものです。
  • 秀丸エディタ
  • Visual Studio Code
  • Notepad++
  • Neovim: ロケールを ja_JP.UTF-8 と設定してやれば GuiFont に日本語フォント名が使える。
  • Sylpheed
  • TortoiseHG: 以前はPythonでの不具合があった(LookupError: unknown encoding: cp65001)が、修正されているように見える。
  • FreeCAD
  • LibreCAD
  • Blender
  • Inkscape
  • Krita
  • Canon Digital Photo Professional
  • Adobe Reader XI
  • SumatraPDF
  • CubePDF
  • AviUtl: 以前はメニュー類、プラグインのダイアログなどが文字化けしていたが、(おそらくシステム側で?)修正されている模様。
  • MuseScore 2

ホームディレクトリのドットファイルを整理する。

UNIX 系の OS で、ちょっと悩ましいのは $HOME(ホームディレクトリ)にドットファイルが増えてしまうことです。

ls -a すると表示されるリストの8割以上がドットファイルとか、もう許して下さいな感じです。

% ls -a
.              .aliases~                        .dbus        .hgignore   .profile         .xinitrc              .zshrc~    __pycache__
..             .bash_history                    .dir_colors  .hgignore~  .python_history  .xprofile             Desktop    bin
.ICEauthority  .bash_logout                     .dmrc        .hgrc       .ssh             .xsession-errors      Documents  build
.Xauthority    .bash_profile                    .esd_auth    .hgrc~      .texlive         .xsession-errors.old  Downloads  work
.Xclients      .bashrc                          .gem         .lesshst    .thumbnails      .zcompdump            Music
.Xmodmap       .cache                           .gkrellm2    .local      .thunderbird     .zsh                  Pictures
.Xmodmap.orig  .chrome-remote-desktop-session   .gnupg       .mozc       .vim             .zshenv               Public
.Xmodmap~      .chrome-remote-desktop-session~  .gvimrc      .mozilla    .vimrc           .zshenv~              Templates
.aliases       .config                          .hg          .pki        .wget-hsts       .zshrc                Videos

編集した結果バックアップファイルやらコピーを残してるのやらありますが、まあざっとこんな感じ。もうちょっと整理して数を減らしたいところです。
このときに頼りになるのが XDG Base Directory Specification。それを規格から実装に照らして説明してくれているのがこちら

なので一つ一つやっていきます。環境は Manjaro Linux XFCE 版なので、他のディストロは適当に読み替えてください。

システム

システム側であらかじめ設定されているのは以下の環境変数です。
XDG_SESSION_ID=c5
XDG_RUNTIME_DIR=/run/user/1000
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
また、ユーザ側で設定しておきたいのは以下の環境変数です。
XDG_CONFIG_HOME=$HOME/.config
XDG_CACHE_HOME=$HOME/.cache
XDG_DATA_HOME=$HOME/.local/share
XDG_RUNTIME_DIR はユーザごとに設定される /var/run みたいなものです。デフォルトではユーザIDが振られています。必要なら設定すればよいでしょう。
それとは別に、/etc/xdg に設定ファイルがいくつか置かれています。ただしこれらは ssh ログイン時などには読み込まれないようなので、ここでは置いておきます。
ここでは、お仕着せでシステムワイドに設定する方向で進めていきます。

bash

まずは標準の shell の bash。Manjaro の場合には、次の順序で読み込まれるようです。bash -l -v で確認しました。つまりログインシェルの場合。
  1. /etc/profile
  2. /etc/profile.d/*.sh
    /etc/profile から呼ばれる。アルファベット順に読み込まれる。アプリケーションごとに必要な設定はここ。ロケールもここ。
  3. /etc/bash.bashrc
    /etc/profile から呼ばれる。システムワイドの bash 設定を行う。プロンプトや $TERM の設定はここ。
  4. /usr/share/bash-completion/bash_completion
    もしあれば読み込まれる。Manjaro にはない。
  5. $HOME/.bash_profile
    $HOME/.bashrc を source しているだけ。
  6. $HOME/.bashrc
    ユーザの環境変数とか alias とかいろいろと設定する。
  7. プロンプトが表示されて bash 起動完了。
  8. $HOME/.bash_logout
    ログアウト時に読み込まれる。何もしていない。
  9. /etc/bash.bash_logout
    ログアウト時に読み込まれる。何もしていない。
bash の場合にはユーザごとのドットファイルはハードコードされているようなので、ドットファイル類を .config/bash に移動することは(現状では)できません。ただ、他のアプリケーションのための設定は必要なので、ここでは /etc/profile.d/xdgenv.sh あたりで XDG ユーザ変数を設定するようにすればよいでしょう。そうすることで他の shell からも source することができます。
/etc/profile.d/xdgenv.sh:
# Set user variables based on XDG Base Directory Specification.
#

export XDG_CONFIG_HOME=$HOME/.config
export XDG_CACHE_HOME=$HOME/.cache
export XDG_DATA_HOME=$HOME/.local/share

zsh

zsh では環境変数 ZDOTDIR が設定されているとそこを見に行きます。
  1. /etc/zsh/zshenv
    本来は /etc/zshenv を読みにいく(manページの説明)ようだが、Manjaro では /etc/zsh/zshenv を読みにいく。
  2. $ZDOTDIR/.zshenv
    環境変数 ZDOTDIR が指定されていれば $ZDOTDIR/.zshenv を、指定されていなければ $HOME/.zshenv を読む。
  3. /etc/zsh/zprofile
    Manjaro では /etc/zsh/zprofile の中身は emulate sh -c 'source /etc/profile' となっていて、/etc/profile を読み込む。/etc/profile の読み込むものは bash と同じ。
  4. $ZDOTDIR/.zprofile
    ZDOTDIR が指定されていなければ $HOME/.zprofile を読み込む。
  5. /etc/zsh/zshrc
  6. $ZDOTDIR/.zshrc
  7. /etc/zsh/zlogin
    ログインシェルの場合に読み込まれる。
  8. $ZDOTDIR/.zlogin
    ログインシェルの場合に読み込まれる。
  9. プロンプトが表示されて bash 起動完了。
  10. $ZDOTDIR/.zlogout
    ログアウト時に読み込まれる。何もしていない。
  11. /etc/zsh/zlogout
    ログアウト時に読み込まれる。何もしていない。
ということなので、bash のところで /etc/profile.d/xdgenv.sh を作成していれば、XDG* はそこで設定されます。また、/etc/zsh/zshenv があれば一番最初に読み込まれるので、ZDOTDIR をそこで設定すればいいのですが、ZDOTDIR=$XDG_CONFIG_HOME/zsh とする必要があるため、二重に読み込むことになりますが以下のようにします。
# /etc/zsh/zshenv
# set ZDOTDIR respecting XDG Base Directory Specification
#

emulate sh -c 'source /etc/profile'
export ZDOTDIR=$XDG_CONFIG_HOME/zsh
また、標準ではコマンドヒストリは $HOME/.zsh/histfile に保存されますが、これを $XDG_CACHE_HOME/zsh/history に変更します。コマンドヒストリはユーザ設定なので、これは $XDG_CONFIG_HOME/zsh/.zshrc で設定し直します。
$XDG_CONFIG_HOME/zsh/.zshrc:
HISTFILE=$XDG_CACHE_HOME/zsh/hisotry
zstyle :compinstall filename '$ZDOTDIR/.zshrc'
これで $HOME から zsh 関連のドットファイルは削除できます。

git

0d94427eから XDG_CONFIG_HOME に対応しているので、$XDG_CONFIG_HOME/git/config を使います。

Neovim

Neovim は最初から XDG Base Directory Specification に沿うように作られているので、$XDG_CONFIG_HOME/nvim を利用すれば問題ありません。
ここで、vim からも同じ設定を使えるように init.vim などを記述しておくと、nvim でも vim でも同じように使えます。

vim

vimはちょっとややこしいです。前述の ArchLinux の Wiki に書いてあるように、.vimrc などは基本的にハードコードされています。が、別途 VIMINIT=":source $XDG_CONFIG_HOME"/vim/vimrcを shell の設定時に行っておけば、vim の起動時に $VIMINIT を参照してくれます。
なので $ZDOTDIR/.zshenv に設定しておきます。ここでは vim と nvim の設定を共通にすることを考えているので、あえて $XDG_CONFIG_HOME/nvim/vimrc にします。ただし、undodir などが一緒になると問題があるかもしれないので、そこは別にしておきます。Manjaro の場合には vim は標準ではインストールされていなくて、ex および vi が標準なので、あえて vim をインストールせずに alias vim=nvim するのもアリかもしれません。
# .zshenv

PATH1=$HOME/bin
export PATH=$PATH:$PATH1

export QT_SELECT=5
export GTK_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export QT_IM_MODULE=fcitx

# better yaourt colors
export YAOURT_COLORS="nb=1:pkg=1:ver=1;32:lver=1;45:installed=1;42:grp=1;34:od=1;41;
5:votes=1;44:dsc=0:other=1;35"

# env for locate updatedb for local files.
export PRUNEPATHS="`echo $HOME/.cache/[a-ce-z]*`"
export PRUNEPATHS="`find $HOME -name \".hg\" -printf \"%p \"` $PRUNEPATHS"
export PRUNEPATHS="$HOME/.mozilla $HOME/.dbus $HOME/.thumbnails $HOME/.thunderbird $
PRUNEPATHS"
export LOCATE_PATH=$XDG_CACHE_HOME/mlocate.db

export VIMINIT=":source $XDG_CONFIG_HOME"/nvim/vimrc
また、vimrc は以下の内容にします。
" vim:set et ts=2 sts=2 sw=2 tw=0 fenc=utf-8:
" _vimrc : initialization file for Vim.
" just source init.vim for commonnization.
"
" Modified: 9 Apr 2018
"
source $XDG_CONFIG_HOME/nvim/init.vim

" mswin.vim maps those keys when gui=yes.
" this is terrible and should be unmapped.
if has('gui')
  unmap <C-f>
  iunmap <C-f>
  cunmap <C-f>

  unmap <C-h>
  iunmap <C-h>
  cunmap <C-h>
endif

mercurial

$HOME/.hgrc は $XDG_CONFIG_HOME/hg/hgrc に移動することができます。が、.hgignore はそのディレクトリ以下の ignore ファイルを指定しているため、移動できません。また .hg ディレクトリはリポジトリのため、移動できません。

その他

.ICEauthority

libice が作成するファイルですが、Use XDG base directory instead of $HOME for .ICEauthorityで議論され、パッチがあげられ、2019年3月25日に push されているので、いずれマージされるでしょう。
それまでは触らないでおくか、export ICEAUTHORITY="$XDG_RUNTIME_DIR"/ICEauthority を /etc/zsh/zshenv あたりに入れておけばよいでしょう。ただ、環境変数がやたら増えるのも困りものですから、ここでは放置しておきます。

.Xauthority

同上です。export XAUTHORITY="$XDG_RUNTIME_DIR"/Xauthority

.Xmodmap

対応策はなさそうです。

.dircolors

source "$(dircolors "$XDG_CONFIG_HOME"/dircolors)" を $ZDOTDIR/.zshenv あたりに入れておきます。bash のほうは $HOME/.bashrc のdircolors に関する部分の変更が必要です。

.mozc

移動できません。ソースを見ましたが、XDG_CONFIG_HOME を参照している部分はありませんでした。

.mozilla(firefox)

$XDG_CONFIG_HOME/mozilla と $XDG_CACHE_HOME/mozilla と $XDG_DATA_HOME/mozilla がある場合にはそちらを使うようです。
なので、以下のようにします。
$ mkdir .config/mozilla
$ mkdir .cache/mozilla
$ mkdir .local/share/mozilla
$ chmod 700 .config/mozilla .cache/mozilla .local/share/mozilla

.python_history

Python がインタラクティブモードで起動されると readlline が作成するようです。今のところ移動できません。

.texlive

ハードコードされているようで変更できません。

.thumbnails

$XDG_CACHE_HOME/thumbnails/ があればそちらを使うようです。

.thunderbird

ハードコードされているようで変更できません。

.xinitrc

基本的には DesktopManager(lightdmやgdmなど)を使っていれば xinit を呼ぶことはないので不要なはずですが、export XINITRC="$XDG_CONFIG_HOME"/X11/xinitrc を指定することで xinit は参照してくれます。

.gnupg

export GNUPGHOME="$XDG_CONFIG_HOME"/gnupgすることで参照してくれます。

MultitailをWindows上で動かす。

Nginx を動かす、というのをやっていて、でも access_log と error_log を同時に眺めたい、そういえば multitail ってのがあったな、と思いだして MSYS2 でパッケージないかしらと探したのですが、なかったので自分でビルドしましょうということです。

他にもあると思いますが、Multitail はこちらを参照しました。ソースは GitHub の flok99/multitail にあります。
必要要件として、ncurses ライブラリがあること、とのことですが、MSYS2 ではすでにインストールされていたので問題なしです(実は問題はありましたが)。

まず、gcc があるかどうかを確かめたところ、gcc は入っていませんでした。なので、pacman -S msys/gcc します。
次に make してみたら、ncursesw/panel.h: No such file or directory というエラーが出たので、pacman -S msys/ncurses-devel します。
いろいろと "警告" や "備考" というのが出てきましたが、それだけでビルドは終了し、試してみたらちゃんと動いたのでそのまま使ってみます。

設定などもあるみたいなので、そのへんはまた今度。

秀丸エディタでユニファイドdiffファイルの強調表示。

かなり小ネタですが、わりとよさげな感じにできたのでメモ。

WinMergeなどでディレクトリまるごとの差分をとって、それをユニファイドdiff形式のファイルに保存し、あとから見比べたいとか修正点を知りたいというときに重宝します。


以下のような雰囲気になります。

こうするためにはいくつかの設定を新規で行います。

ファイルタイプ別の設定で新しく「DIFFファイル」というファイルタイプを作って、そこに設定していきます。

まずは「デザイン→強調表示」。正規表現を有効にして以下のように設定します。

次は「アウトライン」ですが、以下のように設定します。
もうひとつ、「アウトライン→解析」です。

基本的にはこんな感じで、あとはお好みで調整すればよいでしょう。

自分のメールアドレスから来るスパム。

自分は WAKWAK にもアカウントを持っていて、Google のアカウントを作る前はそちらがメインでした。メーリングリストやネットニュースなどはそちらのアカウントで利用してたりしたんですが、もうほとんど使っていません。ただ、第2メールアカウントとして念のために残している形です。そのあたりでのメール構成は bogofilterのデータベースの再構築。 でもちょっと触れています。

そして、~/.mailfilter にてふるい分けから生き残ったメールは、すべて gmail のほうに cc しています。

今回、bogofilter をすり抜け、gmail のスキャンにて怪しいと判定されたメールが届きました。

メールヘッダは下記のようになっていました。
Received: from xuqolaze.com (ip116-13.metrotvnews.tv [103.61.116.13] (may be forged)) by xx.wakwak.com (8.15.2/8.15.2/2018-12-07) with SMTP id x2QNvKOQ022049 for <xxxxxx@xx.wakwak.com>; Wed, 27 Mar 2019 08:57:25 +0900
Received: from unknown (56.35.236.179) by mx.reskind.net with SMTP; Tue, 26 Mar 2019 19:45:10 -0400
Received: from [154.42.37.249] by smtp.mixedthings.net with SMTP; Tue, 26 Mar 2019 19:29:30 -0400
Received: from nntp.pinxodet.net [161.31.175.115] by relay-x.misswldrs.com with NNFMP; Tue, 26 Mar 2019 19:29:01 -0400
Message-ID: <EC540080.1D3DBBF0@xuqolaze.com>
発信元のタイムゾーンは -0400 で、これは大西洋標準時(あるいはアメリカ東海岸時間)で、アメリカの東の一番端っことかカナダのケベック州、ブラジルの一部というあたりです。ただ、これがただちにSPAMの送信者かどうかはわかりませんが。

で、本文の冒頭には、
Hello,

As you may have noticed, I sent this email from your email account (if you didn't see, check the from email id). In other words, I have full access to your email account.

I infected you with a malware a few months back when you visited an adult site, and since then, I have been observing your actions. The malware gave me full access and control over your system, meaning, I can see everything on your screen, turn on your camera or microphone, and you won't even notice about it. I also have access to all your contacts.

とありました。まあ、メールアカウントにフルアクセスされたとしても、それうちのサーバじゃないしで済んじゃうんですが。

内容的には「あなたがPCでビデオを見ている様子を、あなたのPCのウェブカムで撮影したので、これをバラされたくなければビットコインアカウントに905ドル振り込め」という極めて幼稚な振り込め詐欺です。

もう一度書きますけど、メールアカウントにフルアクセスされたとしてもそれうちのサーバじゃないのでうちのシステムには入れないし、そもそもうちのシステムにはウェブカムついてないし。
でもって最後に
Filing a complaint will not do any good because this email cannot be tracked. I have not made any mistakes.

If I find that you have shared this message with someone else, I will immediately send the video to all of your contacts.

Take care!
だそうで、まあなんというか。Google のアカウントが侵入されたなら慌てもしますが、これじゃあ慌てろという方が無理のような。

おうちサーバの功罪。

おうちサーバというのは、UNIX系で遊んでいた人にとってみればいわば憧れみたいなもので、自分でドメインを取得してサーバを立てて、メールとかウェブサービスとかどこからでも自宅にアクセスできるとか、まあそんな感じである意味自己満足の世界なわけですが。もちろん、自己満足だけじゃなくて有意義なサービスを提供したりしている人もいるでしょうけれど。

ただ、最近思うのです。おうちサーバの寿命について考えてしまうのです。

おうちでサーバを立てるということは、つまり管理者は自分。持続性はよほどのことがない限り一代限りです。
すると、そのサーバで提供していたサービスも、管理者の消滅とともに消えることになります。たとえそこに人類にとって有益な情報があったとしても。

自分も、憧れだったドメインを取得しておうちサーバを運用していますが、もしや外部のクラウドサービス的なものに切り替えられるならそのほうがいいのでは、などと考えてしまうこともあります。

ブログやWikiなどで書き溜めた情報もたくさんあります。技術的な情報は古くなると相対的に価値は低くなっていくものですが、一方で古い情報がなくなってしまうというのも問題があります。ファンタジー物などでよくある「古くから言い伝えられている禁忌」が忘れ去られて…みたいな感じで。それがいつ、どのような形で必要になるのかは現時点では判断できませんが、可能性ということで言えばどんな情報でも意味がないとは言えないでしょう。

そうすると、おうちサーバはあくまで「技術的な好奇心」を満足させ、あるいは向上させるのには有意義ですが、その成果はどこか永続的な場所に置いておくべきではないか、などと考えてしまうのです。

JIS規格書の閲覧。

JISの規格書は、購入すれば閲覧も部分印刷もできると思います。また図書館にも蔵書されているので、コピーなどもできると思います。が、閲覧だけなら日本工業調査会のページから閲覧できるのを見つけました。検索、拡大などはちょっと使いにくいですが、参考にはなるかと思います。

PaSoRiでe-Tax。

確定申告をe-Taxで終えたので、やったことのメモ。

  1. まずPaSoRiを用意します。
  2. PaSoRiをPCに繋がない状態で、SONYのサイトから、NFCポートソフトウェアをダウンロードしてインストールします。
  3. PaSoRiをPCに繋ぎます。
  4. 公的個人認証サービスポータルサイトの利用者クライアントソフトをダウンロードしてインストールします。
  5. e-Taxのページから国税庁確定申告書等作成コーナーに飛びます。
  6. 「作成開始」→「e-Taxで提出する」→「マイナンバーカード方式により提出する」と進みます。

あとは画面に従って進んでいきますが、はじめてe-Taxで申告する場合には途中で利用者識別番号(16桁の数字)を申請するようになります。これはその場で取得できますが、今後も必要になるものなので忘れないようにしておきます。また6桁の納税用確認番号を指定するので、これも忘れないようにしておきます。こちらの納税用確認番号は一時保存などを行った場合に必要になると思われますが、今回は取得しただけで使わなかったため詳細は不明です。

鉄製品の錆落とし。その2

鉄製品の錆落とし。では、サンポールを使ったらどうなるのかをちょっと考察してみたわけですが、サンポールの主成分である塩酸は酸化力が非常に強く、錆は落とせてもそのあとすぐにまたオレンジ色の錆が出てきてしまうため、洗浄後はよく水で洗いでからすぐに水置換性のオイルを塗るなどの対策が必要です。

一方で市販の液体錆落としはリン酸を使うものがけっこうあるようです。モノタロウなどで扱っている鈴木油脂工業の液体サビおとし S-012などがそうで、リン酸とグリコール系溶剤、非イオン系界面活性剤が成分です。

リン酸によって錆を落とすと、その後リン酸鉄の被膜が表面にできるためにすぐには酸化しにくくなります。この皮膜を生成する処理を「リン酸塩皮膜処理またはパーカライジング」といいます。

そういえば小学生の頃、御徒町にあったMGCのモデルガンショップでガンブルーという小瓶の液体が売られていて、それを購入してモデルガンに色付けしたことがありますが、たぶんそれもリン酸の水溶液がベースとなっていたのでしょう。このとき生成されるのがリン酸第一鉄で、酸素に触れると黒鉄色に変化します。

大きいものや錆を落としたい鉄の量が多いときには廃糖蜜を使うといいようです。
大きいペール(漬物用の樽など)に廃糖蜜を1:10で水で薄めたものに、錆びた鉄を数日から数週間浸けておくことで錆が分解されリン酸塩皮膜が形成されます。廃糖蜜はサトウキビやテンサイなどから砂糖を精製したあとの副産物で安く手に入ります。

ボール盤とバイス(万力)、ちょっとどうなのよというくらいに錆びてしまったのがあるので、近いうちに錆取りしてみようと思います。さすがに廃糖蜜を使うのは場所もないので、上記の液体サビおとしを使って、モルタルを練るのに使ったトロ舟で刷毛塗りしてしばらく放置してからやってみようと思っています。

ETCマイレージ。

ふと気になったのでメモ。けっこう高速自動車道の料金も変わってきているようなので。

ソースは平成28年4月1日から、首都圏の高速道路料金が変わりました

まず首都圏の高速道路料金から。平成28年(2016年)4月1日から首都圏の高速道路料金の計算方法が変わる(他の路線と同様になる)こと、ただし当面は緩和策として旧料金を上限とすること、ETC2.0搭載の場合には料金割引を導入することがアナウンスされています。

たとえば中央自動車道の均一区間(起点の高井戸ICから八王子ICまで)では、
  • 都心発着の場合: 旧料金が620円 → ETCはそのまま620円、ETC以外は980円
  • 都心通過の場合: 旧料金が620円 → ETCおよびETC以外ともに980円
となっています。ここでいう都心は首都高速と外環道のことです。また通過とは、中央道(均一区間)から首都高速を経由して東北道など別の路線に入ることを言います。

で、よくつかう国立府中から首都高9号木場出入り口では、
  • ETCなし: 2280円(980+1300)
  • ETCあり: 1440円(620+820)
  • ETC深夜割引: 1250円(430+820)
となります。中央道区間は17km、首都高区間は20.6kmになります。


また平日朝夕割引と休日割引は首都圏近郊なので対象外です。


ETCマイレージ、首都高速はマイレージサービスをやっていません。が、NEXCO中日本はけっこうポイント付与率が高いようですね。支払い金額の10%のポイントが付与されます。
ポイントの還元は1000、3000、5000ポイントが溜まったら交換可能で、1000ポイントだと500円分、3000ポイントだと2500円分、5000ポイントだと5000円分になります。
1000ポイントは還元率が低いので、3000ポイント以上で交換するのがいいですね。

Google Homeで家電制御…。

家電関係のショーやフェアではスマートホームというかIoT絡みでのホームオートメーションというか、音声でライトが点いたりテレビのチャンネル変えたりなんていうのをやっているけど、誰かに何かをさせるには、そのための通信を行ってコマンドや応答のやり取りが必要になります。

そのためには有線無線関係なく、それぞれの機器が通信を行うための待機電力が増える、という問題もありますがそれは置いといて。

じゃあ家電とコントローラはどんなプロトコルとどんな手段で通信しているのだろうと、ふと思ったのであります。

ZigBee、BLE(旧Wibree)、DigiMesh、Z-Waveなどなど、低消費電力の無線規格はありますが、ソフトウェア面にはあまり注目していませんでした。

OSI参照モデル的には、Threadはトランスポート層とネットワーク層を担当し、物理層とデータリンク層は802.15.4を利用するようです。もともと802.15.4はIPv6とよく似た形でパケットの形式を定義していて、SourceやDestinationアドレスもIPv6に近い形式(6LowPAN)で指定するようになっています。そのため、LANとの親和性も高く、TCP/IPネットワークとのゲートウェイもかなりシンプルになるはずです。

Thread上でのデバイス開発は、Developing IoT Devices with Threadにありますが、それをオープンソースとして実装したOpenThreadというのがあるようです。
これをデバイス上で動かすことができれば、あとは802.15.4無線モジュールを持ってきて組み合わせてやればよい、ということでしょう。
もちろん電波で通信する関係上、セキュリティは重要になってきますので、その部分もしっかり見ないとですね。

ちなみに上記4つの無線規格のうち、BLEを除くと他の3つは802.15.4規格の上に構築されていたと思います。また、Digi Internationalが802.15.4のモジュールを国内の認証を取得して販売しています。その他にもロームなどが出しているようです。

ただ、802.15.4も電波を飛ばす部分がそれなりに電流を食いますし、受信に限っても送信ほどではないですが食いますので、メッシュネットワーク的には時刻同期を組み合わせた間欠通信かつ輻輳制御ということになるんでしょうか。

実際にはアプリ開発者はそこまではやらずに足回りは通信デバイスメーカに任せるんでしょうけど。

ということで、実際の家電への実装はOpenThreadを見ればそれなりに分かるということですね。

ちょっと眺めてみると、まず説明のところで、OpenThreadはNestが開発したものをBSDライセンスに準じた形のBSD 3-Clause "New" or "Revised" Licenseで公開している、とのこと。その目的は、多くの開発者が使えるようにすることで様々な製品の開発を加速することにあるようです。

また、
a Thread Certified Component, implementing all features defined in the Thread 1.1.1 specification, including all Thread networking layers (IPv6, 6LoWPAN, IEEE 802.15.4 with MAC security, Mesh Link Establishment, Mesh Routing) and device roles, as well as Border Router support.
だそうで、このOpenThreadは上記で通信デバイスメーカに任せるのではと書いた部分も含んでいるようです。

そういえばふと気になったので調べてみたら、かつてEM250というZigBee用のSoCを開発した米国Ember Corp.は、2012年にSilicon Laboratories, Inc.に吸収されたんですね。

余談ですが、いやらしいことに802.15.4は2.4GHzの電波を使用していて、それが無線LANの周波数とかぶっているので、無線LANの電波がバリバリ飛ぶ(たとえばYouTubeで動画を見ているとか)と電波出力の弱い802.15.4は通信障害を起こしやすくなります。また当然電子レンジにも影響を受けます。そのため、海外では700/800/900MHz帯の802.15.4モジュールもあるようです。日本では900MHzに近い帯域として950MHzを使えないかということも検討されていたようですが、現状ではまだ認可されていないかな、と思ったら920MHz帯で規格化されているようですね。

鉄製品の錆落とし。

錆びた鉄製品をサンポールに浸しておくと、赤錆がきれいに落ちる、という記事がけっこうあります。
ちょっとHTML記法的にどこまで表現できるかも含めて、化学式で表現してみます。

まず酸化鉄は酸化第一鉄(酸化鉄(Ⅱ))と酸化第二鉄(酸化鉄(Ⅲ))、それに四酸化三鉄(酸化鉄(Ⅱ,Ⅲ))などがあります。化学式はそれぞれ、FeO、Fe2O3、Fe3O4となります。
このうち、赤錆は酸化第二鉄、黒錆は四酸化三鉄が主成分です。錆びた鉄、という場合にはたいてい赤錆を指します。

産業的には赤錆はフロッピーディスクの磁性面に利用されたり、微粒子を装飾品やガラスレンズの研磨剤としても利用していたようです。現在でも研磨剤として使われていて、グラインダーなどで使用する赤棒は酸化鉄を使用しています。
余談ですが研磨棒は赤→白→青の順に粒度が上がり、白は酸化アルミニウム、青は酸化クロムが主成分になります(https://jp.misumi-ec.com/tech-info/categories/surface_treatment_technology/st01/c1981.html - MiSUMi-VONA 技術情報から)。


閑話休題。


赤錆は酸化第二鉄 Fe2O3 が主成分なのでこれをターゲットとします。一方サンポールは塩酸 HClが主成分です。なので、

Fe2O3 + 6HCl → 2FeCl3 + 3H2O

となるかと思いきやさにあらず。

実は赤錆はその主成分は酸化第二鉄ですが、実際には水和物として存在しているらしく、FeOOH(オキシ水酸化鉄)をもとに考えないといけないようです。別の書き方としては、Fe2O3・H2O となります。そのため、反応式は以下のようになるようです。

2FeOOH + 6HCl → 2FeCl3 + 4H2O

ですがこのとき水中では塩化鉄() FeCl3 はイオンとして遊離しているため、Fe3+ + 3Cl- となっているようです。

赤錆が溶け出した状態では主にこの Fe3+ が水中にありますが、ここに炭酸ナトリウム Na2CO3 を投入します。
すると鉄とナトリウムのイオン化傾向の差によって、

2FeCl3 + 3Na2CO3 → 2Fe↓ + 6NaCl + 3CO2

となって、二酸化炭素の泡が出て、溶けていた鉄が沈殿し、水溶液は食塩水になる、はずです。たぶん。なるといいな。

実際には赤錆以外の鉄も塩酸中に溶け出しているでしょうし、酸化第三鉄なども含まれているでしょうから、必ずしもこの通りになるとは限りませんが、大筋としての理解はこれでいいのではないかな、と思います。

ただし実際に実験する場合、サンポールを使うと塩酸以外の成分も含まれているので、ちょっと舐めてみるというのはやめたほうがいいでしょう。

それにしても、高校のときにも思ったけれど、鉄イオンは2価と3価があり、さらに水和してみたりα、γ、δなどの相に化けてみたり、身近なのに分かりづらすぎ…。

そういえばセスキ炭酸ナトリウムが最近キッチンや洗濯用に出ていて結構な人気だけれど、これは炭酸ナトリウムと炭酸水素ナトリウムを1:1で混合したもので、弱酸性ではあるけれどタンパク質や脂質を溶かすので衣類の汚れ落としなんかに重宝してるんですが、そろそろパナマ風帽子がひと夏過ぎてちょっとニオイがしてるので洗濯しようと思ってます。

BloggerでMathjaxを使ってみる。

やっぱり数式を書くならLaTeXが一番美しく書けますね。実は太陽の重力はどれくらいなんだろうとふと考えたのがこのエントリを書くきっかけ。
BloggerでMathJaxを使ってTeXっぽく数式を入れる方法を参照させていただきました。

で、Wikipediaの重力加速度より、

球対称な天体を考え、自転の影響を考えない場合には、天体の質量を M、半径を R とすると、地表付近での重力加速度の大きさは、万有引力の法則から万有引力定数を G として

$$g=\frac{GM}{R^2}$$

と表すことができる。半径方向の単位ベクトルを\(e_r\)とすれば

$$g=-\frac{GM}{R^2}e_r$$

と表される。自転による遠心力を考慮すれば、自転の角速度を\(\omega = \omega e_z\)として

$$g=-\left(\frac{GM}{R^2}-R\omega^2\right)e_r-R\omega^2e_z \sin \phi$$

となる。ここで\(\phi\)は観測点の緯度である。重力加速度の大きさは緯度によって変化し、赤道で最も小さく、極で最も大きい。また、その方向も球の中心からずれる。

だそうです。
地球の場合には、Particle Data GroupのデータASTROPHYSICAL CONSTANTS AND PARAMETERSによれば、地球の質量は\(5.9724(3)×10^{24}\)kg(ただし(3)は3の循環小数)、半径(nominal Earth equatorial radius)は\(6.3781×10^6\)m、万有引力定数は\(6.67408(31)×10^{−11}\)m3 kg−1 s−2ということなので、自転を考えなければ\(9.79851528...\)m/s2となります。
公式には地球の重力加速度は\(9.80665\)m/s2なので、ほんのちょっと違いますが、およその値としてはかまわないでしょう。

そして肝心の太陽です。
Wikipediaによれば、太陽は質量\(1.9891×10^30\)kg、半径\(6.96×10^8\)mですから、自転を考えなければおよそ\(274.05\)m/s2となります。つまり地球の28倍です。
そしてそんな太陽からの脱出速度は617.7 km/s。地球からの脱出速度は11.186 km/sですから、地球の55倍の速度が必要となり、太陽の重力圏に捕まったらものすごい勢いで太陽に落ちていくんだよ、ということになります。
ちなみに音速のマッハでいえば、マッハ1は340 m/sですから、地球からの脱出にはマッハ33、太陽からの脱出にはマッハ1817と、もう想像することも困難な数字になってきます。時速になおせばマッハ1=1225 km/hとなります。
参考までに成田-サンフランシスコの距離は8236 km、マッハ1なら7.3時間、マッハ33なら0.22時間=13分30秒、マッハ1817なら14.5秒…というとんでもない速度ということになります。

なんというか、天文学ではほんとに天文学的な数字を扱うんだなぁ。

SWDなら3線でいいとはいうものの。

 安価で優秀なデバッグプローブはないかしら、と探したら、 Raspberry Pi Debug Probe というのがあったんですが、これは3線がにゅるんと出てるだけです。 もちろんSWDなら3線を繋げばいいのではありますが、汎用的に考えるなら5x2のリボンケーブルコネクタが欲し...