エレクトロニクス

　ようやく追い込めてきました。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が起動時点で止まってしまいました。
　追記その３) After=setserial.serviceを追加しなければsetserialが有効になる前にttysetupが走るようなので追加しました。また、GNSSモジュールに対するコマンドも見直して、gpsdが上書きする(?)$PMTK220と$PMTK314は削除し、DGPS RTCM, SBAS Enableを追加しました。DGPSの効果は今ひとつ不明ですけど、SBASは2019年2月現在PRN 137, MTSAT-2を捉えることができるようです。MTSAT-2運用終了後は分かりません。
　追記その４) 新品のモジュールで動作を見たところホスト側の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で試験を続けます。
　追記その５)どうやらモジュールへの9600bps→115200bpsの切替を上記のttysetupスクリプトでは起動時に自動でうまく動かないようです。詳細を解析している暇がなく原因が分かりませんけど、切替待ち時間不足か何かと思います。GNSSモジュールにバックアップ電池が付いていれば、手動で一度書き込んでしまえば当分(たぶん半年以上)は保ちそうなのでとりあえず様子を見ます。GNSS側が切り替わったかはgpspipeコマンドの返り値二行目に"bps":115200と表示されることで確認できます。
　追記その６）PMTK314でGPRMC, GPGGAだけに設定してもgpsdが自動的にGNSSモジュールにコマンドを送って解除する点について/etc/default/gpsdに-bオプション(read-only)を入れることでgpsdからのコマンド送信を止めることができました。この状態でgpsmonを動かすとGPRMC, GPGGAで得られる情報だけが表示されます。NTPサーバにしてもGPSロガーにしても通常はこれで足りるため節電や精度向上のため設定を変更しました。
　追記その７）さらに調べると、NTP ServerとしてはGPRMCだけでも何とかなりそうなので更に削りました。あと、DGPSのモードはSBASが標準らしいのであえてPMTK313, 301を設定する必要はないのかもしれません。少なくとも、私が動かしている限りマニュアルのExampleどおりのRTCMではちっともDGPSにならずSBASに切り替えたところ即GPRMCの最後がDに変わりました。
　追記その８）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/)を参考にしました。
　追記その９）起動時のttysetupではUARTの設定変更だけにしてGNSSモジュールへの書き込みは手動の方が確実のようです。
　追記その１０）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にセットアップ済みでも確認は可能です。
　追記その１１）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向けでしたのでこのようにしました。

　昨年12月の怒涛の連続アップデートから1ヶ月ほど間が空きました。年末年始のバタバタで3.6.7はスキップしていました。3.6.8が出ていましたので3.6.6→3.6.8へのアップデート作業を行いました。機能追加や不具合修正など多数です。が、このサイトには大きく影響しないと思います。たぶん。

　更新内容の詳細は正月休み終了 Luxeritas 3.5.8(https://thk.kanzae.net/dev/wp-themes/luxeritas/t10650/)を御覧ください。

　というか、プリウスの駆動用バッテリ故障のせいで下書きとして書きかけのまま放置している記事が増えています。

　秋月電子通商で単体を買うよりもAmazon.co.jpで白浜町の販売店から購入したほうがセットで得そうなので数セット購入しました。複数購入するのは破壊する自信があるからです。壊れ方をみて後日組立手順を変更する可能性があります。
素の状態です。
裏面にポリイミドテープを貼り付けました。
このテープを貼ることで四隅のネジがテープに引っかかるためネジの脱落防止にもなります。
適当に放熱用グリスを塗りました。放熱というよりは横からの粉塵侵入防止です。
セットの値段を考えると高価なグリスは全くの不釣り合いなので怪しげな秋月のHY-1(T-04720)です。ざっと見た感じアンダーフィル材が見当たらないので導電性のチリによる故障防止です。写真CPU右側のシリコン？むき出しのようなチップも見えますがRFフロントエンド？らしくこのチップ周辺にグリスを塗るとWiFiの感度が下がるようです。写真CPU下側がアンテナのパターンになっているらしくここもポリイミドテープで養生しています。
CPUにヒートシンクを載せる前にケースを仮組みします。
ヒートシンクを載せてからケースを組み立てるとヒートシンクと上側のフタが干渉する可能性があります。
ヒートシンクの両面テープを万力で押さえつけます。
締めすぎると色々破壊すると思いますので加減が必要です。
最後に仮止めしていたネジを締めて完成です。
組んだ後になって写真を並べてみると万力で固定している間にネジを本締めしたほうが楽でした。何かインパクトドライバらしき物体が写り込んでいますけど、横着せずに手で回したほうが安全です。このキットで電動ドライバを使うかどうかはともかく、VESSELの片頭剛彩ビット(精密タイプ)は使えます。

　セットで付いていたOTGアダプターは一見不要そうに見えていましたけど実際に届いてみると使えそうに思えました。何も接続して無くても端子の保護と放熱、必要な場合はUSBメモリやイーサネットアダプタをつなげるのでつけっぱなしにすることにしました。

　ペン先がいい加減ダメになったようで誤動作するようになったため高価で先送りにし続けていた交換用ペン先を購入して硬化しました。新品でiPad/iPhone用スタイラスペン Su-Pen P201S-T9C （カーボン軸）購入(https://kadono.xsrv.jp/2016/11/15/3303)から2年ほど使っていました。
主にZE520KLで2年以上使っています。
上が新品、下が古くなったペン先。
　外観はあまり差がなく少しほつれているだけに見えますけど使い勝手はかなり違います。新品は画面上をスイスイと滑って誤動作もほとんど無く快適になりました。性能はいいと思いますけど、値段が高いのと強制的に2個セットで次の交換までに残る1個を紛失する可能性が高いのが難点です。

　一部で待望のマキタ充電式空気入れが新たに発売されました。これまでプリウスに載せていた改造済BENTECH 0311が古くなってきたのもありリプレースすることにしました。
手前MP100DZ+BL1040B、奥BENTECH 0311改(2013年購入)
　寸法はマキタの方が大きいですけど重さは軽いです。ホースをつなぐコネクタが結構な重量があるため一体型のほうが重さは有利です。
早速動作確認。
　時間を測ったわけではないですけど轟音とともに猛スピードで空気が入っていきます。感覚的にはBENTECH 0311比２倍速でしょうか。プッシュボタンでスタートするかと思いきやトリガを引いている間だけ動作します。コンプレッサやタンクから入れる引き金タイプの感覚？に近いかもしれませんが電動ドライバのようなプラスチックのトリガは違和感があります。空気圧調整ならば短時間でいいですけど、大きなタイヤを完全に抜けた状態から入れるのはきついかもしれません。自転車には速すぎるぐらいで空気圧設定を間違えると破裂しかねません。
マキタMP100DZの良い点は、
　☆マキタ10.8Vリチウムイオンバッテリ(BL1015, BL1040B)が使い回せる。
　○バッテリ使用なので電源コードを引き回す必要が無い。作業時間短縮。
　○空気を入れる速度が速い。作業時間短縮。
　○軽い。
イマイチな点は、
　△18Vのラインナップが(まだ？)無い。
　△ホース交換はたぶん無理。
　△ホースに振り回されて本体がコケる。軽さの反対。
　△トリガにセーフティロックが無い。持ち上げて次のタイヤへ移動するときに誤動作(騒音)。
　△液晶表示が今ひとつ見づらい。なぜか空気圧表示が5kPa刻み。アナログ派としてイマイチ。
　△猛烈な勢いで空気が入るためきちんと目標空気圧を設定する必要がある(適当に高めにすると危険)。速さの反対。
　△空気入れとしてはすこし大きく収納スペースを食う。
　×空気入れとして動作音が猛烈にうるさい。夜間の住宅地では使えないレベル。
手動ではなくコストを掛けてまで電動工具を使う理由として大きいのが省力化と作業時間短縮です。いろいろな空気入れを使ってきましたけど初日の印象ではかなり使い勝手がいい方だと思います。暫定採用としてマキタMP100DZをリアデッキ下に積載しBENTECH 0311改を降ろしました。
写真でよく見るとフィルムが残っていました。
　一応、液晶にバックライトは点いているようですけど屋外での使用時あまり見やすくはありません。追加で夜間も動作確認が必要なようです。
近況。空気圧上げました。
　ポンプはともかく、急激に気温が下がったためかGARIT GIZの空気圧保持能力がいまいちなのか思った以上にタイヤの空気圧が下がっていました。
　MP100DZについてはしばらく使ってみて気づいたことがありましたら再度編集・追記します。

Prius ODD Meter 487994km.

　このサイトで利用しているWordPress用テーマLuxeritasを3.5.5から3.5.6へアップデートしました。先日の3.5.5で高速化一括設定では設定が保存できなかった件は不具合だったようです。私は自分のミスと気づかず聞いてしまったのでよう公式サイトで指摘できませんでした。その他の細かい最適化や不具合修正が入ったようです。アップデート内容の詳細はLuxeritas 3.5.6 リリース(https://thk.kanzae.net/wp/release/t6645/)を御覧ください。

　WordPress 5対応のためLuxeritas 3.5.5へのアップデートを行いました。なぜか高速化一括設定からは設定が保存できなかった(次の3.5.6で直りました)ので、以下のようにLuxeritas -> CSS -> WordPressのブロックライブラリ用CSSを必要無い(読み込まない)に設定しました。というか、CSSなどのレイアウト指定のほうが本文よりもデータ容量を使い過ぎている気がします。

アップデートの詳細は開発元のLuxeritas 3.5.5 リリース(https://thk.kanzae.net/wp/release/t6628/)を見てください。

　12/5、v3.4.2～3.5.3.1でスマートフォンで見たときのフォントサイズがv3.4.1以前と変わるという不具合修正が入ったため、3.5.3.1はスキップして3.5.3→3.5.3.2へWPのテーマLuxeritasをアップデートするつもりがいつもどおりSFTPで上書きアップデートしたと思ったらできておらず全てのURLでエラーになりました。平日で見る暇がなかったので一旦3.5.3へ切り戻しました。

　12/6、3.5.3.4がリリースされた(3.5.3.3もスキップ)のでもう一度試したところやはりエラー。仕方がないので開発元に問い合わせたところ新旧バージョンが混ざって全てのファイルが正しく上書きされていないとの指摘を受けました。

　12/7、超絶忙しい年末の有給休暇(?)、勤務先の会社的には休暇なのですけどタスクリストが多く平日よりも忙しかったりします。昨日問い合わせた回答(開発元のコメント欄に残っています)をいただけたので上書きではなく一旦update用のテーマに切り替え、古いバージョンのテーマをWPから削除して新バージョン(3.5.3.4)を新規インストールしたところエラー無くアップデートができました。所用を片付けつつ更新情報をみたらWordPress5.0向け3.5.4が出ていたので初の同日2回アップデートを敢行しました。WordPress5.0への更新は切り戻しに備えた全データバックアップ後に行う予定です。

　テーマLuxeritasの詳細な変更内容については開発元のLuxeritas 3.5.4 リリース（WordPress 5 への対応）(https://thk.kanzae.net/wp/release/t6616/)を御覧ください。バージョンをさかのぼって変更点を確認できます。

　一応、バックアップ作業後にWordPress 5.0へのアップデートも行いました。評判が悪い新規エディタGutenbergよりはこれまでのClassic Editorの方が使いやすそうなのでプラグインでインストールして有効化しました。さらに5.0で未検証らしくWP Multibyte Patchが自動的に無効化されましたが日本語での検索などに影響が出るため手動で有効化しました。

　とりあえずBL1860Bまでのバッテリが一つは入ることまではわかっていましたけど、購入する前に今ひとつサイズがわからなかったので買ってみました。

　BL1860Bが２個ピッタリ入ります。これでキチキチですので内寸がイメージできると思います。BL1680Bを２個入れると他のものは入りません。ADP05を取り付けた場合はBL1040Bでも余裕がなくなります。BL1680B+ADP05が入るとBL1040BにはADP08(現物を持っていません)は付かないと思います。BL1015ならばひょっとしたら。

　実際にはバッテリの収納や運搬用としてではないのですけど使えそうです。あと、届いた製品はなぜかポーランド製でした。