エレクトロニクス

 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)

キンドル

 数ヶ月単位で読む暇もなく放置状態だったKindle VoyageをWiFi接続したところ自動的にアップデートされ4月配信の5.11.1.1になりました。いつの間にか漫画だけでなく文字だらけの小説本もシリーズでまとまるようになっているようです。ただ、全てのシリーズ物に対応しているわけではなく出版社?が対応させたものだけのようです。当然直系のシリーズ以外の派生版(マンガ化・小説化・スピンアウトなどなど)までは対応しきれていないので何千冊もの本の中に埋もれてしまうとKindle本体だけでは探すのも面倒です。何度かPCのブラウザから再配信したことがあります。
バージョンアップ後の新機能確認画面
 パフォーマンス改善という意味では若干はページめくりがスムーズになったかもしれません。

エレクトロニクス

 資金難から安物キーボードばかり使ってきました。しかし、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は初めて購入しましたけど、購入履歴を検索したところお風呂のフタを既に使っていました。

プリウス

 昨年は咲くのが早かったため今頃は既に散っていましたが今年は土曜日にほぼ満開で人も車もたくさんいました。車全体を写せるだけの空きスペースが無いため以下の写真で精一杯でした。
近況。
Prius ODD Meter 500992km.

プリウス

 2005年2月6日に納車されて、2012年7月6日に20万km、2014年6月19日30万km、2016年10月11日に40万kmを超えて、本日50万kmを超過しました。
給油後撮影。ODOメーター500221km.
500,000kmちょうどの時は名神高速を走っていたため撮影できませんでした。

Prius ODD Meter 500221km. (給油時)

プリウス

 3月中は年度末で整備工場の予約が埋まっていたため、4月最初の土曜日に京都トヨペット七条本店へ行き以下の整備を依頼しました。スタッドレスから夏タイヤへの交換、昨年と異なり新品タイヤへの交換ではないためバランス調整も追加しました。BluEarth AE-01F (YYY4617)は昨年だけで25147km走っていますがまだ数ヶ月は使いたいです。今回はうまい具合に時期を合わせることができたためオイルとオイルフィルターも交換、年始めの12ヶ月点検では雪道で凍結防止剤や泥だらけになるためスタッドレスを外すタイミングでエンジンルームクリーニングと下回りスチーム洗浄・パスタ塗装を依頼しました。
 外したスタッドレスタイヤTOYO OBSERVE GARIT GIZ 5セット目(31H4018)は1/19から9022kmだけ走りました。1月の記事では走行用バッテリ交換で動揺していたのか4セット目と誤記していたのを修正しました。使ってきたGARIT GIZの製造週刻印は(P2N4614)(P2N3215)(P2N4015)(31H4617)(31H4018)で現在5セット目です。ちなみに、このNHW20プリウスで異なるタイヤへの交換作業は51回目、31H4018は購入26セット目になります。スタッドレスタイヤの寿命が短いのが効いています。
夏タイヤ溝の残りは半分弱でスリップサインまで1mm~2mm程度です。
近況。
 今回もタイヤの空気圧について指示するのを忘れていたので外したタイヤを片付けてからMP100DZで微調整しました。

Prius ODD Meter 499933km. (入庫時)

エレクトロニクス

 標題の通り、よく分かりません。謎です。マニュアル(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沿いの峠の名前が供御飯峠(くぐいとうげ)というのを初めて知りました。難読なのかわざわざひらがなでふりがなが付いています。

エレクトロニクス

 GPSロガーとして使用しているRaspberry Pi Zero WHがどうやっても不規則にログが途切れるため、gpsd — a GPS service daemon(http://www.catb.org/gpsd/)から最新版の3.18.1をダウンロードして以下の手順でビルド・インストールすることでようやく対策ができました。OSのパッケージシステムの管理からは外れてしまうのでおすすめはできませんがgpxloggerのログが途切れる問題で悩んでいる場合は先に試したほうが早いと思います。
 ビルドするためにはsconsとpython-devを入れておく必要があります。sconsのコマンドなどはbuild.txtの指示そのままです。

sudo apt-get install -y scons python-dev
tar xvf gpsd-3.18.1.tar.gz
cd gpsd-3.18.1
scons && scons check && sudo scons udev-install
sudo systemctl restart gpsd

 Raspbian Stretchで通常の手順でインストールできるgpsdのバージョンは3.16なのですがこの後の3.17で以下の変更が入っています。
http://www.catb.org/gpsd/NEWSより引用・赤線追加
上の画像の赤線部にあるとおり再接続に失敗することが3.16ではあるらしく、しかもトンネルなどわかり易い場所ではなく不規則に止まってプロセスを再起動するまでgpxloggerがファイルにデータを書き込まなくなるのでかなり困っていました。最低限3.17にアップデートすればいいのですけどその後の3.18の更新履歴にもToo many other bug fixes and improvements to mention.などと書いてあるため3.18.1まで一気にアップデートしました。
 アップデート後の注意点としてgpxloggerは/usr/binに上書きではなく/usr/local/bin/gpxloggerとしてインストールされるためsystemdの設定ファイルをこちらに切り替える必要があります。ログの先頭にcreator="GPSD 3.18.1 – http://catb.org/gpsd"、中身に<src>GPSD 3.18.1</src>と出るので切り替わったかの確認ができます。

 gpxloggerの設定については特にRaspberry PiでGPS位置情報を記録(http://denor.daa.jp/raspberry-pi%E3%81%A7gps%E4%BD%8D%E7%BD%AE%E6%83%85%E5%A0%B1%E3%82%92%E8%A8%98%E9%8C%B2)が参考になりました。systemd用のスクリプトはこのサイトの/etc/systemd/system/gpxlogger.serviceをベースにgpxloggerのオプションを-i 120 -m 1に変更して使用しています。-i 120は1km級未満のトンネルや受信状況悪化で分割されるのを防ぐためおおよそ30km/h*2minで約1kmになるためです。-m 1はDGPSになってもせいぜいHDOP 0.8m程度が限界のため1m未満の移動は切り捨てています。

 大問題が解決した記念に車載型の試作機ハード写真(3/20現在)を公開します。構成は据置用NTP Serverとほぼ同じです。
車載型GPXロガー試作機、左は比較用i-gotU GT-600
そもそもi-gotUの充電やUSB経由でのデータ取り出しが面倒、今どきi-gotU GT-600(http://www.i-gotu.jp/?page_id=56)でうたっているような、たったの64MBで大容量という点を改善しリプレースするために作っています。Raspberry Pi ZeroはmicroSDXCメモリ対応のため現在は32GBを使用していますがその気になれば128GB(据置で稼働中)でも256GBでも利用可能です。さらにWiFiで接続すればsftpで大容量・高速データ転送できるのでいちいち本体をプリウスから持ち出したり載せなおしたりする手間もなくせる目論見です。