Dynabook（T75）のHDDを修復（その3）WindowsREの復活

 　前回述べたようにBCDの回復（再構築）は、

> bootrec /rebuildbcd

で出来るが、これでは回復環境（WindowdRE）は回復出来ない。

　WindowsREを回復させるには reagentc コマンドを使う。ただ、reagentc はデフォルトでは現在立ち上がっているシステムを対象としているので reagentc をWindowsPEから使うには一工夫が必要である。

 先ず、reagentcを使うには予め回復環境のボリュームにドライブ文字を割り当てる必要がある。ディスクの管理情報を表示させ、その中で回復環境（WinRE）のVolumeは非表示となっているのでこれにドライブ文字を次の様に割り付ける。次の下線の文字が入力するコマンドである。

> diskpart
DISKPART> list volume
DISKPART> select volume N   ...NはWindowsREの含まれるVolume番号
DISKPART> assign letter R   ...仮に文字Rを割り付ける
DISKPART> list volume
DISKPART> exit

　これを実行した結果、次の様にWinREのボリューム(Volume 3)にRが割り付けられている。なおVolume5,6はWindowsPEの入ったUSBメモリーなので無視してよい。

 WindowsREの実体はWindowsRE.wimというファイルで、これはR:¥Recovery\Windowsのディレクトリ（フォルダ）に収納されているが（私のケースでは）Windows以下が隠しファイルになっていて表示されず、危うく欠落していると判断するところだった。パーティションの容量とボリュームの空き容量が余りにも違う（0.5GBほど少ない）事から何か隠れていると追及して分かった（隠しファイルを表示したい場合はdirコマンドに/a:hオプションを付ける）。

　reagentc はWindowsPEには含まれないのでC:ドライブにあるものを使う。そのため次の様に先ずカレントディレクトリを C:￥Windows￥System32 に移す。

> c:
C:￥> cd ￥Windows￥system32
C:￥Windows￥System32>

 回復環境の場所をBCDに設定するには次のコマンドを使う。/target が起動したディスク以外のディスクに設定する場合の書き方である。

C:￥Windows￥system32> reagentc /setreimage /path R:￥Recovery￥WindowsRE /target C:￥windows

次に 回復環境を起動可能にするには、 

C:￥Windows￥system32> reagentc  /enable  /osguid {guid}

とする。ここで/osguid の引数の{guid}は bcdedit /enum /v で表示されるブートローダの identifier の値（GUID）である。

 これらを適用した結果、BCDのdefaultのブートローダーには次の様に recoverysequence や recoveryenabled が追加されWindowsREが立ち上がるようになった。

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  ja-JP
default                 {default}
resumeobject            {5ef36c70-b615-11ec-93cb-806e6f6e6963}
displayorder            {default}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 10 Home
locale                  ja-JP
recoverysequence        {8d7ba65d-b72b-11ec-b0fc-b5353a56518a}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {5ef36c70-b615-11ec-93cb-806e6f6e6963}
bootmenupolicy          Standard

 ここまで出来て回復環境が使えるようになったので、あとはDynabookの持ち主にやってもらう事とした。

メデタシ、メデタシ。

 

 

 

 

 

 

 

 

Dynabook（T75）のHDDを修復（その2）Windowsの復活

　前回、壊れたHDDからエラー付きでクローンもどきを作ってユーザデータを吸い上げることが出来たが、クローンもどきを実装したDynabookは立ち上がらなかった。この状態でマイクロソフトからWindowsのインストーラをダウンロードしピュアなWindows10をクリーンインストールすることは出来るが、出来ればDynabookの回復環境（WindowsRE）を起動してメーカー提供のアプリを含む工場出荷時の状態に戻せるようにしたい。
　このままでは回復環境が立ち上がらないので作業用PCで（rufus使って）USBメモリーにWindowsPEをインストールし、そのUSBメモリーからDynabookを起動して作業する事にした。
　F12を押しながらDynabookを起動し、USBメモリーから立ち上げ、キーボードの選択を行い、次のインストール画面の左下に小さく表示された「コンピュータを修復する」をクリックし（このとき間違っても「今すぐインストール」をクリックしてはならない）、

 

次に「トラブルシューティング」に移り、

メニュー中の「コマンドプロンプト」を起動する。

　ここで先ずGPTの起動情報（EFIパーティションの中にあるBCDファイルの内容）を確認する。それにはBCDEditコマンドを使う。
　コマンドプロンプトから bcdedit  /enum を実行すると、

>bcdedit  /enum

 Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume7
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  ja-JP
inherit                 {globalsettings}
default                 {default}
resumeobject            {3990bcde-b3ba-11ec-81f0-e8a48f166c51}
displayorder            {default}
toolsdisplayorder       {memdiag}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 10
locale                  ja-JP
inherit                 {bootloadersettings}
recoverysequence        {3990bce0-b3ba-11ec-81f0-e8a48f166c51}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {3990bcde-b3ba-11ec-81f0-e8a48f166c51}
nx                      OptIn
bootmenupolicy          Standard

といった情報が表示される。
　この中に表示されている{3990bcde-b3ba-11ec-81f0-e8a48f166c51}の様な値をGUIDといいシステム的に決まっている定数か或いは重複しないようWindowsが個別に割り当てた値である。{GUID}は「システム上の名前」であり、何処か別の所に定義され或いは存在している実体と結びついている。このほか{default}の様な{}で括られた表現はGUIDにラベル（人が読むための名前）を割り付けたものである。例えばブートマネージャーで引用されている{default}はidentifierが{default}であるブートローダーの事である。

　クローンもどきのHDDが立ち上がらないのは、完璧なクローンならばパーティションのGUIDもそのままコピーされ矛盾は生じないがクローンもどきではパーティションを作成した時点でそこに新しいGUIDが割り振られるためBCDの記述内容と実際に割り振られたGUIDが不整合を起こしているものと考えた。

　ここはダメモトでネット情報を元に管理情報を手作業で書き込んでみることにし、次の一連のコマンドを１つずつ打ち込んだ。

> bcdedit /store BCD /create {bootmgr} /d "Windows Boot Manager"
> bcdedit /store BCD /create /d "Windows 11" /application osloader
ここに新しい{GUID}が表示されるのでそれをコピーして次の{xxxx}に入れる。
> bcdedit /store BCD /set {bootmgr} default  {xxxx}
> bcdedit /store BCD /set {bootmgr} path \EFI\Microsoft\Boot\bootmgfw.efi
> bcdedit /store BCD /set {bootmgr} locale ja-jp
> bcdedit /store BCD /set {bootmgr} displayorder {default}
> bcdedit /store BCD /set {bootmgr} timeout 10
> bcdedit /store BCD /set {default} device partition=c:
> bcdedit /store BCD /set {default} osdevice partition=c:
> bcdedit /store BCD /set {default} path \windows\system32\winload.efi
> bcdedit /store BCD /set {default} systemroot \windows

　これは成功しDynabook単独でWindowsが立ち上がるようになった。しかしBCDの項目数が元のBCDより少ない。元通りの内容に戻したいがこれ以上正確に打ち込める自信も無い（実際幾つか間違った内容も打ち込んでいたが順序に意味がある可能性もあり訂正する方法が分からなかった）。

 あれこれ調べていくうちにbootrecコマンドを使うともっと簡単にBCDを再構築できる事が分かった。そこで次の一連のコマンドで改めてBCDを再構築した。

> bootrec /fixmbr
> bootrec /scanos
> bootrec /rebuildbcd

 これで内蔵HDDからWindowsを起動する事ができた。この時のBCDの内容は次の様になっていた。

Windows ブート マネージャー
--------------------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume3
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  ja-JP
default                 {default}
displayorder            {default}
timeout                 30

Windows ブート ローダー
--------------------------------
identifier              {default}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 10 Home
locale                  ja-JP
osdevice                partition=C:
systemroot              \Windows
resumeobject            {5ef36c70-b615-11ec-93cb-806e6f6e6963}
bootmenupolicy          Standard

オリジナルに比べ幾つか項目が無くなっているが、これでとりあえずWindowsは動く（まだ回復環境は起動できない）。

　ここまで来たらDynabookに通常通りログインし、壊れている可能性のあるWindowsを修復することとした。ネットが使える状態でコマンドプロンプトを管理者モードで立ち上げ、次の2つのコマンドを使って復旧する（多少時間がかかる）。

> sfc /scannnow
> DISM /online　/cleanup-image /restorehealth

　sfcは破損したファイルを修復して正常に終了したが、一方DISMは3.8%進んだ所で「指定されたファイルが見つかりません」とエラーを吐いて止まってしまった。どうやらシステムのファイルが壊れているようだ。いよいよクリーンインストールが必要になった。そのためには回復環境を復活させる必要がある。

 　単にWindowsをクリーンインストールするのなら作成したWindowdPEから「今すぐインストール」を実行すれば良いが、一方Windowsを工場出荷の状態に戻すには回復環境（WindowsRE）を復活させHDDに格納されているメーカー作成のインストーラを起動させる必要がある。しかし回復環境はまだ立ち上がらない。

続く。

Dynabook（T75）のHDDを修復（その１）クローンの作成

　家族がDynabook（T75）が立ち上がらない、と持ってきた。これを使える所まで回復したので記憶と記録を元に書き留める。なお以下の内容は、試行錯誤的な作業を数日間に渡って行った関係で時間的な流れや手順を正確に再現したものではない。

　Dynabookの電源を入れてみると画面の中央にDynabookとタイルが出たままで、BIOSや回復環境へ進むためのファンクションキー（Fxx)の機能を表すメッセージが出る所まで進まず、 暫く放置していると回復環境（WindowsRE）が立ち上がるが修復関係のメニューを選んでもエラーになったりしてWindowsは立ち上がらない状態であった。なお家族によるとWindowsは更新を繰り返し当初Windos10であったものがWindows11までアップデートされたそうである。

　回復環境でコマンドプロンプトを立ち上げてchkdskを実行してみると多くの時間がかかるとともに次のメッセージが出てディスク（HDD）にエラーがある事が分かる。

「破損したディスク上のアッパーケース テーブルが検出されました」

　diskpart を立ち上げ list volume を実行してみると、表示にとても時間がかかってどうやらHDDが壊れているようだ。このHDDを取り出し別のPCに繋げてディスクの管理で内容を見るとC:ドライブに相当するパーティションがNTFSではなくRAWになっている。これではWindowsは立ち上がらない。

　これ以上このHDDで作業してもアクセスにとても時間がかかって作業効率が悪く、さらに最悪の場合HDDを壊してデータが復元できなくなる可能性があるので先ずこのHDDのクローンを作成することとした。

　同じ大きさのHDDを調達し、手持ちの Acronis True Image（2014版）付属のDVDで立ち上げHDDのクローニングを試みるもエラーがあってクローニングは不可とのメッセージで拒否される。代わりにHDDのバックアップの取得を行った(これは実行できた)。特にエラーのあるC:ドライブのパーティションはファイル毎ではなくセクター単位での取得になり、１TBのディスク全体を吸い上げるのに8時間くらいかかった。このとき進行状況の0%辺りと44%辺りがやたら遅かったので、この辺りが物理的に壊れている可能性が高い。

　次にこのバックアップデータをAcronisを使って作業用の新しいHDDに書き込む（リカバリ）。その前段階として新しいディスク全体の管理方法（MBR又はGPT）を元のHDDと同じ（GPT）にする必要がある。復元は、最初はAcronisで行ったが適当にお任せでやったら各パーティションの空きスペースが圧縮され元の状態を復元できなかった。そこで予めパーティションを作成してその中にデータを流し込むこととし、別のPC(※)（以下「作業用PC」とする）のdiskpartを使って壊れたdiskから管理情報（VolumeやPartition情報）を採取した（＃）。

　元のDISKの管理情報は次のようなものである。

（この表示には作業用PCを使ったため、上の表示では元のC:がE:として割り当てられている）

（Partition 2がVolumeとして認識されていないのは、Partition間の隙間だからだろう）

　これらの情報からパーティション（順番、大きさ、フォーマット形式等）をdiskpart（或いは相当のツール）を使って新DISKに再現した。しかし上の表示値は丸められているので正確な値は分からず、元あった場所に狂い無くパーティションを回復することは出来なかった。このときVolume 5 (Partition 3)の属性を正しくNTFSと指定する事を忘れてはならない。

　新しいディスクに管理情報を設定した後、Partition毎にバックアップデータを流し込んだ。このデータの書き込みには4時間くらい、とくに壊れているPartition 3は全セクターをベタ書きするので時間がかかった。そしてAcronisの指示通り最後にトラック0やMBRも書き戻した。これらディスクの管理情報は最後に書き戻すよう指示されているので、ツールが適当に値を修正している筈だ。これでクローン（正確にはクローンもどき）は出来上がった。以下はこのHDDでの作業である。

　このディスクをDynabookに戻して起動を試みたが、いきなりエラーとなるだけで回復環境を含めて全く立ち上がらなかった（これはよくあるパターンで、普通は泣く泣くクリーンインストールするしかない）。各Partitionの位置がオリジナルと完全に一致していない事が原因かと思ったが最後に書き込むMBRはツールで修正されていると思われ、またこのDiskはGPT形式でありMBRを使っていないので関係ない筈なのだが・・・。

　このディスクを作業用PCに付けるとファイルにアクセス出来るようになった（色々試みたのでこの段階で何かの復活ツールの世話になったのか思い出せない）。ただし幾つかのファイル、とくにユーザのファイルへのアクセス権が無いと怒られた。そこでユーザフォルダのプロパティを開き、セキュリティタブの中のアクセス権を編集しUsersやPowerUsersを追加した（％）。ここまで来てユーザのファイルにアクセスできるようになり、ファイルを外付けUSB-HDDに取り出す事ができた。

 　最後にchkdskを/fオプション付きで起動し壊れていたC:パーティションの修復を試み、それによって様々なエラーが修正された。その中には、

　CHKDSK は新しいルート ディレクトリを作成します。
  165 個のインデックスなしファイルがスキャンされました。             
  48 個のインデックスのないファイルが元のディレクトリに回復されました。
  117 個のインデックスのないファイルが lost and found に回復されました。
  48442 個の再解析レコードが処理されました。
　マスター ファイル テーブル (MFT) のミラーでエラーを修復します。
　属性定義テーブル エラーを修復します。
　ブート ファイル エラーを修復します。
　マスター ファイル テーブル (MFT) の BITMAP 属性エラーを修復します。
　ボリューム ビットマップ エラーを修復します。

 などがあった。

　続く。 

（※）作業用PCはDELLのLatitude D630（Core2Duo,4GB） というWindows-XP時代のPCをSSD化しWindows10に更新したものである。 

（＃）SANWAのUSB-CVIDE3というSATA-USB3.0変換ケーブルを使って接続した。

（％）Windowsを十分理解していないのでこの操作が妥当であるかは分からない。ただ、Windowsの調子が悪くなった時はほぼ間違いなくアクセス権と後述の{GIUID}の問題が絡んでくる事は経験済み。

アクションカメラCT9500に外部マイクジャックを追加する

 アクションカメラCT9500に外部マイクジャックを付けて欲しいと頼まれた。マイクは内蔵しているが撮った音量が小さく使えないらしい。私自身はアクションカメラを触ったことはないが、かなり小型の動画撮影用カメラである。

最初はジャックを付けるには隙間が無く改造は無理だろうと思ったがネットに幾つか実例が上がっているとの話なので引き受けた。

改造は分解から始まるが最初の手がかりが分からない。下手に力を入れると酷く傷がついたり壊れて元に戻せなくなる。幸いな事にネットに動画があるので、それを参考に分解した。なおレンズを傷つけないよう作業中はレンズにマスキングテープを張った。

部品を追加する空間の大きさは上の写真を参考にしてもらいたい。分解したら次は部品の調達である。現物を持って秋月に行き、隙間に入りそうな部品を探した。

マイクジャックは2.5mmと3.5mmの物を売っているが部品の大きさがほぼ同じなので、より汎用的な3.5mmの物を使う事にする。3.5mmの物も何種類かあるが、隙間に入りそうな単純な丸い3極のジャックを選び、マイクの切り替えは別途小型のスイッチを追加する事にした(プラグを差し込む事で内蔵マイクと外部マイクを切り替えることが出来るような物もあるが大きくてカメラ内部の隙間に収まりそうにない)。また隙間に収まりそうな直径6mmのマイクを買った（元々基板に乗っていたのは直径4mm厚さ1mm程度のマイク）。

部品が揃ったので加工に移る。先ず穴あけである。内部にうまく収まりそうな位置を決めてケースに穴を開ける。穴を開ける場所は先人の例を参考に微調整した。ここだと手持ち用のホルダーに取り付けるにもギリギリ邪魔にならない（防水ケースに入れるにはジャックの頭が邪魔になるので少し削る必要がある）。 また内蔵マイク用の穴は細いスリット状なのでドリルで広げた。部品を取り付けると次の通り。ジャックはネジ式なのでそのまま固定できるが、マイクやスイッチはホットボンドや瞬間接着剤で固定した。流動性の高い瞬間接着剤は隙間からスイッチの内部に入り込んでダメにするので要注意（私は1回失敗した）。

マイク用配線を引き出すために基板上のマイクを取り外したが、ハンダが融けないうちに力を入れ過ぎてパターンが無くなってしまい、さらに多層基板なのでスルホールがそのまま裏側に出ている訳ではないため簡単に配線を引き出せなくなった。

僅かに残ったスルホールの芯を頼りにテスターであちこち当たってみると配線の行先が分かりそこから配線を取り出すこととした。

上の写真でオレンジで囲んだ配線がマイクの＋端子、青が近くのGNDである。

 あとは配線を接続し、元通りに組み立てればOKであるが、実際には組み立ての途中で部品を通すのに不都合な出っ張りがあったり、部品や配線が微妙に当たったりして綺麗に収まらない。最終的には配線を通す経路を変更したり、リューターで邪魔な箇所や部品を削りやっと押し込むことが出来た。

元々自分のアクションカメラではないので音がどれくらい改善されたかは分からないが、外部マイクが使えることはもちろん、内蔵マイクを使って録音された音が内蔵スピーカーから聞こえるようになったのでやった甲斐はあったのだろう。

なおマイクにはプラグが2極、3極、4極のものがあるが、アクションカメラの録音はモノラルなので 3極プラグの先端(L)だけを使って2極にも対応するようにし、４極は規格が複数あるので変換コードを作って対応することした。

 

 

 

セリアのソーラー・アクセント・ライト タイプ２

 セリアのソーラー・アクセント・ライトを買い足して内部を見たら前に買った同じソーラー・アクセント・ライトと構造が違ってた。端的に言えば回路基板の取付位置が異なり電池の真下になった。この事でLEDのハンダが電池を上に押し上げているものがあり、これは不味い構造だ。実際改造しているとハンダから突き出たLEDのリード線の先が電池の被覆を破りショートすることがあった。

回路的にはダイソーのソーラー・ガーデン・ライトと同じでICがYX8018B或いはZX808となっている。使っている部品の定数が異なる。L1が120μHと小さくなって消費電流が実測11mAと増えている。この理由はよく分からないが、よりLEDを明るくするためなのか或いはLEDの効率が悪いのを補うためだろう。これを補償する為なのか電池の容量が600mAhと増えているが太陽電池は前のままなのでバランスの度合いは不明である。

L1を 220μHに替えると消費電流は5mAになった。明るさは見た目にはあまり変わらない。これをいつも通り改造した。

使ったLEDは自己明滅するキャンドル色のOSY5MK5A31Aというものである。主要部分を一纏めに組み立て、

組み込んだ（この段階でLEDは未実装）。絶縁性を向上させるため、（写真には写って無いが）電池と基板や部品の間にはカプトンテープを挟んだ。

 光り具合は次の写真のようだ。

【LEDの不具合と回避】　今回使ったOSY5MK5A31Aは電圧をかけても光らなくなることがあり一見LEDが故障（断線）した様に見える。こんな症状を何回か経験し、その都度LEDを新品と交換した。不思議な事に取り外したLEDをテストしてみると正常に戻っている。このLEDを単体でテストしたところ、いったん0V以上0.1V以下の低い電圧をかけていると、その後電圧を上げても光らない欠陥がある。どうも内部で一時的にハングアップ的な現象を起こしているようだ。

ソーラーライトの経験で言うと、太陽電池に弱い光を当てた状態でスイッチをONにするとその後暗くなっても光らない。こういう場合は一旦スイッチをOFFにして暫く太陽電池を覆った状態で放置した後スイッチをONにすると復活する。奇妙な現象だ。電源がOFFでも太陽電池の起電力がIC1を通じてLEDに加わっているのが要因の１つだろう。これを解決するために電源OFFの時はLEDの電荷を強制解放するように次の回路に変更した〔第一の回避策〕。

この変更で不具合は少し改善された。つまり電源ONで点灯しなかった場合、太陽電池を覆った状態でスイッチをOFF-ONすると復活する。さらに次の改造を試みた。

この回路では電源をOFFにしてもD3を通じてLEDに1.2Vの電圧を加印している。この電圧ではLEDは光らないが能動状態を維持することができる〔第2の回避策〕。
D3はどこにでも転がっているような普通のダイオードである。R1は万が一LED周辺の回路がショートした場合に電流を制限するための抵抗で通常は電流は流れないので値は適当に選べばよい。この回路ではバッテリーの過放電で万が一スタートを失敗するとLEDは永久に光らないので、その時は一度電池を抜いて暫く放っておいて再度電池を入れてスタートさせることになる。
　結果的に言うと第2の回避策は使い勝手が悪い（もしもの場合に分解して一旦電池を取り出す必要がある）。改造はやや面倒だが第1の回避策の方がよい。

 

上と同様に、LEDを2個直列にして明滅させる物も作った（この回路にも【LEDの不具合と回避】で述べた第1の回避策を適用したほうがよい）。

実装は次の様に組み込んだ。

赤と青のLEDを使うと次のような光り具合でイイ感じだ。消費電流は変わらない。

 

赤と緑は次の様な光り方だ（手持ちの関係で緑はスモークのLEDなので水平発散が強く出て横からでは赤が控えめに見える）。

百均のソーラーライトの電池は100mAhの物が多かったが今回のライトは600mAhのものが使われている。これだと本来はフル充電で120時間持つはずであるが実際に使ってみると朝まで持たない事がある。太陽電池の発電能力も気になるところである。電池の重さは100mAhのものが5gに対し600mAhは6gで大きな差はないので600mAhの容量はどうなんだろう。ちなみに秋月で買った900mAhの物は11.5ｇあって中身が詰まってる感じ。

【注意】セリアの本ライト添付の説明書に「電池交換や改造はおやめください」とあるので改造する場合はあくまで自己責任でお願いします。

【その後】1年近く改造を繰り返してきたが内蔵バッテリーはいつの間にか600mAのものが使われるようになっている。計算上はこのバッテリーで十分な容量があるはずであるが実際には陽射しの強い九州の夏でも朝まで持たなかった（L1はオリジナルの120μHのままでテスト）。同じバッテリーを搭載した吊るソーラーライト（これもL1はオリジナルのまま）は朝まで光っているのでソーラーアクセントライトはソーラーセルの面積が狭い分バッテリーを十分充電できるだけの発電能力はないと思われる。ただ、バッテリーを秋月で売っている900mAのものに変えると（個体差はあるが）朝まで持つたので相性（たぶんバッテリーの内部抵抗が高く充電効率が悪いか或いはソーターセルの能力にバラツキがある）の問題があるのだろう。別の対策としてL1を220μHに交換して消費電力を抑える工夫が有効かもしれない。昼が短く夜の長い冬季に朝まで光らせるためには電池とL1の両方の対策が必要だろう。

ソーラー・ガーデン・ライトにLED2色を搭載する

 以前ジャック・オ・ランタンに赤色LEDを2個直列に搭載した。赤色LEDはVfが1.8V程度と低く、特性の揃ったLEDを2個直列にしても見かけ上のVfが3.6V程度になるだけなので問題は生じない。並列に繋いでも良さそうだが電流が2倍になるので電池の消耗が早くなりそうである（試してない）。

一方色の異なるLEDはVfも異なるため、これらを並列に繋いでもVfの低い方だけが光る事になる。これを防ぐため直列に繋ぎ同一の電流を流してやる必要がある。

元々明るい紫を作りたかったが秋月で入手できるLEDは無かった。そこで赤と青を組み合わせてて紫を作ってみた。秋月には2色入りのLEDも売っているが内部接続がアノード・コモンやカソード・コモンになっており直列接続としては使えないので2色別々のLEDを組み合わせた。青色LEDのVfは2.6V位あるため赤との合成Vfは4.4Vになる。使うLEDは5mmΦでは場所的に大きすぎるので3mmΦのものを使った。

 

実際に作ってみると紫も見えるが青と赤が混在したギラギラした感じで紫単色より良い感じである。

これに味をしめて赤と緑の組み合わせも作ってみた。緑色のVfは2.8V位あるため合成Vfは4.6Vになる。そこでD2には5.1Vの物を使った。

緑がやたら明るく見えるが、それは手持ちのスモークLEDを使ったので水平方向の散乱が強いためである。 

２つの2色ガーデンライトを並べてみた。写真では色が十分表現できないようだ。

なお光の3原色のうち青と緑の組み合わせは試していないが、これは青緑の明るいLEDが既にあるからである（信号機の青として使われている）。

セリアのソーラー・アクセント・ライトのRGBフルカラーLED化 Incorporating RGB full-color LED into cheap solar accent light

 セリアのソーラー・アクセント・ライトは太陽電池が3cm×3cmと前出のダイソーのソーラーライトより小さく面積で約56%しかない。

これを分解すると次のようになっている（これらとは別に土に挿すための杭が付いているが写真からは省いている）。

 この回路をトレースするとダイソーの吊るソーラーライトと同じである。しかし消費電流を計ってみると4.5mAと少ない。太陽電池の面積はこの消費電力に見合った設計になっているのかもしれない。

 内蔵の単4のニッケル水素(NiMH)電池は容量が100mAhなので、消費電流から計算すると20時間以上持つが説明書によると点灯時間は8時間となっている。

このライトにはゆっくり色が変化するRGBフルカラーLED（OSTB5131A-ID）を付け、直流点灯させるため次のように改造した。

 少しやり直した部分があるので配線が汚くなっているのはご愛敬。

このライトの光り具合は次の動画（4倍速）のとおり。

太陽電池の面積が小さい分起電力が弱いようで、前出のソーラーライトと比べ夜間照明のあるような少し明るい所でも夜間点灯できる。

【注意】セリアの本ライト添付の説明書に「電池交換や改造はおやめください」とあるので改造する場合はあくまで自己責任でお願いします。