長らくLatitude Syncや Backitude というアプリを使ってGoogleロケーション履歴をライフログして使っていたのですが、
Google Latitude API が8月にリタイアしてしまい、私も代わりの方法を探していたのですが、なかなかこれというものが
ありませんでした。

そこで、[Google+ GPS Locator]というアプリを作成してみました。

仕組みとしては Google+ の現在地送信機能にGPSによる現在地を「盗み見」してもらって、出来るだけ従来並の精度で
ロケーション履歴を利用しようというものです。

また、もし自分で作るなら実現したいと思っていた移動を検出したら測位頻度を上げ、しばらく動かなかったり、
連続して測位に失敗したら測位頻度をもとに戻す機能を実装してみました。

これによりバッテリーの消費を抑えつつ、移動経路をほぼ特定できる形でログを残すことができています。

Latitude API を使用したものに比べて
・送信頻度が1時間に一度程度 (Google+の動作)
・基地局の位置情報を排除するために[Googleの位置情報サービス]のチェックを外す必要がある
・たまに100~200メートル程度の大きなズレが記録される

というような差がありますが、送信頻度落ちたこともあり、従来よりバッテリーの持ちはよい気がしますし、
移動時の頻度が高いこともあり、総合的にはLatitude APIリタイア前より快適に感じています。

自分の希望に合わせて作ったものなので、必ずしもフィットするとは限りませんが、ロケーション履歴を
使っていたり、興味が有る方は是非試してみてください。


こちら

p119.net182021183.tokai.or.jp

ご紹介ありがとうございます。
早速ダウンロードしてみました。

これはGoogle設定→現在値送信機能はOFFで使うのでしょうか。

現在色々実験中、後日Blogの方でレポートさせて頂きたいと思っています。

> これはGoogle設定→現在値送信機能はOFFで使うのでしょうか。

自分はONにして使っています。

遺憾ながらGoogleのロケーション関連の個々の設定と動作の関係はまだ掴みきれていない事があり
調べなければならないと思っています。

お気づきの点、アイデア、不具合などありましたら色々と教えて下さい。

p119.net182021183.tokai.or.jp

現在位置送信機能をOFFにすると位置送出自体が行われなくなるようでした。
現在位置送信機能をON、GPS以外での測位をONにするとGoogle+本来の(に、近い？)動作になるようで、通知インターバルも不定になりました。
従ってこのアプリの機能を発揮させる場合には、必ず「設定→位置情報サービス→Google位置情報サービス」のチェックを外す必要がありますね。

こうした設定によってアプリの通知インターバルによるGPS測位データが送出されます。
なかなか良く出来ています。

GPS測位精度の問題ですが、アルゴリズムの工夫か何かで改善出来ればベストですね。
設定によってある程度カバー出来ているのですが、他のGPSアプリに比較すると位置のばらつきが多いように思えます。

その設定に関しては、かなり自由度があって良いと思います。
GPSタイムアウト時間が秒単位(一般的には1分単位が多いようです)で設定出来るので、測位不能の時にさっさと諦めさせる事が出来、バッテリ消費量をコントロール出来ます。

WiFiや基地局による測位は個人的には不要(WiFiはともかくGoogleデータベースによる基地局測位は測位精度が良くない)だと思っています。
屋内に居る時などはWiFi測位は有効ですが、WiFiが入っていないと意味ないですしね。

基地局測位はドコモに限ってですが、移動機が基地局測位を行うのではなく基地局側が移動機の通信状態から位置を提供してくれます。
spモード契約必須ですが、アプリからの問い合わせに位置を答えてくれるオプション？があります。
Googleデータベースによる基地局測位だとkm単位で位置がずれる事がありますが、ドコモ側の測位だと200m〜300m程度の範囲には入るようです。
"いまどこ？"はこのオプションを使う設定があります。

GPS測位精度のみ改善の余地ありとは思うのですが、ここもバッテリ消費量とトレードオフですかね。
消費電力優先と測位精度優先の切り替えを持ったアプリもありますが、切り替えが必要なのかも知れません。

仰るとおりこのアプリにとって現在位置送信機能ONとGoogle位置情報サービスOFFはマストですね。
このへんの調査が後手に回っていました。


GPSの精度に関しては思い当たるところがありまして、
Android 2.2の頃の機種のバグ対策とされる設定をとりいていたのですが、
それが悪影響を及ぼしていたようで、それをやめれば測位時間と精度が
改善されている印象です。現行機種では問題ないと思うので外してみようと思います。


> 測位不能の時にさっさと諦めさせる事が出来、バッテリ消費量をコントロール出来ます。

測位不能時の動作に関してはまだ改善の余地がないか調査中です。
常用するツールとしては測位の見込みのないビルの中でタイムアウトするまで電池を
消費するのは痛い、しかしタイムアウトを短くするとビルから出た後の測位ができない。

そこでNMEA値を直読みすることで、測位の見込みがない場合10秒程度で諦められないか調査中です。
(その辺りに明るい方、教えて下さい)


Android標準の基地局測位に関しては、LTEになってからは絶望的ですね。何とかならないものなのか。
当初のプランでは基地局変化をキッカケによる測位を併用するつもりだったので、ある程度調べたのですが
Android APIはGSMとCDMAにしか対応していないようでその辺りも関係有るのかもしれません。


しかしAndroidのサービスを初めて使ってみたのですが、システムの都合で突然終了させられることもあり、
(一定時間動作していると、取りあえず終了させられる)アプリと矛盾なくやりとりしながら信頼性を
確保するのはかなり大変です。殆どその辺りに時間を費やしました。
また、この種のアプリの動作周期が時々不正確になることが不満というか、デバッグが足りないのではなかいと
訝しがっていたのですが、自分がやってみると少なくともバッテリライフを重視する限り仕方がない事を
知りました。

やはり、やってみないと分からないことは多いな、と。

p119.net182021183.tokai.or.jp

基地局測位は、CDMA方式の場合は確度を得やすいのですがLTEは難しいと思います。
TD-LTEで低位層からタイムアライメント値などを読み取れれば多少の精度アップは期待出来るかも知れないのですが、それ以外でマクロセルエリアとなると絶望的です。

通知インターバル(Google+ GPS Locatorの測位インターバルではなくGooglemapへの位置通知)に関しては調査というか検証中です。
Google+のAPIが公開されていない以上、Google+ GPS Locatorから位置情報送信を行わせる事は不可能に近いでしょうね。

Google+アプリを起動して自位置を更新すれば即座に通知出来るんですけどね。
静止時と移動時その他の場合、移動後静止していたエリアに戻った場合なども含めて検証しています。
結果は今週中にはBlogに書こうと思っています。

測位精度が上がりましたね。
移動中の測位ポイントが道路から外れる事が少なくなりました。

要望というか希望なのですが、アプリ立ち上げと同時に現在地を送信するオプションが設定出来たらいいなと思いました。
設定された位置送出時間を待つことなく、ビルに入る前で一度アプリを立ち上げればその時点の位置が送信されるというような使い方です。

アプリ立ち上げと同時に現在地を送信するオプションを追加したアプリをリリースしました。
数時間以内に公開されると思います。

今できることはあらかた実装した感じです。

自分は通知タイミングは1時間毎でも構わないこともあって機能面では概ね満足なのですが、思ったほどダウンロード数が伸びない。
ライフログ的な需要自体が少ないのか？ 単に知られていないだけなのか？

p003.net220148047.tokai.or.jp

バージョンアップしました。
ありがとうございます。

GoogleLatitudeに関して書かれているページもあるので、それの廃止で代替策を探している人も少なからず居ると思います。
アプリ紹介サイトなどに積極的に働きかけている作者さんも居るように、いかに世間に知らせるかが大切なのかも知れません。

blogの方でも使用感レポートを連載しますが、世間の人は一体どんなワードで検索してくるんでしょうね。
Google+は範囲が広くて引っかからないだろうし、LatitudeやLatitudesyncで検索してくれればGoogle+ GPS Locatorは知られる事になると思います。
PLAYへのリンク付けておこうかな。

> PLAYへのリンク付けておこうかな。

ありがとうございます。
ここで取り上げていただくだけで嬉しいですし、参考になります。


> そこで次にLocation Spooferアプリを使用して無線ネットワークの位置情報を誤魔化してみた。
> すると10分ごとに位置通知が行われるようになった。
> この事からGoogle+は基地局による位置情報を元に静止と移動を判断しているのではないかと推測出来る。

上記実験は[Google+ GPS Locator]が意図通り動作する [Googleの位置情報サービス] が OFF の状態ですか？

実は応用の可能性を探るため、早速test codeを作り実験してみたのですが、擬似位置を設定するAPIに対して基地局やWiFiを対象とする[NETWORK PROVIDER]の
位置を、本来の位置から移動させるようにしてもGoogle+の送信周期に変化は見られませんでした。

[Location Spoofer]も[GPS_PROVIDER]を偽装することは間違いないと思うのですが、NETWORKの方を操作しているのかは分かりません。
GPSを偽装すると意味がなくなってしまうし。

p003.net220148047.tokai.or.jp

> 上記実験は[Google+ GPS Locator]が意図通り動作する [Googleの位置情報サービス] が OFF の状態ですか？

その通りです。
ですので、基地局測位による位置情報を使うのみではなく位置情報の送信インターバルを決めるのにも使っているのではないかと思ったわけです。

ただ、

> 位置を、本来の位置から移動させるようにしてもGoogle+の送信周期に変化は見られませんでした。

と言う事ですので、また追試してみたいと思います。
私の実験方法は、特定の場所にスマートフォンを置いてGoogle+が静止と判断して位置通知インターバルが毎時1回になった事を2度確認(つまり、3時間放置)、その後Location Spooferでとんでもない場所まで移動した事にして位置通知が起きるかどうかを見ました。

通知された位置は、その"とんでもない場所"になりました。

すみません、誤りがありました。

> 上記実験は[Google+ GPS Locator]が意図通り動作する [Googleの位置情報サービス] が OFF の状態ですか？

これはONの状態でした。
ONにしないとアプリが起動しないようで、ONにしたのでした。

現在静止中の測位インターバルを300秒にして様子を見ているのですが、ログを見ると測位間隔が5分から9分くらいまでばらついています。
10分間隔でテストしたときは10〜11分ごとに測位が起きていたのですが、何か変わったのでしょうか。
それとも10分以下だとGoogle+が嫌がるとか？？

今から10分間隔に戻してチェックします。

測位周期のばらつきに関してですが、現在公開中のものはスリープ中に「自らはCPUを起こさない」タイプのタイマー(?)を使っています。
これすなわち、他の何かがCPUを動かした時に便乗するものなので電池の消費は最小になるはずです。
ですから長時間操作をしない深夜など特に頻度が下がる傾向があります。

そのため原理上数十秒から数分のばらつきがでるのは元々のつくりです。
ただ、これは説明がなければわからないですね。

これでは(自分はいいのですが)やはり不便なことも多いだろうと思いまして、「自らCPUを起こす」タイプのタイマー(?)を選べるようにしまして、動作確認中です。

ちなみにこのAPIは周期動作するアプリではほぼ必ず必要になるもので、AlarmManagerというのですが、面白いのはNTT DoCoMoがAlarmManagerに関してかなり詳細な解説をしたPDFを公開しています。この件に関しての説明では群を抜いており、とても親切で私もこれで詳細を理解しました。
こちら

少し見ていただくとわかるのですが、通信が集中することを防ぐためとはいえ、こんなに親切な解説資料を公開していたのは以外でした。

p003.net220148047.tokai.or.jp

なるほど、そう言う事だったんですね。
今日何度か試していたのですが、決まって毎時15分頃に5分間隔にしているにもかかわらずインターバルが10分前後になっていました。
たまたまこの時に起き上がるプロセスがなかったんですね。

バッテリ消費量は後日まとめますが、3%/h程度(3分間隔測位)なので少ないです。

需要がないというか、Google+ということで二の足を踏むというか・・・

というわけで放置中のアカウントに久しぶりにログインして
使ってみようかな・・というところです。

決して興味が無いわけでは無いんですけど。
「いまどこ？」はずっと使ってましたし、F&Fで紹介されたので
山旅ロガーを今はそれなりに便利に使ってます。

Google+を便利に使っている人もいるとは思いますが、私はどうも好きではないなぁ。
何でもかんでも共有させようとする、公開させようとする、通知して来るなど面倒だと思ってしまいます。

あまり詳細な記録を求めなければロケーション履歴はちょうどいいサービスなんですが、
やっぱりGoogleに詳細な位置情報が渡ることに抵抗があるのは当然ですよね。
自分もメリットが勝っているだけで、抵抗が無いわけではないです。


スリープ中のバッテリー消費に関しては、1回あたりのCPUの動作時間が

> 測位開始30ms + 測位後1秒につき30ms ( + タイムアウト時 30ms )

となっており、GPS測位精度を100m程度にしておけば60ms程度起きるだけで
済んでいることが比較的良い結果につながっているようです。

当初はGPSの受信状態から室内のように測位の可能性がない場合は早めに切り上げる
仕組みを実装しようとしていたのですが、そんなことよりCPUを寝かせていることが
省エネになると判断しました。


今、ビルから出た時の測位時間短縮のためにA-GPSデータを利用するバージョンを
リリースしました。
最後の測位から指定時間経過するとA-GPSデータをダウンロードします。

自分で試した範囲ではハッキリした差がなかったのですが、宜しければ試してみてください。

p003.net220148047.tokai.or.jp

NTTドコモがアップルのiPhoneを販売するという非公式情報が流れている。
これに関してどこかのアナリストが、グローバルで通用する端末を開発できない国内の端末メーカは生き残れない、という内容をコメントしていた。
私はこれは正しくないと思う。iPhoneは初心者向けなのである。スマートフォンの黎明期ならば初心者も多いだろうが、もはや初心者のほうが少ない。
ドコモから発売されるiPhoneの仕様がわからない現在では確実なことは言いづらいが、おサイフ、NOTTV、dショッピングくらいは対応していないと売れない。なぜなら、スタイルモデル止まりでプライムモデルやプロモデルにならないから。
カタログの一覧表に全部丸が付くのがハイエンドということだ。

顧客が何を求めているのか、経営とは何なのか。一度、孫さんに頼んで教えてもらった方が良い。

proxycg003.docomo.ne.jp

リテラシーの高いユーザはAndroidに流れたと思われ、現在従来型ケータイを使っている人たちの半分くらいはAndroidは難しい、スマートフォンは難しいと思っているのではないでしょうか。
iPhoneならば、確かに機能は少ないですが何となく使えそう。
そう思う人たちがSBMやauに出ていく。

なのでiPhoneを扱えば、そのようなユーザを取り込める可能性があると思います。
個人的にはFelicaは欲しいのですが、その他のドコモアプリやサービスは要らないなぁ。
NOTTVのプロセスもdマーケットも無効化出来ずに動き続けますから、邪魔です。
勿論NOTTVを観たい人も居るとは思いますが、それはAndroidスマートフォンを買えば良いわけです。

都心に住んでいる実家から相談を受けました。
現在　ウイルコムの基地局３Gの設置をビルの屋上で運用しています。契約　平成11年
設置場所使用料6万電気使用料10,800円です。今回A-XGPの基地局の増設を行いたいとの
申し入れを受けました。3Gと込みで設置料72,000円電気使用量45,000円となります。
3Gの時間当たりの電力使用量は、電源ケーブルにワットメーターを付けた実測値ですと
30〜50W/hくらいですので損はしていないと思います。しかし今回設置するA-XGPの基地局の場合8本アンテナ・GPS付、制御装置最大消費電力200W、無線装置最大消費電力271Wとなり最大消費電力で471Wと約10倍以上の電力消費量になります。常時最大出力ではないと思いますがこの契約条件は不利なので、止める方向で話を進めるように助言しました。
しかし実家は、契約解除できないとの説明を受け（実家では契約書を紛失しているようです）困っています。実家としては設置しても良いが不利になる条件（電気使用量の持ち出し）は受けたくないことなので電気使用量としてはどのくらいが妥当な線なのでしょうかお教え頂きたくお願いいたします。私としては、14年間も設置場所使用料の値上げもなく
突然の申し入れに対して基地局の撤去を申し出したい（相手方の不誠実）と考えております。電気使用量に関しては電事連の過去のデータから算出しても、3Gの場合　妥当な金額であると思えるので値上げに対してのの損得勘定はありません。ちなみに今回の基地局増設時の電力量単価は23円/Kwhで算出しているそうです。

詳しくは言えませんが同じように旧ウィルコム→SBM変更で電気代が大幅に上がったことによりSBMと揉めたことがあります。
相手を不誠実だとお考えなら契約解除が一番いいと思います。（もし相手の会社がつぶれたら負債のみのこってしまいますよ）

どうしても契約を更新するのであれば
１）東京電力と直接契約してもらい、設置場所使用料のみを受け取る
２）新たに専用電力メータを設置させて完全従量制として電気代は実費を受け取る
いずれかの条件にすることをお勧めします
電力単価も今後値上がりすることはほぼ間違いないでしょうから固定金額での
契約は不利でしょう

ところで
>制御装置最大消費電力200W、無線装置最大消費電力271Wとなり最大消費電力で471W
この情報は相手から開示された情報ですか？
私の経験ではもっと大きな電力になるように思います。

あと、契約ブレーカーに消費電力が増える分をまかなう余裕がありますか？

ntaich306196.aich.nt.ftth4.ppp.infoweb.ne.jp

仕様書の最大消費電力は、決してこの値を超える事がないという電力値です。
3G設備の実測が50W程度は、たぶん接続してくる人がいないか少なかったのでしょう。
総合電力利用効率は10%以下になるのが普通なので、出力20WのBTSの場合だと消費電力は200Wとか300W位になります。
マイクロ局であれば当然消費電力は下がりますし、マルチバンドの高出力局だとkW級の電力を消費しますし冷却設備が必要になる場合もあります。

基地局の設置場所は取り合い状態です。
設置場所を変更するとエリア設計をやり直す必要があり、周辺局にも影響するので大変な事です。
このため契約条件として、場所提供者側からの契約解除に多額の解約料が設定されるなどするわけです。
3Gの契約書がないのは困りましたね。
いったんAXGPの契約を短期で受け入れて新たな契約書を作成して貰うのも一つの方法だとは思います。
電力料金のこの先が不透明だとして2年ごとの条件見直しとしても良いかもしれません。

いずれにしても場所提供者の方が強い(特に都市部では)ので、相手の言いなりになる事はありません。

契約上で大切なのは、設備の撤去に関する事です。
支払いが滞った場合は設備の所有権に関わらず強制撤去出来る事を明確にして、その場合の費用が払えない場合は基地局設備を(所有権に関わらず)売却する(担保に取る)権利を確保する事が必要です。

電柱や駅のホームに電線の切られたASTELの基地局がぶら下がっていますよね。
ASTELから事業を買い取った某社(!)は、それらの撤去費用を受け取りながら他に流用してしまったので撤去が出来なくなったのです。
場所提供者側はその撤去権を持っていないために手が出せないわけです。

色々とご助言ありがとうございます。
契約書が見つかりました。契約先はDDI東京ポケット電話�鰍ﾅした。
これが、変更になりWireless City Pianning�鰍ﾆなります。
内容的には、非常に緩い契約条項でした。（解約料の発生も書いてありません）
解約条項は、３ヵ月前までに書面をもって通知し、甲乙協議の上云々
明け渡しは、乙は設置した施設を遅滞なく撤去し、設置場所を現状に回復し云々
とありますので内容証明付きの解約書を相手方に送ってみます。

>制御装置最大消費電力200W、無線装置最大消費電力271Wとなり最大消費電力で471W
この数字は、相手から設置する機器についての概要書で書かれていた数字です。
光回線を新設し、どうやら無線制御装置（BBU）を設置するようです。
電源は、ビルの共用ラインから引きますので緑のブレーカー30Aが付いてます。

消費電力監視用に、積算子メーター設置してはどうですか？
材料・工賃込みで３万円程度かな？

もっとお手軽には、→ こちら
なんてのも１万円少々であります。

jerrybirdさま　ご助言ありがとうございます。実家は老夫婦が住んでおります。
電気には詳しくなく、長男の私に相談されました。私自身実家の屋上にPHSのアンテナ
が設置されていることも知らず、相談されて気が付いた次第です。
なるべく手間をかけず、PHS基地局にお引き取り願えればと考えております。
相手もWireless City Pianning�鰍ｩら委託を受けている業者なので、話がなかなか
進まず気長にやります。ご紹介のワットメータの取り付けも考えましたが
そこまでお金をかける気にはなりません。

ゴールドレーンを使う人＝ゴールドカードを持てるハイクラスの人ですよね。とても憧れます。
料金プランは真似できても、このようなサービスやステータスは無理だろうな〜
近々タイゼン端末もドコモから出るはずですし、他社がどう真似をしようとも、時代の先端を行くのはドコモ以外ないですね。

自動車も同じです。メルセデス並の性能は作れてもホテルに行ってもサマになるのはメルセデスだけなのです。

proxycg067.docomo.ne.jp

ゴールドカードくらいでひがみなさんな。
この板を見てるくらいの人なら何とでもなるでしょうに。

メルセデスでは安っぽくて？ダメという世界もありますよ。

この板の過去ログをよく読んで少し行動すれば
メルセデス１台くらい買えるネタはいくらもあると思います。

こちら
だそうです。


ところで、去年はこんなバカな事をやっていたんですね…
こちら
TVの下らないバラエティー番組調なのが何とも。

20年前に上ったきり富士山にはいってないけど、TV等で見る限り、山としての魅力はどうなんだろう、と思います。人が多すぎるって田舎者にはちょっとつらいんですけど。
あのご来光渋滞はTV的な誇張なのでしょうか？それとも本当にヘッドライト行列がとぎれることなく山頂までつづいているのでしょうか？

でもLTEはありがたいです。富士山では下山時にブルドーザー道に迷い込み危うく遭難しかけたので。携帯エリアも山頂や過疎地域で乗合はできないのかなぁ、できないんでしょうねぇ。

3514.c.hiroshima-u.ac.jp

ヘッドライト行列は登山ブームとか言われだしてからは毎年恒例で、山中湖畔から夏場は毎日の様に見えたような…。


個人的には、無理してLTE化しなくても3Gで良い気がします。通信速度が遅くても、バッテリ余力に主眼を置くべきじゃないんでしょうかねぇ？？　登山中に3GとLTEが頻繁に切り替わったりしたら洒落にならないんだけれど…。

ヘッドライト行列、太平洋側からも(たとえば三島や沼津から)夏の風物詩でした。登山道が光で浮かび上がって見えます。

以前うちで飼っていた猫の時は毎日栄養剤の注射をしてもらっていました。
毎日ぐったりとして苦しそうにヒューヒュー息をしていたのを覚えています。
もしかしたら治るかも？と思って毎日病院に連れて行っていましたが結果良かったのか
どうかわかりません。

”今日わ”の　”わ”は終助詞で間違いとは一概に言えません。
”今日は”の”は”は、”は”と『現代仮名遣い』がそのように決めたからでしょう。

当然、それ以前も以降も例外はあるようです。

終助詞としての”わ”は”は”の転じたものですよね？
適用範囲は狭くて、基本的に女性が”〜ですわ”の様に使うものだったはずです。
元々、”今日はお日柄もよく”や”今日は御機嫌如何でしょうか？”などの省略形なので”わ”を使うのは変なんですよ．．．

em111-188-35-49.pool.e-mobile.ne.jp

内閣告示「現代仮名遣い」　こちら
> (一)　法令、公用文書、新聞、雑誌、放送など、一般の社会生活において現代の国語を書き表すための仮名遣いのよりどころを示すものであること。
>
>(二)　科学、技術、芸術その他の各種専門分野や個々人の表記にまで及ぼそうとするものではなく、また、固有名詞などでこれによりがたいものや、特殊な音、外来語の音などの書き表し方を対象とするものではないこと。

学校教育における「現代仮名遣い」の取扱いについて　こちら


学校時代に『「こんにちわ」は間違いだ』と先生から教わった人が、無条件に『「こんにちわ」は間違いだ』と思いこむのは仕方ないでしょうね。
『「現代仮名遣い」に則った表記法が正しいものだ、という前提で君たち（子供達）に教えている』という断りは、おそらくほどんどの人が聞かされなかったでしょうから。

＃「ちわーっ！」や「ちわーす！」は、さすがに「ちはーっ！」「ちはーす！」と書く人はあんまりいないかと思って検索したら、けっこう律儀な方がいらっしゃるもんですね（笑）。

kng2-p104.flets.hi-ho.ne.jp

以前に「わかる」に関して書いた事があります。
判る、解る、は標準表記に沿っていないので分かると書くべきだとご指摘を受けました。
小説ではない一般記事に於いてはそれに従うべきかなと思う所もあり、可能な限り過去の記事に関しても分かるに変更しました。

そこからすれば新書に近い形のメールでの表記は自由でも良いとなりますが、どうなのでしょうね。
「わかる」とは違って「こんにちわ」は誤記的雰囲気を感じるという点で私は違和感を憶えますが。

「十回」は「じゅっかい」ではなく「じっかい」なんですね。

　教育の影響の大きさには、驚かされます。
これも情報の非対称性でしょうか？

少々ながいのでこちらに書きます。


NFCっていまカオスですよね・・・
狭義のNFC、本来の意味のNFCはISOが定める非接触IC技術の単なる無線通信規格です。
でも今世の中でNFCといえば上層のOSやらファイルシステムやらを含めてます。
まあこれを広義のNFCとでも言えばしっくりしなくもないですが。
広義のNFCを広めたのはSonyとNXP（旧フィリップス）が立ち上げたNFC ForumですがNFC関連の記事を見回すと広義のNFCと狭義のNFCの使い分けが出来ておらずにひっちゃかめっちゃかな解説をするものが多くて見るに耐えません。
もっとも良く見かける誤記は「FeliCa対NFC」とか「FeliCaからNFCへ」など思わずライターの名前をチェックしてしまいます。

NFC通信規格の代表格といえばType A(≒Myfare)、Type B、FeliCaです。
FeliCaとFeliCaOSはSony Onlyなので互換性はかなり高いですがType Aはこれまたカオスです。
Type Aを主導するNXPですがNXP自身が仕様が異なるいろんな種類のMyfareチップとMyfareOSを出すものだから非接触ICもReader/Writeもどこまで対応してるか確認するのが大変です。
Type Bは斜陽ですね、主導していたMotorolaが放置気味なので。
Type AカオスぶりはOpenNFCがまとめてるこのPDFを読み解くと分かりやすいです
分かり難いですがこれが一番分かりやすいです＾＾；；；
Type AだけでType Tgaが何種類もあるってそもそも・・・・
こちら

WiiUが標準でNFC I/Fを搭載してますね。
Android国内機種、たしかdocomoのGALAXY SIIやIII機は何故かNFC非対応だとか。
アンテナ給電の非接触ICではない電源のあるNFC Chip搭載品はほぼNFC Reader/Write機能付きだと思われます。
Reader/Write同士なら低速ながら相互通信が可能です。
なのでWiiUとAndroidスマートフォンの間でNFCを介して何かやるというのは出来そうです。
電子決済も認証も携帯の向こう側の携帯回線を経由して何かするとかも技術的には出来るかもしれません。
まあ先に書いたカオスな細かい仕様を全部対応しないと繋がらないスマートフォン機種とか出てきそうですが。

スマートフォンNFCの使い道ですが、現在はIDタグリーダーライターとしての使い方がメインのような気がします。Type A/Type B/Felica とも物理フォーマットはさまざまですが、NDEFフォーマットを利用するとどの種類のカードでも非接触タグ機能を実装することができます。で、これは昔からあるFelica独自のアプリケーション機能とは相当かけ離れたものです。

日本では携帯のFelicaカードエミュレーション機能がまず普及したため、NFCでもまずこれが実現されると誤解していた人が多かったのですが、NFC規格的にはカードエミュレーションはオプションで、むしろリーダーライター機能のほうがメインです。日本の携帯/スマホのFelicaカードエミュレーション機能は世界的に見ると特殊なアプリケーション、ということになります。

とはいえ、NFCが普及するにつれて13.56MHz帯を利用するNFC用ICチップやアンテナ等はかなり安価になり、現在ではFelicaカードもカードリーダーライターもNFC用のチップを使っています。SONY製RC-S380などのPC用カードリーダーライターでは、従来からのFelicaアプリを開発するSDKも、NFC規格のアプリケーションを開発するためのSDKも両方利用可能(しかも同時に)になっており、ライトなNFCアプリもディープなFelicaアプリもともに開発の敷居は下がってきています。
(しかし、いまだにFelica SDKは有償でしか入手できないのですが...)

ところで、「SIMはピンク色」の話をはじめて聞きました。調べてみると
こちら
のTypeA/TypeBでのセキュアエレメントの実装ですね。

いわゆるガラケーのFelica実装や日本のMobile FelicaスマホではFelica暗号キーはOS内にソフト的に内蔵されていますが(iアプリではネットからもらうものも有り)、AndroidでのTypeA/TypeBのセキュアエレメント実装は、要するにAndroid OSにセキュアキーを埋め込むのは危なすぎてとても決済に利用できないから、ということですね。

で、Felicaでも同様にSIMカードを利用したセキュアエレメント実装をSONYが提案していると聞いたことがありますが、こちらの実装は進んでいるのでしょうか? SIMカード内のマイコンの処理が遅くて日本の改札のスピードには対応できないとか言っていた気がしますが。

そういえば雑記では多少あいまいな書き方がされていましたが、

店頭でスマホに情報をプッシュされるのはいわゆるURL誘導のよう仕組みで、このときスマホ側はリーダーとして動いています。このような誘導を行うカード側の書き込みは非常に簡単で、またセキュアである必要もありません。
書き換え可能なNFC規格のいずれかの白カードを買ってきてNFC対応のAndroidスマホでタグデータを書くことができます。(もちろんNFCつきPCでもできる)

以前のモバイルFelicaは基本カードエミュレーション機能ですが、トルカなどはFelica物理カードでは不可能なURL誘導が行えるように「モバイルFelica」規格策定時に機能拡張されたものです。(データ自体はHTMLテキストデータ)
つまりこのときだけリーダーとして動いていました。

いっぽう「ピンク色SIM」のアプリケーションはNFC決済サービス＝決済(IC)カードエミュレーション機能で実は微妙に異なっていたりします。

雑記より。
昔流行したミニカー。今考えると、大きさ、加速、実用性、どれをとっても中途半端でしたね。

おそらく今現在、ミニカー登録してる最も多いベース車種は、ホンダジャイロではないでしょうか？
青ナンパー付いたジャイロを、たまに見かけます。

いわゆるミニカーとは違い、原付と同じ車格ですから、渋滞を縫って走ることも可能。（道交法的にＯＫかどうか判りませんが）
後部に大きなトランクを装備できたり、キャノピーやワイパーを装備することもできますので、新規格の超小型車よりずっと実用的だと思います。
※ただしベースが原付一種なので２名以上乗せることはできませんが。

※しかし新規格の超小型車。子持ち主婦をメインターゲットに考えているようですが。
　　燃費と免税だけで３ナンバーのプリウスを乗り回すのが主婦的発想ですので、
　　購入後、自宅に巨額なインフラ整備（屋外充電設備）が必要になる時点で
　　超小型車は主婦からはソッポ向かれる気がするのですが。
　　超小型車の電気代は永久に無料、とでもすれば話は別かもしれませんが。

丸山です。

こちらには久しブリの書き込みです。

毎年恒例のエコランアタックですが、2年分をまとめて
レポート書きました。


タイヤサイズ変更で燃費はどう変わるのか実験。
215/45R17→195/55R16 です。

更にタイヤ空気圧変更で燃費がどう変わるのかも実験。
210KPa→260Kpa です。


怪しげな燃費詐欺商品をさんざん実験してきましたが、
今回はマトモなネタです(笑)


こちら

恐ろしく良い燃費ですね。
そういえばスバルもちょっと昔stiバージョン以外のインプレッサやフォレスターの
ターボエンジンの圧縮比を上げて加給圧を下げた事があったような・・・
モデルチェンジ時に旧モデルより最高出力を下げた時ですね。

試乗したら結構乗りやすかった（街中ではstiより速い位）のですがあまり売れなか
った様で結局無くなってしまったんだったかな？
あれも燃費は良かったんだろうなあ。

タイヤの空気圧・・・スローパンクに気がつかなかった事が一度ありました。
休憩時にタイヤの温度が高い事に気がついて慌てて近くのガソリンスタンドで修理。

他には2輪でL型アダプタを付けっ放しで走っててブレーキキャリパに接触→バルブ
吹っ飛び→JAFのお世話になる。と言うのを前輪後輪一度ずつやってます＾＾
バルブ修理代14000円は痛いのでアダプタは毎回外しています。