エレクトロニクス

 資金難から安物キーボードばかり使ってきました。しかし、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沿いの峠の名前が供御飯峠(くぐいとうげ)というのを初めて知りました。難読なのかわざわざひらがなでふりがなが付いています。

エレクトロニクス

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

エレクトロニクス

 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/)を御覧ください。

エレクトロニクス

 模型の組立を初めたわけではありません。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,0x8 ntp.jst.mfeed.ad.jp,0x8" /syncfromflags:MANUAL /update
net start w32time
sc config w32time start= delayed-auto
w32tm /resyncで手動で合わせてw32tm /query /peersで192.168.1.1がアクティブならばOKのはずです。IPv6のサーバを指定する場合はfe80::aaaa:bbbb:cccc:dddd%11,0x8というようにゾーンインデックスまで入れる必要があります(少なくともリンクローカルアドレスの場合)。

レジストリの設定では上記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向けでしたのでこのようにしました。