プリウス

 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”、中身にGPSD 3.18.1と出るので切り替わったかの確認ができます。

 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で大容量・高速データ転送できるのでいちいち本体をプリウスから持ち出したり載せなおしたりする手間もなくせる目論見です。

プリウス

 購入履歴を検索したところ、2015年1月のPIAAスーパーグラファイトスノーブレードリア400MM WG40KWへ取替(https://kadono.xsrv.jp/2015/01/17/3029)からリア用は一度も替えゴムを変えていなかったようです。ゴムが切れてきているのは知っていたのですけど、寒いし面倒だしで放置していました。ここのところ続く雨でいい加減気になってきましたので交換作業を行いました。結果的に4年以上使えたことになります。
上側が新しいゴム、下側の新品付属品はボロボロで変色しています。
 夏冬でワイパーを変えていた頃は簡単に外していたのですけど久しぶり(たぶん4年ぶり)になると手順を忘れていました。ロックを解除するところは覚えていたのですけど引き抜く方向がすぐに分かりませんでした。

エレクトロニクス

 NTP Server等で稼働しているRaspberry Pi Zero WHのOS (大本は2018-11-13-raspbian-stretch-lite)をLinux version 4.19.27+ から Linux version 4.14.98+への切り戻しを2台行いました。現状でrpi-updateとすると4.19になります。2台だけ実験機として4.19で動かしていたのですけど余計なモジュールをロードしたり、アップデート時の警告表示で出る通りドライバが不安定なようで4.14.98まで切り戻すことにしました。

 手順についてはRaspberry Pi Mouse 研修[1](https://products.rt-net.jp/micromouse/archives/7242)を参考にしました。参考リンクからたどれるrpi-firmwareのGitHub(https://github.com/Hexxeh/rpi-firmware/commits/master)から4.14.98のhash番号a08ece3d48c3c40bf1b501772af9933249c11c5bを入れることで古いバージョンからはアップデート、4.19からはダウングレードができました。ただし、特にダウングレード(切り戻し)はそれなりにリスクがあると思いますので推奨はしていないと思います。

sudo rpi-update a08ece3d48c3c40bf1b501772af9933249c11c5b # 4.14.98
sudo shutdown -r now

 使っているのがLAN, UART, I2C, I2SぐらいでCLIばかりの私の使い方では特に問題になっていないようですけど画像や動画処理関係は影響するかもしれません。使いもしないカーネルモジュール(v4l2_*やらvideo*)が多々入って困っていました。4.19に関してはもう少し落ち着いて警告表示がなくなってからアップデートを考えます。

エレクトロニクス

 WordPress用テーマLuxeritasを3.5.8から3.5.9へアップデートしました。Chrome 71での仕様変更への対応と不具合修正だそうです。このサイトではPWAを有効にしていないので直接の影響は無いと思います。詳細は
Chrome 71 以降?だと ServiceWorkers が上手く動作しなくなってたので修正 Luxeritas 3.5.9(https://thk.kanzae.net/dev/wp-themes/luxeritas/t10660/)を御覧ください。

プリウス

 本来は所用でプリウスに乗れそうにない2/23に予約を入れたかったのですけど既に予約がいっぱいだったため無理やり過密スケジュールの午前のみの有給休暇に組み込みました。
 午前中の用事の合間に京都トヨペット七条本店へ行きプリウスを預けて予約は午後ですが午後は出勤しなければならず受け取りは仕事後の夜になりました。
近況、整備上がりです。
 また、バタバタしていてタイヤのローテーションをするかどうか迷っていたのですけれど、2月中に夏タイヤにするのは危険なため入庫前に電話して急遽追加してもらいました。このため、空気圧を指示するのを忘れてそのままローテーションされました。受け取り後の試走でどうにもおかしいと思い道の駅で停めて昨年購入したMP100DZとRCG-20で前輪2本の空気圧をポンプで上げて後輪2本をゲージで下げる作業を行いました。
MP100DZでの加圧作業。
 MP100DZを暗い場所で使うのは初だったかと思いますけど写真のように強力な作業灯ML801で照らすことで作業自体に支障はありませんでした。どちらかというと、車外での作業は寒さのほうがきつかったです。