トリマー(電動工具)の集じん機代わりに家庭用掃除機をつなぐ
600円 + 20円くらいで解決できます（トリマーの集じんベース代は含まず）。
トリマーの切り粉をどうにかしたい
トリマーは犬の美容師とかではなく、電動工具です。自宅でちょっと削りたくてもトリマーは切り粉がすごい。でも狭小マンションに集塵機なんて置けない。ちょっとなら家庭用掃除機*1でなんとかならないかな？
揃えたもの
対象のトリマー本体はリョービのMTR-42なんだけど、集じんベースアタッチメントは別売りだから買うしかない(約991円)。これは内径が約30Φ
ホースを見繕います。これは片側はラッパ状なのである程度どうとでもなるとして、もう片側は32mm? 結局ジョイントアダプタないとだめ？
継ぎ手
そこで近所の金物屋へ、トリマーの集じんベースアタッチメントと家庭用掃除機のホースを持って行き「これとこれを、そこに売ってる洗濯機ホースで繋ぎたい」と相談します。
すると、金物屋のおやじさんは「なるほど、集じん機の代わりに掃除機ねえ… うーん」と言い、しばらくしてバックヤードから30Φの軟化塩ビのホースの切れ端を持ってきて「これ入るかなあ」と言いました。塩ビホースを継ぎ手にするということです。
うわーシンデレラフィットだ。トリマー側は結構ギチギチに填まり、洗濯機ホース側はそこそこキッチリ。塩ビホースは柔らかく変形するので融通が利きます。
内径30Φの塩ビホースを切売り10cm (20円くらいだったか)、それと洗濯機ホースも買って帰ります。
掃除機側もきちんとはまりました。掃除機の嵌合部に大きい隙間があるように見えるのは、掃除機ヘッドのパワーブラシに電源供給するコネクタ部なので空気は漏れません。この洗濯機ホースは片側がラッパ状なのでわりとどの掃除機にもつながりそうです。
実用性は
集じんパワー自体はわりとあり、洗濯機ホースは充分柔らかく、実用的です。塩ビホースの継ぎ手 (20円) は曲がりにくく取り回しが若干ウザいので、半分に切っていいかも。
この三菱の掃除機は紙パック式ですぐ満タンになるけど、それは別の問題ですね。試しにサイクロン付きのマキタのハンディクリーナーを繋いでみたらさすがに吸引力が弱すぎました（※追記 そのマキタのサイクロンアタッチメントを三菱の掃除機に挟み込めばマシになるんじゃないか!?）
ノギス
写真に写ってるノギスは500円の変な奴だけど、なぜか精度は悪くない。まあ所詮プラスチックなので力をかけないように測定しないと歪んで誤差が出るけど。でもミツトヨとかを手荒に扱うのは無理だけど、500円なら乱暴にしていい気がするので便利です。乱暴に扱ってるのにもかかわらず、たまにミツトヨと比べてるけど別に狂ってきてるとかはない。どういう構造してんだよ。
金物屋
この洗濯機ホースは金物屋でも amazon でもヨドバシドットコムでも同じものを売ってます。ヨドバシドットコムとか圧倒的に安い。しかし、金物屋じゃないと今回みたいな継ぎ手のコンサルティングは受けられない。そしてコンサルティング代は切売りホース代金の20円じゃ済まない。
*1:三菱 TC-FXE7P
UPSを買った。APC RS550S, apcupsd
UPS を買った
家のブレーカーは気軽にトリップさせたい
これは UPS おすすめ記事とかではないので、UPS の導入を検討している方に有益な情報はありません。
10年以上前だけど APC SU700j 使ってたな。30Aのブレーカの家に二人で住んでいた頃、ドライヤーと電子レンジを同時に使って雑にトリップしてた。
そのあと引っ越したあともしばらく惰性でUPS付けてた。東日本大震災があり、しかしなぜか輪番停電は受けなかったので特に活躍はなかった。そのあと3度目くらいのバッテリ寿命を迎えて APC SU700j ごと廃棄した。
上の写真のEXIFは2007年だったけどどこで撮ったか覚えてない。落合の廃工場だったか。そもそもブレーカじゃないなこれ。
APC RS550S (BR550S-JP)
どうせ中開けて遊ぶならジャンクを買おう
機種選定の基準
- 家庭用
- apcupsd *1 とかのOSSが対応してる (must)
- 12V バッテリを2本使うのはだるいから1本のやつ (must)
- 出力 200～300W; 500VAくらい
- 正弦波
- 安い
- 改造、ハックの情報が存在する (should)
正直、APC でも SmartUPS シリーズはハックの情報がそれなりにあるけど Back-UPS BR シリーズのはあんまりない。SUシリーズは企業がリプレースで廃棄したリユース品が大量に出回っているのに対して、Back-UPS シリーズは業務用としてはあまり導入されないからだろうか。
バッテリが1本で動くモデルがSUにあるならSUでよかったけど多分ないよね。たいした出力いらないのにバッテリ2本使うのはだるい。
PCからはUSBシリアルとして認識されるもんだと思ってたら, USB HID だから驚いた。HID Power Deivces って subclass があるのを知らなかった。これによってOSが直接バッテリとして認識するみたい。Windows10 デスクトップパソコンに繋いだら、特にドライバやアプリをインストールすることもなくラップトップみたいにOSにバッテリー残量とかが認識された。まあこれのせいで後でビビるんだけど…。
ref. usb.org PDF Universal Serial Bus Usage Tables for HID Power Devices
Linux では以下のような感じ。Ubuntu Desktop からもラップトップのようにバッテリが認識された。
allen@vmx260: $ lsusb Bus 003 Device 005: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
allen@vmx260: $ lsusb -v (タップして展開..)
Bus 003 Device 005: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x051d American Power Conversion
idProduct 0x0002 Uninterruptible Power Supply
bcdDevice 0.90
iManufacturer 1 American Power Conversion
iProduct 2 APC RS 550S FW:941.c6 .A USB FW:c6
iSerial 3 3B2022
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 1049
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 100
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled
dmesg
Apr 27 00:19:28 vmx260 kernel: [ 17.867416] hid-generic 0003:051D:0002.0002: hiddev0,hidraw1: USB HID v1.00 Device [American Po wer Conversion APC RS 550S FW:941.c6 .A USB FW:c6 ] on usb-0000:13:00.0-2/input0
apcaccess
allen@vmx260:~$ apcaccess status PC : 001,036,0863 DATE : 2023-04-27 03:12:57 +0900 HOSTNAME : vmx260 VERSION : 3.14.14 (31 May 2016) debian UPSNAME : vmx260 CABLE : USB Cable DRIVER : USB UPS Driver UPSMODE : Stand Alone STARTTIME: 2023-04-27 00:19:27 +0900 MODEL : APC RS 550S STATUS : ONLINE LINEV : 101.0 Volts LOADPCT : 0.0 Percent BCHARGE : 63.0 Percent TIMELEFT : 444.1 Minutes MBATTCHG : 10 Percent MINTIMEL : 5 Minutes MAXTIME : 0 Seconds SENSE : High LOTRANS : 85.0 Volts HITRANS : 120.0 Volts ALARMDEL : No alarm BATTV : 13.0 Volts LASTXFER : No transfers since turnon NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A SELFTEST : NO STATFLAG : 0x05000008 SERIALNO : 3B2022 BATTDATE : 2023-04-25 NOMINV : 100 Volts NOMBATTV : 12.0 Volts NOMPOWER : 330 Watts FIRMWARE : 941.c6 .A USB FW:c6 END APC : 2023-04-27 03:13:09 +0900
なんか表示少なくない??? と思ったら
apcaccess(8): status info from apcupsd - Linux man page より引用::
Back-UPS RS 1500 (USB) LINEV : Current input line voltage LOADPCT : Percentage of UPS load capacity used (snip) *ITEMP : UPS internal temperature in degrees Celcius (snip) * presence dependant on USB firmware version.
* presence dependant on USB firmware version.
おーい！ マジかよ。温度取れないとかはさすがにちょっと…。
テスト運転
バッテリがどれくらい生きてるか確認のためテストしてみた。
純粋な抵抗性負荷 (白熱電球など) があれば良かったんだけど、手元に500Wのアイランプとか大きいのしか無かったんで、適当なラップトップの USB-C ACアダプタをつないでる。負荷が揺れてるのはラップトップをいじってるせいです。あとLEDライトも足した。
datadog
apcupsd の apcaccess の標準出力を datadog に送って可視化した。datadog は私にとって手っ取り早いのでそうした。バッテリが死んでるかどうかだけ分かればいいんで急拵えのダッシュボードはすごく雑です。
バッテリ動作中
これは ONBATT 中の画像です。とりあえずバッテリ電圧と UPS の考えるバッテリ残量と残り時間を見たい。負荷は、まあ電池が12V/7Ahくらいだろうから 20W 程度で勘弁してやるか。残量20%で(測定中のOSを)自らシャットダウンさせるテストも兼ねておく (※これのせいで後でビビるんだけど)。
ジャンクだからバッテリ期待してなかったけど、結構生きてた。新品が分かんないけどまだ7割くらい生きてるんじゃないかな。
- いままでの APC 製の UPS は過充電気味でバッテリを短期間でダメにする印象があったけど、これは満充電後の運転中でも 13.64V (at 20℃) 程度しかかかっていなくて良い。この機種はバッテリ寿命がカタログスペック並に出るかも。満充電バッテリを外して数時間後のバッテリ開放電圧は 13.3V 程度。
- UPSの自己申告でいうバッテリ残量 0% まで使った直後 10.71V 。ちょっと使いすぎじゃない? もしそういう設計であればこの機種では 0% まで使い切らない方がいいと思う。それかこのバッテリの寿命か不明。
- 15-20W で1時間以上稼働した。Timeleft はけっこう正確。
これは20%まで放電後、15分程度充電したところ
- 商用電力復帰後、充電が始まってもバッテリ残量表示はしばらく (10分間ほど) 下がり続ける(良い)。
- 充電電流は 0.6A 前後 ? (直流クランプメータで見たから不正確だけど実際そんなものかな)。
- 充電 20% → 100% に6時間程度かかった。
- 温度の情報がとれず、ファンレスなので少し怖い
出力波形
一応見てみた。きれいな正弦波です（ここまで綺麗である必要もないんだけど）。無負荷から突然150W程度の抵抗性負荷かけても特に動じなかったのでいいと思います。50Hzの地域だけどコールドスタートしたせいか 60Hz で出てる。
他の感想
- 停電時(ONBATT時)の警告音を完全に off にもできる。というかいつ鳴るのか細かく設定できなくて、まるっとon/offになる(有償のPowerChuteで見てないから分からないけど)。バッテリが死んだときの警告音までoffになるかはまだ不明。
- バッテリはホットスワップできる
- 内部温度はとれないっぽい（マジかよ）
- 背面パネルを外すとき、商用電源から基板に行ってるファストン端子が簡単にスッコ抜けて、組み戻したとき気付かなかった。こわい！ この個体がおかしくなってるのか元々そうなのか不明
- 内部のUART接続ポイントはまだ見てない。従来の APC SmartUPS Protocol *2が喋れるのか、っていうこの機種SUシリーズじゃないし出自もSUと関係ないはずだから喋れない気もするな。いや Cisco の元 Linksys 製品が, Cisco スタイルの running-config を見よう見まねで吐く製品みたいなのもあるけど…。
apcupsd の自動シャットダウン
ビビったって話
USBパススルーには気をつけよう。ビビる手順は以下の通りです
- apcupsd と datadog のテストに使う OS (Ubuntu22.04) は Windows 上の VM で動かしてて、UPS も USB パススルーで繋いだ。
- バッテリ残量 20% で OS の自己シャットダウンは正常に完了した (想定通り)。
- VM ゲスト OS がシャットダウンされたので USB パススルーが解除され、UPS は自動的にホスト OS に接続された（忘れてた）。
- ホストOSは突然バッテリ残量わずかなUPSを認識し、ホストOSはすぐサスペンドした（たぶん?）。
- ディスプレイは消え、UPS の電源も自らオフになり、負荷のために繋いでたLEDライトも消えて部屋ごと暗くなった。VM ゲスト内だけでやってたつもりが突然ホストごと落ち、部屋も暗くなり、俺はジャンプスケアを食らった。
小型UPSの需要
停電の可能性があるようなオフィスとかにサーバを置かない時代なので、小型～中型のUPS市場は縮小していそうだな とか思った。
10年経ってもログが消えてないのすごくないですかね
「日本で無料Wi-Fiが普及しないたくさんの理由」については、空白の10年間でさまざまが解決していってよかったですね。むしろもう公衆無線LANの需要が下火。 fernweh.hatenadiary.com
ラオスの写真は2009年だったっけな。
携帯端末で何か情報を調べたり予約したりなんて概念は全くの無でした。このとき長距離列車に乗る計画で駅に行ったら、ストで全て終わってたっけ。
日本で無料 WiFi が普及しないたったひとつの理由
日本では無料公衆無線LANが非常に少ない
海外のカフェやホテルでは無料で WiFi インターネットアクセスが提供されていることが多い。しかし今どき、日本ではあまり普及していない。海外旅行者などは口を揃えて「海外じゃ無料、日本は遅れている」というが、日本のキャリアはケチなのか？
回線が犯罪に使われるとか、何かあったらかなり面倒なことになるから
日本の WiFi インターネットアクセスが有料なのは、本人認証のシステムに必要なコストが大きいからで、回線を無料で提供しないカフェやキャリアがケチなのではない。ユーザから見れば同じことだが、インターネット回線自体よりも認証のシステムにコストがかかりすぎるのである。
無料のインターネットアクセス提供でも特定電気通信役務提供者となるので*1、プロバイダ責任制限法など権利侵害情報の対応では民事*2、警察の犯罪捜査では刑事手続による発信者情報開示請求が行われる。ここで身元が特定できないアクセスを受け入れる、ログが取れないなど設備上の制限を含む発信者情報開示請求に対応しないことが、故意または重過失と見なされる可能性が残る*3 *4。
公衆WiFi提供者への開示請求は、想像以上に頻繁にある
たとえば、日本国内である店舗・サービスをチェーン展開している企業が提供している無料WiFiに関して、1-2ヶ月に一度ほど開示請求があるという。
実際に、ログが残っていない等での開示請求不能ですぐに無料公衆無線LAN提供者自身が追求される可能性は低いのかもしれない。が、少なくとも面倒なことにはなる。ログがあればすぐ提出して済ませるところなのに。
PC遠隔操作マルウェアによる誤認逮捕事件では、IPアドレスを確証とした。現状、日本ではそういう捜査が行われる、ということである。
認証システムは安価な既製品がきわめて少ない
日本は無料 WiFi が少なすぎるとか、別の回線でメールアドレス登録しなきゃいけないのは鶏と卵問題だとか、故に日本は遅れているといわれるが、認証システムつきのWiFi機器は安価な汎用品が少なく、管理も簡単ではない。仮に回線コストだけで無料 WiFi を提供できるような状況なら、おそらくもっとたくさんの無料公衆無線LANが提供されているのではないかと思う。
たとえば喫茶店の個人経営者がインターネットアクセスを無料提供しようとしたとき、安心して導入できる安価なシステムがきわめて少ないのが問題である。
代表的なソリューション FREESPOT は接続性に問題があるように見受けられる。透過プロキシのようなものが入っているようで通信をいじっているように見える。問題が多い。たとえば、HTTP での接続は不安定、SMTP(Submission)で SSL(TLS)接続をするためネゴシエート中に STARTTLS コマンドを発行した瞬間にコネクションが切断されるなど。ログを採取し、不正な利用を防ぐために必要なことかもしれないが、不安定なため通常利用も支障がある状況で、あまり人気がない。
ハードウェアの話になるが、もしも、つながった端末の MACアドレスや Web の接続先をある程度長期間ロギング可能なルータや無線アクセスポイントが安価に販売されていたら、多少は状況がマシになるのかもしれない。また、以上の法的な項目に関しては、弁護士に相談したり都道府県警察本部のサイバー犯罪相談した結果をメモ書きしているだけで、私自身は法律の素人なため、間違いがあれば指摘していただきたく。
ちなみにアジアを旅行するとやたらと暗号化なしの野良 WiFi が飛んでいるが、彼らの回線が誰にでも使えるのは捜査なんてないから。これを「途上国は遅れている」と捉えるか、「そういう捜査なんてそもそも無理なんだし、彼らは遥か未来のサイバー世界に行っちゃってる」と捉えるか。
そもそもどうして満充電にしないで使いたいのか
といわれた。
リチウムイオンバッテリは以下の条件が揃ったとき、急激に劣化する。
- 満充電
- 高温(大体45℃以上)
また
- 深放電(過放電)
- 放置
他にもセルバランスとかあるけども、基本的にはこういったことを起こさず適度に使っていれば、メーカーが謳うように 500 サイクルの寿命を全うできると考えてよい。
一番まずいのが満充電で高温になること。劣化が非常に早くなるし、運が悪いと即死することもある。ただし、充電量が少ない状態ならば結構熱くなっても割と大丈夫だったりする。だから、満充電のラップトップマシンが高負荷などによって高温になったら、ACアダプタを外してバッテリ駆動に切り替えて放電させるのが理想。でも、面倒だから普通はそんなことしない。
Let's Note などの ECO モードは「満充電すると寿命が短くなるから80%で充電をやめておく」というが、むしろ「満充電のときに高温になると そこで死を迎えやすいが、満充電でなければ高温になったとしても死ににくい」というニュアンスのほうが近く、またそれがバッテリ本来の寿命だろう。
リチウムイオンバッテリに興味がないのであれば、寿命を迎えたら交換する使い方が最も賢い。もしもバッテリ自体に興味があれば、(満充電 && 高温) の AND 条件を満たさぬようにすると、寿命を延ばすことができるだろう。さらに興味があれば、BAYSUN のリチウムイオン電池の話 も面白い。
スマートフォンの充電制御も温度が考慮されている。
「充電器につないだまま使っていても充電が追いつかなくて、バッテリが減っていってしまう」といった事例では、充電が追いつかないのではなく冷却不足の場合があるように見受けられる。スマートフォンのような機器は、内部温度が上がるとバッテリ保護のために充電を止める、または充電電流を下げる制御を行うことがある。すると、高負荷なアプリを動かすと充電が追いついてないように見える。
また、外部電源が接続されていて、既に 100% 充電されている状態から高負荷などにより内部が高温になった場合、外部電源は(供給されていても)使用せず、バッテリを満充電状態にしないためにバッテリから使うような制御を行うことがある。これもまた、充電が追いつかないように見えるだろう。
他にも、たとえばバッテリ内蔵の PND（カーナビ）は高温にさらされやすいため、さらに積極的な放電を行う製品もある。電源がONでないスリープ状態でも、高温になると自動的に内蔵バッテリの放電処理を行う。
これらの自動的に行われる放電もサイクルにカウントされると考えてよい。ワンサイクルは充放電の浅深にあまり関係がないと考えられており、知らぬ間にバッテリの充電サイクル寿命が削られていっているだろう。
MacBook の AC アダプターと Hyperjuice, Airline Adapter の充電のなぞ追試
この記事の続きです:: id:ektar:20120813
Apple Airline 電源アダプタを買ったのでテストした。電源は手元にあった IBM Thinkpad のACアダプタ(16V/4.5A)がちょうどよかったので、切断してシガーソケット化し、Airline アダプタを接続できるようにした。
結論は Airline アダプタを使えば、いっさい充電されない。目論見通りで、成功である。OS X v10.7 ではバッテリ残容量にかかわらず、メニューバーは以下のようになる。
ただし、Mid 2012モデル以降に充電するには MagSafe2 変換 が必要であり、これを使うと(?)LEDの挙動が変わる。実際には充電されていないのに、バッテリが満充電でないときはLEDがオレンジになる。これは MacBook Pro Retina 15inch での例。LEDはオレンジなのに「充電中：いいえ」
MacBook Pro Mid2009 では MagSafe 変換もいらず、つねにLEDはグリーンになる。
45W ACアダプタの MagSafe 部分のみを流用することで、出力電流が低い TL160K でも Retina MacBook Pro を充電することができる。
モバイルバッテリ TL160K で Retina MacBook Pro を充電してみた #3
電源の能力、充電の可否などは MagSafe コネクタ部によって決まる可能性が高い。
電源部と MagSafe コネクタ部は単純にV+とGNDだけでつながっている。ここに何らかの情報を載せているとも考えにくい。実際に上記の引用記事ではコネクタ部のみを切断して、ポータブルバッテリーを 45W だと認識させることに成功している。
MacBook の AC アダプターと Hyperjuice, Airline Adapter の充電のなぞ
写真は去年の気仙沼。AGFA ULTRA50などというビンテージフィルムで撮影
MacBook の MagSafe コネクタとバッテリの充電はどうも面倒なことがあるようだ。
Hyperjuice などの外付けバッテリーで駆動した場合、MacBook 本体には電源供給されるものの充電されない現象があるときいた。
また、MacBook の内蔵バッテリが 100% 満充電になっていなくても充電を停止し、ACアダプタからの給電で動作する方法を探している。どうせACに繋ぎっぱなしにしたら、早々にバッテリーが死ぬのはわかりきっているからだ。Let's Note や Dynabook のように80%で止める機能もない。充電制御は SMC などの低レイヤで行われているので、アプリみたいなレイヤからハックするのも不可能だろう。Hyperjuice で充電されない原因がわかれば、逆に利用できそう。
Apple MagSafe Airline 電源アダプタ
- MagSafe Airline電源アダプタを使ってコンピュータの電源を得られますが、バッテリーの充電はできません。
- MagSafe Airlineアダプタは自動車のシガレットライター電源には対応していません。
- 結果は車のエンジンがかかっている時は 「充電できていません」という表示が出ますが 外部電源を供給しているという形で使用できました。
アップルの Magsafe Airline アダプタを使用すると充電ができないらしい。たしか、航空機の座席電源は 5A くらいしかとれないはず*1なので、MacBook pro など大きなラップトップではそれを上回ってしまう可能性があるから、わざと充電できないようにしている可能性がある。
Apple MagSafe Airline 電源アダプタ bbs.kakaku.com
- 13.5V付近から本体の電源アイコンがコンセント表示に変わります。
- 電源は供給されているようですが、充電はされません
Airline アダプタを車載用に転用するには、下限が 13.5V ではかなり厳しいと思われる（エンジンがかかっているときの公称が 13.8V, かかってないときは 12.0V）。航空機は DC15V。なお16Vのポータブルバッテリーからの供給はOKだが、やはり充電はされないとのこと。
Hyperjuice 関連のサイトを読むと、単に供給電圧の問題で充電されないという意見が多いように見えるが、MacBook本体とACアダプタは通信しているように見えるので（MacBook 側のシステム情報で接続されている AC アダプタのワット数、シリアル番号などが表示される）、そんなに簡単な話じゃないだろうと思っていた。
http://pangea.stanford.edu/~schmitt/magsafe/ が面白かったのでメモがてら超訳
Apple Airline MagSafe アダプタについての注意
アップルは、Airline MagSafe アダプタは電源を供給するがコンピュータのバッテリーを充電しない、としている。この警告は正しい。以前、この充電されない問題は単に航空機から供給される電圧が低いためかと考えていたが、そうではなく、Airline MagSafe に加えられた電圧と充電されない問題は無関係であることがわかった(Kieran Hervold による報告)。
（略）MagSafe コネクタについて
PIN(s) Function 1, 5 V- 2, 4 V+ 3 LED/charging control? （MagSafe コネクタについている）あの LED はちょっと不思議。V+ へ約 16V 以上が加わるとグリーンに光る。Apple の AC アダプタは、無負荷時には約 6.25V まで落ち、LEDは消える。よくある多機種用のユニバーサル AC アダプタは負荷にかかわらず常に設定した電圧を出力するが、この場合 LED はコンピュータが接続されていなくても点きっぱなしになる。
MagSafe の LED はコンピュータが充電中であることを知っているときにオレンジになる。したがって、MagSafe の pin 3 (the center pin) で LED の色をコントロールしているのではないかと推測される。pin3 と V- (GND) の抵抗を測ると約 426 kΩ, pin3 と V+ の間は導通は無し。また注目すべきことに、ユニバーサル AC アダプタから電源供給した場合、コンピュータから MagSafe を外しても同じ色のまま点きっぱなしになる。
Kieran Hervold は MagSafe コネクタを分解した。 コネクタ内部には小さいICがあり、これが LED の色を制御しているのではないか? 同様に Apple Airline MagSafe アダプタはコンピュータにバッテリ充電を無効にするようコントロールしているのではないかと推測される。
How to build an auto / airline MagSafe power adapterApple MagSafe アダプタの充電ストラテジ
65W アダプタ
自分の知る限り、つねに 16.5V をコンピュータにかけている。
85W アダプタ
85Wアダプタは、負荷によって出力電圧を変えている。最大負荷(充電時など)は 18.5V まで上がる。最小負荷では、16.1V 〜 16.5V。
バッテリが 37% から 100% 充電になるまでの電圧を監視した(スクリーン最大輝度、CPU負荷は低、WiFi はオン)。70%以下では 17.0V 〜 18.1V, 71% になったとき、突然 16.5V まで下がった。充電中以外は、16.1V 〜 16.4V。
結論はまだない。なぜなら Airline MagSafe アダプタは高くて買えない。
2012-09-21 続きを書きました id:ektar:20120921
Argyll CMS を使って ubuntu でも液晶モニタのキャリブレーション
2011年8月下旬、秋葉原のショップインバースでジャンクのレッツノート CF-T5 をわずか 8,000円で買った。既に所持している CF-W5（新品で25万くらいで買った）のサブで ubuntu 専用機が欲しいなーと思ってたところだった。
良い買い物をした。買って一ヶ月以上経つけど、なんの故障もなく使えてるし、バッテリーも4時間はもつし、CoreDuoでそれなりに実用的な速度で動く。外観もそんなに悪くない（上の写真を見て）。でも、ひとつ難点があるとすれば、液晶のバックライトが劣化してきて黄色く見えることだ。モニタを何台も並べていると色の違いが気になる。
モニタを校正することにした。Mac や Windows なら市販のモニタキャリブレータが使えるけど、Linux (X) でそのままでは使えない。仮想マシンでも LUT が利用できないので無理だろう。ノートだからモニタを外して別のマシンで校正することもできない。
オープンソースの CMS アプリケーション Argyll Color Management System を試すことにした。ubuntu 11.10 では apt-get で簡単にインストールできる。適合する古い測色器(x-rite DTP94)が手元にあった。
Argyll は CLI ツールだけど、易しい GUI ラッパー Argyll dispcalGUI も出ている。しかし今回は、パッケージの依存関係を解消するのがだるくて使っていない。
argyll パッケージ内の dispcal を使って校正, icm モニタプロファイルを作成する。
dispcal の man はこちら。
% dispcal -v1 -d1 -c1 -o CF-T5_1.icm -O "CF-T5 display icm profile 1st" -qm -yl -t5000 -p 0.5,0.5,0.5 -K c
測色器をつないでから dispcal を実行してね。
画面の真ん中にカラーパッチが表示されるので、そこに測色器をセットする。
Setting up the instrument Instrument Type: DTP94 Serial Number: 0238xx Boot version: D929 Software version: DB06 Want projection measurement capability but instrument doesn't support it so falling back to display mode. Place instrument on test window. Hit Esc or Q to give up, any other key to continue: Display type is LCD Target white = 5000.000000 degrees kelvin Daylight spectrum Target white brightness = native brightness Target black brightness = native brightness Target advertised gamma = 2.200000 Display adjustment menu: Press 1 .. 7 1) Black level (CRT: Offset/Brightness) 2) White point (Color temperature, R,G,B, Gain/Contrast) 3) White level (CRT: Gain/Contrast, LCD: Brightness/Backlight) 4) Black point (R,G,B, Offset/Brightness) 5) Check all 6) Measure and set ambient for viewing condition adjustment 7) Continue on to calibration 8) Exit
実行すると測色器が検出され、ディスプレイの輝度やゲインの設定アシスタントモードになる。*1 このノートPC、もはや最大輝度にしても明るくないし、他に何も調整ポイントがないので skip した(7を押す)。
patch 6 of 6 Black = XYZ 0.61 0.65 0.64 Red = XYZ 29.09 16.87 2.28 Green = XYZ 19.43 32.60 6.82 Blue = XYZ 9.84 10.67 39.33 White = XYZ 57.48 59.21 47.50 patch 128 of 128 Initial native brightness target = 59.210000 cd/m^2 Had to scale brightness from 59.210000 to 58.371133 to fit within gamut, corresponding to RGB 0.998531 1.000000 0.947055 Target white value is XYZ 56.676262 58.371133 44.541255 Adjusted target black XYZ 0.61 0.65 0.63, Lab 9.90 -1.26 -3.71 Target black after min adjust: XYZ 0.610 0.650 0.630, Lab 9.904 -1.260 -3.706 Gamma curve input offset = 0.000000, output offset = 0.011136, power = 2.259617 Total Iteration 3, Final Samples = 64 Final Repeat threshold = 0.600000 Creating initial calibration curves... Doing iteration 1 with 16 sample points and repeat threshold of 1.200000 DE patch 16 of 16 Brightness error = -1.261133 cd/m^2 (is 57.110000, should be 58.371133) White point error = 1.024338 deltaE Maximum neutral error (@ 1.000000) = 1.319932 deltaE Average neutral error = 0.795555 deltaE Failed to meet target 1.200000 delta E, got worst case 1.319932 Number of measurements taken = 44 Computing update to calibration curves... Doing iteration 2 with 32 sample points and repeat threshold of 0.848528 DE patch 32 of 32 Brightness error = -1.601133 cd/m^2 (is 56.770000, should be 58.371133) White point error = 0.998361 deltaE Maximum neutral error (@ 1.000000) = 1.457514 deltaE Average neutral error = 0.595230 deltaE Failed to meet target 0.848528 delta E, got worst case 1.457514 Number of measurements taken = 63 Computing update to calibration curves... Doing iteration 3 with 64 sample points and repeat threshold of 0.600000 DE patch 64 of 64 Brightness error = -1.991133 cd/m^2 (is 56.380000, should be 58.371133) White point error = 1.014456 deltaE Maximum neutral error (@ 1.000000) = 1.669090 deltaE Average neutral error = 0.483882 deltaE Failed to meet target 0.600000 delta E, got worst case 1.669090 Number of measurements taken = 219 The instrument can be removed from the screen. Written calibration file 'c.cal' Luminance XYZ = 0.000000 58.854391 0.000000 White point XYZ = 0.968459 1.000000 0.790729 Black point XYZ = 0.010818 0.011650 0.011543 Created fast shaper/matrix profile 'lib/CF-T5_1.icm'
どれどれ…見た目 相当ましになってる！
できたプロファイルは以下のようにしても反映できる。
% xcalib CF-T5_1.icm
プロファイルを無効にするには
% xcalib -clear
see also man (1) xcalib : xcalib
もっと酷いガンマカーブを想像してたので、こんなもので収まってるんだなとむしろ感慨深い。少し暗くなったけど、白い画面も気持ち良く見られるようになった。
ちなみに i1 display 2 はなぜか検出されなかった。検索すると使えてるっぽい記述があるので手元の環境の問題かもしれない。関係ないけど xrite 社のサポート電話番号は土曜休みみたいで今日はかからなかったぞ。
NEC IX2015
夏から冬になる。秋がない。写真は沖縄。けっこう寒かった。
デジカメのズームレバーを壊してしまった。
ルータ NEC IX2015 の proxy-dns (DNS cache) に負荷をかけ続けるとルータが再起動する件。
NEC IX2015 を知人の集合住宅(シェアハウス)に設置するために設定し、テストのためしばらく自宅で動かしていた。知人宅は住人が多いため端末数もそれなりに多く、またゲストも多く定期的に訪問する。そんなこともあって気に掛かっていたうちの設定のひとつ DNS proxy/cache で、ちょっと実験のため webalizer の DNS 逆引きでテストしてみようかと思った。webalizer のそれは、設定によってかなりエグい動作をするので、負荷テストのかわりに使用している*1。
結論からいうと正しく対応できなかった。ファームは 8.3.48.
webalizer.conf に設定したのはこれくらい。
DNSChildren 64
IX2015 の関係がありそうなところはこんなもん。IPv4 のみ。
ip ufs-cache max-entries 9600 ip ufs-cache enable ! dns cache enable dns cache max-records 255 dns cache lifetime 300 dns ncache lifetime 60 ! proxy-dns ip enable proxy-dns ip max-sessions 127 proxy-dns ip query-retries 3 proxy-dns ip query-interval 3 ! ! interface FastEthernet0/0.1 description PPPoE encapsulation pppoe auto-connect ppp binding hoge ip address ipcp ip tcp adjust-mss auto ip napt enable ip napt inside list pppoe-napt ip napt translation max-entries 32768 ip napt translation max-entries per-address 2048 ip filter priv 100 out ip filter all-permit 65000 out no shutdown
ix2015-sh(config)# sh proxy-dns
Proxy DNS for IPv4 enabled
Max sessions 127, life time 90 seconds
Query max retries 3, retransmit interval 3 seconds
DNS server(s):
61.207.11.153, dynamic (IPCP), FastEthernet0/0.1, priority 100
221.113.139.137, dynamic (IPCP), FastEthernet0/0.1, priority 100
Proxy DNS for IPv6 disabled
Max sessions 32, life time 90 seconds
Query max retries 4, retransmit interval 5 secondsこの設定では proxy-dns は PPPoE の ipcp でもらってきた DNS サーバに問い合わせる。これで IX2015 の proxy-dns に対して webalizer が激しく逆引きしまくると IX2015 がギブアップする。
ix2015-sh(config)# show memory
Calculating configuration memory size...
Heap memory:
97% memory used, 3% memory avail
Total 57241800 bytes
2117988 bytes free (1934964 clean, 183024 dirty)
55123812 bytes busy (39964144 reserve, 15159668 dynamic)ヒープが徐々に消費されてゆき 100% に達してしばらくすると死ぬ。すると、コンソールにこんなのが出る。
ix2015-sh(config)# System uptime is 58 minutes CPU is MPC8270A: PVR = 0x80822014, IMMR[16:31] = 0x0a10 CPU Register Context: R00 = 0x0000c0e6 R01 = 0x00b5b6b0 R02 = 0x00968830 R03 = 0x0000f5db R04 = 0x00441f80 R05 = 0x00000000 R06 = 0x006d0000 R07 = 0x006d0000 R08 = 0x006ced50 R09 = 0x03ffee7c R10 = 0x006ced5c R11 = 0x0085c598 R12 = 0x44b5ba84 R13 = 0x00000000 R14 = 0x00000000 R15 = 0xac1000fe R16 = 0xac100101 R17 = 0x00000000 R18 = 0x00870000 R19 = 0x00860000 R20 = 0x00860000 R21 = 0x00b5b6e0 R22 = 0x00880000 R23 = 0x0000649e R24 = 0x0000aa7e R25 = 0x0085c598 R26 = 0x0000002e R27 = 0x00441f80 R28 = 0x00000000 R29 = 0x0000f5db R30 = 0x0085c598 R31 = 0x0000f5db CR = 0x24b5ba44 MSR = 0x00003030 LR = 0x000002a0 SRR0 = 0x00178750 SRR1 = 0x0008b032 SPRG0 = 0x03000000 SPRG1 = 0x00000000 SPRG2 = 0xfe00f1cc SPRG3 = 0x00000001 XER = 0x00000000 CTR = 0x00000000 DAR = 0x00000000 DSISR = 0x00000000 ESR = 0x00000000 EMR = 0xff1f0000 ECR = 0xff1f0000 SIUMCR = 0x4060c000 TESCR1 = 0x00004200 TESCR2 = 0x00000000 PCI_EACR = 0x00000000 PCI_EDCR = 0x00000000 PCI_ECCR = 0x00000000 SIPNR_H = 0x40200000 SIPNR_L = 0xa000c000 SIVEC = 0x00000000 PDTEA = 0x010f5d28 LDTEA = 0x00000000 SDMR = 0x00 PDTEM = 0x24 LDTEM = 0x00 IPSEC_PCI_STS = 0x02a0 IU_PCI_STS = 0xffff Exception Type: machine check (watchdog) (0x00000200) Exception Stack: PC(SRR0) = 0x00178750, SP(R01) = 0x00b5b6b0 Stack Trace: F00: 0x00178868 F01: 0x004429c4 F02: 0x001795d8 F03: 0x00163448 F04: 0x0016361c F05: 0x00562b70 F06: 0x00563114 F07: 0x00027828 F08: 0x00000000 F09: 0x00000000 F10: 0x00000000 F11: 0x00000000 F12: 0x00000000 F13: 0x00000000 F14: 0x00000000 F15: 0x00000000 reboot... NEC Bootstrap Software Copyright (c) 2001-2008 NEC Infrontia All Rights Reserved. %BOOT-INFO: No boot records found, attempting flash load. %BOOT-INFO: Trying flash load, exec-image [ix2010-ms-8.3.48.ldc]. Loading: ######################################################## [OK] Starting at 0x20000 Loading configuration file: startup-configuration. Configuring router subsystems (before IDB proc): done. Constructing IDB(Interface Database): done. Configuring router subsystems (after IDB proc): done. Initializing router subsystems: done. Starting router subsystems: done. All router subsystems coming up. login:
負荷は高くない。
ix2015-sh(config)# sh utilization hi
System utilization per 5 seconds(last 5 minutes): 35/26/27 (peak/low/average)
(* = average, | = maximum and minimum)
222222222222222222222222232222222222222222222222222222222222
887887887788877887888888858898978788987798968878888789988888
100
90
80
70
60 |
50 |
40 *
30 *************************|**********************************
20
10
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
0s 30s 60s 90s 120s 150s 180s 210s 240s 270s 300s
System utilization per 1 minute(last 46 minutes): 29/25/27 (peak/low/average)
(* = average, | = maximum and minimum)
2222222222222222222222222222222222222222222222
8988888888888888888888888888888888888775555557
100 |
90 |
80 |
70 |
60 | |
50 | | | | |
40 | | || | |||||| | |
30 **********************************************
20 | |||||||
10
+----+----+----+----+----+----+----+----+----+----+----+----+
0m 5m 10m 15m 20m 25m 30m 35m 40m 45m 50m 55m 60m最初は dns cache max-records を増やして 1024 にしていたり ip ufs-cache max-entries 16384 していたので、そのあたりをデフォルトに戻した。けども、死ぬまでの時間稼ぎにはなるものの、そのうちヒープを 100% 食い潰して死んでしまう。
dns cache 自体を無効にすればメモリのお漏らしはほとんどなくなるけど、遅くなるよなあ。
ふつう webalizer 64 並列で逆引きなんてことはしないのだから、多少のお漏らしには目を瞑って dns cache は(少なめでいいから)設定しておいたほうがいい気がする。reboot 自体は速いので、家庭用アクセスルータとしては復帰も一瞬といえる範囲。*2
IX2015 の名誉のために書いておくと、こんな実験をするまでは一度もクラッシュしたことはない。
ix2015-sh(config)# sh version NEC Portable Internetwork Core Operating System Software IX Series IX2010 (magellan-sec) Software, Version 8.3.48, RELEASE SOFTWARE Compiled May 10-Tue-2011 15:33:32 JST #1 by sw-build, coregen-8.3(48) ROM: System Bootstrap, Version 22.34 System Diagnostic, Version 20.31 System uptime is 31 minutes System woke up by reload, caused by crash System started at Oct 13-Thu-2011 22:40:16 JST System image file is "ix2010-ms-8.3.48.ldc" Processor board ID <2> IX2015 (MPC8270A) processor with 65536K bytes of memory. 3 FastEthernet/IEEE 802.3 interfaces 1 ISDN Basic Rate interface 512K bytes of non-volatile configuration memory. 8192K bytes of processor board System flash (Read/Write) Current configuration is based on "startup-configuration" This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
IX シリーズのソフトウェアにはメモリ管理に問題があってクラッシュする、というのをどこかで読んだ記憶がある。また、その問題は 8.4.x などで解決しているらしい(?)けど IX2015 には入らない。
372：afo：2010/06/11(金) 16:35:43 ID:???downup
>>371
この糞スレにいる大多数のファーム乞食はIX2015を使ってる訳で、2015には
適用出来ない8.4系で改善されたとか言われても、それは改善されたとはいわ
無い。結局IX2015はメモリが足りなくなったら勝手に再起動っつー最悪かつ糞みたいな
http://2chnull.info/r/network/1269162000/
バグを放置したまま終了ってことで。
