Archive for the ‘Linux’ Category

先日、Thunderbird(とLightning)が良くなった(去年くらいからデグレ(機能劣化)していたのが直った?)と思って試していたが、やっぱり駄目だった。ぬか喜びだった。(主にLightningに)以下の問題が残って居るか追加されたので、再びSeamonkey(カレンダーを使用)に戻した。

  • Todayペインの今日の予定が出なくなる。: 去年から
    • なんらかのタイミング(昼が近くなると?)で、今日の予定が表示されなくなってしまう。
    • 新しく作った予定は出るようだ。
    • 過去に作った予定だけ、タイムゾーンの処理がうまく行っていない??
  • 予定をダブルクリックして編集できないので面倒。それで出るのは予定内容の表示ウインドウで、その「編集」ボタンを押さないと編集できない。: 近頃の版で改悪された?
    • わざわざ無駄なステップを増やして馬鹿みたいだ。
    • これの設定はなし。
  • 予定編集時、予定の年や月がプルダウンで選べないので、数か月・数年前後を指定するには◀▶を何度も押さなくてはならず、面倒: 近頃の版で改悪された?
    • 新しい、機能が少ない部品をわざわざ作った??
    • これの設定はなし。
  • 細かい色など。: 去年から
    • メールのアカウントのアイコンが青でテーマに沿っていない。
      • TodayペインのTODOの"↓"も同様。
  • 設定がタブで使いにくい。: 去年から

「はい、やり直し!」ってか、この分では永遠に(僕には)使いものにならない気がする。Mozillaの連中はクソみたいな不要な「改良」ばっかりして、嫌になる。

もちろん、こんな ユーザーに嫌がらせする団体に寄付なんかしないよ。

 

PS. フォーラムに投稿すれば直る可能性は0ではないが、今まで見て来た感じでは、放置されるか数年後にようやく直る確率が8割くらいなので、投稿する労力が無駄だからしない。実際、Todayペインでの予定のマウスオーバーで中身が出ないなんて単純なデグレを直すのですら、1年掛かったではないか。

もちろん、UIの改悪については絶対に直らない。彼らは胸を張って、「それが良いからそうした」と言うに違いない。でも、数年すると また変えるんだぜ。

  •  0
  •  0

いろいろ劣化したために、数年前(と思っていたら、まだ去年だった)に見限ったThunderbird。ただ、代替品(Seamonkey(カレンダーとTODO), Evolution(メール))も なかなか いけずなところがあるので、更新版をウォッチしていた。※

※自動で定期的に更新をチェックし、気が向いたらダウンロードして動かしてみていた。

昨日だったか、ニュース※にThunderbirdの更新*が載っているのを目にした。今回は表示関係も直っているようだったので、(それでも全然期待せずにw)試してみた。すると、なんと、Lightning(カレンダーとTODO)の問題が直っていたのだ。全部ではないが、一番嫌だった、Todayペインの予定にマウスオーバーしても中身が出て来ない問題が直った。ようやく誰かが気付いて直したようだ。

※確か窓の杜だったと思う。アプリの配布サイトは もう余り意味がないと思うが、ここはいつまで続くのだろうか?

*ニュースを見る少し前に、上記の自動更新チェックでも更新が通知されていたが、今回のはその次の版だった。

ただ、それ以外の嫌な点(メールのアイコンが青、TODOの"↓"も青)は元のままだ。それでも、カレンダーに使っているSeamonkeyが古くて「そろそろかなあ」かと思って居たので、ThunderbirdのLightningを試してみることにした。

まだ半日くらいだが、もう一つの止めた切っ掛けの、「Todayペインの予定の今日の内容が表示されなくなることがある」やそれ以外の大きな問題は今のところ起こっていない。良くなったことは、Seamonkeyより起動が速い以外は余りないが、それでも充分だ。一部の色などが気に入らないのは きっとなんとかできると思うから、後回しでいい。

Lightningが問題なければメールも試し、良ければEvolutionも止めようと思う。Evolutionはそれほど悪くないけど(積極的に使いたいほど)いいことも余りないし、やっぱり古いので、(再び)Thunderbirdに統合してアプリを減らしたい。

うまく行った暁には、直してくれたお礼に(、Firefoxも使っていることだし)、Mozillaに寄付しよう。

↑ 「直してくれた」とは書いたものの、元々ちゃんと動いていたのを不注意で駄目にして、一年経ってようやく元に戻しただけのことだ(むしろ遅過ぎる)。世間で良くある、悪い奴が更生したら「偉い」と褒めるようなものだ。が、そうであっても お世話になっているのは確かだ。 (9/10 23:38)

  •  1
  •  0

先日、Linux Mintを20.2に更新したのだが、いつものように苦労した。更新自体は概ね問題なかったのだが、ちょっと使ったら以下のような問題(または変化)が見付かった。多くは何とか対処できたが、できていないものも残って居る。

  • 更新
    • usrmergeを実行したが、何も変わらない感じ・・・ → 調べても分からなかったし、/usr Merge自体の意義とかメリットが不明なので、対処せず。
      • 単なる自己満足じゃないかと思うし、数年したら また変わりそうな気がする。
      • その後、sudo dpkg-reconfigure usrmergeでできそうなことが分かったが、未実施。 (→ 参照)
  • Xfce(またはxfwm)
    • パネル(Windowsのタスクバーに相当)
      • fcitx(入力メソッド切り替えプログラム)のアイコンが変わってしまった。 → すごく苦労して直した(後述)。
      • DateTimeプラグインのフォントが変わってしまった。 → 再設定した。
      • Status trayプラグイン中のアイコンの順序が変わってしまった。 → ちょっと苦労して直した(後述)。
    • Thunar(ファイルマネージャー): 左側パネルのPlaces(フォルダなど)とDevices(ストレージなど)の上下が逆になった。 → 対処方法不明。大きな問題がないので保留。
    • Settings Managerなど、多くのXfce(Mint?)アプリのウインドウの縁が角ばるようになった。 → 面倒なので未対処。 → 前の版の時に、そもそもの問題(Whikerのメニューを開くのが遅くなる)を回避するために止めたxfwmのcompositorを有効にして、試している。 (9/6 6:53)
      • xfwmのcompositorを有効にしないと枠が赤くなるウインドウがあるので、以前の版の時に、赤くならないように、テーマのCSSを調整して角ばった枠にすることで対応したが、また赤くなるアプリが増えたようだ。
      • 対処するにはテーマのCSS(これが見にくい・・・)を新旧で比較しないといけないので、なかなか面倒だ。
    • Chromeのアドレス入力フィールドやブックマークウインドウの入力フィールドなどの縁が赤くなった。 → 未対処。Chromeは余り使わないので保留。
      • 上記のテーマのCSSと同じ問題と思われる。 → 使っているテーマ(Mint-X-Sand)の問題(相性?)らしく、compositorを有効にしても直らない。 (9/6 6:53)
  • アプリ
    • Spotify: OSと一緒にバージョンが更新されてしまった。 → パッケージ板はアンインストールし、バックアップから元の版を入れた。
      • 元: 1:1.1.42.622.gbd112320-37
      • 新: 1:1.1.55.498.gf9a83c60
      • 新しい版はデザインがひどいうえに使いにくい(例: 前/後のショートカットキー(Alt+←/→)が効かない)ので、使えるうちは元の版を使い続けたい。
        • ひどいことに、古い版は取得できなくなっているので、バックアップがあって良かった。
      • 幸い、関連ディレクトリ(主に/usr/share/spotify)がまとまっていて、それを入れるだけで動いた。(将来試すかも知れない)パッケージ版と競合しないように、spotify.origという名前にした。
    • Seamonkey(ThunderbirdのLightningの代わりに使っている): なぜか、最初の起動でちゃんと動くようになった感じ。 → 様子を見ている。
      • 以前は、OS起動直後に起動するとカレンダーとTODOペインが表示されなかったので、自動で再起動するようにしていた(なぜか、そうすると出ることが多い)が、それが不要になった。
      • システムプロセスの起動順序の関係?

Status trayプラグイン中のアイコンの順序が変わってしまった件と対処

Status trayはWindowsではシステムトレイに相当すると思われる。その中のアイコンの順序は設定できるのだが、新しい版では中身の種類("Status notifier"と"Systray icons")ごとに順序は設定できるものの、種類の順序が変えられない。

今までは頻繁に確認するMozc(fcitx)のアイコンを一番上にしていたのだが、上記の種類の順序のため、中間に来るようになり、しかもアイコンもキーボードに変わってしまい(後述)、結構戸惑うようになった。 (→ : 上から3番目のキーボードのアイコン)

プラグインの設定では種類の順序の変更は無理だったが、以前使っていたStatus notifierというプラグインは その名のとおりStatus notifierだけを出せるので、併用すれば良さそうなことが分かった。ただ、Systray iconsはStatus trayプラグインでないと出せないので使わざるを得ない。それで、以前の版をバックアップから取り出し、プラグイン名を"Status Tray Plugin (old ver.)"に、ファイル名に"old"を追加して使うことにした。 (→ 順序の変更後(fcitxのアイコンも変えている(後述)))

新しい版のStatus trayプラグインでも、Status notifierのアイコンを隠す設定なら、古い版でなくても同じことができるが、Status trayのアイコンの下に"V"のマーク(隠れたアイコンがあるの意味)が出るのが鬱陶しいので、古い版を使うことにした。全く余計なお世話だ。

fcitxのトレイアイコンが変わってしまった件と対処

fcitxはMozc(日本語入力システム)が無効・有効時のアイコンを設定でき、僕はそれで変更していたのだが、新しい版ではその設定が無視されるのか、無効時には必ずキーボードのアイコンが表示されるようになった。 (→ : 最上部)

(無理やりではあるが)そのキーボードのアイコンを自分の好みのものに置き換えれば直せるのだが、アイコンのファイルが全然見つからなかった。随分探して、数日後にようやく分かった。"fcitx-kbd-symbolic"(/usr/share/icons/hicolor/scalable/apps/fcitx-kbd-symbolic.svg)だった。今までも検索には出ていたが、通常の場所(/usr/share/icons/テーマ名や/usr/share/fcitx)でないのとSVGのために小さくて灰色だったので、見過ごして居た。そのファイルを置換して、ようやく好みのアイコンに戻せた

なお、アイコンが見つからない時に、fcitxと同様の機能のiBusを試したが、GoogleによるMozcのibusサポートが終了しているようなのと、微妙に動作が遅くて入力にストレスがあるので止めた。あと、Mozc有効・無効のアイコンが小さくて見にくい(大きくできなかった)のと、ウインドウを切り替える時に一瞬Mozcの丸いアイコンが出るのも気に入らなかった。変換機能についても、試す前は「変換できれば何でもいい」と思って居たものの、Mozcにある予測変換がないのが物足りなかった。 ← iBusは変換しないので、思い違い。Anthyを試した時のことか。

 

そもそも無料だし、何らかの目的・目標(があるのだと思うが・・・)に向かって日々改良・改善しているのだろうから、バージョン更新時に変更されるのは仕方ないが、余計なお世話とか単なる自己満足的な変更(これが実に多い気がしている。例: usrmerge)とか、不完全なものや退化したものを(誇らしげに)出す(これも実に多い。例: Spotify)のは止めて欲しい。

 

おまけ: ちょっとした文字サイズの違いが気になる件

(Mintの更新とは関係ない。) 先日、パネルにYL-40のセンサで測定した室温を出すようにしたのだが※、アルファベットと記号(℃)のサイズが微妙に違って見えて気になる。

Rm ℃

と出している場合、"℃"が大きく見える。(→ : 中央から少し下) フォント(Liberation Sans)に"℃"(日本語)が入ってないせいかと思い、フォントに入っているアルファベットの"℃"(U+2103)にしても同様だった。(→ )

※センサでの測温が大分安定したので、机上の温湿度計を他に移した。なかなかすっきりした。ついでに湿度も分かれば最高だがw

それで仕方なく、"°"(U+00b0) + "C"にした。(→ ) "°"と"C"に わずかに間が開くのは気になるものの、大きさは問題ないので これにした。

なお、フォントには合字(?)用の"°"があり、それだとぴったりくっつきそうだが、使い方が分からないので(というか、いつも失敗している)試していない。 → どうやら、それは本体の上とか下に付けるもののようで、横には付かないようだ。

ついでに、どこかにありそうだと思って探したらあった温度計"🌡"(U+1f321)も試したが、やっぱりわずかに大きいものの、絵のせいか余り目立たない。(→ ) ただ、絵のために他から ちょっと浮くのと、単位が分からない(と言っても、ここでは℃の他にないが・・・)ので却下した。

書いてから、このブログでは大きさの違いが目立たないこをに気付き、フォントをVerdanaにしたら、フォント自体がちょっと大きいので、サイズを下げて先頭に空白を入れたら いい感じだ。 (→ )

と思いきや、今まで使っていたフォントはLiberation Sans Narrowで、それをNarrowでないものにしたら、あっさりと直った。これなら、他と同じフォントなので統一感も向上する。何ともしょうもない話だが、Narrowに含まれる文字が少ないとは思っていなかった。。。

ただ、同じようなものを何度も見たために感覚がおかしくなって(ゲシュタルト崩壊?)、実は直ってない、あるいは、そもそも大きさに違いはないというオチもありそうだ。

→ 一晩経って、改めて見てみると、最終版(NarrowでないLiberation Sans)でもわずかに大きく見えるが、最初のNarrowよりは良いし、Verdanaも同様だ。一方、°+Cは なぜか問題ない。文字の配置による錯覚ではないか。他には、文字のベースラインの違いだろうか。℃は微妙に上になっていて、大きく見えるのか。

いずれにしても、キャプチャしたものをドット単位で比較すれば確認できるがw、さすがに面倒だ。 (9/6 7:05)

→ 面倒だけど比較したら、意外な結果となった。以下に比較図を示す。本当に文字の高さが違っていたのだが、高かったのは"℃"の"°"の部分だった。それがわずかに高い。そして、"°"+"C"だけは、"°"が他の文字と同じ高さなので大きく見えなかった訳だ。

すっごく微妙だな・・・ そして、人間の感覚の鋭さに改めて驚いた。こんな微妙な差を、40cmくらいのところで感じてしまうのか・・・

これを発展させると、使うフォントによって見る側に無意識に何か(例: 「何となく好き/嫌い」、「何か変」)を感じさせることができそうだ。商品が売れるフォントとか、偉い人の決裁が通りやすいフォントなんてあるかも知れないな。ただ、相手によって感じ方が違うだろうから、いつも同じフォントが受けるとは思えない。 (9/6 9:25)

そして、この問題を丸く収めるには、"°"が高くない"℃"を持つフォントを探すことだが、さすがにしない。そのうち慣れるよwww (9/6 7:33)

→ やっぱりフォントを探した。: "℃"の"°"が上に出っ張らないフォントを探したところ、FreeSans, DejaVu Sans Condensed, Mgen+ 1cp, Mgen+ 2cp, Noto Sans, Noto Sans CJK JP, 源真ゴシックP, NanumGothicなどは"°"が"C"の手前にあって、上には出っ張っていなかった(DejaVu以外はRegularまたはNormal)。

なお、NanumGothicは"°"は上に出ているものの、全体が一段小さいので出っ張らない。ただ、形が今ひとつなので却下した。

字形を比較したところ、大きく分けると、"C"の開口部が広いものと狭いものの2系統あるようだ。そして、FreeSans, Mgen+ 1cp, 源真ゴシックPは開口が狭くて他に合いそうなので、Mintの標準フォントにしている源真ゴシックPにした。 → 源真ゴシックPにしてみたら"°"と"C"が離れているように見えたので再確認したら、なぜか字形が変わっていた(設定ミスだろうか?)。それで、FreeSansに換えた。

源真ゴシックPは好きなのだが、これを見たらがっかりした。おそらく、元のNoto Sansの形を引き継いでいるので仕方ないが、もっといい(日本語)フォントが欲しくなった・・・ この点だけならMgen+ 1cpが良さそうだが、他の字形がちょっと開放的過ぎるので常用はできない。

以下にそれらのキャプチャを示す。

これで、ようやくすっきりしたはずだ^^ (9/6 14:31)

→ 安心も束の間、良く見たら、再び"℃"がわずかに高いことに気付いてしまった。上の候補の高さを比較し、DejaVu Sans Condensedなら大丈夫そうなので、それにした。他は線の太さ分くらい高いようだ。なかなか気が抜けない。 (9/6 19:57)

※なお、"Rm"はRoomの略で、℃を温度の右に書くと微妙に幅が足りないので、Roomを短縮して上に置いた。ここもちょっと気に入らないが、どうしようもない。 (9/6 14:46)

  •  1
  •  0

随分手こずったが、ようやく、センサモジュール(YL-40)で温度(室温)が まともに測れるようになった。量が多くてちゃんとした文章にするのが大変なので、下書きの箇条書きを少し手直しして載せる。そのほうが却って読みやすいかも知れない・・・

なお、番号の箇条書きは時間順である。

YL-40の温度センサ(サーミスタ)での温度測定(計算)の調整・較正

  1.  サーミスタの温度が合わない(おかしい)。
    • ある温度に幅広い抵抗(その逆も)が対応するため、どうしても合わない場合ができる。
    • ただ、それ以外に変な挙動があった。: 温度計と全然合わないことがある。 (例: グラフ: 13時辺りの水色の線(温度計での室温)や13:30辺りのベージュの線(センサでの温度)の凹んだところ) → 後述の「センサ(サーミスタ)と温度計がズレたまま直らない問題」だった。
      • ADCの変換誤差、温度・電源変動かと思って調べたが違うようだった。
  2. 体温計のサーミスタを試す。 → やっぱりYL-40のでもいいんじゃない?
    • 古い体温計分解してサーミスタを取り出して、YL-40に繋げてみた
    • ある程度、それらしい温度が取れるようになったが、敏感過ぎるのか変動が激しい(グラフ: 赤線)。一方、YL-40は小さいケースに入っているせいか、温度変化速度が適度な感じ(グラフ: オレンジ)。
      • 近似式のパラメタが今ひとつのせいか、不安定なこともあるようだ。
      • ただ、YL-40も、サーミスタの仕様(B, R0, T0)がわからないと、正しい温度を得るのは難しい。
    • 体温計とYL-40のサーミスタの挙動(温度変化)が近かったので、YL-40でも行けそうな気がした。
    • 室温(温度計)との差は、計算誤差以外に気流や温度計の熱容量の影響もあることが分かった。
      • 場所でも異なる。たった20cmくらいでも、0.2℃くらい違う。
    • 体温計のサーミスタと取り付け基板を見て、マジンガーZみたいなアニメの操縦機とかボスボロットを思い出した。
  3. やっぱり、YL-40のサーミスタも合わないことがある(惜しい)。
    • 24℃台が駄目(低過ぎる)。
  4. → 近似式(Steinhart-Hartの式)を止め、通常の式(B係数を使うもの)に戻した。 → 25-26℃台はなかなかいい? (→ グラフ: ベージュ)
    • ただし、係数を試行錯誤で決めた。
    • 一番の決め手は、(Bでなく)R0(一般的に25℃での抵抗値)が仕様(と思われる: 参照したページより)の4.7kΩと異なっていたこと(約5%大きい感じ)。
      • 以前は直列抵抗を変えたが、それよりもちゃんと効く。
    • この頃は寒くなってしまったので、高温での確認ができなかった(が、後に充分できた)。
      • 過去データでシミュレーションはできて、それでは悪くない結果になっている。
    • 電源on後は、サーミスタや基板やケース全体が温まる(?)まで、約30分間は温度が低目になる。 ← 実はPCやアンプやサブディスプレイの熱の影響で、それらが温まるのに時間が掛かっていたのだ。(後述)
  5. 温度分解能を上げる(温度ステップを小さくする)ため、サーミスタの直列抵抗を5.7kΩに変更したが、全く効果がなかった・・・
    • 元の抵抗1kΩの代わりに付けていた4.7kΩを元の抵抗に直列に繋いだ。
    • スプレッドシートで試算しての経験則だが、温度分解能(温度レンジでの最大・最小電圧の比に関係する)を最大にする直列抵抗は、上限と下限でのサーミスタの抵抗値の相乗平均になるようだ。
    • ただし、電圧はADCで量子化されるので、その電圧ステップ・温度ステップと区切りの電圧・温度を考慮する必要があり、その結果、分解能の変化が吸収されてしまい、効果がなかった。
    • 現状の温度ステップは15-30℃の範囲では約0.36℃で、想定される温度誤差は約±0.36℃。
      • なお、オリジナルの温度ステップは約0.65℃。
    • その後、サーミスタの非直線性による量子化誤差のバラつきを減らすため、15-30℃でリニアライズできる抵抗4.1kΩに換えた。
      • リニアライズの原理を良く理解していないし、通常の直列抵抗とどう違うのかも分からない。ただ、AD変換の出力の区切りの温度がなるべく均等になりそう(→ 量子化誤差のバラつきが減る)だと思って試した。
      • 温度ステップは約0.36℃で変わらず。
    • その後、4.1kΩを構成する2本の抵抗の片方の精度が悪くて(5%)気分が悪いので、1%の20kΩに交換して4.06kΩにした。
      • おそらく、温度を計算する時に抵抗値を補正すればそのままで良かったのだろうが、精度が悪いものは温度特性も悪いかも知れないので交換した。
      • ところが、あとで試算したら、誤差に効くのは値の小さいほう(精度1%)だったので、無駄なことだった。が、戻すのは面倒なのでそのままにした。
    • 更に温度分解能を上げたくなり、ADCの基準電圧(VREF)を5Vから3.3Vに下げて分解能を上げることを検討し、サーミスタの直列抵抗を調整することで、現在の約1.5倍の分解能の0.23℃にできそうなことが分かったが、分解能と精度は異なるので、単に無意味に細かい数字が出るだけの可能性があるので、やっぱり止めた。(でも、やってみたいw → 結局実施した(後述)。)
  6. その後、高温(最大約29℃)で測ったら温度が合わず、試行錯誤してR0を調整して5040Ωで計算するようにしたら(Bは想定される仕様どおりの3977)、なぜかうまく合うようになった。
    • 5040Ωは元の値と思われる4.7kΩ+約7%。 → その後測っていたら、27℃で4.7kΩになることが分かり、サーミスタの仕様は「R0は(通常の25℃でなく)27℃で4.7kΩ」だったのかと思っている。
      • あるいは、R0は25℃で5kΩ(上の5040Ωとほぼ同じ: 誤差0.8%)なのかも知れない。計算上は同じ特性・曲線になるはずだ。
    • それからは なかなか「いい感じ」になった。高温(最大30℃)でも問題なかった。 (→ グラフ: オレンジ, R0調整前はベージュ)
    • 合わない原因として、温度による電源電圧の変動による影響を疑い、別の電源(USB)を使って電源(VGAの5V)の電圧を測ったが、余り関係なさそうだった。 (→ グラフ: 赤の前半。後半はVGAから電源を取って測ったので余り意味がない。)
      • 基板の電源に使っているPCのVGA端子の5VはPCの他の5Vと共通だろうから、大きく変動することはなさそうだ。
  7. つい魔が差してw、上記のADCの基準電圧(VREF)を5Vから3.51Vに下げて分解能を上げた。
    • ADCは一定の段階(YL-40は256ステップ)で区切って電圧を数値に変換するので、全体に割り当てる電圧範囲を狭めれば(= VREFを下げる)、1ステップ当たりの電圧が小さくなる。一方、サーミスタの温度は抵抗の電圧から求めているので、結果として温度ステップも小さくなる(= 温度分解能が上がる)。
      • 電圧ステップは元の19.5mVから13.7mVになった。
      • 温度ステップは元の約0.36℃から約0.25℃と、約1.4倍に向上した。
        • オリジナルは約0.65℃だったので、約2.6倍にまで向上した。
    • 予想以上に大変だった。
      • サーミスタの直列抵抗を測定可能温度範囲と15-30℃での直線性と分解能で調整した。 (参考: 直列抵抗とADC出力のグラフ)
        • 測定可能温度は5Vの時(グラフ: 青実線)は0℃以下でも可能だったのが約11℃以上と狭くなった。が、そもそもPCは10℃以上で動かすべきとのことなので、大きな問題はないとした。
          • ↑ 書くまでは7℃以上だと思い込んでいたが、グラフを見て「おや」と思って再確認して約11℃と分かった(VREFが5Vの場合と取り違えていたようだ)。ちょっと気になるが、まあ、室温が11℃のまま我慢できることもないだろうから、今のところは良しとする。
            • もし、7℃くらいの低温から使うなら、直線性は低下するが、抵抗を6kΩくらいにすれば良さそうだ。
          • なお、オリジナルの抵抗1kΩは、分解能は低く、直線性も悪くて何もいいことがない、まさに「テキトーに付けた」としか思えないものだ・・・ (グラフ: 黄実線)
      • 基板の改造量が「半端なかった」。 (後述)
        • 動作確認するまで忘れて居たが、光センサ(CdS)の直列抵抗も変える必要があった。
        • ジャンパピンで元の構成(Vref= 5V, 光・温度センサの直列抵抗)に戻せるようにしたせいもある。
      • 間違って(勢い余って)切ったパターンもあって、その修正もした。
      • ソフトの対応(光・温度センサの出力レベルの変換)や再較正も手間が掛かった。
  8. 当初の設置場所の机右側はPCやアンプやサブディスプレイの熱が影響する可能性があることが分かり、新たな位置を探した。
    • PC・アンプとセンサの電源onから数十分すると、測定される温度が上がるのが証拠(上記の「約30分間は温度が低目になる」)。
      • 当初はセンサ(サーミスタ)が定常状態になったと思って居た。が、それには長過ぎる。
    • 机から少し離れた本棚辺りだと影響が少なくなり、サーミスタの抵抗値と温度との相関が高まった(移動前に比べ、移動後は抵抗値に対応する室温の幅が狭くなった)が、まだ完全ではなかった。
      • 一方、影響のない離れたところ(壁際)は机の温度と異なるので体感に合わず、実用性がない・・・
    • 机の左端にした。
      • 前に障害物がないため今までより明るいので、その補正式を作った。
        • 明るさに応じて明るさを減らす。比例ではなく、とても明るい場合は より減らす。
          • l': 補正後の明るさ, l: 明るさとすると、
            • l'= m(l) * l
            • m(l)= k * l + m0
          • 現在のパラメタ: k= -0.0025, m0= 0.95
        • 当てずっぽうで作ったのだが、結局、2次関数での補正となった。CdSの特性は対数なのに、どうしてこれでいいのかは分からないが、使ってみると悪くない。
          • 使っている明るさの範囲でのCdSの抵抗値の曲線と2次関数の形が似ているのだろうか?
          • 対数・指数関数での補正も試したが、うまく行かなかった。式が間違っていた(対数と指数の順序が逆だった?)のかも知れない。
  9. 「センサ(サーミスタ)と温度計がズレたまま直らない問題」が勃発(再発)
    • センサの温度が温度計より低い・高いままの状態がしばらく継続する。 → 例: グラフ: 13時辺りの水色の線(温度計での室温)や13:30辺りのベージュの線(センサでの温度)の凹んだところ。
      • 例えば、暑くて冷房を強くしたあと、エアコンの風が弱まった場合に起こる。
    • なぜか、温度計(センサの場合もある)内部に熱・冷気が溜まることがあるようだ。
      • (1分くらい)ファンで送風すると温度計の温度が本当の室温に合う。
        • 手であおいでも、なかなか効果が出ない。
      • センサと温度計の反応速度差(熱容量による)もあり、なかなか原因が分からなかった。
      • そういうことがあるのか まだ疑問だが(普通は、時間が経てば熱は拡散するので)、この場合は温度差が1℃未満(0.5℃など)と小さいので、温度計のケース内の空気で長く保温されてしまうのだろうか。
    • センサは通風がいいように設置することが重要そう。
      • 何か(柱など)にくっつけると良くなく、孤立させたほうが良い。 → センサを台に直接付けず、スペーサーで約1cm離した
        • スペーサーは、PCケースのスロットの未使用レールを保持する部品を加工して作った。: 適当な大きさに切ったものを上下に貼り合わせて、センサのケースと台が貼れるようにした。
      • 温度計もその必要があるが、そういう作りではない。: サーミスタは浮いているが、ケースの中なので今ひとつな気がする。
    • 調整と測定の日々・・・
      • 場所や設定を変えては、日がな室温を変えつつ※温度計とセンサの値を記録してチェック・一喜一憂していた。
        • ※室温を変えるのは冷房のoff/onでやるので、なかなか身体には悪そうだ。が、まあサウナだと思えばいいかw
      • ADCの温度特性による変動も疑い、電池の電圧の測定もした。
        • 試しにドライヤーで35℃くらいに熱して冷ましたら、一時的に電池の値が1cnt上がったが、その後戻った。温度変化でADCの出力が変動したのか たまたまかは不明だが、温度の値がずっと変わったままになる(器用な)現象とは異なると考えられる。 (→ グラフ: ベージュ: 温度, 紫: 電池(電圧ではない))
        • → 結局、通常の状態では電池(電源とは無関係に電圧がほぼ一定)の電圧値は全くと言っていいほど変動せず(→ グラフ: 紫の線)、ADCの温度特性は問題ないことが分かった。
        • 最初は、定電圧を生成する部品(ツェナーダイオードやLDO)はないので、(無意味そうな気がしつつも)電源から抵抗で2.5Vを作って測ったが、ふと、「電池でいいじゃん」と気付いた。電力を消費しなければ、数時間くらいは問題なく一定電圧を保つだろう。
    • 結局、この問題と温度計とセンサの反応速度差、それからPCなどの熱のために温度計とセンサの値がずれて、計算式を何度も変えたり体温計も諦めたようなもので、なかなか意外なところに落とし穴が いくつもあった。

YL-40基板の改造

  1. 上記の温度センサ(サーミスタ)の直列抵抗を変更した。
    • 抵抗で直線性と温度分解能が決まる。
      • ADCを使う場合、直線性がいいほうが温度ステップが均等になるので良い。
    • 最初は4.7kΩにし、次に5.7kΩにし、その後約4.1kΩにした
  2. ボリュームを外し、パスコンを交換・追加した。(それらの温度変化による、電源・ADCへの影響を疑ったためだが、そうではなかった)
    • パスコンは元のを外し、タンタルとセラミックにした。
    • タンタルは大きいので、外したボリュームのところに付けた。
    • 味気なかった基板にオレンジと青が加わって、カラフルになった。
  3. ADC/DACの基準電圧(VREF)の変更: 温度分解能を高めるため、PCF8591のVREF(ピン14)の電圧を5Vから3.51Vにした。
    •  その電圧は抵抗で電源(5V)を分圧して作った。
      • VREFピンの入力抵抗がそれほど高くないせいか、最初に大きな抵抗を使ったら電圧降下したので、1/10(2kΩ+4.7kΩ)にした。
    • 当初は3.3Vを考えていたが、3.5Vのほうが手持ちの抵抗で作りやすく、3.3Vは おぼろげに浮かんで来ただけの値でw、ぴったりにする必要はなかったのでそうした。
    • 新しいVREFに合うように温度センサ(サーミスタ)と光センサ(CdS)の直列抵抗を変更した。
      • サーミスタは5.1kΩに、CdSは7.8kΩにした。
        • CdSの抵抗を換える予定はなかったが、CdSの電圧がADCに対してオーバーフローするので変更した。
    • VREFと各センサの直列抵抗を、ジャンパピン(P4,5,6)をショートすることで元の状態に切り替えらえるようにした。
      • CdSの抵抗も換えなくてはならなくなってジャンパピン3個を全部使ってしまったので、当初の計画だった、ジャンパピンで電源LED(D2)を暗く光らせるようにするのはできなかった。
        • それ以前に、ここまでの改造で疲れて する気も起こらなかった。
    • DACの出力も小さくなるので、そのままのプログラムからの出力ではLED(D2)が光らなくなったので、出力する値を調整した。
    • 思って居たより大掛かりな改造になった。: 基板表面は余り変化が分からないものの、裏面はジャンパ線と抵抗で一杯になった。
      • ジャンパピンからのパターンを切る時、思い込みでGNDを切ったり、勢いで、切らなくていいパターンまで切ってしまったので、その修復のための線が増えた。

※参考までに、最新のハードウェア構成図と改造後のYL-40基板の回路図を載せる。

スタンドやコードをちゃんとした。 → 光・温度センサのハードが完成した。

  • センサをスタンドのポールに取り付ける延長ポール付き台を作った。
    • 延長ポールは半田のケース(丁度、スタンドのポールに嵌まる)を、ポールと台の角度を付けるのにはスピーカー保護キットで使わなかったターミナルを挟んで接着した。
    • センサを取り付ける台は猫のカレンダーのベースを使った。
  • VGAコネクタをちゃんとした。
    • シェルの前側(コネクタを囲む部分)の前半分を後ろ半分に半田付けした
      • 元々は固定ネジ用の穴の内側からハトメのように固定されていたが、分解・改造するためにそれを外したため。
    • シェル本体(後側)の上下部は結束バンドで留めた。
    • シェル本体(後側)は前側の後ろ半分に爪で引っ掛かっているだけなので、コネクタを抜く時に引っこ抜けないか心配・・・ → あとでダクトテープを巻いた。

ソフトの拡充・改良

  • 部屋の明るさ、ディスプレイ輝度、室温をsensors(改造版)(図の"YL-40"以下)やMuninで出せるようにした(→ , )。
    • 「改造版」と言っても、元々Muninのカスタマイズ用にsensorsの出力を加工して出すものを作っていて、それにYL-40の値を追加しただけである。
    • Muninでは、明るさを1/2にして、温度変化を分かりやすくした。
    • Muninのグラフを比較して、マザーボードの温度は室温に比例することが確認できた。: マザーボードの温度= 室温+約6℃。
      • ただ、マザーボードの温度は1℃ステップなので、室温計の代わりにはならない。
  • Xfceのパネルに測定した温度(室温)を出せるようにした(図の"Room"の下)。
    • つい、湿度や外気温も ずらっと出したくなる・・・
  • センサ値を読む時にADCから値を連続して数回(現在は4回)取って平均することで、精度や分解能を少し改善できるようにした。
    • 雑音的な変動の影響が減らせる。
    • いつもではないが、センサの値がADCのステップの中間で変動している場合に中間値が取れる。
      • 例: ADCのステップでの温度27.76℃と28.01℃の間の27.82℃などが出ることがある。
  • 他にもいろいろしたい細かいことはあったが、基本的にちゃんと使えるので、まあ「おいおい」とした。

仕上げ

センサのケースの蓋を、結束バンドを成形したもので閉じた。固く締めておらず、引けば横に抜けるので、メンテも容易である。また、上述のように、センサの温度追従性を高めるため、スペーサーで台と離すことにした。

それを再度ちゃんとスタンドに付け設置して完成。 ・・・ だったらいいな^^

なお、下の写真を撮影したあとに、メインディスプレイ(EIZO CX241)の熱の影響を避けるため、センサをもう少し左、机の左奥の角辺りに移動した。サブディスプレイ(同S170)と違ってメインディスプレイの側面はほとんど熱くならないが、それでもわずかに熱を持つことが分かった(気がした)ためである。

ちなみに、今日(8/29)のYL-40での室温測定結果は問題なかった。既知の「熱・冷え溜まり」による温度差は一回あった(11:30頃)ものの、全体的に良く温度計に合っていた(温度計との差は概ね±0.25℃以内だった)。

雑感

  • 最初は、サブディスプレイの輝度の自動調整がしたかったから明るさが取れればいいと思って居たのに、いつの間にか温度がメインになってしまった・・・
  • 温度は意外に細かく測る必要があり(でないと体感に合わないことがある)、今の0.25℃ステップでも不満なくらいで、0.1℃ステップにしたいくらいだ。
    • もちろん、分解能だけ高くしても駄目で、その分の精度を確保する必要はある。
  • 冬になると今は測れない低い温度になりそうなので、また確認と調整が要りそうだ・・・
  • ついでに外気温や湿度も測りたいが、全然「ついで」には行かない。測れたって、「おもしろい」以外に特にメリットはない(それでいいんだけどw)。
    • 外気温は体温計のセンサが使えるが、そもそも較正がクソ面倒なうえに、接続ケーブルが長くなるのでトラブルが起こりそうだ。 (でも、おもしろそうではある・・・)
    • 湿度はセンサがない。あっても、サーミスタと違って抵抗値で測れる訳ではない。
  • まあ、いつものように随分横道に逸れて なかなか大変で疲れはした(+暑かったw)が、おもしろかったし いろいろな知識が得られ、体験ができた(という書き方は意識高そうで嫌だ)。
    • たった数百円(新たに買ったものはYL-40基板だけ)でここまで遊べたのは、なかなか「コスパがいい」^^
    • YL-40は やっぱりいろいろ甘く、熟練者が見たら「お前、何考えてんだ! 常識ないぞ!」とか どやしそうだが、まあ、こうやって遊び・考え・苦しみながら「どうにか使える」ようにするのも一興だ(とは、余裕があるから言えるw)。

 

かくして、久し振りに再び作業机が片付いた。

 

PS. いつの間にか、シチズン小(または大)の湿度計も劣化していた。大と小の差が大きく、8%くらい違う。

  •  0
  •  0

プロトが動いたあと、正式版にするため いろいろな作業をしていたが、意外にうまく行っており、今は実際に使ってみて問題がないか確認中である。

光センサで取得した部屋の明るさに基づいて自動調整されるサブディスプレイ(EIZO S170)の輝度は、概ねメインディスプレイ(同CX241)に合っている。微妙に明るさが違うことはあるが、同じウインドウを二つのディスプレイに またがって表示して比べたりしなければ気にならない。(自分の性格のため、一旦気にし出すと気になってしまうのだが・・・)

ただ、視覚特性の影響や階調特性や発色の違いなのか、色や表示の明るさによって明るさの差が違って感じることがある※(例: 無彩色(白・グレー系)でも、ある色(明るさ)がCX241とS170で同じ明るさに見えても、それより暗い色が なぜかS170のほう明るく見える場合がある)ので、完全に合わせるのは無理そうだ。

※これは実は明るさでなく、色の違いによるなのかも知れない。二つのディスプレイの発色・色温度などが異なるので、無彩色でも、明るさによって色が違って見え、それが明るさの違いと認識されるのではないだろうか?

それから、センサ基板(YL-40基板: 以下、「基板」)に載っているので「ついで」に試した温度センサは、誤差(真の室温が分からないので、正確には「本物の温度計との差」)はあるものの、「それなりに」室温が取れるようになった。

 

今回の一番大きな改良は、基板をケースに入れ、それをスタンドに付けて設置を安定させたことだ。また、さまざまな部屋の明るさで画面の明るさの違いをチェックして、センサの明るさ値からS170に設定する輝度を求める近似式を改良した。

不思議と、近似式はグラフの形状から予想した指数関数でなく、3次の多項式が合った。指数関数(ただし、輝度がほぼ一定な暗い領域(概ね、明るさが30以下)を直線近似にした)のパラメタをいろいろ調整しても、明るい領域(概ね、明るさが60以上)で輝度が大きくなり過ぎてしまう。画面の輝度は無限に明るくできないから、CX241は指数関数を使っていないのだろうか。あるいは、指数関数は処理が大変なので、多項式にしたのだろうか。いや、そうでなく、視覚的に現状の特性がいいから こうなっていて、それがたまたま3次に近いのだろう。

 

今回使ったハード(物)は全部手持ちのものの再利用で済ませた。基板のケースはエーモンの部品(車用電装部品? 古過ぎて何だったかは不明w)が入っていた小さいプラケースを使った。基板を支えるスタンドは、オーディオの特性測定・調整を始めようとした時に買ったけど、小さ過ぎて今ひとつで使わずに死蔵していて何度も捨てようと思って居たマイクスタンドを使った。基板をスタンドに付ける台は、2年くらい前の猫のカレンダーのベース(台)を使った。そのカレンダーを挟む溝の幅がスタンドのポールの直径に近く、丁度良かった。※ ただ、ポールだけだと少し低かったので、以前エアコンの温度の微調整に使おうとして断念した灯油ポンプのパイプ(この直径も丁度良かった)の切れ端(写真上部の半透明の筒)で延長した。

※スタンドに添付のマイクホルダーがあれば、角度が自由に変えられて更に都合が良かったのだが、捨ててしまったようだ。

なお、基板を垂直に設置したら若干明るさが弱くなったので、プロトのように少し(15°くらい?)上に向けて取り付けた。※ 角度を付けるための台には、楽天モバイルのポケットWi-Fiの緩衝材が役に立ったw

※光センサが多少暗くても輝度の自動調整は可能だが、折角調整(較正)した明るさから輝度への変換式のパラメタが変わってしまうので、なるべく合わせたかった。

基板とPCの接続ケーブルはUSBケーブルの両端のコネクタを切って作った(本当は、電話線のような もっと細くて柔らかいものが良かったが、手持ちにはなかった。電話線は余るほどあったが、随分前に全部捨ててしまった)。基板とケーブル間のコネクタは、アンプで余ったXHコネクタの延長コードを使った。

ケースはいろいろ迷った。最初はSDカードケースを考えていたが、基板の部品の背が高くて入らず、エーモンの薄目(高さ約1.2cm)のケースを試したが まだ無理があったので、同じくエーモンの厚目(高さ約1.7cm)のケースにした。それでも幅が少し足らなかったので、右側のPC接続用ピンに挿すコネクタのカバーを切り詰め(写真右側の黒い長方形。ただし、その後 気が変わって使わなくなった)、左側のアナログ入力用のピンを少し上に曲げて収めた

ケース(基板)の取り付け方(オリエンテーション)もかで迷った。最初はコードの引き回しの関係で縦にしたが、光センサがジャンパピンのカバーの陰になる(左側からの光が遮られる)気がしたので(写真: カバーは中央辺りの赤い四角、そのすぐ上に光センサ)、カバーを外して「肉抜き」した。(写真: ケースの中央左端にピン、そのすぐ右の丸が光センサ) ただ、この状態だとピンの保持が完全でなくて外れやすいので、あとでちゃんとする必要があった。そうこうするうちに、やっぱり横に戻したので、カバー付きのものに戻した(が、それもあとで使わなくなる)。

それから、ケースでなくても基板をカバーすればいいのではと思って、少し厚手のビニルで覆ってみた。が、ビニルを台に付けるために折って居るところに埃が溜まりそうだったので止めてケースに戻した。更に、厚いケースは不格好に思えたので、いろいろ無理して薄目のケースに収めた出来上がりは、なんとなく(実物を見たことはないが)可搬式オービスを連想させる。

※上記のアナログ入力用のピンとジャンパピンを2-3mmくらい切り詰め、ボリュームの脚を折って付けて低くした。ボリュームを低くしたあと、なぜか抵抗の両端(電源とGNDに繋がっている)がショートしてしまって起動しなくなったが、付け直したら直った。電源側がGNDのパターンに繋がってしまったのか。

更に、ジャンパピンはピンのカバーが高いので、光と温度センサのジャンパのパターンをリード線でショートしてピンを不要にした。ボリュームは滅多に使わないので信頼性はなくて良いから、ジャンパはカバーを外したピンの上部を折って低くしたものを使った。

また、幅を狭めるため、PC接続用ピンとコネクタは使わず、コードを半田付けし、外にコネクタ(XH, プラグ)を付けた。なお、電源スイッチは無意味なので付けないことにした。漏れ電流のせいか、なぜかoffでも動いてしまうので・・・

あと、温度センサ(後述)の室温への追従性を向上させるために、左右両端に通気口を開けた。まあ、気休めの気はするが・・・

それから、試している時に気付いたが、ケーブルの力が掛かって、ブルタックでケースに固定した基板の上部が浮いてしまうので(下部はボリュームなどがあって隙間がないので、動かない)、蓋に届く厚さの緩衝材(上記の楽天のもの)で上の角を押さえた

 

輝度自動調整プログラムは、基本的な動きは最初の長ーいコマンドと同様で、さまざまな明るさで確認して近似式の係数を調整した程度である。現状の、YL-40基板で測定した部屋の明るさとCX241の画面輝度(青)、それに合うように本プログラムで設定したS170の輝度(赤)のグラフを次に示す。

YL-40の明るさとCX241, S170の輝度

通常使っている明るさの領域は点が密集した辺りで、S170の輝度が変化する範囲は約15-22%と大きくないが、昼にカーテンを開けて明るくすると、右側の明るい領域になる。また、夜に照明を消した場合などの暗い領域(左側: グラフにはないが、その領域での確認もしている)ではCX241が自動調整する輝度に下限(約50cd/m2)があるため、S170も14%までしか下げられない(まあ、際限なく下げたら見えなくなるがw)。あと、前回も同様なことを書いたが、CX241はOSDで表示している輝度と実際の輝度が異なることがある(グラフで、同じ明るさで点が上下にあるところ)ようで※、その場合にはS170の輝度は合わず、「わずかに違う」状態となることがある。

※想像だが、CX241が輝度の調整速度が遅く(ユーザに急変を感じさせないため?)、OSDで見た時には まだその輝度に達していないのかも知れない。

輝度の調整以外では、随分 機能追加・改良した。例えば、測定値の移動平均(4点、約2分分)を取るようにして、頻繁・無駄に輝度を変更しないようにした。また、ディスプレイのOSD(メニュー)で手動で変更した輝度を自動調整に加味できるようにした(具体的には、変更分を加算して設定する)。その際、PCの省電力機能(DPMS)やスリープからの復帰時にディスプレイが消灯状態から点灯した時に自動的・一時的に画面が明るくなって輝度が大きくなっているのを、手動での変更とみなさず無視するようにした。

他には、起動時に基板やS170の接続をチェックし、接続されていなかったらエラーで終了するようにした。

あと、全くの お遊びだが、起動時と毎回の測定後にLED(基板のIC PCF8591のDACに繋がっている)を一瞬弱く点灯させて、動いているのが分かるようにした。LEDに関しては、電源LEDが明る過ぎて目障りかつケース内面に反射して光センサに影響を及ぼしそうなので、パターンカットして点灯しないようにした。当初はLEDの上にハリ玉を被せて見えないようにしたのだが、明る過ぎるためか光が通ってしまうので、点かないようにした。

 

「ついで」の温度測定については、前回参考にしたGayの本に書いてある計算式(下記)を用いて、センサ(サーミスタ)の値から実際の温度を計算するようにした。※ 恒常的な誤差が約1℃*あるのと**、部屋の気流が かなり影響するが、定常状態になれば概ね(本物の)温度計の値に近い温度が得られることが分かった。

サーミスタ(NTC)の温度T(K)を求める式: 1/T= 1/T0 + 1/B * ln(R/R0)

定数・係数

    • R: 温度Tでのサーミスタの抵抗 (Ω)
    • B: サーミスタの「B定数」
      • 試行値: 3947
    • R0: 温度T0(「室温」)での抵抗 (Ω)
      • 試行値: 当初: 4700 → 現在: 5000 (Ω)
    • T0: R0の温度, 「室温」 (K)
      • 試行値: 25℃ (= 298.15 (K))

※明るさと同様に移動平均(8点、約4分分)して、値の変動を抑えた。

* その後、いくつかの室温と比較し、恒常的な誤差(オフセット?)を1.44として補正すると、更に(本物の)温度計に近い値となった。上の式を見ると、このオフセットはR0の仕様との差で生じているのではないか。実際、上の式で、Rを元の4.7kΩと別の情報で見た5kΩで比較すると、現在の通常の室温約28℃での差は約1.4℃と上のオフセットに合うので、現在はR= 5kΩ, オフセット= 0で試している。

なお、別品種のBやR0でも試したが、良い結果は得られなかった。 (8/7 10:30)

**書いたあとで気付いたが、基板に載っているサーミスタの仕様が分からないので、別のページに書かれた値("YL-40 #1"の、25℃での抵抗値=4.7kΩ, 係数B=3977)を使って計算しているのだが、実はそれも正しくないために温度の差が出ている可能性は否定できない。

ただ、ADCの量子化ステップ(室温では約0.6℃相当)の関係で※、室温との差が、大きい時(例: 室温がじわじわ上がっている時)には1℃近くなるので、エアコンの微妙(「自分にとって快適な」の意味)な調整には向かなそうだ。とは言え、そもそも、室温を正確に測っても、それでエアコンの微妙な調整ができる訳では全くない(物理的な温度よりも体感温度が重要)から仕方ない。まあ、大まかな室温が分かって自動的に記録できれば、何かの役に立つかも知れない。

※この点は、回路を変更して狭い温度レンジにADCのレンジ(0-255)を割り当てるようにすれば(要するに、「倍率を上げる」)、もう少し分解能(精度と同じではない)が上げられると思うが、具体的にどうすればいいかは まだ分かっていない。

→ その後検討して、サーミスタに直列に接続されている抵抗(R1, 1kΩ)を大きくすれば、ある程度 分解能を上げられることが分かった。

使用する温度範囲でセンサ出力をADCの入力レンジに最適化するには、ADCの前で増幅する必要があるが、アンプを入れるのは面倒だし、「ついでに」やっていることなのに、そこまでする意味がない。もしかしたらADCにPGA(プログラマブル・ゲイン・アンプ)が入ってないかと思ったが、さすがになかった。

計算では、R1を4.7kΩにすることで、通常の室温(10-40℃)でのADC出力レンジは元の46から82(cnt※)に広がり、分解能(上記の量子化ステップと同じ)が約0.7℃/cntから約0.4℃/cntに改善できることが分かり、実際に抵抗を換えて(限られた室温であるが)試してみたら、確かに分解能が向上したようだ。

※特定の単位がないADC出力の単位の書き方が分からないので こう書いたが、何かの個数ではない。

分解能を調べるのと同時に精度も調べたのだが、やはり固定した誤差(偏差)が気になり、計算式を検討したら、サーミスタのB定数と直列抵抗の誤差が考えられた。試算では後者のほうが効くようだったので、いくつかの値を試したところ、今のところ、-0.3%の補正(抵抗が0.3%大きいと想定)が良い感じで、限られた室温での短時間での評価ではあるが、本物の温度計との差は概ね±0.4℃以内となり、冬など条件が異なる場合でもこれなら、充分に満足できそう(「許せる」)だ。 (8/7 17:18)

ところが、いつものように、そう やすやすとはうまく行かない。温度の誤差が大きくなる場合があるのだ。通常は大きくても0.4℃なのだが、なぜか0.8℃くらいになることがあって、どうも許せない。観察していると、起こりやすい温度範囲がある。温度が上がる場合と下がる場合に(起こりやすい温度範囲はそれぞれ異なる)しばらく起こる。いろいろ検討し、試行錯誤しているが、何となくADCの性能(精度)に依存するような気がしている。 (8/9 7:55)

その後、自動測定・記録しているセンサなどの値をグラフにすればおもしろいと思い、Linuxの管理ソフトMuninで取り込んでグラフにするようにした。最初は温度(室温)だけだったが、ついでに部屋の明るさとそれに合わせて設定したS170の画面の輝度も出すことにした。今までのグラフを下に示す。

明るさ(グラフの緑線)は外(天気や日照)やカーテン・照明の状態によってダイナミックに変わるので、結構おもしろい。当然ながら、画面の輝度(グラフのオレンジ線)は 明るさに合わせて変わる。室温(グラフの青線)は上記のように調整・確認中である。 (8/7 17:18)

 

というところで、あとはケースやスタンドやケーブルをちゃんとする(接着・固定や補強や外見の改善)こと、プログラムの細かい改良などである。これ以上買うものはなさそうだから、結局150円くらいでできた。

書いて気付いたが、「細かくない」問題として、CX241の輝度(自動調整のベースとなる輝度)を手で変更した場合には、当然ながらS170の輝度が合わなくなってしまう。S170の輝度を手で調整して合えばいいが、非線形なので、そうも行かない気がする。CX241の輝度を変更することがないので実害はないが、気分的には良くない。

この辺りは近似式の較正・調整の話に関連し、例えばディスプレイの設置位置や向きを変えたら再調整が必要になるかも知れない。マウスでグラフィカルにできると手軽だが(→ イメージ)、そういうものを作る気合いは なかなかないw

 

結局、今回の一番の効果は、寿命になったサブディスプレイ(M170)をスペアだったS170に交換するに あたり、格安で同等の機能(自動輝度調整)にできたことだ^^ そもそも、今はスクエア型のディスプレイは入手困難なので、(自分のスペアだから無料で)交換できたことだけでも良かった。

そして、PCにI2CのADC/DACを繋げられたので、今後はRaspberry PiやArduinoなど用のI2Cのセンサ類(既にADCがあるので、なんならセンサの素子単体でも)が容易に使えそうだから、楽しみが増えた。何をするかは別としてw

 

PS. YL-40基板は手軽でいいんだけど、僕にしてみれば いろいろ甘い。例えば、本文に書いたように、LEDが明る過ぎるとか、サーミスタの分解能など、抵抗の値の決め方が安直だ。抵抗が小さくて(ほとんど1kΩ)、流れる電流が大き過ぎる。電源スイッチを切っても電源LEDが付いたり回路が動作するなんてのは、その証拠だ。確実には動くんだろうけど、僕の好みではない。

PS2. 上を書いたあとで回路図を見ていて、電源スイッチがoffでも(電源を供給していなくても)動く理由が分かった。I2Cのclockとdataが、(プルアップのためだろうけど、)それぞれ10kΩでVcc(電源)に繋がっており、VccとGNDには平滑コンデンサが繋がっている。そうすると、clockやdataの電圧は変動するだろうが、コンデンサで平滑化されて「電源」になってしまって、IC PCF8591が動くのだ。PCF8591の動作電圧は広く、低消費電力であろうから、そういう弱い電源でも動いてしまうのではなかろうか。

まあ おもしろいけど、「ちょっと」だ。だったら無電源で(clockとdataの電力で)動くようにすればいいのに・・・

とは言え、10kΩならプルアップとしては適当な気がするから、ちゃんと対処するのは難しいのかも知れない。33kとか47kΩくらいにする? それでも動いちゃうかもね。

  •  0
  •  0

と、ベタな文句しか出て来ないジジイと成り果てて居るが、ディスプレイ輝度の自動調整システムのプロトタイプが動き出したので、ちょっとうれしい。

先日検討して注文した光センサ基板(正確にはPCF8591 AD/DA基板, "YL-40"。以下、「基板」などと書く)が、数日前に届いた。中国からだが、今回は意外に速く、1週間くらいで届いた(と思ったが、実際には注文から2週間近く掛かった。1週間というのは、発送されてからだった)。EMS(かどうかは不明だが、郵便扱い)だと速いことがあるのかも知れない。

例によって非常に簡素な梱包で、基板の入ったビニル袋が汚くて、以前の汚ねえピンジャックを思い出したが、中身の基板はピカピカだったので安心した。これなら全然問題ない。早速電源を繋いでみたら、ちゃんと電源ランプが点いたので更に安心した。

ただ、一つ謎がある。電源スイッチ(下記の暫定接続ケーブルと一緒に付けた)を切った状態でも電源ランプが薄く点くのである。おそらく、I2Cの信号線(DataとClock)の電圧がIC PCF8591経由で漏れている(一種の逆流)のだと思う。余り良くない気がするが、壊れることはなさそうだ。

それに気を良くして、暫定版の接続ケーブルを作って※PCのVGAコネクタに繋いだら、Linuxのi2cdetectコマンドで以下のように基板のアドレス(0x48)に表示が出て、I2Cデバイスとして認識できていることが分かった。

$ sudo i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

※当初は、容易に延長できることやケーブルの細さ・柔からさなどを考えて、電話用のモジュラーコードを使おうと思って居たのだが、システム構成を確定させ、ある程度「行ける」ことが分かってから そこら辺をちゃんとしようと考え、まずは手持ちの長い(約3m)バラ線4本を(切らずに)そのまま使った(切ったら端切れが出来てしまって、最後に無駄になるので)。

同様に、VGAコネクタ(これを用意するのには なかなかの苦労があった。 → 下の「おまけ1」を参照)に電源スイッチを組み込もうと思って、結構苦労して付けられるようにしたのだが、実際にはコネクタがPC背面の込み入ったところにあるためにスイッチが操作しにくいから あっさり却下して、基板側のコネクタに仮付けした。

次に、I2C経由で基板上のADCとDACを動かしてみたら、これもあっさりとできた。i2cget, i2cset, i2ctransferコマンドを使うことで、基板上のADC(光, 温度, ボリュームが繋がっている)の値が読め、DAC(LEDが繋がっている)にアナログ電圧の出力ができた。

中国製品は当たり外れが激しいというのが常識だが、今回は当たりだった。きっと、この基板は、どこかのちゃんとした人が設計したもの(メーカーの評価基板?)が回り回って手に入るようになったのだろう。で、ADCやDACとは言ってもしょぼい簡素なものなので*、部品を載せて半田付けするだけで調整なしで動くから、部品が壊れてなくて半田が付いている限り、ちゃんと動くのだろう。

*簡素とは言っても、これがあれば、サウンドカードではできなかった、直流電圧が入出力できるから、PCでできることが格段に増える、超優れものだ。

基板に書かれている"YL-40"という型番(写真左下)がポイントで、Amazonで検索した時に()その番号が見え、"PCF8591 YL-40"で検索したら、Raspberry Piなどで使っている人が多いことが分かり、その関係の資料や情報が結構あったので、これを買うことにした。

ちなみに、買ったのはAmazonでなく、残ったポイントを使うために楽天にした。Amazonより高くて約700円だったが、ポイント利用で150円くらいになった。PCF8591が載っていて、外観が希望のものと同じで、一応 基板に"YL-40"が見えるものを選んだ。ただ、それには何の保証もなく、一種の賭けではあった。

余談ではあるが、明らかに勝算がなく、失敗した時の損失なども検討せずに 大言壮語してむやみに賭けをする大馬鹿者が居るが、言語道断だ。今回は150円だったから安心して賭けられたw

なお、基板には説明書も回路図も何も付いていないので、上のような情報がないと使うことはできないだろう。謎の多い基板だが、情報が多い点で当たりだった。ただ、これを何も知らない一般の方が買って どうにかできるものとは思えず、Raspberry Piなどで使った経験者が書いたものを参考にして使っているのだろうが、最初の方はどうしたのかなど、興味深い謎は多いw

それから、基板から取得した明るさの値からS170に設定する輝度を求めるための関係を調べるため、基板の光センサ(CdSセル)の特性を調べた。CdSセルの型番はもちろん分からず、データシートを参照できないためだ。基板はビニル袋に入れてS170の脚の上に設置した。ここだと机に向かった時に見えないのと、ディスプレイの熱が当たりにくいので良い。また、基板を垂直に近くして埃が溜まりにくくした。また、電源ランプが明る過ぎるので、テープを貼って隠した。

手元に光量(「照度」などいろいろあるが、正しい呼び方は不明)の分かる・設定できるライトなどないので、日光(カーテンも併用w)や部屋の照明(明るさが調整できる)を使い、基板から取得した明るさの値と、輝度が自動調整されるメインディスプレイ CX241のOSDに出る輝度と、それに合うサブディスプレイ S170の輝度を記録して、それらの関係を調べた。

足掛け2日くらい測って、関係が大体分かった。基板の明るさ値とS170の輝度(正確にはCX241の自動調整輝度に合う輝度)は2次曲線とか指数関数のような感じ(グラフの青線)だった。※ のだが、使ったLibreOffice Calcのそれらの近似では合わないので、とりあえず、イメージに近くなる3次の近似を使った。ただし、誤差や ばらつきの影響で、測定したデータを全部使うとまともな近似にならないので、「良さそうな」もの(イメージした曲線に乗っているもの)だけを選んで、その近似式を「作った」(近似式の実体は、グラフ上部の式か下記のコマンドの"be="以降を参照のこと)。

「なんだかなあ」だが、ちゃんとした使い方をすればできるのかも知れないし、自分で指数関数なりの近似式を求めればいいのだが、指数関数だと kAbx+C + D のように、底(A)や係数など(b, C, k, D)求めるべき項がいくつもあるし、そもそも底は何が適当なのか(e? 10? その他??)分からなかったのでパスしたw

※当初は、基板の明るさの値とS170の輝度の関係は単純な式(例: 直線)にはならないと思ったので、いくつかの測定値を用いて、LUT(変換テーブル)と線形補間にしようとしていた。が、線形補間が面倒なので、できれば単純な式にしたかった。それで測定を重ねてグラフを眺めたら、上のように指数関数的なことが分かった。

なお、CX241のOSDで表示される画面輝度(グラフの赤線)は遅延やバラつきがあるのか、今ひとつ基板の明るさ値との相関が悪かった。特に、基板の明るさ45-55辺りに対応する輝度に変化がないように思ったが、今見るとS170も同様の形状なので、基板の光センサ(CdS)の特性なのかも知れない。CdSについて調べた時に、前歴依存性というのが出て来たが、それだろうか? それとも、単にCX241の輝度調整特性(この辺りだけ、明るさへの追従が鈍い?)の問題だろうか?

試行錯誤の末にできたのが、この渾身の(怒涛かつ笑える)コマンドだ。たった(?)1行で、S170の輝度を、30秒ごとに、YL-40基板から取得した周囲の明るさに合わせて、CX241に合う明るさに自動調整する。

sudo sh -c 'proc_int=30; i2c_ch=2; yl40_addr=0x48; s170_hid=0; s170_FB=0x21; usbmc_cmd=~xxxxx/misc/usbmonctl/usbmonctl; sleep_t=0.2; while true do; date; d0=`i2ctransfer -y $i2c_ch w1@$yl40_addr 0 r1`; sleep $sleep_t; d=`i2ctransfer -y $i2c_ch w1@$yl40_addr 0 r1| sed -n "s/^0x//p" | tr a-f A-F`; echo "D0=$d" > /dev/null; di=`echo "ibase=16; $d"| bc`; echo "di=$di" > /dev/null; d2=`expr 255 - $di`; echo "L=$d2"; b_s170_e=`echo "be=0.0001972222 * $d2^3 - 0.009486435 * $d2^2 + 0.1930219 * $d2 + 13.56602; scale=0; bf10= (be*10)%10; if (bf10 >= 5) {bf= 0.5} else {bf= 0}; scale=3; be2= be - bf10/10; be2= be2 + bf; scale=1; be2/1.0" | bc -l`; b_s170=`$usbmc_cmd -g "F,$s170_FB" /dev/usb/hiddev$s170_hid | sed -nr "s/^([0-9]+) .+/\1/p"`; echo "Cur. S170 B=$b_s170"; echo "EB_S170=$b_s170_e"; b_s170_e_set=`echo "scale=0; $b_s170_e * 2 / 1.0" | bc -l`; echo "New S170 B=$b_s170_e_set"; $usbmc_cmd -s "F,$s170_FB=$b_s170_e_set" /dev/usb/hiddev$s170_hid; t0=`i2ctransfer -y $i2c_ch w1@$yl40_addr 1 r1`; sleep $sleep_t; t=`i2ctransfer -y $i2c_ch w1@$yl40_addr 1 r1 | sed -n "s/^0x//p" | tr a-f A-F`; ti=`echo "ibase=16; $t"| bc`; t=`expr 255 - $ti`; echo "T=$t"; echo; sleep $proc_int; done' |& tee -a ~/tmp/yl-40-lt-2021-07-30-1.log

※「プロト」だというのを免罪符に、シェルスクリプトにすらしていないし、無駄な処理が多い。 → さすがに起動が面倒なのでスクリプトにした時に、無害だけど誤りも見付けた。 (← 修正した。: 8/1 11:14)

簡単に処理の内容・動作の説明を書く。

  1. 動作条件などを設定する。: proc_int=30; ..の箇所
  2. 以下を繰り返す。: while true ..の箇所
  3. 現在の日時を表示する。: date; の箇所
  4. ADCの光センサを読む。: d0=`i2ctransfer と d=`i2ctransfer .. di=`echo の箇所
    • 光センサのチャネル(AIN0)を読む。
    • i2ctransferコマンドを使い、読み出すチャネルを指定してから読む。
    • 変換時間の関係か、PCF8591のADCは前回変換した値が読み出されるため、少し(約0.2秒)間を開けて2回読んで現在の値を得る。
  5. 取得した値から明るさを求める。: d2=`expr 255 ..の箇所
    • 値は反転している(明るいほど小さい)ので、最大値(255)から引いて反転させる。
  6. 明るさの値を表示する。: echo "L=$d2"; の箇所
  7. 明るさから近似式でS170に設定する輝度を求める。: b_s170_e=`echo .. be2= be2 + ..の箇所
    • 設定する輝度は0.5単位なので丸める。
  8. 参考のため、S170の現在の輝度を取得する。: b_s170=`$usbmc_cmd ..の箇所
    • usbmonctlコマンドを使う。
  9. 現在の輝度を表示する。: echo "Cur. S170 B= ..の箇所
  10. 上で求めたS170に設定する輝度を表示する。: echo "EB_S170= ..の箇所
  11. MCCS(DDC/CI)でS170に設定する輝度の値に変換する。: b_s170_e_set=`echo "scale= ..の箇所
    • MCCSでの値は上の値を2倍した整数。
    • MCCSとは書いたが、実際にはS170(M170もCX241も)は準拠していなくて、Featureの番号が全然違う。
  12. S170に設定する輝度(変換後)を表示する。: echo "New S170 B= ..の箇所
  13. S170に輝度を設定する。: $usbmc_cmd -s ..の箇所
    • usbmonctlコマンドを使う。
    • S170の輝度はFeature 0x21で取得・設定可能。
      • また、バックライトの輝度(推定)はFeature 0xceで取得可能。
      • それらはM170では異なるし、CX241では不可。
  14. ついでにADCの温度センサを読む。: t0=`i2ctransfer -y .. ti=`echo "ibase=16 ..の箇所
    • 光センサと同様に、温度センサのチャネル(AIN1)を2回読み、値を反転させる。
  15. 温度センサの値を表示する。: echo "T=$t"; の箇所
  16. 約30秒待つ。: sleep $proc_int の箇所
  17. 4から繰り返す。: done の箇所

実行すると、以下のように、基板から取得した明るさ("L=")、現在のS170の輝度("Cur. S170 B=")、明るさから計算したS170に設定する輝度("New S170 B")を表示する。なお、"EB_S170="はS170のOSDで表示・設定する輝度(上の測定や近似式を求める時に使った値)、"T="は基板に載ったサーミスタからの値(温度に依存する: ついでに出しているだけで、輝度設定には無関係 → この値と室温の関係は「おまけ4」を参照)である。

Fri Jul 30 21:00:12 JST 2021
L=33
Cur. S170 B=32
EB_S170=16.5
New S170 B=33
T=48

これを昨日の午後から試していた。周囲が明るい場合にS170が少し明る目だったので使うデータを調整して近似式を改良したあとは、夕方近くも朝も概ね問題なく調整できて居たので、あとは(本当の)昼間も大丈夫なら、予想より楽に動いてしまったことになる。

ちなみに、普通に使っていて設定されたS170の輝度の範囲は15-23%程度で、カーテンを開けて明るくすると40%くらいになった。また、CX241が自動設定する輝度には下限があるようで、夜 照明を消しても15%程度だった。

まあ、それから「ちゃんと」作る訳で、そうすると途端に面倒なことがいろいろ出て来るので、いつものように誰かに「あとは頼んだ」と言いたいところだw

参考資料

主に以下が役に立った。

 

おまけ1: VGAコネクタの5Vピンを「何とか」した話

以前も書いたように、EIZOのディスプレイに添付のVGAケーブルには5Vのピン(ピン9)がないので、この用途には使えないことが分かった。が、VGAケーブルもコネクタも安くない。大体500円くらいする。中古屋も見たが、新品はやっぱりそのくらいだったし、ジャンク品ですら300円くらいだったので馬鹿らしくなった。テキトーな中古VGAケーブルなんて高くても100円くらいで買えると思ったが、今は世知辛いのか・・・

何とかならないものかとコネクタを眺めていたら、180°回転させればピン9が「できる」気がした。調べたら、180°回転させた状態でも、GNDやI2Cに使うピンも大丈夫そうだった。

早速工作した。それまでに、何とかしてピン9を追加できないかと思い、すごく苦労してコネクタをモールドから取り出して居たので、そのコネクタをシェルから外し、D形状の上部左右の角を削り、180°回転させてもシェルに入るようにした。更に、回転させたために中段の左端のピン(元のピン6)が余るので切った。どうにかできたものをPCに挿したら、見事に5Vが出た。

回転させたことで嵌ったのは、基板へのコードを繋ぐ時に中段のピンの番号を1つずらしていたために、最初は電源が出なかったことだ。上述の切ったピンに相当する「幻のピン6」を考慮していなかったためである。

それから少し綺麗にして、とりあえず完成となった。

なお、本文に書いたように、コネクタに電源スイッチを内蔵させたくて、モールドの一部を切ってスイッチを嵌め込めるようにもしたが、使いにくいので却下した。まあ、いくら苦労したって、「駄目なものは駄目」と捨てる勇気は重要だ。

おまけ2: モジュラージャックを「何とか」した話

当初は電話線でVGAコネクタと基板を繋ぐことを考えていたので、モジュラージャック2個が必要だった。これは100円ショップで延長アダプタを買えば安いが、暇に飽かせて何とかした。

手持ちに電話用の3分岐のアダプタがあったので、それを「イッコニ化」wした(2個のジャックに分割した)。3分岐のために、丁度、2個のジャックからの線が使えるので良かった。ケースを切断し、少し綺麗にしVGAコネクタに接着できるようにして完成となった。

これはまだ却下ではない。最終的に電話線で繋ぐ場合には生きる。が、何となく、そこまでする必要はなく、もっとテキトーに(例: 今のバラ線を少し綺麗にする。USBケーブルの線だけ使う。VGA側のジャックはなし)繋いでも充分な気がしている。

おまけ3: M170の光センサ基板を単体で動かした話

寿命になったサブディスプレイ M170は、光センサ辺りが壊れたと思って居たが、実際には生きていた。ちょっと試してみたら、明るさに従った電圧が出るのを確認した。

接続コード(FFC)は6芯だが、2本ずつGND、電源、出力になっていた。電源は何Vか分からなかったが、基板にツェナーダイオードが載っていたので、多少高くても壊れないだろうと思って5Vを入れたら、ちゃんと動いた。: テスターで測ったら、明るさに比例した電圧が出て、光センサ(フォトダイオード)を塞いだ場合はほぼ0Vが、ライトで照らすとほぼ5Vが出た。

あの回路はフォトダイオードがLDOの電圧調整らしきピンに繋がっていて何とも謎なのだが、そういう使い方があるのか、実際にはLDOでない(I-V変換や温度補償素子?)のか。

光センサ基板が届く前は これを使おうと思って居たが、基板のセンサ(CdSセル)が結構使えそうだし、こちらだと温度特性が不明だしシステムのサイズが大きくなってしまうので、ひとまずは保留とした。

 

おまけ4: YL-40基板の温度センサ(サーミスタ)を試した。

輝度調整コマンド(その後、スクリプトにした)で ついでに表示していた温度センサ(サーミスタ)の値と その時の室温をグラフにしてみたら、測っている時からそんな気がしていたが、今ひとつ相関が悪い。

YL-40の温度センサの値と室温

何となくリニアには見えるが、ばらつきが多い。ディスプレイの近くなので、その熱の影響があるのかも知れない。あと、サーミスタは電源ランプ(LED)のすぐ隣なので(ランプはCdSにも近いし、この配置は ひどい)、LEDの熱に影響されているのかも知れない。

まあ、これには期待して居なかったし、もう少し様子を見たり試してみたい。 (8/1 11:03)

 

PS. 気付いたら、前回の投稿から結構日が経っていた。何をしていたか記憶がないことはないが(とは言え、すぐには思い出せない)、意外に空いた。そうやってブログは廃れて行くのかも知れない・・・

  •  0
  •  0

去年、出来が良くないために移行を止めたdigiKam7。依然としてイマイチではあるが、今まで使っていたdigiKam6でGoogleの地図が出なくなってしまって※旧版の居心地の悪さを感じたのと、digiKam7にこれ以上改善の見込みがない(出している人たちは いつも「これで完璧!」のように思ってそうだ・・・)ので、仕方なく移行した。

※あとで気付いたが、地図については下記の7.3での手順と同じようにすれば出ると思うが、終わってしまった製品なので7に移ることにした。

7.3を試して気付いた問題は以下である。(Linux Mint 20 Xfceにて)

  • マウスカーソルが古臭くて嫌。
    • Xfceのテーマが反映されていないのか、古臭いものが出る。特にサムネイル選択時の「指」(下図参照)。

      digiKam7の古臭いマウスカーソル (左付近下部)

  • Googleの地図が出ない。
    • 去年は出せるように直したつもりだったが、今回は出なくなって居た(警告("This page can't load Google Maps correctly.")が出て地図が暗くなる)。
      • 調べたら、Google mapsが有料になり、digiKamではお金が払えないからOpenStreetMap(OSM)をデフォルトにしたようだ。

マウスカーソルは きっとKDEの環境なら問題ないように思う。僕はXfceなのだが、その場合にどうすればいいか分からず対処できなかった。digiKam6では問題なかったので、差分を調べれば分かるかもしれない。

→ 書いたあとでdigiKam6と7の差分を調べたら、X11のマウスカーソルのライブラリの内容が異なっていた。どうもdigiKam7のAppImageのものは古いようで、システムのものに比べて以下のsoが不足していた。

    • libXcursor.so.1.0.2
    • libwayland-cursor.so.0.0.0

それで、最新のカーソルのライブラリを参照するようにしたら、正常なカーソル(下図)になった。手順の概略を最後に示す。

修正したdigiKam7のマウスカーソル (中央付近下部)

なお、digiKam6にはカーソルのライブラリは入っていないので、システムのライブラリが参照されて正しいカーソルが出たようだ。

カーソルが正常になっても そもそものデザインが古い感じなのは否めないが、デスクトップの他の要素と統一されたので良しとする。 (16:37)

 

試行錯誤して、Googleの地図が出るようになった(手順の概略を最後に書く)。最初はOSMでも我慢できそうに思ったが、やっぱりいろいろ今ひとつなので、Googleの地図を出せるようにした。ただ、Googleを使う設定が設定ファイルに保存されず※、digiKamを起動するたびにOSMに戻ってしまうのが気に入らない。いろいろ調べたが直せなかった。まあ、地図は余り出さないし、Googleが出ないよりはいいが、性根が悪いと言いたくなる。

※その後の試行錯誤や調査で、設定変更後に設定ファイルに保存はするが、起動時に必ずOSMになってしまって反映されないようであることが分かった。6と7のソースを比較すれば確証が得られるかも知れないが、分かっても修正が困難なので馬鹿らしい。 (7/18 9:16)

他に、(いつもやっている、)日本語入力ができるようにして(→ 参照)、とりあえず使えるようになった。

 

全般的に、digiKamの「製品」としての詰めは甘く、そのうえAppImageになっているせいでライブラリや設定など、いろいろなことが混沌としている。リリースしてから随分時間が経っても、そこら辺の細かいことを全然書いてくれないのはとても困る。Googleの地図を止めた件だって、僕が調べた限り、フォーラムでの質問への回答にしか書いてない(→ 参照)のでは、みんな分からなくて困るのではないか。

AppImageは手軽に動かせるのは いいが、上述のマウスカーソルのようにライブラリの競合でうまく動かないことがあり、その場合は容易には原因が分からないので今ひとつだ。デモ版とか試用板ならいいが、正式版でも延々と使い続けるのは良くない。かといってSnapは最低なので止めてほしい。Flatpakは良く知らない。次善の策は、AppImageを展開して自分でインストールすることだろうか?? (16:32)

 

注: 以下はLinux Mint 20 Xfce (x86 64bit)の場合である。その他のLinuxやWindowsやmacOSについては各自考えること。

digiKam7の古いマウスカーソルを直す手順 (概略)

※AppImage中の古いライブラリが余計なので、本来はそれらを削除すればいいのだが、AppImageを作り直さずに済ませる方法を考え付かなかったので こうした。

  1. システムのマウスカーソル関係のライブラリをローカルな場所(例: $HOME/.local/usr/lib/x86_64-linux-gnu)にsym-linkする。
    • 例:
      1. cd
      2. mkdir -p .local/usr/lib/x86_64-linux-gnu
      3. cd $HOME/.local/usr/lib/x86_64-linux-gnu
      4. ln -s /usr/lib/x86_64-linux-gnu/libXcursor.* .
      5. ln -s /usr/lib/x86_64-linux-gnu/libwayland-cursor.so* .
  2. digiKam7のAppImageからAppRunを取り出し、その中のLD_LIBRARY_PATHの設定の最初に上のディレクトリを追加する。
    • 例: export LD_LIBRARY_PATH="$HOME/.local/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH"
  3. digiKam7をそのAppRunで起動する。 (上記のようにLD_LIBRARY_PATHを設定して、AppImageを起動するのでもいいかも知れない。)

digiKam7でGoogle mapsを表示させる手順 (概略)

  1. Google mapsのAPIキーを取得する。→ 参照
    • 注意: Google mapsは有料なので、有効なGoogleアカウントと支払い方法が必要。
      • 料金: digiKamで使うMaps JavaScript APIは1000件で7USD。ただし、毎月200USD分までは無料。
  2. digiKam7のAppImageをマウントする。
    • 例: ./digikam7.appimage --appimage-mount
  3. マウントしたAppImageから、Google mapsを表示するファイル(下記)をローカルな場所($HOME/share/digikam/geoiface)にコピーする。
    • (マウントされたディレクトリ)/usr/share/digikam/geoiface/
      • backend-googlemaps.html
      • backend-googlemaps-js.js
  4. コピーしたbackend-googlemaps.html中のGoogle mapsのAPIキーを自分のものに変更する。
      • 例: 下のXXXXXXXXの部分に自分のAPIキーを書く。
        • <script type="text/javascript"
          src="https://maps.google.com/maps/api/js?key=XXXXXXXX"></script>
      • 注意: APIキーが漏れると他人に使われて料金が増大する可能性があるので、取り扱いに注意すること。
  5. digiKam7を起動し、地図を表示する。
    • digiKam7で標準のOpen Street Mapの地図

  6. 地図左下の地球のボタンのメニューで"Google Maps"を選択すると、Google mapsが表示される。
    • digiKam7でGoogle mapsを表示

 

digiKamの作者たちは ただGoogle mapsを止めるのでなく、Google mapsのキーを設定すれば使えるようにすればいいと思うのだが、なぜかそういう考えはないようだ。お金が絡むので、問題が起こるのが嫌なのだろうか。

それから、(これを言ったら悪いけど、)新バージョンが出ても、問題が直っていないうえに、いろいろ機能が増えても魅力的なものが何一つなくて溜息が出るのはなぜだろうか? digiKamのメインとなる多くのユーザーは僕とは離れたところに居るのだろうか?

 

あと、Google mapsを含むGCPのページは大変分かりにくく、こっちも性根が腐って居ると感じた。※ こんなのだったらGCPは使いたくない。それと同時に、他のページ同様に日本語の翻訳がクソなので更にひどくなっているのではないか。

※仮に性根が悪くないのなら、真面目にやって あんな使いにくい物しか作れない能またはセンス無しだ。

  •  0
  •  0

昨日、Linuxのメモリ消費が多くなって来たので※再起動したら、青天の霹靂。なぜかSpotifyアプリが激変してしまった。

※いろいろなアプリがメモリリークしていて、長期間動かすとそれが溜まるせいだと思う。

今考えると、おそらく少し前にアプリが更新されていた※のだが、アプリを再起動していなかったので更新が反映されなかったのではないかと思う。そういえば、3月末辺りに"Made for you"が変わったのは、これの関係だったのかも知れない。その変更の時は、「なかなか良くなった」と喜んでいたのだが・・・

※問題のバージョンは1:1.1.55.498.gf9a83c60

少しいじっただけで、以下のような違いに気付いた。

  • なくなったショートカットキーがある。
    • 例: 前・後ページ(表示内容)への移動 (Alt+←, Alt+→)
  • 設定のAboutがなくなったので、バージョンが表示できない。
    • 細かいことだけど、「どうよ」と思う。
    • 前の版に戻して(後述)気付いたのだが、実はAboutはあったけど気が動転して気付かなかったのかも知れない。
  • ライブラリにMade for youのタブがなくなった。 → Homeから表示しろってことだろうか。
  • 画面のデザインが煩雑になってしまった。
    • Web版に近い気がする。
  • 起動時にdevilspieでの位置指定が効かない。
    • 起動後は効くので、起動時のアプリ名が変わったのだろうか?

ショートカットキーがなくなったのは とても不便だ。今までは、マウスジェスチャ(右クリック+左/右ドラッグにAlt+←/→を割り当てた)でページ切り替えしていたのができなくなってしまった。

すごく不便なので、何とか対処したいが できないだろうか? xdotoolで試したが、それらのショートカットキーの対応自体がなくなった感じだ。

デザインはまさに劣化と感じる。その劣化度は、以前のがどうだったか思い出せないくらい強烈だ。。。 一番嫌なのは、再生中の曲の左のアイコンがちょろちょろ動くことだ(画像の黄色い円の中)。ひょっとしてアニメGIF? 90年代じゃねーんだよ!! そもそも、ページに画像や色が無駄に多くて全く鬱陶しい!!! 鬱陶しいので余り表示させたくない。

以前のが簡素過ぎたのかも知れないが、目障りでない点ではずっと良かった。

それで、試しに(、デザインがどうだかは分からないが、)Winodws版アプリをWineで動かそうとしたら、「管理者アカウントではインストールできない」というエラーとなって、諦めた。。。

 

不思議なのは、この劣化を検索しても出て来ないことで、誰も気付いていないのか、多くの人は新しいデザインが好きなのか、Linux版を使っている人がすごく少ないのか、僕の環境がおかしいかのどれかだ。

想像だが、Linux版のメンテが面倒になって、UIに関しては基本的にweb版を表示するようにして手を抜こうと思ったか、逆に、下手に頑張っちゃってLinux版をWindows版に寄せたか共通化してしまったのかも知れない。

 

今はまだ耐えられるけど、更にLinux版の手抜きが進んで、消滅(Evernoteのように「Web版を使ってね!」)という憂き目になったら すごく困るな・・・ その時はまた「移動」かも知れないな。もちろん、行く先があればだが・・・

とりあえず、(クソな状態で使いたくないが、そんなのに対応するのは時間の無駄だし そんなパワーもないので、)アプリを前の版に戻したら(コマンド例は下記)、当然ながら元の表示・動作になった。ただ、いつか使えなくなりそうだ。

sudo aptitude install \
spotify-client=1:1.1.42.622.gbd112320-37

Spotifyアプリを前の版に戻して、平和が戻った。

即座に更新マネージャが更新の案内を出したが 「無視」にして、しばらくは これで お茶を濁そう^^

  •  1
  •  0

以前ちょっと書いたように、Androidスマフォでの自動処理などに便利に使っていたAutomagicが終了になってしまったので、他の同等なアプリに移るか使わないで済むようにしようとしていた。具体的には、それまで使っていた2つの処理: スマフォ内の画像のPCへの自動転送とWriteNoteの代わりのメモ作成・送信が対象だった。

調べてみると、有名なTaskerは余りにも操作性が悪いとのことだったし(あと、デモ版がない)、ちょっと試したAutomateは まあ悪くなかったが、またいつか使えなくなる可能性があるのは嫌だし、電池を食う可能性があったので、そういうアプリを使わないで済む方法を考えた。

WriteNoteの代わりについては、以前も書いたように、比較的容易にBNoteという自分用サービスができた。自分のサーバでノートを記録するサーバプロセスを動かしておき、スマフォのブラウザで書き込むものである。

残ったのはスマフォ内の新規画像(動画、音声も可能)のPCへの自動転送だが、これがなかなか難しかった。技術的には全然高度ではないが、Automagicなどのようなアプリなしでスマフォを外から状態取得・制御することは不可能なので、そこを「なんとか」するのが難しかった。具体的には、スマフォ内に新規画像が出来たことはスマフォしか知っていないが、AutomagicなどがないためPCに通知することができないのだ。

それでも、いろいろ考え、試行錯誤やAndroidの動作を確認して、以下のような処理にした。スマフォ側アプリは使わないので、全部Linux PCからの処理だが、念のため、処理の主体として"[PC]"と書いた。

  1. [PC] スマフォがLANに接続され、sshが通じるまで待つ。(= スマフォが室内に入ったか、スリープが解除されるまで待つ。)
  2. [PC] スマフォ内の新規画像の有無を調べる。
  3. [PC] 新規画像があれば取り込む。
  4. [PC] 少し(今は3分)待つ。
  5. [PC] スマフォがLANに接続されていてsshが通じていたら、2へ。
  6. [PC] スマフォにsshが通じなくなったら、1へ。

最初に書いたように、元々Automagicのプログラムからの通知を契機に画像をPCから取得するプログラム(システム)があったのだが、それを上のような処理もできるように変更(機能追加)した。従来のはサーバーモード、今回のはpull(またはポーリング)モードと呼んで居る。今回は、上の処理の3以外の部分を作った(正確には、共通部分=3は同じものを使いたかった)。

なお、「スマフォ側アプリは使わない」と書いたものの、実際にはsshサーバアプリ(SimpleSSHD)を使っている。これにより、PCからスマフォに接続してコマンド(多くのLinuxコマンドが使える)を実行したり、スマフォのストレージにアクセスしたりする。sshサーバ(sshd)はとても汎用的なので、Automagicのようにディスコンになって困ることはまずない。ある製品がディスコンになっても、互換の別のものに置き換えることが容易なためだ。

スマフォ内に新規画像が出来たことをスマフォから通知できないので、PCから定期的に調べる(ポーリング)ことにした。この方法はほとんどいつも無駄にファイルを検索するので好きでないが、仕方ない。頻繁にストレージにアクセスすることで電池消費率が増えなければ良しとしたが、今のところ問題なさそうだ。Androidの仕様なのか、スリープ状態の時は処理が遅くなる(例: 新規画像の検索(の開始)に1分以上掛かることがある)ので、GUIでないプログラムも省電力化されているようだ。

それから、外から帰って来た時などに、スマフォへの接続がなかなかできない問題があった。いろいろ調べたら、スマフォがルータに接続していないためで、当たり前のことだった。Androidはあまり頻繁にWi-Fiをチェックしないようだ。帰宅して画面を点灯しないでいると数十分は繋がらないので、15-30分間隔だろうか(それで、以前は即座に繋げるようなフローをAutomagicで作ったのだが、電池を食うので止めた)。

もう一つの問題は、やはり省電力化に関係すると思われるが、sshで繋がっても、コマンドによって処理が遅いものがあることだ(速いコマンド・場合があることが謎である)。具体的にはrsync(新規画像の取得に使う)が遅くなることが多かった。また、find(新規画像の検索に使う)も遅くなることがある。正確には、どちらも実行が遅いのでなく、起動するのが遅いようだ。rsyncは数分間掛かることがあり、普通の設定だとタイムアウトしてしまう。かといって、タイムアウトを10分などにするのも今ひとつだ。

それで、試しに、sshfsでスマフォのストレージをPCにマウントして画像取得してみたら、マウントされるのが遅いことがあるものの、その後は高速に処理できたので、画像取得はsshfs+rsync(スマフォのストレージをローカルととして扱う)で行うことにした。

ただ、そんなことは(今まで使っていて、今回も使っている)画像取得プログラムは想定していないので、いろいろな対処(「調整」)をした。それらを場当たり的でなく、なるべく汎用的にするのが大変だったが、「まあまあ」だ。

その他に、スマフォの処理状況をPCは分からないので、書き込み中の中途半端な画像を取り込んでしまうのを防ぐことにした。これも どう実装するか悩んだ。結局、ファイルの更新時刻が新し過ぎるものは取り込まないようにした。※ 具体的には、ファイルの更新時刻が現在時刻より1分以内のものは次回(約3分後)に取り込むようにした。

※他の方法として、画像ファイルなどの中身(が正しいか)をチェックすることも可能だが、既存のプログラム(例: ffmpeg, ImageMagickのidentify)で最後の数バイトが欠けても分かるものはなさそうだったので、止めた。

ただ、3分待たずに画像を取り込みたいこともあるかも知れないので、以前同様に手動取り込みもできるようにした。スマフォ側からは、ブラウザでPC側のサーバに(従来と類似の手順で)アクセスする(通知を送る)ことでできるようにした。PC側からは、上の2と3の処理を(周期的なタイミングでなく、)僕のしたいときにするような処理にしている(従来と同じ処理)。

細かい工夫として、スマフォのIPアドレスはルータの設定や交換などで変わる可能性があるが、そのたびにPCの画像取得の設定を変えなくても済むように、スマフォをMACアドレスで管理し、通信する時にarpコマンドでIPアドレスを調べるようにしている。なお、スマフォやPCが起動直後などでarpテーブルに登録されていない場合は、broadcast pingなどで調べるようにした。

 

作って(正確には既存プログラムの改良)出来て、それなりにちゃんと動き出した。手前味噌だが、スマフォで写真を撮影したり画面キャプチャして少しすれば(忘れて居たりするw)勝手にPCに来て、digiKamで"New"のタグが付けられていて一目で分かるので、かなり便利だ。

 

という訳で、めでたく(というか、多くの場合と違って何も問題はなかったので、めでたくはないのだが)Automagicを使わなくすることができた。

 

(バックグラウンドで動く、純然たるサーバプログラムなので全く画像がない。出すとしたら、(ハッカー映画みたいな)ターミナルにデバッグ文字列が流れる動画?w)

  •  0
  •  0

先日買ったLogitecのHDDケース(ビデオ用)が僕のPCや別の外付けHDD(バックアップ用)と相性が悪いようで、USB3では まともに繋げられないことが分かった。もちろん、そもそも、ビデオは観ないので気にする必要はなく、そのまま「そういうものだ」と目をつぶって忘却の彼方に放り出せばいいのだが、それはできない相談だw 随分試行錯誤して、原因に関係ありそうなことが分かって対処ができ、今は無事USB3で繋がるようになった。

環境

  • マザーボード: ASUS P8H67-V
    • USB3のコントローラ: ASMedia ASM1042
  • HDDケース
    • Logitec LGB-EKU3 (= LHR-EKWU3BK)
    • センチュリー 裸族のインテリジェントビル5Bay CRIB535EU3
  • OS: Linux Mint 20 Xfce

現象

  • LogitecのHDDケースに入れたHDDとセンチュリーのケースに入れたHDDをASMediaのUSB3ポートに繋いで同時に電源を入れると、片方(ほとんどはLogitec)が認識されないことが多い。
    • 認識されない場合、Logitecの電源はoff(ランプが消灯)になる。
    • 片方ずつ電源を入れた場合はほとんど問題ない。
      • ただし、センチュリーのケースはタイミングによっては起動しないことがある(offにした直後にonすると、まず駄目)。
      • Logitecもたまに駄目なことがある。
  • 認識されなかった場合、lsusbコマンドでも表示されない。
  • 認識されなかった場合でも、問題のドライブのUSBコネクタを抜き挿しすれば直る。

原因に関係ありそうなこと

  • ドライブを接続した場合、システムのログ(syslog)には、USBのconfig error(詳細は不明)が出ることが多い。
  • センチュリーのケースは一旦High Speedで認識され、すぐに切断されてSuper Speedになることが多い。
    • ただし、上の2つの現象が起こっても正常に認識されることもある。
  • 以下は推測
    • センチュリーのケースの電源が経年劣化で弱くなっていて、電源投入直後の動作が不安定。
      • 仕様上は電源の容量は足りている(HDDの起動時の消費電流を概算で確認した)。
    • Logitecのケースの自動電源オフ機能がせっかち過ぎて、アイドル(USBプロトコル的に非接続)状態だとすぐにoffになってしまう。
      • この状態になると、PCに繋がっていないのと同じなので、電源off/onや抜き挿しする以外は何もできない。
    • ASM1042が古く、USB3対応が怪しい。
    • 同様に、マザーボードも古く、BIOSのUSB3対応が怪しい。
    • 同様に、LinuxのASM1042ドライバが怪しい。

関係なかったこと・試さなかったこと

  • UAS(USB Attached SCSI)が問題になるという情報があったが、どうもASM1042(またはLinuxのドライバ)は対応していないようで(ログに非対応というメッセージ("usb 4-2: USB controller 0000:05:00.0 does not support streams, which are required by the UAS driver.")が出る)、UASを有効にしても無効にしても、現象には関係なかった。また、速度も変わらなかった。
    • ただ、非対応と出るので、念のために無効にしている。
    • 古い情報(2014)だが、LinuxではASM1042のUASはうまく動かないために、無効にするパッチが出ていたようだ。それが今はどうなっているかは不明(無効にはなっておらず、致命的な問題もないが、うまくも動かない)。
  • ドライブやケースが冷えていることは関係なかった(寒い朝に起動しても問題は起こらなかった)。逆に熱いほうが関係しているのだろうか? あるいは、純粋にタイミング的な問題で、温度には無関係なのかも知れない。
    • 今日の昼の比較的暖かい時に試したら問題なかったので、温度は関係なさそうだ。 (12/15 16:50)
  • BIOSのUSB関係の設定はいくら変えても関係なかった。
    • 意味が分からないものがほとんどで、マニュアルにも書いてないものがあり、手探りで試した。
  • 以下は試さず。
    • BIOSのファームウェアは最新なので、更新しようがなかった。
    • ASM1042のファームウェアは公式に配布されていないので、更新しようがなかった。
    • どちらかのドライブをUSB3のハブを介して接続すれば、あるいは、別のUSB3インタフェースボードを使えば直りそうな気がしたが、どちらも手持ちはないからお金が掛かるし、わざわざ古いPCに追加するのは馬鹿らしいので止めた。
    • センチュリーのケースの電源を交換したかったが、やっぱり手持ちはないので、壊れてからにすることにした。
    • 書いたあとで気になったが、どちらかあるいは両方のケーブルが悪いということはあるだろうか? まずないとは思うが、そういうオチもあるから怖い。

対処

  • 問題のドライブ(のUSBコネクタ)をソフト的に抜き挿ししてみたら、うまい具合に両方のHDDが認識されたので、処理を自動化するプログラムを作った(次項を参照)。
    • 検索したら いくつかの方法が見付かったが、USBコントローラを無効にしてから有効にするのが効果があった。 (→ 参照)
      • 具体的には、LinuxのUSBコントローラのunbindとbindという制御ファイルにコントローラのデバイスID(Linuxのデバイス関係にはいろいろな名前があるので、正しい呼び方は分からない)を書き込む。
        • 例(super userで実行):
          • dev_id="0000:05:00.0" (/sys/bus/pci/drivers/xhci_hcdの下にIDの名前のディレクトリがあるので、対象のものを探す)
          • 無効化: echo $dev_id > /sys/bus/pci/drivers/xhci_hcd/disable
          • 有効化: echo $dev_id > /sys/bus/pci/drivers/xhci_hcd/enable
      • この方法だと、そのコントローラに繋がっているすべてのデバイスが切り離されてしまうので、多くのデバイスを使っている場合は余り便利でない。(別のコントローラに繋がっているデバイスは全く問題ない)
    • 念のため、抜く前に、認識されてマウントされているディスクをumountすることにした。

ソフト

  • 問題発生の検出と対処を自動化するスクリプト(chk-usb3-mf.sh)を作った。
  • chk-usb3-mf.shは以下の処理を行う。 (概要)
    1. システムのログ(/var/log/syslog)にメッセージが記録されるたびにチェックし、問題に関係のあるイベント(下記)を抽出して、それぞれに対応する処理を行う。
      • USB config error (例: "usb usb4-port1: config error"): 処理に必要ではなく、参考のために抽出している。
      • Super Speedデバイスの認識 (例: "usb 4-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd"): それほど重要ではなく、参考のために抽出している。
      • High Speedデバイスの認識 (例: "usb 3-1: new high-speed USB device number 2 using xhci_hcd"): 処理に必要ではなく、参考のために抽出している。
      • SCSIデバイスの接続 (例: "sd 6:0:0:0: Attached scsi generic sg3 type 0")
        • なぜか、ディスクIDの先頭は"sd"の場合と"scsi"の場合があった。
      • ディスクのマウント (例: "Mounted /dev/sdd1 at /media/XXXX/VOLUME on behalf of uid YYYY"): 上のattachと比べてマウントには時間が掛かるので、今は参考程度にしか使っていない。
      • 周期タイマー(ログのイベントではない): タイムアウト処理のため、一定時間(2秒)ごとに起動する。
    2. SCSIデバイスが接続されたら、ディスク数を+1する。
    3. ディスク数が想定値(2)になったらOK(= 問題は起こらなかった)なので、タイマを停めて内部状態をリセットする。
    4. そうでない場合はタイマを起動する。
    5. タイマがタイムアウトした(前回のSuper Speedデバイスの認識から規定時間(6秒)以内にディスク数が想定値(2)にならなかった)場合、問題が発生したので、USBの再スキャン(USBコントローラの無効・有効化)処理を行う。
      1. 再スキャンを行うかのダイアログを出す。
      2. 回答が「行う」の場合は、以下を実行する。
        1. Super userの権限が必要なので、以下の処理をpkexecを使って行う。
        2. 認識されたディスクがマウントされていたらumountする。
          • タイミングによっては、問題を検出したときはドライブを認識だけしていて、この処理の直前にマウントされる場合があるので、ドライブのデバイス名が分かる場合は、エラーになってもいいのでumountするようにした。
        3. そのディスクのUSBコントローラ(= ASM1042)を無効にする。
        4. 少し(1秒)待つ。
        5. 無効にしたUSBコントローラを有効にする。
        6. 少し(1秒)待つ。: 不要と思われるが、念のために入れた。
      3. 内部状態をリセットする。

結果

  • 成功: おそらく10回以上試したが、問題の発生を確実に検出できてダイアログを表示し、そこで指定することでUSBデバイスの再スキャンを行って両方のドライブを認識できるようになった。

その他

  • 電源投入直後に比べ、コントローラの無効・有効後のドライブの認識はすごく速い。これが何か関係あるのかも知れない。
    • 単に、HDDなので電源on後に回転数が上がるのを待つ時間があるだけなのか?
  • ASM1042のSuper SpeedとHigh Speedは、仮想的に別のポートとして扱われている(LinuxではデバイスIDが異なる)。
  • 一度、ファイルマネージャ(Thunar)の動作がおかしくなった。Thunarのボリューム管理と本プログラムのumount処理が競合したと思われる。
  • 想定した数のドライブが接続されていることを前提にしているので、本当にドライブが少ない場合でも問題が起こったと認識してダイアログが出るのが今ひとつ。
    • ドライブが認識されていない状態ではドライブが繋がっているかどうかは分からないので、ドライブ数を自動で判別するのは難しい。
  • イベントのチェックや再スキャン処理の実行はもっとスマートな方法(udevを使う?)があると思うが、udevはなかなか手ごわいので、今回は見送った。
  • 本当はダイアログを出さずに自動的に再スキャンしたいが、無限に再スキャンし続けることがありそうなので、今は止めている。

 

これでめでたくLogitecのHDDケースもUSB3で繋げられるようになった。USB3になった効果としては、転送速度が約2倍(80MB/s前後)になった。とはいえ、何度も書いているように、このHDDを使うことはほとんどないので、あくまでも自己満足の世界であるw

ただ、USBポートのソフト的な抜き挿しは以前からやりたかった(何度も失敗していた)ので、用途は限定的ながらもその方法が分かったのは、収穫だ。

 

そして、(前に書いたが、)Logitecのケースについては、この処理に加えて、定期的にアクセスすることで自動電源オフ機能を実質無効化できたのと電源・アクセスランプを前面に付けたので、ようやくまったく普通に使えるようになった。いやぁ、全く面倒な奴だ・・・w

 

PS. デバッグや動作確認で何度もoff/onすると、いつかセンチュリーの電源が壊れそうで ひやひやしていたが、今はまだ大丈夫そうだ。でも、古いもの(2011年に購入)なので いつかは壊れる気がする。

  •  0
  •  0