プリウス

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

エレクトロニクス

 模型の組立を初めたわけではありません。PN1-150-Sでピンソケットを切り離そうとしたら刃が厚すぎで1pin分潰してしまう上に切断面が今ひとつなのでプラスチック用の薄刃ニッパーを購入しました。
下が標準PN1-150-S、上が薄刃ニッパー74035。
 上の写真の刃の左横においたピンソケットの切断面を見ていただければ分かる通り、標準ニッパーでは切断したピンの金属が見えていて接触不良を起こします。薄刃ニッパーでは無駄なピンを出すことがなくきれいに切れています。
 ピンソケットで特に差が出ますがピンヘッダでも同様です。金属は使用上非対応ですけど極細のUEWならば切れます。また、金属が切れにくいことから細い配線の被覆を外すのにも使えます(推奨用途外でしょうけど)。

 後日追記)プラスチック製のインシュロックタイ(AB80-Wなど)を切るにも良さそうです。

エレクトロニクス

 ようやく追い込めてきました。Raspberry Pi Zero WHにAE-GYSFDMAXBを接続してGPSロガー(車載)とNTP Server(据置)両方を試作しているのですけどそれぞれで問題がありログが途切れたりoffsetやjitterが安定しなかったり、一見良さそうでも情報通信研究機構(以下NICT)やmfeedから取得できるNTP経由での日本標準時から10msec以上乖離したり…。一応、収束してきましたのでメモを公開します。多くのWebサイトを参考にしました。全ては紹介しきれませんけど感謝しています。

 まず、現状の据置Raspberry Pi Zero WHでの状況です。ここまで追い込むのにカレンダー上1ヶ月以上掛かっています。1PPSの信号をいかに正確に取り込むかが精度向上の鍵になっています。GNSSモジュールの受信状況が悪化や故障してもインターネット接続が途絶してもできる限り正確な時刻を維持し続けることを目指しています。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*SHM(2)          .SHM2.           1 l    3    8  377    0.000   -0.019   0.004
 LOCAL(0)        .LOCL.          10 l  879   64    0    0.000    0.000   0.000
+ntp2.jst.mfeed. 133.243.236.17   2 u   15   64  377   22.029    1.784   0.535
+ntp1.v6.mfeed.a 133.243.236.17   2 u   21   64  377   22.772    0.150   1.079
-ntp2.v6.mfeed.a 133.243.236.17   2 u   22   64  377   20.671    1.789   0.723
-ntp3.v6.mfeed.a 133.243.236.17   2 u   24   64  377   22.118   -0.299   1.029

 無線LANの区間があるためどうしてもdelayが大きくなっています。IPv4, IPv6での有意差は無さそうです。NICTを外しているのは負荷に制限(1時間平均で20回)があるためです。GNSSモジュールからのoffsetとjitterが一気に小さくなったのは/etc/ntp.confを以下の設定に変更したことによります。

# 28; SHM(2), gpsd: PPS data from shared memory provided by gpsd
# # http://doc.ntp.org/current-stable/drivers/driver28.html
server  127.127.28.2  minpoll 3  maxpoll 3  true
fudge   127.127.28.2  refid SHM2  stratum 1
# https://www.raspberrypi.org/forums/viewtopic.php?t=191050
# http://denor.daa.jp/raspberry-pi%E8%B5%B7%E5%8B%95%E6%99%82%E3%81%ABgps%E3%81%A7%E7%8F%BE%E5%9C%A8%E6%99%82%E5%88%BB%E3%82%92%E8%A8%AD%E5%AE%9A1pps%E5%AF%BE%E5%BF%9C
server  127.127.1.0
fudge   127.127.1.0 stratum 10
server ntp.jst.mfeed.ad.jp
server ntp1.v6.mfeed.ad.jp
server ntp2.v6.mfeed.ad.jp
server ntp3.v6.mfeed.ad.jp

 上記設定内のコメントにも記載していますが、Raspberry Pi起動時にGPSで現在時刻を設定(1PPS対応)(http://denor.daa.jp/raspberry-pi%E8%B5%B7%E5%8B%95%E6%99%82%E3%81%ABgps%E3%81%A7%E7%8F%BE%E5%9C%A8%E6%99%82%E5%88%BB%E3%82%92%E8%A8%AD%E5%AE%9A1pps%E5%AF%BE%E5%BF%9C)の記事で紹介されていますSHM(2)がこれまで私が試した中では最良の結果を出しています。このサイトの他のGPSに関連する記事も参考になりました。
 据置ではGNSSモジュールの受信状況悪化はしにくいためtrueオプションを付けたほうがいいと思いますがトンネルなど不安定化しやすい車載用では外すかもしれません。2 台の NTP サーバーを、「プライマリ」および「バックアップ」と指定して使用することはできますか?(https://access.redhat.com/ja/solutions/441873)にこのオプションのわかりやすい説明があります。
 また、据置LAN内GNSS NTP Serverを参照するWindows PCの設定についてはwindowsでNTP時刻同期の精度を向上させるには(https://qiita.com/ymfj/items/380d0b3ea5f6cf3dfdb6)のW32Timeサービスの設定とNTPによる同期について(http://zokibayashi.hatenablog.com/entry/2015/04/11/003004)から複数台設定が特に参考になりました。Windows10 Pro 1809の場合はレジストリで設定しなくても以下のコマンドで設定できるようです。192.168.1.1はLAN内NTPサーバーの仮アドレスです。
w32tm /config /manualpeerlist:”192.168.1.1,0×9 ntp.jst.mfeed.ad.jp,0x9″ /syncfromflags:MANUAL /update
net start w32time
sc config w32time start= delayed-auto
w32tm /resyncで手動で合わせてw32tm /query /peersで192.168.1.1がアクティブならばOKのはずです。レジストリの設定では上記Qiitaの記事にあるUpdateIntervalは記事中にあるように100程度まで下げなければ100msec以下の精度が得られないようです。100msec以上1秒以内のズレで問題ないならばレジストリ設定は不要かと思います。
 他には127.127.46.u (GPSD-NG client driver)や127.127.22.u(PPS Clock Discipline)、127.127.20.u(Generic NMEA GPS Receiver)も試しました。次点で良かったのがserver 127.127.20.0 mode 82ですがNAVSTAR衛星の位置に因ってかCPUの負荷か?time2の微調整を行っても時に1msec以上のoffsetが発生しました。据置ではgpsdは止めていましたが車載用の精度を高めていったら据置を超えてしまったのでSHM(2)へ統一することにしました。
 この設定で完璧かといいますとそうでも無いようです。コールドスタートするとちっともSHM(2)を読みにいかず、gpsmonやcgpsを手動で叩くといきなり動き出すという謎の挙動をします。対策として上のサイトでは起動時に一度gpspipeでアクセスすることで動作しているようなのでcrontabに以下の乱暴な対策を追加して暫定対策にしています。(後日修正)rc.localに以下の空読みを加えています。cronで何度も読んでもgpxloggerのランダム停止は防げませんでした。gpsd.serviceが動き出してから最初の1回だけで十分なようです。

cat << 'EOS'| sudo tee -a /etc/rc.local
/usr/bin/gpspipe -w | /usr/bin/head -1 > /dev/null 2>&1
EOS

※Webで調べる限り、脈絡なしのハングアップはsmsc95xx.turbo_mode=Nと関係するのではないか?と疑っています。→3/20追記)ようやく対策の目処が付きました。gpxloggerのログ途絶対策についてはRaspberry Pi Zero WHにgpsd 3.18.1をビルド・上書きインストール(https://kadono.xsrv.jp/2019/03/20/8052)を参照してください。
 上記以外にもUART 115200bps化など細かいチューニングを行っていますので追って時間を見つけて編集します。
以下は設定メモです。あちこちからの寄せ集めで十分な確認をしていませんので注意してください。

sudo cp /boot/cmdline.txt /boot/cmdline.txt.orig
sudo sed -i -e 's/console=serial0,115200 //g' /boot/cmdline.txt
sudo systemctl stop serial-getty@ttyS0.service
sudo systemctl disable serial-getty@ttyS0.service
sudo bash -c "echo enable_uart=1 >> /boot/config.txt"
cat << 'EOS'| sudo tee -a /boot/config.txt
dtoverlay=pps-gpio,gpiopin=18,assert_falling_edge=true
EOS
cat << 'EOS'| sudo tee -a /etc/modules
gps-gpio
EOS
sudo apt-get install -y gpsd gpsd-clients pps-tools
sudo mv /etc/default/gpsd /etc/default/gpsd.orig
cat << 'EOS'| sudo tee -a /etc/default/gpsd
START_DAEMON="true"
USBAUTO="false"
DEVICES="/dev/gps0 /dev/pps0"
GPSD_OPTIONS="-b -n"
EOS
sudo systemctl enable gpsd.socket
ls -alF /dev/serial*
cat << 'EOS'| sudo tee -a /etc/udev/rules.d/99-pps.rules
KERNEL=="ttyAMA0",SYMLINK+="gps0"
KERNEL=="pps0",OWNER="root",GROUP="dialout",MODE="0660",SYMLINK+="gpspps0"
EOS
sudo apt-get install -y setserial
cat << EOS | sudo tee -a /usr/lib/systemd/system/ttysetup.service
[Unit]
Description=Prepare tty UART for GNSS
Before=gpsd.service
After=setserial.service
[Service]
Type=oneshot
ExecStartPre=/bin/setserial /dev/ttyAMA0 low_latency
ExecStart=/bin/stty -F /dev/ttyAMA0 raw 115200 cs8 clocal -parenb -cstopb
[Install]
WantedBy=multi-user.target
EOS
sudo systemctl daemon-reload
sudo systemctl enable ttysetup

sudo shutdown -r now

 後日追記) 115200bps化のためsttyで切り替えようとしても/etc/rc.localに書いたのではgpsdが起動した後になるようです。これを防ぐにはsystemdで明示的にgpsdよりも前に設定が入るようにする必要があり上記設定を更新しました。115200bps化についてはGPSモジュールの測定周期を10Hzに変更できたが gpsdを起動すると1Hzに戻される(https://qiita.com/snz/items/624544d508867e6473c2)が参考になっています。NTPではPPSが支配的なため測定周期を上げる必要は感じていませんがGPSロガーでは試してみたいと思っています。systemdでの起動順序についてはsystemdのサービスの起動順序を決める(https://takeg.hatenadiary.jp/entry/2017/02/15/220536)で説明されているsystemd-analyze plot > systemd.svgでファイルを作成してChromeブラウザで見ると分かりやすかったです。
 更に追記) 上記で追加したttysetup.service中の順序設定ですけど当初Before=chronyd.service gpsd.socketとしていてRaspberry Pi Zero WHでは動作していたのですがマルチコアCPUの影響か?起動タイミングがまるで異なるRaspberry Pi 3 Model Bではgpsdが起動時点で止まってしまいました。
 追記その3) After=setserial.serviceを追加しなければsetserialが有効になる前にttysetupが走るようなので追加しました。また、GNSSモジュールに対するコマンドも見直して、gpsdが上書きする(?)$PMTK220と$PMTK314は削除し、DGPS RTCM, SBAS Enableを追加しました。DGPSの効果は今ひとつ不明ですけど、SBASは2019年2月現在PRN 137, MTSAT-2を捉えることができるようです。MTSAT-2運用終了後は分かりません。
 追記その4) 新品のモジュールで動作を見たところホスト側のUARTが9600bpsでコマンドを送れていないようでした。対策として、明示的に9600bpsにして115200のコマンドを発行する行を追加しました。バックアップ電池等でモジュール側が既に115200bpsの場合は無視されるはずです。再起動ないし以下の手順で切り替えることができるはずです。例によって検証は不十分です、

sudo systemctl stop gpsd
sudo systemctl stop gpsd.socket
/bin/stty -F /dev/ttyAMA0 raw 9600 cs8 clocal -parenb -cstopb
# cat /dev/ttyAMA0 # 必要ならばUART動作確認(CTRL+Cで止める)
/bin/echo -e "\$PMTK251,115200*1F\r\n" > /dev/ttyAMA0
/bin/stty -F /dev/ttyAMA0 raw 115200 cs8 clocal -parenb -cstopb
# cat /dev/ttyAMA0 # 必要ならばUART動作確認(CTRL+Cで止める)
sudo systemctl restart ttysetup
sudo systemctl start gpsd
gpspipe -w -n 2

 一旦gpsdが起動するとUARTをつかみっぱなしになるため一旦止めてからttysetupや手動でのコマンド書き込みを実行する必要があります。また、AE-GYSFDMAXBのマニュアルには明示されていませんけどPMTK220で5Hzに切り替わることは確認しました。NTPでは恩恵が無いのと一般道の速度では1Hzでも十分そうなので当面は1Hzで試験を続けます。
 追記その5)どうやらモジュールへの9600bps→115200bpsの切替を上記のttysetupスクリプトでは起動時に自動でうまく動かないようです。詳細を解析している暇がなく原因が分かりませんけど、切替待ち時間不足か何かと思います。GNSSモジュールにバックアップ電池が付いていれば、手動で一度書き込んでしまえば当分(たぶん半年以上)は保ちそうなのでとりあえず様子を見ます。GNSS側が切り替わったかはgpspipeコマンドの返り値二行目に"bps":115200と表示されることで確認できます。
 追記その6)PMTK314でGPRMC, GPGGAだけに設定してもgpsdが自動的にGNSSモジュールにコマンドを送って解除する点について/etc/default/gpsdに-bオプション(read-only)を入れることでgpsdからのコマンド送信を止めることができました。この状態でgpsmonを動かすとGPRMC, GPGGAで得られる情報だけが表示されます。NTPサーバにしてもGPSロガーにしても通常はこれで足りるため節電や精度向上のため設定を変更しました。
 追記その7)さらに調べると、NTP ServerとしてはGPRMCだけでも何とかなりそうなので更に削りました。あと、DGPSのモードはSBASが標準らしいのであえてPMTK313, 301を設定する必要はないのかもしれません。少なくとも、私が動かしている限りマニュアルのExampleどおりのRTCMではちっともDGPSにならずSBASに切り替えたところ即GPRMCの最後がDに変わりました。
 追記その8)cat /dev/ttyAMA0で表示が崩れる問題の対策としてraw 115200 cs8 clocal -parenb -cstopbというように仕様書の設定Data 8bit, Stop 1bit, パリティなし、フロー制御なしを明示的に設定することで対策できました。使用しているモジュールは異なりますけどRaspberry Pi3のシリアルポート UARTに VK16Eの GPSモジュールを接続する方法(http://www.neko.ne.jp/~freewing/raspberry_pi/raspberry_pi_3_serial_gps/)を参考にしました。
 追記その9)起動時のttysetupではUARTの設定変更だけにしてGNSSモジュールへの書き込みは手動の方が確実のようです。
 追記その10)UARTで書き込むGNSSモジュールへのコマンドについてはAE-GYSFDMAXB設定コマンドの謎
(https://kadono.xsrv.jp/2019/04/05/8154)
へ移しました。
据置型ハード現況。
主なハード部品(Raspberry Pi Zero WH スターターセット分は除く)
AE-GYSFDMAXB
AE-RasPi-Universal
PH-2x40SG
FHU-2x42SG
PH-1x40SG
FHU-1x42SG
USB CABLE A-MICROB(2A L0.15m)
USB-LAN100R
 OSは2018-11-13-raspbian-stretch-liteからアップデートを繰り返してLinux version 4.14.98+です。demsgで認識している据置用のモデルはMachine model: Raspberry Pi Zero W Rev 1.1になります。
 AE-GYSFDMAXBのファームウェアは2019年1月に購入したものはすべて0014(みちびき3機版)にアップデート済みでした。いちいちPCに接続し直さなくても$ /usr/bin/gpspipe -w -n 2で2行目の"subtype":"AXN_2.5_3339_17110325-0014"の末尾にバージョン"0014"が出ますのでRaspberry Piにセットアップ済みでも確認は可能です。
 追記その11)3ヶ月以上運用してNTP Server用としてAE-GYSFDMAXBは特に問題が無いのですけどGPSロガー用としては車載用GNSSモジュールをGT-902PMGGへ変更(https://kadono.xsrv.jp/2019/05/03/8256)のとおり変更しました。

エレクトロニクス

 シェルスクリプトを置き換えるために調べていて検索したところPythonで空ファイルを作るハナシ(https://www.hobochuritsu.com/entry/2018/10/04/223929)に書いてあるスクリプトがほぼそのまま使えそうでした。しかし、残念なのがファイルがある場合は中身を替えずに更新時刻だけ実行時刻に変えるという点が何もしない(pass)になっていました。そこをos.utime(path,Name)にすることでほぼLinux等のtouchコマンドの挙動になるようです。非常におしいです。

import os
def touch(path):
# https://www.hobochuritsu.com/entry/2018/10/04/223929
# http://www.gesource.jp/programming/python/code/0019.html
    if os.path.isfile(path):
        os.utime(path, None)
    else:
        with open(path, "w") as f:
            pass

Python3.4以降ならばそのままtouchもあるようなのですが作っていたスクリプトがPython2向けでしたのでこのようにしました。

プリウス

 予算難により高速代を圧縮する必要があるものの毎年恒例となっている熊野本宮大社へは行きたい。というか、行かねば。ということで天気が微妙だったものの往復R168経由という強行軍で行ってきました。観光バスなどに阻まれて門限の17:00までに到着できそうになければ代替案も考えていましたが交通量が少なく快調に流れたため想定よりも早く到着できました。河原の駐車場はガラガラで階段横に止めて一気に上がりました。
熊野川河川敷駐車場
 曇り空のためか気持ち車や人は少なめだったと思います。
八咫ポスト2019、驚愕の緑色
 まだ片付いていなかったので八咫烏付きの黒ポストの様子も伺いましたが何と黒だったはずの烏が緑色になっていました。去年は2月に参拝したときは黒でしたけど検索すると一時期特別色で金色にもなっていたようです。

 ドラレコ(ドライブマンGP-1)のデータはまだ確認していませんので追記するかもしれません。

 また、Raspberry Piベースの特製GPSロガーの動作試験も兼ねて出発したのですけどシャットダウンスクリプトの誤動作でなんと右折1回、左折1回(1km未満)で位置データの記録が停止していました。AE-GYSFDMAXBでの時刻取得やBME280の温度・湿度・気圧計は動作し続けていたためハード的には問題なかったようです。出発から帰着までこの試作中GPSロガーは完全放置で帰ってからデータを見るまで気づきませんでした。要改良。

 あと、驚いたのがR168五条市内にローソン五條野原西店が2/1に開店したようです。オープンのノボリが立っていましたが直前に五條インター店に寄っていたため今回はパスしました。