ANT+準拠の無線心拍計が届いた

ANT+無線心拍計のパッケージ

何年も前から、運動時の記録が残せるような心拍計が欲しかった。Androidが登場してからはAndroid端末と連動する心拍計が欲しくなった。今ならBluetooth Low Energy (BLE)準拠のものを選ぶのが妥当な判断だろうが、残念ながら自分の使いたい端末で対応していない。悩んだ結果ANT+準拠のものを注文した。

CooSpo ANT+無線心拍計

それが中国から6/28に届いた。6/11にebay.comで注文したことになっているから、2週間強かかったことになる。まぁ、早い方ではないだろうか。

商品写真では”CooSpo”というブランド名らしきものが印字されている。が、自分のところに配達されたものは無印。ちなみに、文字のスタイリィングによって、”p”がなかなか認識できなかった。が、”Coo(l)” + “Spo(rt)”ということなんだろう。わかってしまえばなぜわからなかったかの方が不思議なくらい。

だが、”CooSpo”がわかったからといっても特に意味がない。どこの会社のブランドであるか、とか、この心拍計のモデル名/番号があるか、などは全くの謎だ。まぁ中華グッズにはよくある話。

製品の形状・使用形態は同様の商品と基本的に同じだと思うが、チェストストラップの内側に電極部が

説明書によると、チェストストラップの内側に電極部がある（黄色線で囲んだ部分）ということだが、これは知らなかった。てっきり、計測器の裏側部分だけがそういう役目を果たすものと思っていた。この製品だけの話か、他の同様の製品にも当てはまるのか、自分にはわからない。

心拍計ユニットをストラップに固定するスナップの間隔は4.5cm

ただ、心拍計ユニットをストラップに固定するスナップの間隔が4.5cm、というのは標準サイズのようで（写真は、今回購入したCooSpoのものではなく、eBayの一リスティングから）、以前買った中国Kyto社のHRM-2830のものとサイズ的には互換性がある。だが、パッと試した範囲では、CooSpoの計測ユニットをHRM-2830のベルトにつけて見ても、スマホから心拍計に接続できなかった。これがひょっとするとHRM-2830が使えなかったことと関係しているのかもしれない。

ちなみに、中国Kyto社のHRM-2830と今回のCooSpoの比較というと、計測ユニットはどちらも横幅はほぼ同じだが、CooSpoのものの方が縦に若干長く、かつ厚い。そうはいっても、着用しているときには全く気にならない程度。

Xperia X10 Mini, Galaxy Note 3とも無事接続（両端）。だが、Xperia Acro IS11S（真ん中）はダメな模様。

早速、ANT+をサポートしているはずのXperia X10 Mini E10i, Xperia Acro IS11S、Galaxy Note 3 N-9005でテスト。GN3はストックROMのまま（ただしルート化済み）だが、X10 MiniにはGinger BreadベースのカスタムROM MiniCM 7をインストールしてあるし、AcroにはIce Cream SandwitchベースのカスタムROMがインストールしてある。それぞれ、ANT Radio ServiceとANT+ Pluginsの2つのアプリが最初からプリインストールされているか（GN3）か、このために自分でインストールした（他の2機種）。後日他の連携Androidアプリについても調べてみた。

その上でANT+ Heart Rate Grapherで心拍数をモニタしてみた。簡単なペアリングの後（Bluetoothのようにパスキーの入力などはない）、X10 Mini, GN3では写真のように無事計測し始めたが、Acroではうまくいかない。

「ハートレートセンサー購入しました」、「Xperia acro IS11S + GARMIN Hart rate monitor」、などを見るとIS11Sにハードウェア的にANT+機能があることは間違いないと考えてよさそうだ。なぜうまくいかないのかわからないが、実際に心拍計と併用するのはX10 Miniのつもりだったので深入りしないようにする。一応接続に失敗した時のログは取ってみたので、この記事の末尾に付けておく。

これでわかるように、ANT+では1対多の通信が可能な模様。というか、既にペアリング済みの受信機が複数あるときに、特定の1台だけに送信する、ということはできないんじゃないか。もっとも実装を考えればこちらの方が簡単なんだろうが。

WikipediaのANT+のエントリ内の “ANT+ Plugins on Android”のセクションには以下の記述がある：

The ANT+ Plugins also feature multi-app concurrency, where any number of apps may have access to the same data coming from the same sensor simultaneously, and any number of phones/devices may read data from the same sensor simultaneously. This opens additional use cases such as always-on background monitoring for multiple apps or group training, and further reduces the burden on developers by helping to ensure them access to device data no matter which apps may be running at the moment.

しかし自分が試した範囲では、同じAndroid端末内では、受信を受けられるのは1アプリに限られるようだった。つまり、何かのアプリが心拍数データを受信している状態で、同じ端末上の他のアプリに心拍数データを受信させようとすると、「ANT+チャネルが使えない」といったエラーが表示され、場合によっては「無理やりこちらに奪うか？」というようなメッセージが表示された。これはGBベースのX10 Miniでの話なので、それが関係しているのかもしれない。その他のバージョンのAndroidの端末では試していない。

 

以下、「ほなみん化」したXperia Acro IS11Sで、心拍計に接続できなかったときのログ。

---- Jun 28, 2014 2:02:57 PM ----
06-28 13:46:36.257   349   657 I ActivityManager: START {cmp=com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard} from pid 4322
06-28 13:46:38.577   349   618 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.pluginsampler/.Activity_Dashboard} from pid 690
06-28 13:46:38.657   349   349 I ActivityManager: Start proc com.dsi.ant.antplus.pluginsampler for activity com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler: pid=4355 uid=10142 gids={}
06-28 13:46:39.907   349   657 I ActivityManager: Start proc com.dsi.ant.service.socket for service com.dsi.ant.service.socket/com.dsi.ant.service.AntRadioService: pid=4371 uid=10137 gids={3003}
06-28 13:47:03.047  4355  4355 E ActivityThread: Activity com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler has leaked ServiceConnection com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc$2@2bef2db8 that was originally bound here
06-28 13:47:03.047  4355  4355 E ActivityThread: android.app.ServiceConnectionLeaked: Activity com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler has leaked ServiceConnection com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc$2@2bef2db8 that was originally bound here
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.bindAndRequest(AntPluginPcc.java:638)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.requestAccess_Helper_SubMain(AntPluginPcc.java:549)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.requestAccess_Helper_Main(AntPluginPcc.java:522)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pccbase.AntPluginPcc.requestAccess_Helper_SearchActivity(AntPluginPcc.java:367)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pcc.AntPlusHeartRatePcc.requestAccess(AntPlusHeartRatePcc.java:197)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.plugins.antplus.pcc.AntPlusHeartRatePcc.requestAccess(AntPlusHeartRatePcc.java:246)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler.requestAccessToPcc(Activity_SearchUiHeartRateSampler.java:31)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.antplus.pluginsampler.heartrate.Activity_HeartRateDisplayBase.handleReset(Activity_HeartRateDisplayBase.java:90)
06-28 13:47:03.047  4355  4355 E ActivityThread: 	at com.dsi.ant.antplus.pluginsampler.heartrate.Activity_HeartRateDisplayBase.onOptionsItemSelected(Activity_HeartRateDisplayBase.java:389)
06-28 13:48:12.634   349   613 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.grapher.heartrate/.HrGrapherActivity} from pid 690
06-28 13:48:12.934   349   619 I ActivityManager: Start proc com.dsi.ant.antplus.grapher.heartrate for activity com.dsi.ant.antplus.grapher.heartrate/.HrGrapherActivity: pid=4427 uid=10141 gids={}
06-28 13:49:38.824   349   360 I ActivityManager: Process com.dsi.ant.plugins.antplus.managerlauncher (pid 4322) has died.
06-28 13:49:40.824   349   574 I ActivityManager: Process com.dsi.ant.antplus.pluginsampler (pid 4355) has died.
06-28 13:49:40.824   349   574 I WindowManager: WIN DEATH: Window{2bfc9468 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.Activity_Dashboard paused=false}
06-28 13:49:51.124   349   574 I ActivityManager: Process com.dsi.ant.plugins.antplus (pid 4334) has died.
06-28 13:50:08.654   349   657 I ActivityManager: Process com.dsi.ant.service.socket (pid 4371) has died.
06-28 13:53:20.285   349   574 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 pkg=com.dsi.ant.plugins.antplus.managerlauncher cmp=com.dsi.ant.plugins.antplus.managerlauncher/.PluginManagerLauncher} from pid 690
06-28 13:53:20.485   349   619 I ActivityManager: Start proc com.dsi.ant.plugins.antplus.managerlauncher for activity com.dsi.ant.plugins.antplus.managerlauncher/.PluginManagerLauncher: pid=5401 uid=10139 gids={}
06-28 13:53:20.705   349   359 I ActivityManager: START {cmp=com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard} from pid 5401
06-28 13:53:20.825   349   657 I ActivityManager: Start proc com.dsi.ant.plugins.antplus for activity com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard: pid=5413 uid=10138 gids={}
06-28 13:53:26.185   349   613 I WindowManager: WIN DEATH: Window{2c69d9a0 com.dsi.ant.antplus.grapher.heartrate/com.dsi.ant.antplus.grapher.heartrate.HrGrapherActivity paused=false}
06-28 13:53:26.185   349   614 I ActivityManager: Process com.dsi.ant.antplus.grapher.heartrate (pid 4427) has died.
06-28 13:53:26.195   349   614 W ActivityManager: Scheduling restart of crashed service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService in 5000ms
06-28 13:53:31.315   349   371 I ActivityManager: Start proc com.dsi.ant.antplus.grapher.heartrate for service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService: pid=5430 uid=10141 gids={}
06-28 13:53:33.065   349   359 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.grapher.heartrate/.HrGrapherActivity} from pid 690
06-28 13:53:33.905   349   618 I ActivityManager: Start proc com.dsi.ant.service.socket for service com.dsi.ant.service.socket/com.dsi.ant.service.AntRadioService: pid=5450 uid=10137 gids={3003}
06-28 13:53:46.155   349   619 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.plugins.antplus.managerlauncher/.PluginManagerLauncher} from pid 690
06-28 13:53:46.465   349   349 I ActivityManager: START {cmp=com.dsi.ant.plugins.antplus/.utility.db.Activity_PluginMgrDashboard} from pid 5401
06-28 13:53:48.275   349   574 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplusdemo/.ANTPlusDemo} from pid 690
06-28 13:53:48.525   349   618 I ActivityManager: Start proc com.dsi.ant.antplusdemo for activity com.dsi.ant.antplusdemo/.ANTPlusDemo: pid=5472 uid=10140 gids={}
06-28 13:54:10.155   349   657 I ActivityManager: START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.dsi.ant.antplus.pluginsampler/.Activity_Dashboard} from pid 690
06-28 13:54:10.645   349   561 I ActivityManager: Start proc com.dsi.ant.antplus.pluginsampler for activity com.dsi.ant.antplus.pluginsampler/.Activity_Dashboard: pid=5495 uid=10142 gids={}
06-28 13:54:18.145   349   561 I ActivityManager: START {cmp=com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler} from pid 5495
06-28 13:56:09.195   349   359 I ActivityManager: Process com.dsi.ant.antplus.grapher.heartrate (pid 5430) has died.
06-28 13:56:09.195   349   359 W ActivityManager: Scheduling restart of crashed service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService in 5000ms
06-28 13:56:09.805   349   561 I ActivityManager: Process com.dsi.ant.plugins.antplus.managerlauncher (pid 5401) has died.
06-28 13:56:10.915   349   349 I ActivityManager: Process com.dsi.ant.antplus.pluginsampler (pid 5495) has died.
06-28 13:56:10.915   349   349 I WindowManager: WIN DEATH: Window{2c0355a8 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.Activity_Dashboard paused=false}
06-28 13:56:10.925   349   587 I WindowManager: WIN DEATH: Window{2c26dbf8 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler paused=false}
06-28 13:56:10.925   349   390 I WindowManager: WINDOW DIED Window{2c26dbf8 com.dsi.ant.antplus.pluginsampler/com.dsi.ant.antplus.pluginsampler.heartrate.Activity_SearchUiHeartRateSampler paused=false}
06-28 13:56:14.225   349   371 I ActivityManager: Start proc com.dsi.ant.antplus.grapher.heartrate for service com.dsi.ant.antplus.grapher.heartrate/.HrCollectorService: pid=5628 uid=10141 gids={}
06-28 13:56:39.805   349   613 I ActivityManager: Process com.dsi.ant.antplusdemo (pid 5472) has died.
06-28 13:56:42.885   349   587 I ActivityManager: Process com.dsi.ant.plugins.antplus (pid 5413) has died.
06-28 13:57:42.015   349   613 I ActivityManager: Process com.dsi.ant.service.socket (pid 5450) has died.
06-28 13:58:55.283   437   437 E wpa_supplicant: Unsupported command: SETSUSPENDOPT 0
06-28 14:00:06.783   349   619 I ActivityManager: Start proc com.dsi.ant.antplus.pluginsampler for activity com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler: pid=6062 uid=10142 gids={}
06-28 14:00:07.733   349   359 I ActivityManager: Start proc com.dsi.ant.plugins.antplus for service com.dsi.ant.plugins.antplus/.heartrate.HeartRateService: pid=6078 uid=10138 gids={}
06-28 14:00:08.333   349   360 I ActivityManager: Start proc com.dsi.ant.service.socket for service com.dsi.ant.service.socket/com.dsi.ant.service.AntRadioService: pid=6094 uid=10137 gids={3003}
06-28 14:00:08.593   349   384 I ActivityManager: Displayed com.dsi.ant.antplus.pluginsampler/.heartrate.Activity_SearchUiHeartRateSampler: +1s847ms
06-28 14:00:20.333   437   437 E wpa_supplicant: Unsupported command: SETSUSPENDOPT 0
06-28 14:00:20.663   437   437 E wpa_supplicant: Unsupported command: SETSUSPENDOPT 0
---- Jun 28, 2014 2:02:57 PM ----

台湾ROMを積みドコモXi SIMカードを挿したHTC J ISW13HTからSMSを送信する

自分のメイン端末のHTC Jは台湾ROMではXi SIMカードを使っている場合、普通の方法でSMS送れない。このことは「ISW13HT HTC J、Sense4.1ポートROMについて (HTC速報Dev)」で、このROMを編纂した方本人が書いておられる。ソフトバンクSIMカードなら問題ないようで癪だ。

そのページにコメントの中にも書いたが、Beyond SMSというアプリ（XDAでのスレッド）を使えば可能。単なる「ドコモ以外のスマホからドコモのSIMでSMS送信をすると失敗するようだが”validity period ”を設定可能なSMSアプリなら送信できるようだ」の受け売り。ただ、Beyond SMSはSMSアプリの置き換えを意図しているわけではなく、プログラム的に操作しようとすると（例えば特定のイベントで自動的にSMSを発信する、など）簡単ではない。

さて、最近Xposedを試しにインストールしてみたときに、XposedのモジュールにXposedSendRawSMSというのがあるのを知った。これは、かつてはAndroidのAPIの一部であったsendRawPduを使用するもので、それはBeyond SMSと同じ。sendRawPduはその後のAndroidのバージョンで廃止されてしまったようなのだが、一部Androidデバイスのモデルでは、製造会社が意図的に残しているらしい。自分のHTC Jはたまたまそういう端末であったため、Beyond SMSが使える。つまり、XposedSendRawSMSも使える可能性が大。

XposedSendRawSMSの中身を見てみると、核となるのはModSmsMessage.javaのようだ。リフレクションを使ったコードなんて久しぶりに見た。XposedSendRawSMSは、sendRawPduのパラメタを自由に設定した上でSMSを送れるようにするのがその目的だが、自分の場合そんなことはできる必要はなく、validity periodを決め打ちで変更できればいいだけ。なので、XposedSendRawSMSをいわば機能縮小したモジュールを作成すれば、普通のSMSアプリを使って、普通にSMSの送受信ができるようになるのではないか。

以下参考：

• Online PDU Encoder and Decoder
• SMS Messaging
• SMS PDU mode
• Development Tutorial

 

 

HTC J ISW13HTにXposedを導入してみた

HTC J ISW13HTに台湾ROMを焼きさらにWCDMA (UMTS)化をしてドコモのネットワークで使っている。自分の用途には十分なパフォーマンスで概ね満足しているが、電池の管理には少し不満があった。通知エリアに表示されるピクトグラムではまだそこそこ電池に残があるように見えていても、突然「あと9%です」とかいう通知があって、手を打たないと、と思うまもなくシャットダウンしてしまう。ピクトグラムではなく、はっきり残量をパーセント表示で見たい。

Xposedというルート化済み端末向けのカスタマイズ機構で実現できそうだ、と考えて、以下を参照にやってみた。

• Xposed モジュール まとめ
• [FRAMEWORK ONLY!] Xposed – ROM modding without modifying APKs (2.6.1)(20.05.2014)

Frameworkをインストールして初期化した際、Segmentation faultが起こる、ということで、busyboxバイナリを含むインストーラーで再度インストールすることを求められた。

さて、Xposed Module Repositoryを見たりしながら自分の用途に使えそうなモジュールをインストールして試してみたが、うまくいくものがなかなかない。モジュールはJelly Bean以降を対象としていることが多いようで、ICSのこのROMには適用できないのかもしれない。

そこそこ時間を費やして試しまくり、やっと目的を達成してくれたのは、Ex-Themer[ICS/JB][ A Warehouse Of Android Themes ]。

が…数字表示の数字が小さくて読みにくい…。てか、読めない。ああ、嫌だよ老眼、激しく嫌。

結局、XBatteryThemerという普通のアプリを使うことにした。しかも、その後、SDカードの問題でシステムの初期化をしなくてはならなかったので、Xposedフレームワーク自身今は全く使わない状態になってしまった。

参照：

• Collection of Xposed Modules on XDA Developers

DLNA/UPnP AV DMSs and Playlists

Yet another old and only-half-finished article, which I am publishing anyway. On the topic, I ended up using Playlist Creator on the file system from which our primary DMS serves its contents. Using relative paths, of course.

---

It turns out that the DLNA/UPnP AV standards do not provide systematic support for server-side playlist management, which I find utterly surprising. Aren’t there obvious needs for that?

Some DMSs pick it up if there’s a playlist file while scanning their media libraries in file systems, but there does not seem to be any predefined protocol through which you can manage playlists; you can only do that on the file system you are exposing to DMSs. For example, here is a way to do it for MiniDLNA servers. Also, here’s a list of playlist creation tools.

Some DMPs, DMRs and DMCs do support playlists, but not in a collaborative way. Normally those playlists are never propagated elsewhere and stay isolated, confined only inside that particular device/app.

If they should be propagated at all, that happens only between, say, a DMS and a DMC that are designed to work together from the get-go, but not between other devices/apps. Since there is no support for it from the DLNA standards themselves, the interoperability does not exist.

That is why I was very much intrigued by BubbleUPnP Server. It is not a DMS by itself, but it works as a proxy to existing DMSs and provides additional functionality, such as transcoding and remote access.

I am sure some would consider it useful enough for those additional benefits, but I was more interested in the fact that it can also create an OpenHome compliant renderer, acting as a proxy to an existing DMR .

I’ll be honest here — I am not still quite sure what OpenHome is. My first impression was that it is a home automation framework (on a related note, I wrote “Home Automation Systems and Intercoms” before). iControl Networks does present it that way. At any rate, OpenHome includes an arm on home media management called OhMedia, which supposedly addresses the flaws of the UPnP AV standard. Each of the claims seems legitimate, but my take on it is that they should be addressed by augmenting the UPnP standard, not by creating a separate standard. At any rate, OhMedia offers the playlist management functionality, and that is the additional benefit you get by creating a OpenHome compliant DMR with BubbleUPnP Server.

Initially, I thought that was exactly what I wanted, but then realized it wasn’t. The server maintains playlists on its side on the per-renderer basis. Is this what people normally want? Don’t we rather want playlists that are not bound with a particular renderer?

Sure, since you can start playing a playlist on a renderer and then switch the renderer midway, you could potentially create playlists for a “catch-all” renderer and use its playlists as “renderer-unbound” playlists. But I find this solution conceptually unnecessarily complicated and methodically awkward. (I’d also think the initial renderer needs to be present at all times for this scheme to work.)

So, okay, the verdict is in: BubbleUPnP Server is not for me. At least with regards to the server-side playlist management, that is. I might use it for its transcoding and remote access capabilities.

The other option I considered is Twonky Server (Packet Video’s explanation of Twonky Server) combined with Twonky Manger.

You can create playlists with Twonky Manager running on your Windows PC or Mac (no Linux) for Twonky Server. Those playlists will be shown on your DMC/DMP in a Playlists folder. If you are running Twonky Server on a Windows PC, the playlists made on that PC in Windows Media Player will be shown alongside.

The fact

The Android app Twonky Beam’s UI is not quite user friendly. It does not allow playing videos on an external player, thus limiting the codecs it can handle.

In the Windows version, those playlist data are stored at a specific place. Since Twonky Server offers WebDAV access, I wonder why you cannot just place those playlist files directly in such a way that those playlists can be utilized even when the media contents are served by other servers.

One interesting feature of Twonky Server is to aggregate media content from other DLNA servers. I was surprised to learn that it can download DTCP-IP mpegs from the over-the-air digital TV tuner with recording capabilities.

Comparison of UPnP AV media servers

Universal Media Player, derivative of PS3 Media Server

 

Android端末でApp2SD機能によりSDカードに追いやったアプリが消えたり現れたり

先週末にはまった話。

自分のメインのAndroid端末でそのApp2SD機能によりSDカード（厳密にはmicro SDHCカードだがここでは簡単に「SDカード」と呼ぶことにする）に追いやったアプリが消えたり現れたりする、という現象が起こるようになった。再起動で解消することもあれば、そうでないことも、という状態。

件のSDカードは2つのプライマリ・パーティションに分けてあった。第1パーティションはFAT32でフォーマットしてあり、Androidからは普通の外付けSDカードはカードの扱い。2つ目のパーティションはExt4でフォーマットしてあり、Link2SD用に使っていた。

最初は、SDカードのマウントそのものに失敗していると思い込んでしまった。実は第2パーティションは問題なくマウントされてLink2SDによりそこに格納されたアプリは使えていた。第1パーティションも全くマウントされないのではなく、App2SD機能でSDカードに追いやったアプリを格納する/mnt/asec以下がダメなだけで、それ以外の普通のファイルは問題なくアクセスできた。

このしょっぱなの現状把握の段階で誤ってたので時間をだいぶ浪費した。これに気づく前に、たまたま用意していてた新しいSDカードに総入れ替えして置き換えてみたが同じ症状だった。

App2SDの動作の仕組みとか調べてみたが（簡単な説明、もう少し詳しい説明（ディレクトリ名などは古い））、だからどういう原因でこういう現象が起きていて、どう対処すればいいかまでわからない。Link2SDは動作していたので、App2SDはもう使わないようにして全てLink2SDにしてもよかったが、気持ち悪いので以前この問題が起き始める前にCWMリカバリーでバックアップしていたデータをリストしたが /data がリカバーできないというエラーが出る。これは想定外。何のためのバックアップかわからない。

もうしょうがなくROMの焼き直しで初期化。

Link2SD用の第2パーティションはそのまま。つまり、初期化してもそのパーティションは削除されないので、その後Link2SDをインストールして、（ルート化が必要だが）それによりしかるべきマウントスクリプトを導入すれば、それらアプリはすぐ再使用できるようになる。第2パーティションにAPKがあっても、Link2SD自身が認識できていないとそれに相当するアプリは使えないので、Link2SDのオプションの「全てのアプリを再リンクする」を選択し、その後再起動すればその後それらアプリは使えるようになる。

ただ、無料版のLink2SDではアプリの内部データまではSDカードに移せない。なので、上記のようにして、初期化後も以前のアプリが使えても、肝心の設定データ等が失われてしまう。有償のLink2 SD Plusを購入すれば、内部データまではSDカードに移すことが可能になる。予めそうしておけば、今回のように初期化を経ても、設定データ込みで以前のユーザーアプリがすぐ使えるようになるはず…と期待している（未確認）。

しかし、何が悪かったのかわからないが、また最初の問題が発生するようになってしまった。

ここで、App2SDによりSDカードに移されたアプリが格納されている/sdcard/.android_secureディレクトリの名前を、ものは試しでリネームしてみた。Android OSが立ち上がっている状態ではこれはrootでもマウントを解除したりしなければできないので、CWM Recoveryで/sdcardをマウントをした状態でadb shellでroot権限にて行った。その後端末を立ち上げると、システムが自動的に/sdcard/.android_secureを作成するのだが、その上でApp2SDを行うとうまく行っているように見える。

ちなみに、初期化してしまったのでTitanium Backupから取ってあったバックアップをリストアしようとした。そのため、Titanium BackupをPlayストアから再インストールしようとしたが、何度試そうと「容量が不足」エラーでインストールできなかった。結局、/data/以下に元々はLink2SDが作ったと思われるシンボリックリンクが残っていたのが原因で、これを削除すると無事再インストールできた。その他の一部アプリに関しても同様の状態になっていたので、久しぶりに書いたスクリプトでこれら無効なシンボリックリンクを削除すると、問題なくリストアできた。

今は、アプリのSD移動は基本Link2SDでExt4の第2パーティションに移すことにしている。その上でテストを兼ねて、使えなくなってもすぐには困らないようなアプリをAndroidネイティブのApp2SD機能でFat32の第1パーティションに移している。その後数日経つが、今のところ安定して動作しているようだ。

考えてみると、この問題が起こっているときは、端末が異様に熱くなっていた。App2SD機能の実現には複数のmountが使用されているが、これが何らかの理由でうまくいかず、何度もリトライでもしていたのだろうか。

モバイルPSTNのPBX収容

最近、携帯回線での発信が定額、というサービスが出てきている。これがPBXに収容でき、trunkとして利用できれば非常に使い勝手がよいだろう。

その携帯回線用のスマートフォン単独でこのブリッジが実現できれば理想的だが、自分が知る限り簡単にそれが実現できる方法はない。あればこのようなコーダー公募はないだろう（それにしても、予算$250 – $750なんて無茶苦茶）。

なので、自前でPBXを運営し、しかるべきセットアップをする必要があろう。パッと調べてみると同じようなことを考える人はいていろいろ見つかった。

GoIPなるデバイス（紹介記事）。Aliexpressでもいくつかモデルがある。残念ながらどれもGSMのみに対応のようで、日本では使えない。VoIP-Info.orgには同様の機器のリストがある。その中でGemproという台湾の会社の製品が面白い。そのeBayのストアではGP-710という電話端末とBluetoothで接続するタイプのものが$170. モバイル網との通信はBluetooth接続する電話端末の機能次第なので、それがUMTS (WCDMA)をサポートしていればそれが使える。

追記：Siemens Business Comm Gigaset One S30853 H1135 R301 Bluetooth Gatewayなんてのがある。$70程度だからこの手のものにしては最も安いのではないだろうか。

「電話革命-写真編」でPORtechのMV-370という機器が紹介されている。これは単独でUMTS通信機能を持つ。PORTech VoIP GSM Gateways,SIM Server,SIM Bank,E1 GSM Channel Bank,SMS Gateway,SMS Server,IP Speaker,3 way conference box,GSM VoIP Terminal,3G VoIP Gateway,UMTS SIP Gateway,VoIP CDMA Gateway,GSM Fixed Wireless Terminal,sim array,VoIP Adapter ATA–VoIP GSM GatewayによるとCDMA2000対応版もある模様。設定方法。eBay.comで見ると、$275（送料別）で、やはりGP-710の方が安い。もっとも別途Bluetooth対応の端末が必要になるが、それは一台くらい転がってるものだろう。

Asterisk用Chan_dongleモジュール。Huaweiのドングルを使うものでこれは3GもOK。Chan_mobileでBluetooth端末と接続。

2005年以降更新のないMiax: Mobile IAX。OpenWrtではリポジトリからすぐインストールできる。Inter-Asterisk eXchange – Wikipedia, the free encyclopedia。

FreeSWITCHであれば、GSMopenというモジュールで実現できそうだ。MobiGaterというGSMopenと併用することを前提にしたハードウェアもある（Asteriskとの併用も可）。Bluetoothで接続した携帯端末を利用するというmod_handsfreeという非公式のモジュールがある（ただし古い）。GSMOpenでBluetoothが利用できた、というコメントもある。参考：HFP for Linux is a Bluetooth Hands-Free Profile server。

OpenBTS (Wikipedia)。上のAsterisk、FreeSWITCH専用のモジュールではなく、Asterisk, FreeSWITCHなどのPBXシステムから利用できるよう独立したもののようなもの？GSM専用のように思えるが、UMTS（日本ではWCDMA）についての言及もあるので、それもサポートしているかも。関係ない？

Bluetooth対応の携帯電話（スマートフォンでなくても構わない）とAsteriskをChan_MobileというモジュールでBluetoothで接続させる。すご…。

番外：

SIPではないが、GSMとSkypeとのブリッジ。モデムから得られる音データではなく、ヘッドセットジャックからの出力を利用するという執念を感じさせる力技。

Skypeというと以前はSIPとのブリッジに興味があった。もうあまり必要性を感じてないが、Ippiの無料のUnlimited 5というプランは、SIPからSkypeやHangoutsへのブリッジをサポートするようで、それはそれで面白いかも。ただ、条件つきの無料かもしれない。

EZCastが届いた

パチもん感バリバリのパッケージ

とはいえなかなか洒落てはいる

注文していたChromecastクローンのEZCastが届いた。以下、自分の感想・メモだが、あくまで自分用であり、他の紹介記事に出ているようなことはばっさり省略しているので、ご覧になる方はそのつもりで。これだけ読んでも、全体像はわかりませぬ。

EZCastデバイスが自宅LANにwifi接続できるよう、手元のAndroid端末上のEZCastアプリでセキュリティーキーを入力する必要があるのだが、Google日本語入力を使っていると、ソフトウェアキーボードのキーを押すたび、その前に入力された文字が消去された。一時的にデフォルトのキーボードに替えることでしのいだ。

給電用USBケーブルはwifiアンテナも兼ねている模様。使用中結構暖かくなる。

EZCastデバイスを使用とするデバイス（仮にクライアント・デバイスと呼ぶ）は、直接それにwifi接続する。そのEZCastデバイスは無線LANルータにwifi接続する。クライアント・デバイスがLAN、あるいはインターネットに接続するにはEZCastデバイスを経由する、というのが基本の使用形態。対してChromecastの場合は、クライアント・デバイスとChromecastとはセットアップ時のみ直接wifi接続し、その後は一般的IPデバイス同様、二者はルーターを介して接続するようになっていると理解している。

EZCastデバイスを使用とするデバイスには自宅LANのサブネットとは別のサブネットのIPアドレスが振られる。自宅LAN内のデバイスは見えない（例えば後で出てくるDLNAメディアサーバ）が、インターネットとの間で動作するHangoutsやSIPによるVoIPは問題なかった。

VGAディスプレーを使ってテストするためゴテゴテとアダプタをかます。くたびれた畳が哀愁を誘う。

さて、EZCastデバイスはそうやってインターネットに繋がるなり自動的に自らをアップデートした。失礼ながら中国製品とは思えないまともさ。

それどころが、全般的にきっちり作りこまれていて好感をもった。画面表示は自動的に日本語が選択され、その日本語に違和感もない。ただ、マニュアルには残念感がひしひしと漂う。一度だけでも英語に堪能な人を一人雇うだけで、あまりに頓珍漢な英語は避けられると思うのだが。

ステータスを示すLEDランプがあるのだが、最初壊れて全く点灯していないんじゃないかと思ったくらい、はかない点灯ぶり。まぁ、実害はないが、LEDに対する不満としてはまぶしすぎることが多いことを考えると、ちょっと意外。

先程も述べたように、クライアント・デバイスは通常EZCastデバイスを介してインターネットに繋がる。しかし、その基本の使用形態ではなく、クライアント・デバイスが直接自宅LANに繋がっている状態でも、EZCastデバイスのDMRはアクセスでき、同時に自宅LAN内のメディア・サーバー（DMS）は見えるのでよかった。これができなければ自分としては利用価値は激しく落ちるところだった。

やる気を感じさせない音楽再生画面

とはいえ、音楽を再生させたときの画面のやる気のなさと言ったら…。アルバムアートくらい表示して欲しかった。全般的になかなか完成度が高い製品なので、もう少し頑張って欲しかったところ。

ちなみに、自分が以前CDをリップする際はWMAでエンコードしていたが、これをBubbleUPnPを通じてEZCastデバイスに再生させようとすると、サポートされてないフォーマットだ、といってエラーになる。が、これはBubbleUPnPのSettings -> UPnP Tweaks -> Mime-type checkのチェックを外すことで回避できた。

アカウント登録するのにSSIDの入力も求められる

Windows 7/8 PCからはサブディスプレーとして使えるようだ。このYouTubeビデオの4:08過ぎから、それを行っている様子を見ることができる。自分も試そうと、Windows用クライアントソフトをダウンロードしようとしたら、iezu.comでアカウント登録を求められた。そのときに電子メールアドレスだけでなく、EZCastデバイスのSSIDの入力も求められたのにはちょっと感心した。機種ごとのIDの役割を果たしているのであろう。

さて、自分のメインのデスクトップPCで試してみると、EZCastデバイスにwifiで接続できることが要件のようで、その機能のない我がPCでは無用の長物となってしまった。

自分としては、EZCastデバイスを利用するためには、クライアント・デバイス上でwifiのアクセスポイントを変えねばならないこと、基本的にあらゆる操作をEZCastアプリを経由して行わなければならないところが煩わしい。Chromecastであれば、wifi設定の変更は必要ないし、アプリ側が対応してさえいれば（例えばビデオ・プレーヤー）、アプリを使用中、「あ、これはTVで見たいな」と思ったら、すぐアプリのキャストボタンでChromecastで再生できる…はず（何せ実物を持ってないので想像）。いちいち、EZCastを立ち上げて、再生していたビデオを再度探して…などという面倒な手続きは発生しない。ただし、上で述べたように、DLNA機能だけであればwifi設定を変えることなく利用できる。

結論としては、もし自分だけが使うという前提ならどうせDLNA機能しか使わないので2,000円強ならまぁありかな、と。最近のTVはスマート化していてDLNA機能などは最初から持っていたりするようだが、そうでないものにこれを挿して、簡単スマート化するのも手だろう。EZCastの方はまだ機能が上がる可能性がある分、あるいは自分でハックできる可能性がある分、扱いやすいとも言える。

最近のAndroid端末にビルトインの基本的なメディア再生アプリには、さりげなくDLNA機能が盛り込まれているように思う。Samsungの端末にはAllShareという名前で、XperiaだとThrowというボタンで、既に端末上で再生中のものを他のDMRに再生させられるようになっている。DMCからメディアをコントロールするより、このようにDMPから行うほうが我々の直感に合っているのではないだろうか。この傾向はChromecastの登場もあってますます加速するだろう。だとすると、EZCastのようなディバイスにも、DLNA機能さえあれば一般人には用が足りるんじゃないかと思う。もっとも、アプリ（製作者側）の都合でそうされたくないもの（例えばVODアプリ？）を無理やりTVで見るためにはミラーリングが有用かもしれないが。

いずれにせよ、これはそもそもiOSデバイス（具体的にはiPad）ユーザ向けのプレゼントとして用意したもの。EZCastのAirPlay機能を利用するなら、Chromecastと同様の使い勝手が得られると期待している。ただ、それでもwifiのAPを替えなければならない、というのはいただけない。←これは自分の誤解で、iOSデバイスとAirPlayを介して利用する際には、最初のセットアップ時以外直接iOSデバイスからEZCastにwifi接続する必要はない。それぞれがルーターにwifi接続し、ルーターを介して間接的に接続する形態で利用できる。

物理的な設置については、”EZCastの設置を試みた“をご覧あれ。

Mopera UスタンダードプランからSPモードへ変更…しなかった

自分はドコモの回線を2本持っている。1本は主回線で音声通信主体。2本はデータ専用回線。あと、父用のが1回線（音声主体）。これら全てでデータ通信のISPとしてMopera Uスタンダードを利用してきた。使用料は月500円であるが、最初の6ヶ月間は無料、というキャンペーンをやっていたから。が、その6ヶ月が過ぎようとしていたのでより安いものに変更しようとした。

もととは、「「mopera U シンプル」プランの提供および「mopera U スタートキャンペーン」お申込み終了について」というのを知り、スタンダードプランの500円から200円（どちらも税抜き）に落とせるのならめでたい、と考えた。しかし、ドコモショップで手続きしようとすると、それはドコモの新料金プランの一環で、シンプルプランを利用しようとすると、新料金プランに切り替えないといけないという。それは自分にはメリットがないので止めて、代わりにMopera Uシンプルプランよりは高いものの、スタンダードプランよりは安いSPモード（300円/月）に変更を依頼した。

これが愚かだった。

ISPとしてSPモードとMopera Uとの違いをよく理解していなかった。特に、SPモードはドコモ端末専用で、IMEIによるふるいわけにより、それ以外の端末からは使えない、ということを知っていなかった。「SIMロックフリー端末をdocomoのSIMカードで利用する方法まとめ！」ぐらい目を通しておけばよかったが、ドコモのSIMカードであれば、ドコモ純正端末であるかないかがISPの選択に影響がある、という発想が全くなかったのだ。なので、一般ドコモユーザ向けの違いの解説を読んでは、ちょっとした機能の違いしかないのか？などと考えていた。

とはいえ、SIMフリーiPhone5でSPモードが使えた（同様の情報）、あるいは、Google Play版Nexus 5でも、という情報もあるにはあるので、XperiaのspモードのAPN情報を参照しながら、ダメ元でメイン端末のHTC J ISW13HTとサブ端末のSony Ericsson Xperia X10 Mini E10iの2機種で試してみた。使用したSIMカードは、Xi用で、当然その回線用にSPモードの契約はしてある状態。

結果はやはり双方の機種でダメ。まぁそうだよな…。

結局元のMopera Uスタンダードプランに戻すことに。ただし、データ専用回線のみで、その他の2回線についてはISP契約を全くしないことにした。普段使うことはなくても、何かの非常事態に単独で（つまりモバイルルーターが使えなくても）データ通信ができるよう、保険をかけられるのに越したことがないのだが、その費用が月500円だと割が合わない、と判断。

ちなみに、このデータ回線契約に付随してDocomo Wifiも利用しているが（自分の契約しているデータプランでは無料なので）、wifiのセキュリティーキーは以前と全く同じだ。考えてみれば激しく当たり前な気も。

さて、このデータ通信用回線については、ドコモのスタッフに、電話でしか情報を確認したり契約の変更したりできない、と説明されたが、それが嘘だということがわかった。My Docomoを利用するにはDocomo IDが必要。Docomo IDの作成には通常認証のためSMS受信が必要だが、SMSが受信できなくても登録する方法がちゃんとWebには記載されていた。言われたことをそのまま真に受けた自分が馬鹿だった。

My Docomoを使えるようにした上で今までの料金を見ると、このデータ通信回線の費用は610円/月だった。これからMopera Uスタンダードプランの費用が追加されるので合計1,100円強になるが、これで月に7GBまでLTEで通信できるのだから悪くなかろう。最近価格競争の激しいMVNOの提供するサービスでも、これに匹敵するのは見当たらない。モバイル・ルーターを別途持ち歩かなくてはならなのだが煩わしいが。

ちなみに音声回線については、月々サポートの額の方が通話料金を除く各種料金より大きいので、事実上無料電話分があるような状態。2年目から基本料金（タイプXi にねん、だったか）の780円/月が課金されるようになるから、そうするとこの無料電話分はなくなるだろう。それでも月300円、とかそういう程度になるはず。

VoIPサービスScydoを試してみた

「世界一安い海外IP電話サービス『Scydo』アプリの使い方」、「『Scydo」　（通話料［１．４円／分］の電話サービス）」、なんかをみて、ScydoというVoIPサービスに興味をもった。何せありえないような安さ。SIPサービスプロバイダという形ではなく、専用のAndroidアプリ、あるいはiOSアプリで利用する形になる。

が、その使用には躊躇した。なぜなら、いわゆるBetamaxクローンと呼ばれている一群のVoIPサービスプロバイダの1つであるから。Betamaxクローンは総じてビジネス面で評判が悪い。たいがいは、一旦クレジットカード情報を渡してしまうと、その後いわれのないチャージをされてしまう、といった苦情だ。

ただ、上記記事を見るとiPhoneアプリではiTunesから支払えるので直接クレジットカード情報 が渡す必要がなく、それならまだ安全だろうと考えた。Androidアプリについてはあまり記載がなかったが、それではきっと同様にGoogle Playから支払うという道が用意されているだろう、と勝手に踏んだ。…が、それは誤りだった。Androidアプリではそのような支払い方法は用意していない。

そこで一計を案じた。この時点で既に自分のAndroid端末でアカウントを作成していたので、知人のiPhoneユーザに頼んで、自分のアカウント情報を教えた上でScydoアプリをインストールしてもらい、それでiTunesでの支払いの代行を頼もう。…が、これも失敗。なぜかそういう支払いの選択肢が提示されないという。

それならば、と一旦既に作ったアカウントを削除することも考えた。ウェブサイトScydo.comのアカウント管理画面では、そのためのボタンが用意されているのだが、何度押そうと何も起こらなかった。

諦めてウェブサイトScydo.comでクレジットカードを使って10ユーロ分のクレジットを購入。ちなみに、アプリでのログイン時には自分の携帯番号として090…や080… のままを使えばよいが、ウェブサイトScydo.com上でログインする際は、先頭の0を落とさなければならない。

実際に使ってみた感想は以下。

このアプリを使って発信すると、アカウント作成時に登録した番号が通知される。どの端末を使っても、だ。SIMカードすら挿さずwifi運用している端末からアプリを使って発信しても、だ。これを詐欺紛いだと感じる人は多いだろう。

ただし、「世界一安い海外IP電話サービス『Scydo』アプリの使い方」にも書いてあるが、ドコモ回線には非通知になってしまう。非通知電話を拒否している人も多いだろうから、これはうれしくない仕様。もっとも、おそらくはこれはドコモ側の事業者としての判断の結果で、その判断自身は正しいと思うが。

上記記事では、通話音質は十分使いものになる、というふうな記載があるが、端末機種によって違いがあるようで、Au携帯電話番号宛に発信してテストしてみると、現在自分のメイン端末のHTC J ISW13HTでは、相手の声はこちらには明瞭に聞こえるものの、こちらの声が相手には聞き取れないほど小さくしか伝わらないらしく、実用にならない。極めて残念。公式アプリを使うしかないのだがマイクの調整のようなことは全くできない。そもそもISW13HTの内蔵マイクがいまいちだというから、そのせいかもしれない。Bluetoothヘッドセットで使えばその問題を回避できるかも、と思ったが、残念ながらそうするとアプリが落ちる。

Scydo.comのアカウント設定画面には”SIP settings”の文字が

その他自分が使える端末で試してみると、通話品質は Xperia Acro IS11S > Samsung Galaxy Note 3 > Xperia X10 Mini の順になるようだ。ただ、最下位のXperia X10 Miniでも、なんとか使えるレベルだというのは嬉しい。このXperia 2モデルには現在SIMカードは挿しておらずwifi運用している。特にAcroに至っては、元々Au用端末だったものにUMTS (WCDMA)用カスタムROMを焼いているので、SIMカードを挿して携帯電話として使うことはもうできない。それでも（仮に詐欺紛いであっても）自分の携帯電話番号を通知して電話をかけることができる。これが役に立つこともあるだろう。

さて、先に述べたように、ScydoはいわゆるBetamaxクローンと呼ばれているものの1つなのであるから内部的にSIPが使われているのは間違いあるまい。ウェブサイトでもちらっと”SIP Settings”と書かれたリンクもある。リンク先にはSIP関係の情報は記載されてないが、なおのことそうではないかと思ってしまう。もしSIPで扱えるのなら自由度がぐっと高くなる。なんとかその情報を抽出できないか。

…というわけで、パケットキャプチャしてみることに。

まずは、Lubuntuをインストールしてあるネットブックで、”Make Your Linux Machine a Virtual Router“で仮想wifiホットスポットを作成し、そこにAndroid端末を接続させる。

コマンドラインで操作するのだが、既に設定が済んでいれば、

• ホットスポット開始はsudo ap-hotspot start
• 停止はsudo ap-hotspot stop
• 起動はsudo ap-hotspot restart

仮想ホットスポットを動かしているネットブックにAndroid端末から2.4GHz帯11nでwifi接続したときの通信速度

ついでにこの状態で端末でスピードテストもしてみた。本編とほとんど関係ない画面キャプチャその2である。

その上でネットブック上でWiresharkを使ってパケットキャプチャしてみた。結果としては、明らかな形ではSIPプロトコルは使われてなかった。まずサイトAとの間で通信があり、次に別のサイトBとの間で通信が行われている。後者はメディア・データの交信であろうから、前者ではセッション管理が行われているのだろうと想像されるが、自分の力では中身は理解できなかった。これは暗号化されているから？

残念！

追記：

ここまでやらなくてはプロトコル解析なんかできないってことですね。ちょっとパケットキャプチャしただでできると思った自分が甘かったです。

バッファローの無線LANルータWHR-HP-G300NのOpenWrt化

また古い未完成記事。いつか役に立つこともあるか、と。

---

バッファローの無線LANルータWHR-HP-G300NのDD-WRT化

Open WRT Wiki: Buffalo WZR-HP-AG300H

WZR-HP-G300NHへの簡単OpenWRTインストール法

WZR-HP-AG300H/VにOpenWRTをインストールする手順とまとめ

OpenWrt and DD-WRT on the Buffalo WZR-HP-AG300H
Open WRT Wiki: WHR-HP-G300N

Buffalo WHR-HP-G300N

 

These units not only support DD-WRT, but they ship with it from the factory. You can revert them to Buffalo’s proprietary firmware if desired, though that firmware has reduced functionality. Both Buffalo’s branded DD-WRT version and the standard DD-WRT distribution version have bugs that lead to crashing under high load, high connection count situations. BitTorrent is particularly problematic. I am not aware of a way to fix this through configuration options and there has been no patch by Buffalo or DD-WRT.

OpenWRT “Attitude Adjustment” V 12.09 works very well on these units and can be flashed from the DD-WRT upgrade page of the web based admin interface using the file openwrt-ar71xx-generic-whr-hp-g300n-squashfs-factory.bin. OpenWRT works very well and even under abusive loads remains stable. I consider this the preferred firmware for the device.

These routers also have removable antennas and work quite well with enhanced antennas like D-Link’s ANT24-0700

Note that all the above information is based on the hardware revision A1 version of the Buffalo WHR-HP-G300N

実際http://downloads.openwrt.org/attitude_adjustment/12.09/ar71xx/generic/に該当ファイルがあることを確認した。

手持ちの機器はA0 A0

PPPoEが使えるためにはオプションのパッケージをインストールする必要がある

Transmit Power

13 dBm (19mW) -> Tx-Power 13 dBm,

27 dBm (501mW) -> Tx-Power 18 dBm

Country CodeをUSではなくJPにすると後者は選択できなかった。

既にバッファロー版DD-WRTが走っているので、Webインターフェースから …factory.binをフラッシュ。

DD-WRTに戻る方法

Configuring OpenWRT Settings on Buffalo Routers

UCIによる設定はWireless configuration

OpenWrtをインストールした後早速実験だが、Tp-Linkのときとは実験状況が異なる。つまり、そのときの結果と、これからの結果は比較できない。今回は、2階西部屋のテーブルの上にルータ。アンテナはどちらも直立。 1階玄関のwifiカメラの所で測定

まず最初に、比較のためにDD-WRTベースの米バッファロー公式”Pro”版でTx Powerを200dBmに設定した場合

次にOpenWrtで

Transmit Power
13 dBm (19mW) -> Tx-Power 13 dBm,

27 dBm (501mW) -> Tx-Power 17 dBm

これだけ見ると顕著な改善があったようにみえるだろうが、それは実は怪しい。まず今回の測定地点では数値はかなり大きく変動する。10dBmくらいの幅で平気で振れる。極力平均的状態でスクリーンキャプチャしたつもりだが、それはあくまで私の主観（だったら、スクリーンキャプチャに何の意味があるんだよ、と言われると反論できない）。上の実験ときはここまで大きくは振れなかったように思う。

それでもひょっとすると平均すると数dBm程度改善したのかもしれない。仮にそうだとしても、たま?に -90dBmを下回っていた。これでは困る。

自分なりの結論は以下の通り：

実験機のWHR-HP-G300Nに関しては、玄関に設置したwifiカメラへの電波を強くする、という目的だけに関して言えば、DD-WRTだろうがOpenWrtだろうが、顕著な効果があったとは思えない。ルータ側の電波強度以外の要因があると思われる。なので、直視できる近い位置にAPを設置することで解消する。

本来のターゲットのWZR-HP-AG300Hについては、上を踏まえて、日本の公式版ファームウェアを引き続き使用するか、なにかするにしても米バッファローの公式”Pro”版をインストールするだけにとどめる。

実験機のWHR-HP-G300Nは、借り物であるが、米バッファローの公式”Pro”版に戻して返却する。深くは追求しなかったもの、OpenWrtでは倍速を実現できなかった上に、自分の知識・技量ではOpenWrtできちんと設定できる自信がないため。

ところで、アンテナ出力を大きくすることには意味があると主張する”Increasing a Router’s Transmit Power“でも、一般的使用方法では下流方向の通信速度が重要で、上流方向の通信速度はそうではない、という前提で議論を進めている。それはそうだと思うが、wifiカメラを使うという点においては、重要度が逆転し、上流方向の通信の安定性・速度がより重要になる。なのでそれを根本的に解決するには、無線を止めて有線にするのでなければ、カメラ側の出力を何らかの方法で改善しないといけない。