SONY (製造は下請けである十和田オーディオ)の日本製ラジオであるICF-801 (cf. [ICF-801 | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/products/ICF-801/))が生産完了 (discontinued)っぽいと今更ながら知った (7/18頃に発表されていた？)。
以下のページでICF-801に「生産完了」のマークがついていると確認できる → [AMラジオの番組がFM放送でも聴ける ワイドFM（FM補完放送）！ | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/radio_sony/fm/)
このモデルのように長く生産されて「時代によって証明されている」モデルは細々とでも続けて欲しいと思ってしまうけれど、企業的には儲けが出なければどうしようもないって所なのだろうか。
後継機種とされているICF-506 (cf. [ICF-506 | ラジオ／CDラジオ・ラジカセ | ソニー](http://www.sony.jp/radio/products/ICF-506/))では、基本的な操作体系に変更はないようだが、部品点数削減のためかAM/FM切り替えスイッチに電源機能が統合されていたり、表示板のバックライトが無くなっていたりと、合理性は理解できるが「なんだかなぁ」と思う点がある。一方で、電源がC×3ではなくAA×3になっている点は、稼働時間が減りはするものの、電源の入手性という点から堅実な改善点だと思う。
カードサイズのシンセサイザーチューニングラジオICF-R351もいつの間にやらカタログから消えているし (後継機種はICF-R354MかSRF-T355あたり？)、世代交代は進んでいるんだなと。SRF-T355は、ワンセグの音声が受信できるXDR-63TVと共通点が多いようで、一度使ってみたい気はする。
2017年8月3日木曜日
2017年8月2日水曜日
fcitx-skkで「ゐ」や「ゑ」を入力する方法
defaultの変換テーブルでは:
* xwi → ゐ (ヰ)
* xwe → ゑ(ヱ)
fcitx-skkはlibskkを利用しているので、defaultのかな変換テーブルは、/usr/share/libskk/rules/default/rom-kana/default.jsonにある。これを見るまで入力できることすら分からなかった。
このmappingが気に食わなければ、適当な場所にcopyして内容を変更した上でそれを使うように設定すればoverrideできる (cf. [fcitx - Omong Kosong Lagi](http://www.lapangan.net/omongkosong/tag/fcitx/))。
ちなみに、fcitxってどう読むかご存知だろうか。ファイティクス、だそうな。
* xwi → ゐ (ヰ)
* xwe → ゑ(ヱ)
fcitx-skkはlibskkを利用しているので、defaultのかな変換テーブルは、/usr/share/libskk/rules/default/rom-kana/default.jsonにある。これを見るまで入力できることすら分からなかった。
このmappingが気に食わなければ、適当な場所にcopyして内容を変更した上でそれを使うように設定すればoverrideできる (cf. [fcitx - Omong Kosong Lagi](http://www.lapangan.net/omongkosong/tag/fcitx/))。
ちなみに、fcitxってどう読むかご存知だろうか。ファイティクス、だそうな。
Raspbianで起動時にscriptを自動実行させる
Raspberry Pi 3 Model B (RasPi3)で部屋のLED照明とか、RasPi3自身の冷却ファンのPWM制御とか、室温の計測&loggingをさせている。それらのscriptを起動時に自動実行させたくなったので調べてみた所、以下のwebpageがとても参考になった (というかそのものズバリ)。
* [Raspberry Piでプログラムを自動起動する5種類の方法を比較・解説](http://hendigi.karaage.xyz/2016/11/auto-boot/)
題にもあるように5つの方法が紹介されているが、個人的な用途やpros/consを考えると
cronのjobとして登録する方法が一番のお勧め。
* 登録と削除がcrontab -eで出来て楽
* 起動するscriptはuser権限で起動する
RasPi3はRTCを持たないので再起動時した直後など暫く時刻がズレていることがある。室温・湿度などをCSV fileに記録する際にはこれが問題となり、本来時系列順であるべき所がいきなり時間が戻ったりする。
19:01:03 ...
19:01:04 ...
18:30:33 ... <--- ここから...
...
18:30:52 ... <--- ここまでおかしい
19:03:12 ... <--- NTPで補正された
19:03:13 ...
cron側でNTPで時刻が補正される迄実行しないようにできれば一番良い。試してはいないが、systemdを使っているのだから依存関係を適切に設定すればNTPの実行後にcronを立ち上げられるような気もする。
取り敢えずsensorから値を取得するscriptの冒頭で、現在時刻とlog fileのmtimeとを比較して、現在時刻がmtimeよりも前 (eg. 現在=16:30でmtime=17:00)なら異常と判断してNTPによるsyncを待つようにした。
もしこれで足りなければ (super userで動かしたいとか)、/etc/rc.localに細工 (exit 0の前あたりに追記)する方法を取る。
正当なやり方はsystemdのserviceとして登録する方法なんだろうけど、たかが小さなscriptを自動実行させたいってだけであんな長ったらしい設定fileを書くのは面倒すぎる。
検索時に気になったのは、あちこちに残っている古い情報が検索の上位に出て来ること。例えばRaspbianのdefault init systemがsystemdに移行したとかの事前情報が無いと、上手く起動しないとか、設定fileが無いとか、無駄に混乱する原因になりそう。
* [Raspberry Piでプログラムを自動起動する5種類の方法を比較・解説](http://hendigi.karaage.xyz/2016/11/auto-boot/)
採用した方法と理由
題にもあるように5つの方法が紹介されているが、個人的な用途やpros/consを考えると
cronのjobとして登録する方法が一番のお勧め。
* 登録と削除がcrontab -eで出来て楽
* 起動するscriptはuser権限で起動する
cronを使う時の問題点 (2017-08-25追記)
RasPi3はRTCを持たないので再起動時した直後など暫く時刻がズレていることがある。室温・湿度などをCSV fileに記録する際にはこれが問題となり、本来時系列順であるべき所がいきなり時間が戻ったりする。
19:01:03 ...
19:01:04 ...
18:30:33 ... <--- ここから...
...
18:30:52 ... <--- ここまでおかしい
19:03:12 ... <--- NTPで補正された
19:03:13 ...
cron側でNTPで時刻が補正される迄実行しないようにできれば一番良い。試してはいないが、systemdを使っているのだから依存関係を適切に設定すればNTPの実行後にcronを立ち上げられるような気もする。
取り敢えずsensorから値を取得するscriptの冒頭で、現在時刻とlog fileのmtimeとを比較して、現在時刻がmtimeよりも前 (eg. 現在=16:30でmtime=17:00)なら異常と判断してNTPによるsyncを待つようにした。
発展
もしこれで足りなければ (super userで動かしたいとか)、/etc/rc.localに細工 (exit 0の前あたりに追記)する方法を取る。
正当なやり方はsystemdのserviceとして登録する方法なんだろうけど、たかが小さなscriptを自動実行させたいってだけであんな長ったらしい設定fileを書くのは面倒すぎる。
補足
検索時に気になったのは、あちこちに残っている古い情報が検索の上位に出て来ること。例えばRaspbianのdefault init systemがsystemdに移行したとかの事前情報が無いと、上手く起動しないとか、設定fileが無いとか、無駄に混乱する原因になりそう。
2017年7月7日金曜日
libc6 (glibc)をgcc-7でbuildする (@Debian Sid)
Debian Sidのgcc-7 (7.1)でlibc6 (glibc)をsource packageからbuildしようとすると、-werrorの効果でwarningがerror扱いになり途中で止まってしまう。これは使い方によっては有用なoptionだが、取り敢えずbuildを通したい時には面倒なので細工してみる。
glibcの./configure scriptには--disable-werrorという便利なoptionがあるのでこれを与えれば良さそうだと分かる。問題は、dpkg-buildpackageでbinary packageをbuildする際にどのようにこのoptionを./configureに渡すか。
まず最初に思い付いたのがdebian/rulesに適当な記述を加える方法だが、./configureに直接optionを渡せそうな設定項目が無かった。
次に目を付けたのがdebian/sysdeps/amd64.mkで、これはamd64 (aka. x86_64, x64) platformにて利用されるbuild script。中身を見てみると、丁度利用できそうな部分があったので次のように書き換え:
extra_config_options = --enable-multi-arch
extra_config_options = --enable-multi-arch --disable-werror
あとはいつも通り、top levelで:
% dpkg-buildpackage -us -uc -B -d -rfakeroot -j8
あたりを発行しbinary packageをbuild。
glibcの./configure scriptには--disable-werrorという便利なoptionがあるのでこれを与えれば良さそうだと分かる。問題は、dpkg-buildpackageでbinary packageをbuildする際にどのようにこのoptionを./configureに渡すか。
まず最初に思い付いたのがdebian/rulesに適当な記述を加える方法だが、./configureに直接optionを渡せそうな設定項目が無かった。
次に目を付けたのがdebian/sysdeps/amd64.mkで、これはamd64 (aka. x86_64, x64) platformにて利用されるbuild script。中身を見てみると、丁度利用できそうな部分があったので次のように書き換え:
extra_config_options = --enable-multi-arch
↓
% dpkg-buildpackage -us -uc -B -d -rfakeroot -j8
あたりを発行しbinary packageをbuild。
2017年4月17日月曜日
Intel CPUの殻割りとリキプロ化
今更ながら手持ちのCPU 2つを殻割り (delid)し、TIMをLIQUID PROに変えてみた。
Shuttleのキューブ型ケースを利用しているのでCPUクーラーの交換は難しい。そこで、いわゆる「グリスバーガー」を解消すれば状況が改善とすると考えて殻割りすることにした。
定格運用でも、いわゆる「熱ダレ」(thermal throttling)が起き難くなることが期待できる。
3330はoverclockできない（マザーボードもH61）ので殻割りする意味は余りないが、いきなり6700Kで作業するのが怖かったので練習がてらやってみた。
事前調査 (3770Kと6700Kについて)どちらもヒートスプレッダ内部にチップコンデンサ等が実装されていないので、難易度は低いと思う。
試しに負荷を掛けてみた。室温は23度C程度。CPU温度はpackage temperature。
主にゲーム用として使っているのでCINEBENCH、手持ちのゲームなどを試してみたが60度Cを超えない。
手持ちのソフトはCPUよりGPUパワーを必要とするタイトルばかりなので、AMD RX480がbottleneckになっている感じ。当然ながらCPU負荷も温度も上がらない
マシン構成
Linux machineで行う負荷の高い作業は:
※以下、PC内温度32度C
巷で話題のAMD Ryzenならソルダリングなのでこんな手間は必要ない。
利益率を上げる為に行われる製品の製造プロセスの見直しは必要だが、さすがにやってい良いことと悪いことがあると個人的には考えている。Intelは（せめてK付きとかは）ソルダリングに戻してほしいし、AMDにはこのままソルダリングで続けて欲しい。
動機
メインマシンの6700KでCPUに負荷を掛けるとパッケージ温度が70度Cを超えてしまい夏場の使用が不安である。Shuttleのキューブ型ケースを利用しているのでCPUクーラーの交換は難しい。そこで、いわゆる「グリスバーガー」を解消すれば状況が改善とすると考えて殻割りすることにした。
定格運用でも、いわゆる「熱ダレ」(thermal throttling)が起き難くなることが期待できる。
使った物
対象CPU
- Intel Core i5-3330
- Intel Core i7-6700K
3330はoverclockできない（マザーボードもH61）ので殻割りする意味は余りないが、いきなり6700Kで作業するのが怖かったので練習がてらやってみた。
事前調査 (3770Kと6700Kについて)どちらもヒートスプレッダ内部にチップコンデンサ等が実装されていないので、難易度は低いと思う。
道具類
- カッターナイフ (今回はその辺にあったものを利用したので刃は厚さ0.39mm。OLFAから壁紙カット用として販売されている0.2mmぐらいの薄い刃を勧める)
- テレホンカード (厚さ0.27mm。ボロボロになるので使用済み、もしくは不要なポイントカードなどがあればそちらを勧める)
- LIQUID PRO (液体金属。もしくはクマメタル)
- ブラックシーラー (ゴム系接着剤。本来は車のボディの補修に使う物だが、殻割りする人々の間でも広く用いられている)
- マスキングテープ (裏側の電極やチップコンデンサなどの保護のために利用。この用途にセロハンテープなどを使うと接着剤が残るのでNG。一方でゴミ取りには少々接着力不足)
- 綿棒 (CPUグリスやダイに残ったTIMを掃除する、LIQUID PROを塗るなど)
- 爪楊枝 (基盤やヒートスプレッダの内側に残った接着剤を擦り取ったり、ブラックシーラーを塗る時に使う)
- ティッシュペーパー (手に入るならキムワイプとかの方が良いだろう。一応のためダイは綿棒で掃除した)
- 燃料用アルコール (毒性の問題があるので無水エタノールを用いた方が良いが代用)
- 金属板 (静電気でCPUを壊さないように作業場として利用。気休め)
- エアダスター
作業を終えて、あったら良かったなと思ったもの:
- 絶縁テープ (6700Kはヒートスプレッダ内の基盤に剥き出しの電極があるのでそこを覆う。注文したが届いていないので今回はブラックシーラーで代用)
- セロハンテープ (ヒートスプレッダの位置を固定したり、飛び散った接着剤を掃除するのに便利。今回はマスキングテープで代用)
手順
- CPUのヒートスプレッダの隅から基盤との間にカッターの刃を入れる
- 或る程度入ったらテレホンカードやポイントカードを差し込んで接着剤を切っていく
- TIMと接着剤を除去してLIQUID PRO (もしくはクマメタル)をダイの上に塗る
- ヒートスプレッダの周囲にブラックシーラーを塗り元の位置に固定
- 乾燥させて固定する
- マザーボードに取り付けて動作確認
感想
- 最初にカッターの刃を入れる時が一番緊張する。角度を間違えると基盤を傷付け故障の原因になるので入らなくても無理をしない
- カッターだけでやる人もいるがテレホンカード類を用意した方が安全。或いは殻割り専用ツールを使う
- 3330でも6700KでもTIMは完全に乾燥してボロボロになっていた。これは冷えない訳だ
- ヒートスプレッダを綺麗に戻すのは結構難しいが、最初に写真を撮っておいてそれを参考にすると良いと思う。最終的には取り付けられれば問題ない
- 本来なら或る程度乾燥の為に時間を置くべきだが、壊していないか確認したくなり早速取り付けてしまったが今の所問題なく動いている
結果
試しに負荷を掛けてみた。室温は23度C程度。CPU温度はpackage temperature。
i5-3330
マシン構成- OS: Microsoft Windows 10 (64bit)
- CPU: Intel Core i5-3330
- Mem: DDR3-1333 16GBtyes
- GPU: HIS (AMD RX480)
- HDD1: WD5000AAKX (500GBytes)
- HDD2: WD30EZRX (3TBytes)
- 適当なケースがなくバラック状態
主にゲーム用として使っているのでCINEBENCH、手持ちのゲームなどを試してみたが60度Cを超えない。
手持ちのソフトはCPUよりGPUパワーを必要とするタイトルばかりなので、AMD RX480がbottleneckになっている感じ。当然ながらCPU負荷も温度も上がらない
6700K
マシン構成
- OS: Linux (Debian/Sid) w/ Linux kernel 4.10.10 (64bit)
- CPU: Intel Core i7-6700K
- Mem: DDR4
- GPU: Onboard
- SSD: SATA 512GBytes
- HDD: WD 8TB
Linux machineで行う負荷の高い作業は:
- Source codeからのbuild (Linux kernel, Mozilla Firefox, etc)
- 3D graphics (iGPU)を多用するsoftware (Stellarium, Celestia, etc)
- ffmpegなどによる動画encodingなど
※以下、PC内温度32度C
- Linux kernel (v4.10.10)、Mozilla Firefox (55.0a1, 54.0a2)などをbuildして60度Cを超えない
- Celestia, Stellariumなどを実行しても40度Cを超えない
- ffmpegでのsoftware encoding (h264)では最大63度C。QSVを利用したtranscoding (h264, rescaling)なら40度Cを超えない
これからの展望
巷で話題のAMD Ryzenならソルダリングなのでこんな手間は必要ない。
利益率を上げる為に行われる製品の製造プロセスの見直しは必要だが、さすがにやってい良いことと悪いことがあると個人的には考えている。Intelは（せめてK付きとかは）ソルダリングに戻してほしいし、AMDにはこのままソルダリングで続けて欲しい。
2017年4月2日日曜日
NieR:Automata Original Soundtrackのヨコオタロウ氏のメッセージをshellとnkfでdecodeする
NieR:AutomataのOriginal Soundtrackに付属するブックレットに、ディレクターであるヨコオタロウ氏のメッセージが16進数で記載されており、（大抵の人間は）そのままでは読めない。
ネット上では既に多くの先人達が解読しており、URL等で使われる「パーセントエンコーディング」であると知られている。これをshell scriptとnkfを使ってdecodeしてみる。
なお、メッセージの内容については一切触れない。
* OCRで文字に変換
* 16進数文字列→日本語
最も面倒だったのがOCRで文字に変換する部分だった。写真の撮影のしかたが悪かったのもある。今回はGoogle driveにuploadしてOCRにかけ、目視で比較して修正するという方法を取らざるを得なかった。
一旦文字列になってしまえば後はnkfに掛けるだけである。
% echo '\n＜16進数の文字列＞' | fold -s2 | tr '\n' '=' | nkf -WwmQ
まず、foldで2文字ごとに区切る。次に、trで改行コードを'='に変換する。最後にnkfに文字列を渡してdecodeする。
* [40.Linuxのコマンドから行うURLエンコード、URLデコード](http://www.garunimo.com/program/linux/linux40.xhtml)
* [パーセントエンコーディング - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%BB%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)
ネット上では既に多くの先人達が解読しており、URL等で使われる「パーセントエンコーディング」であると知られている。これをshell scriptとnkfを使ってdecodeしてみる。
なお、メッセージの内容については一切触れない。
実際の作業
* 写真を取る／スキャンする* OCRで文字に変換
* 16進数文字列→日本語
最も面倒だったのがOCRで文字に変換する部分だった。写真の撮影のしかたが悪かったのもある。今回はGoogle driveにuploadしてOCRにかけ、目視で比較して修正するという方法を取らざるを得なかった。
一旦文字列になってしまえば後はnkfに掛けるだけである。
% echo '\n＜16進数の文字列＞' | fold -s2 | tr '\n' '=' | nkf -WwmQ
まず、foldで2文字ごとに区切る。次に、trで改行コードを'='に変換する。最後にnkfに文字列を渡してdecodeする。
参考URL
* [shell で4文字づつ切り出す方法 - Qiita](http://qiita.com/mapk0y/items/51e6765add9b79264714)* [40.Linuxのコマンドから行うURLエンコード、URLデコード](http://www.garunimo.com/program/linux/linux40.xhtml)
* [パーセントエンコーディング - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%BB%E3%83%B3%E3%83%88%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)
2017年3月20日月曜日
SwissMicros DM15Lのfirmware v22がreleaseされていた
(2017-06-16更新) Firmware V23がreleaseされていたのでupgrade (詳細はhttp://typeinf-memo.blogspot.com/2016/07/swissmicros-dm-15lfirmware-upgrade.htmlにて)。
WP 43Sのhardwareを開発していることについて何か書いてないかとSwissMicrosのwebsiteを覗いてみたら、DM15L (及びその他製品の) firmware v22がreleaseされていた。
前回同様に無事update完了。WP 34Sもこれくらい楽だったら良かったのだが……。
WP 43Sのhardwareを開発していることについて何か書いてないかとSwissMicrosのwebsiteを覗いてみたら、DM15L (及びその他製品の) firmware v22がreleaseされていた。
前回同様に無事update完了。WP 34Sもこれくらい楽だったら良かったのだが……。
登録:
コメント (Atom)