エレクトロニクス

 2015年9月に購入したAQUOS K SHF32クリアホワイト(https://kadono.xsrv.jp/2015/09/19/3085)の電池の持ちがかなり怪しくなってきたのと、筐体自体がボロボロになってきたため最新のKYF39を購入して入れ替えました。料金プランの変更はありません。
SHF32の外装に傷が目立ちます。
開いた感じはほぼ同じですけど、KYF39の方がボタンが少ないです。

 KYF39の特徴としてUSB TypeC端子になることでZE520KLなどと充電ケーブルが共用にできます。また、通話用の端末なのであとから録音という機能が使えそうでICレコーダでいちいち録音する手間が省けます。

 少しだけ使用しているキャリアメール機能についてはSHF32で行っていたBluetoothテザリングは運用を止めてWiFiのみに統一します。これは車に乗るときに車載機器がWiFiのみ対応のため乗り降りのたびにMR05LNやZE520KLを切り替える手間がバカバカしいためです。どのみち運転中はメールの内容を見る暇など無いのでWiFiで間欠接続した方が切り替えの手間だけなくバッテリの持ちも良くなるのではないか?と思います。MR05LNとBluetoothテザリング接続できるか?も試しましたけどダメなようです。特別な設定方法があるのかもしれませんけど、先述の通りWiFiへ統一するという目的もあるため詳しくは調べていません。

 また、auのパケット通信を使わせたいのかはたまたEZWebメールを使ってほしくないのか、SHF32とは異なりWiFiで接続していると自動的には@ezweb.ne.jp宛のキャリアメールを受け取らず通知のみとなります。ここからが面倒で端末を開く→[サーバにメールあり]→通知[サーバにメールがあります。]→新着確認でようやく何のメールが来たかが確認できます。即時に着信したメールの概要は分かりません。私は通話用として購入しているし半日遅れの返信など日常茶飯事なので気にしませんけど操作の手間が増えるのは少し面倒に感じます。

機種名:au AQUOS K SHF32 → au GRATINA KYF39
メーカー:シャープ株式会社→京セラ株式会社
対応通信規格:4G LTE VoLTE対応(3G非対応)
SIMカード:au Nano IC Card 04 → au Nano IC Card 04 LE
サイズ(高さ×幅×厚さ):約51x113x16.9mm(17.4mm)→約51×112×17.4mm
重量:128g→125g
連続待ち受け時間:430h(4G LTE) → 530h(4G LTE)
連続通話時間:660min(VoLTE) → 610min(VoLTE)
バッテリ容量:1410mAh → 1500mAh
充電時間:約110分→約120分
充電器:キャップレス防水microUSB端子 → TypeC (明記はされていませんけどキャップレス防水のはず)
ディスプレイ:約3.4インチ540x960(QHD TFT) → 約3.4インチ854×480(FWVGA TFT)
カメラ:13.10Mpixel → 8Mpixel

 京セラ製の端末を購入するのは初です。シャープ製の継続も検討はしましたけどSHF34もmicroUSBなのと通話用端末としてKYF39の方が良さそうだったため移行となりました。

 メーカーサイトの快適な通話機能にこだわった「GRATINA(グラティーナ)」(KYF39)多彩なカラーバリエーションで登場(https://www.kyocera.co.jp/news/2019/0502_ggur.html)より、

バッテリーケアモードでは、最大容量の85%までにおさえる充電設定で電池を保護し、電池の負担を軽減します。
なお、本製品はauのケータイで初となるUSB Type-C™対応です。

この2点を評価しています。目標としては追加バッテリ購入無しで3年以上稼働です。

 カタログスペックで落ちるのがLCDの表示画素数518.4k対409.92kとカメラの13.1M対8Mですがデータ通信をほとんどせずメールも文字だけならば、この程度の液晶やカメラの違いは気にならないと思います。スマートフォンとは異なり高解像度表示や撮影が全く期待されない音声通話用端末としては問題ないはずです。

エレクトロニクス

 本サイトで使用しているWordPress用テーマLuxeritasを3.5.11から3.5.12へアップデートしました。詳細は開発元の要望1件反映 + Pocket と LinkedIn の仕様変更対応 Luxeritas 3.5.12(https://thk.kanzae.net/dev/wp-themes/luxeritas/t10701/)を参照してください。

 新バージョンでの機能追加は使い方が分からないので運用はしないと思います。公開する必要が無いコメントを半端に残す必要も無いと思うので私はさっさと削除します(しています)。PocketやLinkedInは使用していないため影響無しと思います。

 また、冗長かもしれませんけどコメント画像認証の設定で"Google reCAPTCHA v3 による画像認証を使用する"を有効にしました。XSERVERの"国外IPアドレスからのコメント・トラックバック制限"を通過してもこの認証に対応していない環境・国・地域からのコメント記入はできませんのでご了承ください。v3はv2のようにチェックボックスが表示されたりはせず右下にロゴが表示されるだけのようです。

エレクトロニクス

 このサイトで使用しているWordPress用テーマLuxeritasを3.5.10から3.5.11へアップデートしました。高速化と不具合修正とのことで念の為。詳細はSNS カウントキャッシュのメイン処理からの分離と高速化 Luxeritas 3.5.11(https://thk.kanzae.net/dev/wp-themes/luxeritas/t10691/)を参照してください。

エレクトロニクス

 WordPress用テーマLuxeritasを3.5.9から3.5.10へアップデートしました。SNSとの連携は一切使用していないので影響は無いと思います。ちなみに、私はGoogle+は完全に無視していましたし、TwitterもFaceBookもアカウントを持っていませんので連携のしようがないともいいます。今回のアップデートでの変更点の詳細は開発元のGoogle+終了に連座してサイトが高負荷になったりFacebookのカウントが取れなくなったりする不具合の修正 Luxeritas 3.5.10(https://thk.kanzae.net/dev/wp-themes/luxeritas/t10675/)を参照してください。

エレクトロニクス

 1年以上酷使して容量も逼迫してきたNVMe SDD PX-128M8SeGNをPX-256M9PeGNへ置き換えることにしました。NVMe SSD本体はかなり値段が下がってきていますけど、実績がある放熱用のフィンAquacomputer kryoM.2は高価なままでコストダウンのため同等と思われる廉価品に置き換えました。PX-128M8SeGN+kryoM.2は分解せずそのまま実験機に移動させます。WDなど他のメジャーなメーカーではなくPLEXTORにしたのはPX-128M8SeGNが安定して使えていた実績を評価したのとPX-256M9PeGNの値段(ヒートシンクと合わせても1万円切った)からです。
 値段と性能(ヒートシンクのサイズ)を考えて新しい放熱器はAINEX AIF-08(https://www.ainex.jp/products/aif-08/)にしました。ただ、この汎用部品セットはPCI Expressカード上部がLEDで青く光ります。という余計な機能がついています。筐体内がギラギラに光って隙間から夜間に部屋に光が漏れるのが不気味で嫌なためGTX-1070と同様に実力行使でLEDを除去しました。
まずLEDを6個外します。
 接着剤は使われていないのでハンダを除去するだけでLEDを外せますが仕上がりを考えるとサンハヤトの特殊ハンダSMD-B05等を使用した方がきれいに外せます。もちろん、改造すると返品や保証は一切なくなります。が、値段や元から汎用品で動作保証などあってないようなものなので気にせず通電動作確認前に作業しました。
SSD本体を実装します。
 SSDを固定するナットをボードの裏からネジで止めなければならないのですけど組み立て説明図が付いていないため少し手間取りました。
ヒートシンクをネジで止めますが説明図が無いので少しパズルです。
裏面。
 組み立ててからPC本体に組み込みます。
PCI Expressのスロットに取り付け。
 AmazonのレビューにOption ROMがこのモデルにはないらしいのですけどPRIME Z370-Aに取り付けてWindows10をクリーンインストールして特に問題なく起動しました。Z370が十分新しいだけかもしれず古いM/Bに取り付ける場合は注意が必要かもしれません。ベンチマークを取るとPX-256M9PeGNの方が少し速いようです。といってもSeq Read 1000MB/s以上で差が分かる状況の方が稀かと。
 温度についてもベンチマーク中でも40℃未満で安定しているため大きなヒートシンクが役に立っているようです。

エレクトロニクス

 GW前半の悪天候下でプリウスに載せていたAE-GYSFDMAXBが走行中に頻繁にハングアップしました。ほぼ休憩のため停車するごとに電源を入れ直す有様で毎日コールドリセットコマンドを送ったり9600bpsに落としたり様々な対策を検討しましたけど、完全に出力停止を防ぐことができず、車載GPSロガーとして使うことは断念しました。最悪PhotoMOSで強制的に電源を再投入する対応策も考えはしたもののハングアップ判定までのログが欠損します。さらに電源ラインに余計な素子とプログラム制御を追加することによる信頼性の低下も懸念されるため他のモジュールに切り替えることにしました。据え置きのNTP Server用としてAE-GYSFDMAXBは2ヶ月以上連続稼働しているためこちらは継続使用します。

 次の候補として業務用や研究用で評価が高いスイスu-blox社製のICを組み込んだ
GPS/GLONASS受信機(Galileo/BeiDou可)u‐blox M8搭載 みちびき3機受信対応[GT-902PMGG]通販コードM-12905(http://akizukidenshi.com/catalog/g/gM-12905/)を急ぎで購入しました。取替は簡単でAE-GYSFDMAXBを取り付けていたヘッダにUARTの配線を接続するだけです。仕様上3.0V typ.となっていますけど販売店のWebにも・入出力信号レベル:3V(3.3Vデバイスで使用可)、非同期シリアル信号とありますように3.3V直結で動作に問題は無いようです。若干パワーロスはあるかも。
Raspberry Pi ZeroにGT-902PMGGを接続。試験運用なので熱収縮チューブは被せず仮止めです。
 あと、AE-GYSFDMAXBは1PPS信号の立ち下がりエッジを使用していましたがGT-902PMGGは立ち上がりエッジ(default)になるためそのまま動かすとntpdできっちり100msecのオフセットが生じるため/boot/config.txtを以下のように変更しました。

#dtoverlay=pps-gpio,gpiopin=18,assert_falling_edge=true
dtoverlay=pps-gpio,gpiopin=18

 u-blox M8の性能はさすがです。たぶん載っているCPUとソフトの性能がMediaTek MT3339/3333よりもかなり良さそう。特に山岳国道を中心に数100km走った限り一度も高度がマイナスにならずこれまでのどのGPSロガーよりも高性能で高度も記録できそうです。GT-600, AE-GYSFDMAXB, GYSFFMANCいずれも受信状況が悪化すると丹波高地の山の中なのになぜか海水面下になったり高度データが使い物にならないレベルで暴れます。

 あまりにユピテル社のレーダー探知機GWR103と補足衛星数や挙動が似ているため、検索したところユピテル社、日本の改良型レーダー探知機にu-blox QZSSテクノロジーを選択(https://www.u-blox.com/ja/yupiteru-selects-u-blox-qzss-technology-enhanced-radar-detector-japan)が見つかりました。思ったよりもずっと高性能なモジュールを積んでいたようです。

 このモジュールはかなり使い勝手が良さそうですけど完璧というわけでもなく設定がWindowsPCから専用ソフトでしかできなさそうという点が挙げられます。現状Raspberry Pi Zeroにつなげているモジュールは設定変更無しで電源を入れただけの状態で動作検証中です。また、覆道区間では追従しきれないのはMT3339と同様です。
GT-902(往復分)でも法面や川の中へ突っ込んでいます。
GT-600などではぶっ飛ぶ区間ですのでモジュールの性能というよりは受信状況(アンテナ位置で少しは?)が主要因と思います。法面補強部もそうなのですけど、強固な鉄骨鉄筋コンクリートと車体がLバンドを乱反射させるようです。

 GT-902PMGGについて触れているWebサイトは太陽誘電を含めたMediaTek系と比べて少ないのですけど分解したページがあるようです。
秋月のu-blox搭載GNSSモジュール(GT-902PMGG)を分解してみた(https://qiita.com/chromium_k/items/056f2ac72e81ca054185)

エレクトロニクス

 資金難から安物キーボードばかり使ってきました。しかし、1年半ほど使っていたTK-FCM077PBKの左側シフトキーが引っかかるようになりRaspberry Piなどのパスワードを打ち間違えることが多くなったため買い替えを検討しました。同機種は既に生産終了。何度もパスワードを打ち直すのはセキュリティ的にも問題なので高級(値段10倍)キーボードを探して”東プレ REALFORCE SA R2 テンキーレス 静音/APC機能付き 日本語 静電容量無接点方式 USB 荷重30g 昇華印刷(墨) かな表記なし ブラック R2TLSA-JP3-BK”を購入しました。そのものズバリの型番は展示されているのが見たことが無いため半分は東プレREALFORCEブランドと仕様から読み取れる情報だけで決めました。
上がTK-FCM077PBK、下がR2TLSA-JP3-BK
 まず、静電容量無接点方式はHHK以来、USBは机の上のケーブルが邪魔ですけど2.4GHz帯があまりにひどいため有線式です。静音はTK-FCM077PBKと同様でスペックダウンを防ぐためですし東プレの静音にも興味がありました。日本語配列は会社支給のキーボードとの違和感をなくすためです。学生時代はEN101で問題なかったのですけど就職してからはJP106系の配列が使えないと困る状態です。ただ、キーボード表面の印字は見ることなく打ちまくるためかな表記は無しで構いません(あっても見ない)。荷重30gはどうするか迷いましたけど経験上軽いほうが速度が上がったため軽いものにしました。APCやキースペーサは特に必要を感じないため使っていません。箱から出したままで使っても十分安物との差がわかります。
 後は耐久性で10年は無理でも5年ぐらいは保ってほしいと思います。購入履歴を見ると2000円台の安物はだいたい1~2年で壊しています。

 テンキーについては右側にあってもマウスと干渉して邪魔なため、昨年購入のエレコム有線テンキーボードTK-TCM011BK(https://kadono.xsrv.jp/2018/04/16/3630)をそのままR2TLSA-JP3-BKの左側に置いて継続使用します。

 おまけ)東プレ製品はREALFORCEは初めて購入しましたけど、購入履歴を検索したところお風呂のフタを既に使っていました。

エレクトロニクス

 標題の通り、よく分かりません。謎です。マニュアル(GYSFDMAXB_spec_ae.pdf)が秋月電子伝統(?)の不親切さで結局一つずつ挙動を確かめて経験的に設定を改善していくしか無さそうです。趣味?用に販売するための措置でしょうか。当初はRaspberry Pi Zero WHでAE-GYSFDMAXBを使用したgpsd+ntp server(https://kadono.xsrv.jp/2019/02/11/7939)の記事中にAE-GYSFDMAXBへのコマンドも含んでいたのですけどあまりに挙動がおかしいので一旦全削除しました。改めてこの記事でまとめておきます。
 私が勝手に挙動を調べただけの個人的なメモを公開しているだけですので、都合により更新・変更・削除する可能性があります。大量のWebサイトやMT3339とシリーズの資料を漁ったのですけど参考になるのはごく一部で決定版と言えるほどまとまったサイトは無さそうでした。私の目的からは外れていてもヒントにはなっていますので公開していただいているサイトには感謝しています。

 省電力設定を解除して常に測位データを出力し続けるようにする:
/bin/echo -ne '$PMTK225,0*2B\r\n’ > /dev/ttyAMA0 # Normal
Raspberry Pi Zero WHにgpsd 3.18.1をビルド・上書きインストール(https://kadono.xsrv.jp/2019/03/20/8052)で書いたとおり、gpxloggerのバグをアップデートで直してもGNSSモジュールからの信号が途絶しては意味がありません。面倒なので工場出荷時の設定がどうかまでは調べていませんけど、明示的に解除する設定をしています。PMTK262はGYSFDMAXB_spec_ae.pdfに記載されていないので外しました。

 内部測位を10Hz, 測位データ出力を1Hzにする(300→220の順番アリ):
# '$PMTK300,100,0,0,0,0*2C\r\n’ # meas 10Hz
/bin/echo -ne '$PMTK300,1000,0,0,0,0*1C\r\n’ > /dev/ttyAMA0 # meas 1Hz
一般道では10Hzで出力するほど速く走れません。GYSFDMAXB_spec_ae.pdfにはPMTK300しかなくPMTK220(PMTK_SET_POS_FIX)は載っていません。PMTK220も動くようではありますけど使用しない方が良さそうです。PMTK300(PMTK_API_SET_FIX_CTL)を設定すると出力の頻度も切り替わります。

 (車載器向け)AICを無効:
/bin/echo -ne '$PMTK286,0*22\r\n’ > /dev/ttyAMA0 # AIC disable
デフォルトで有効になっているらしいAICが原因で補足できる衛星数が減っていたようで無効にした方が測位が安定しました。アンテナの設置場所や使用環境に依って大きく異なると思います。Enableは電磁ノイズが多い都会向け設定かもしれません。MT3339の仕様書には22 tracking and 66 acquisition-channel GPS receiverとありますので最大22chまで追尾できる*はず*です。12chで頭打ちになって困っている場合は試す価値があるかもしれません。下記SBASの信号がキャンセルされる可能性も高いようです。

 SBAS, DGPS(SBAS)を有効(デフォルトと同じ):
/bin/echo -ne '$PMTK313,1*2E\r\n’ > /dev/ttyAMA0 # SBAS Enable
/bin/echo -ne '$PMTK301,2*2E\r\n’ > /dev/ttyAMA0 # DGPS SBAS
後から冗長と分かったのですがマニュアルの設定例はRTCMとなっていますがRTCMではDGPSになりませんでした。

 UARTへの出力設定(GPSロガー向け未確定):
/bin/echo -ne '$PMTK314,0,5,0,1,1,5,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n’ > /dev/ttyAMA0 # GPRMC,GPGGA,GPGSA,GPGSV
/bin/echo -ne '$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n’ > /dev/ttyAMA0 # GPRMC only (NTPサーバ向け)
NTP Serverとしては1PPS信号が支配的なためGPRMCだけで十分なのですけど、GPSロガーとしての安定動作要因を探る場合には最低でもGGA, GSVはあったほうがいいです。GSAはgpxloggerでhdop,vdop,pdopを記録するために必要なようです。なぜかAE-GYSFDMAXBのマニュアルにはGRS, GSTの記載がありません、けど実機は動くようです(GYSFFMACのマニュアルには載っています)。

 NTP Serverの記事でも書きましたけどgpsdを使用している場合は-bオプションを付けてread onlyにしてコマンド送信を禁止しておいた方が無難です。gpsmon等を実行した時に勝手に意図しない設定が変更される恐れがあります。

エレクトロニクス

 ブログを含めたWebサイトで利用できる地図について自治体のホームページで安心して使える地図の作り方(http://koutochas.seesaa.net/article/444993828.html)がよくまとまっていると思います。ただ、私の使い方ではこのページで推しているOpenStreetMapは使いにくい点があるのです。

  • 1つ目が難読地名が多い京都周辺の地名の正確さです。国土地理院が完璧とは思いませんけどかなり正確と思います。
  • 2つ目は等高線、道路位置の精度です。私は地形が複雑な山岳国道を多く走るため正確かつ読みやすい地図が必要です。GPSロガーで記録した軌跡の位置や精度を確認するにも基準が必要です。私としてはNTP Serverが情報通信研究機構の日本標準時を参照して合わせに行くようにGPSロガーは地理院地図の位置データ(緯度・経度・標高)を基準にします。
  • 3つめが地図記号です。地理院地図も慣れないと読みにくいかもしれませんけど非常に正確なので助かります。慣れてくると今度はカーナビ等の表示をノースアップ(北を上で固定)にしないと位置や経路を把握しにくくなります。

 地理院地図をスクリーンショットではなく、利用規約で指定された方法で動的に国土地理院のサイトを参照している限り特に申請は必要無いため私としては地理院地図を標準で使おうと考えています。
 4/11現在、以下のページで地理院地図を使用しています。様子を見ながらぼちぼち追加します。
地理院地図に描画したGT-600とRaspberry Pi Zero+AE-GYSFDMAXB(gpxlogger)比較(https://kadono.xsrv.jp/2019/03/21/8071)
霧の高野龍神スカイライン・高野山バイパス(R371新道2015.3〜)、鍋谷峠道路・父鬼バイパス(R480新道2017.4〜)走行(https://kadono.xsrv.jp/2017/11/18/3587)
一般国道169号奥瀞道路(II期)新道へ(https://kadono.xsrv.jp/2015/11/22/3106)
葉桜が来た夏 全五巻(https://kadono.xsrv.jp/2014/12/30/2820)
道の駅柿の郷くどやまへ(https://kadono.xsrv.jp/2014/10/12/2788)
玉置山へ2014(https://kadono.xsrv.jp/2014/03/23/2732)
道の駅奥飛騨温泉郷上宝へ(https://kadono.xsrv.jp/2013/11/03/2107)
R425(R169~R168間)へ(https://kadono.xsrv.jp/2013/08/16/2074)
R309行者還トンネルへ(https://kadono.xsrv.jp/2013/08/10/2072)
玉置神社へ(https://kadono.xsrv.jp/2013/05/18/2036)
新東名神で道の駅川根温泉へ(https://kadono.xsrv.jp/2012/10/21/1937)
龍神へ(https://kadono.xsrv.jp/2011/10/23/1504)
佐々里峠の石室へ(https://kadono.xsrv.jp/2011/07/14/1477)
播磨道経由で白兎神社へ(https://kadono.xsrv.jp/2011/04/16/1447)
東海北陸道全線走破(https://kadono.xsrv.jp/2010/09/18/1048)
真夏の小松へ(https://kadono.xsrv.jp/2010/08/15/1030)
越前・河野しおかぜライン(https://kadono.xsrv.jp/2010/06/12/999)
金沢へ、GARIT G5高速道(https://kadono.xsrv.jp/2010/02/27/957)
賤ヶ岳SA(上り)イルミネーション(https://kadono.xsrv.jp/2009/12/19/582)
R162小浜-三方間(https://kadono.xsrv.jp/2009/10/10/563)
スプリングス日吉へ(https://kadono.xsrv.jp/2009/05/03/533)

エレクトロニクス

 実際のところ、市販品GPSロガー(GT-600)と比べて半自作のRaspberry Pi Zero+AE-GYSFDMAXBはどうなのか?ある日のデータを地理院地図の使い方を調べながら作ってみました。
 地理院地図での表示やこのサイトへの埋込については地理院地図にスマホのGPSログを表示する 平成30年(2018)1月23日(http://www.yamaaruki.biz/gpslog2.html)を参考にしました。
赤線がGT-600、青線がgpxloggerの軌跡です。比較地図全画面表示(https://kadono.xsrv.jp/wp-content/uploads/2019/03/gsi20190321215816230.html)
 時刻データまで入るのかどうか?など懸念がありましたけど生成されたhtmlデータを見る限り、読み込んだ.kmlのファイルと地図上の座標(GNSSモジュールで測位した緯度・経度・高度)のみになるようです。上の地図のようにトンネル出口付近でデータが飛んでいる場合、高度はメチャクチャです。GT-600の高度は1000mを超えています。gpxloggerは地中(地理院地図の標高よりも低い高度)を進んでいます。地図右上のメニューから[機能]→[3D]→[大]で見ると飛び/潜行具合が確認できます。また、同時刻の最初の点がGT-600はトンネル手前、gpxloggerはトンネル出口後になっていますけど、実際にはトンネルに入って数秒の位置が正しく両方共時刻と位置は合っていません。従って、この区間での速度データも大きく狂っています。データが収束するのが上で描画している最後付近になりズレ具合は異なるものの両方共5min程度掛かっています。
 gpxloggerのデータ源AE-GYSFDMAXBはQZSS 3機に対応しているため天頂付近の衛星を捉えることで復帰は早いです。ただ、測位精度、特に高度に対しては天頂付近の衛星を補足していてもあまり良くはならないようです。GLONASSにも対応しているZE520KLやGWR103sdのデータを見る限り捕捉できる衛星が多くても上の地図の区間のように見通しが悪い山間部(+トンネル+急カーブ+勾配+杉林)で測位に使う衛星の切替が多いとマルチパスの影響も大きくなるのか軌跡がシフトしたりふらつく傾向があります。

おまけ)地理院地図を貼り付けてR162沿いの峠の名前が供御飯峠(くぐいとうげ)というのを初めて知りました。難読なのかわざわざひらがなでふりがなが付いています。