プリウス本来は所用でプリウスに乗れそうにない2/23に予約を入れたかったのですけど既に予約がいっぱいだったため無理やり過密スケジュールの午前のみの有給休暇に組み込みました。午前中の用事の合間に京都トヨペット七条本店へ行きプリウスを預けて予約は午後ですが午後は出勤しなければならず受け取りは仕事後の夜になりました。近況、整備上がりです。していてタイヤのローテーションをするかどうか迷っていたのですけれど、2月中に夏タイヤにするのは危険なため入庫前に電話して急遽追加してもらいました。このため、空気圧を指示するのを忘れてそのままローテーションされました。受け取り後の試走でどうにもおかしいと思い道の駅で停めて昨年購入したMP100DZとRCG-20で前輪2本の空気圧をポンプで上げて後輪2本をゲージで下げる作業を行いました。MP100DZでの加圧作業。MP100DZを暗い場所で使うのは初だったかと思いますけど写真のように強力な作業灯ML801で照らすことで作業自体に支障はありませんでした。どちらかというと、車外での作業は寒さのほうがきつかったです。エレクトロニクス模型の組立を初めたわけではありません。PN1-150-Sでピンソケットを切り離そうとしたら刃が厚すぎで1pin分潰してしまう上に切断面が今ひとつなのでプラスチック用の薄刃ニッパーを購入しました。下が標準PN1-150-S、上が薄刃ニッパー74035。上の写真の刃の左横においたピンソケットの切断面を見ていただければ分かる通り、標準ニッパーでは切断したピンの金属が見えていて接触不良を起こします。薄刃ニッパーでは無駄なピンを出すことがなくきれいに切れています。ピンソケットで特に差が出ますがピンヘッダでも同様です。金属は使用上非対応ですけど極細のUEWならば切れます。金属が切れにくいことから細い配線の被覆を外すのにも使えます(推奨用途外でしょうけど)。後日追記)プラスチック製のインシュロックタイ(AB80-Wなど)を切るにも良さそうです。エレクトロニクスようやく追い込めてきました。Server(据置)両方を試作しているのですけどそれぞれで問題がありログが途切れたりoffsetやjitterが安定しなかったり、一見良さそうでも情報通信研究機構(以下NICT)やmfeedから取得できるNTP経由での日本標準時から10msec以上乖離したり...。一応、収束してきましたのでメモを公開します。多くのWebサイトを参考にしました。全ては紹介しきれませんけど感謝しています。ここまで追い込むのにカレンダー上1ヶ月以上掛かっています。1PPSの信号をいかに正確に取り込むかが精度向上の鍵になっています。GNSSモジュールの受信状況が悪化や故障してもインターネット接続が途絶してもできる限り正確な時刻を維持し続けることを目指しています。1.029無線LANの区間があるためどうしてもdelayが大きくなっています。IPv6での有意差は無さそうです。NICTを外しているのは負荷に制限(1時間平均で20回)があるためです。GNSSモジュールからのoffsetとjitterが一気に小さくなったのは/etc/ntp.confを以下の設定に変更したことによります。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オプションを付けたほうがいいと思いますがトンネルなど不安定化しやすい車載用では外すかもしれません。サーバーを、「プライマリ」および「バックアップ」と指定して使用することはできますか?(https://access.redhat.com/ja/solutions/441873)にこのオプションのわかりやすい説明があります。PCの設定についてはwindowsでNTP時刻同期の精度を向上させるには(https://qiita.com/ymfj/items/380d0b3ea5f6cf3dfdb6)のW32Timeサービスの設定とNTPによる同期について(http://zokibayashi.hatenablog.com/entry/2015/04/11/003004)から複数台設定が特に参考になりました。1809の場合はレジストリで設定しなくても以下のコマンドで設定できるようです。192.168.1.1はLAN内NTPサーバーの仮アドレスです。/peersで192.168.1.1がアクティブならばOKのはずです。IPv6のサーバを指定する場合はfe80::aaaa:bbbb:cccc:dddd%11,0x8というようにゾーンインデックスまで入れる必要があります(少なくともリンクローカルアドレスの場合)。レジストリの設定では上記Qiitaの記事にあるUpdateIntervalは記事中にあるように100程度まで下げなければ100msec以下の精度が得られないようです。100msec以上1秒以内のズレで問題ないならばレジストリ設定は不要かと思います。Receiver)も試しました。82ですがNAVSTAR衛星の位置に因ってかCPUの負荷か?time2の微調整を行っても時に1msec以上のoffsetが発生しました。据置ではgpsdは止めていましたが車載用の精度を高めていったら据置を超えてしまったのでSHM(2)へ統一することにしました。この設定で完璧かといいますとそうでも無いようです。コールドスタートするとちっともSHM(2)を読みにいかず、gpsmonやcgpsを手動で叩くといきなり動き出すという謎の挙動をします。対策として上のサイトでは起動時に一度gpspipeでアクセスすることで動作しているようなのでcrontabに以下の乱暴な対策を追加して暫定対策にしています。(後日修正)rc.localに以下の空読みを加えています。cronで何度も読んでもgpxloggerのランダム停止は防げませんでした。gpsd.serviceが動き出してから最初の1回だけで十分なようです。2>&1EOS※Webで調べる限り、脈絡なしのハングアップはsmsc95xx.turbo_mode=Nと関係するのではないか?と疑っています。→3/20追記)ようやく対策の目処が付きました。3.18.1をビルド・上書きインストール(https://kadono.xsrv.jp/2019/03/20/8052)を参照してください。115200bps化など細かいチューニングを行っていますので追って時間を見つけて編集します。あちこちからの寄せ集めで十分な確認をしていませんので注意してください。115200bps化のためsttyで切り替えようとしても/etc/rc.localに書いたのではgpsdが起動した後になるようです。これを防ぐにはsystemdで明示的にgpsdよりも前に設定が入るようにする必要があり上記設定を更新しました。gpsdを起動すると1Hzに戻される(https://qiita.com/snz/items/624544d508867e6473c2)が参考になっています。NTPではPPSが支配的なため測定周期を上げる必要は感じていませんがGPSロガーでは試してみたいと思っています。systemd.svgでファイルを作成してChromeブラウザで見ると分かりやすかったです。Bではgpsdが起動時点で止まってしまいました。After=setserial.serviceを追加しなければsetserialが有効になる前にttysetupが走るようなので追加しました。Enableを追加しました。MTSAT-2を捉えることができるようです。MTSAT-2運用終了後は分かりません。新品のモジュールで動作を見たところホスト側のUARTが9600bpsでコマンドを送れていないようでした。対策として、明示的に9600bpsにして115200のコマンドを発行する行を追加しました。バックアップ電池等でモジュール側が既に115200bpsの場合は無視されるはずです。再起動ないし以下の手順で切り替えることができるはずです。2一旦gpsdが起動するとUARTをつかみっぱなしになるため一旦止めてからttysetupや手動でのコマンド書き込みを実行する必要があります。AE-GYSFDMAXBのマニュアルには明示されていませんけどPMTK220で5Hzに切り替わることは確認しました。NTPでは恩恵が無いのと一般道の速度では1Hzでも十分そうなので当面は1Hzで試験を続けます。追記その5)どうやらモジュールへの9600bps→115200bpsの切替を上記のttysetupスクリプトでは起動時に自動でうまく動かないようです。詳細を解析している暇がなく原因が分かりませんけど、切替待ち時間不足か何かと思います。GNSSモジュールにバックアップ電池が付いていれば、手動で一度書き込んでしまえば当分(たぶん半年以上)は保ちそうなのでとりあえず様子を見ます。GNSS側が切り替わったかはgpspipeコマンドの返り値二行目に"bps":115200と表示されることで確認できます。GPGGAだけに設定してもgpsdが自動的にGNSSモジュールにコマンドを送って解除する点について/etc/default/gpsdに-bオプション(read-only)を入れることでgpsdからのコマンド送信を止めることができました。GPGGAで得られる情報だけが表示されます。NTPサーバにしてもGPSロガーにしても通常はこれで足りるため節電や精度向上のため設定を変更しました。ServerとしてはGPRMCだけでも何とかなりそうなので更に削りました。301を設定する必要はないのかもしれません。少なくとも、私が動かしている限りマニュアルのExampleどおりのRTCMではちっともDGPSにならずSBASに切り替えたところ即GPRMCの最後がDに変わりました。パリティなし、フロー制御なしを明示的に設定することで対策できました。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)へ移しました。4.14.98+です。AE-GYSFDMAXBのファームウェアは2019年1月に購入したものはすべて0014(みちびき3機版)にアップデート済みでした。Piにセットアップ済みでも確認は可能です。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コマンドの挙動になるようです。passPython3.4以降ならばそのままtouchもあるようなのですが作っていたスクリプトがPython2向けでしたのでこのようにしました。プリウス予算難により高速代を圧縮する必要があるものの毎年恒例となっている熊野本宮大社へは行きたい。いうことで天気が微妙だったものの往復R168経由という強行軍で行ってきました。観光バスなどに阻まれて門限の17:00までに到着できそうになければ代替案も考えていましたが交通量が少なく快調に流れたため想定よりも早く到着できました。空のためか気持ち車や人は少なめだったと思います。八咫ポスト2019、驚愕の緑色まだ片付いていなかったので八咫烏付きの黒ポストの様子も伺いましたが何と黒だったはずの烏が緑色になっていました。去年は2月に参拝したときは黒でしたけど検索すると一時期特別色で金色にもなっていたようです。ドラレコ(ドライブマンGP-1)のデータはまだ確認していませんので追記するかもしれません。Piベースの特製GPSロガーの動作試験も兼ねて出発したのですけどシャットダウンスクリプトの誤動作でなんと右折1回、左折1回(1km未満)で位置データの記録が停止していました。動作し続けていたためハード的には問題なかったようです。出発から帰着までこの試作中GPSロガーは完全放置で帰ってからデータを見るまで気づきませんでした。あと、驚いたのがR168五条市内にローソン五條野原西店が2/1に開店したようです。オープンのノボリが立っていましたが直前に五條インター店に寄っていたため今回はパスしました。