エレクトロニクス

 1年以上酷使して容量も逼迫してきたNVMe SDD PX-128M8SeGNをPX-256M9PeGNへ置き換えることにしました。NVMe SSD本体はかなり値段が下がってきていますけど、実績がある放熱用のフィンAquacomputer kryoM.2は高価なままでコストダウンのため同等と思われる廉価品に置き換えました。PX-128M8SeGN+kryoM.2は分解せずそのまま実験機に移動させます。WDなど他のメジャーなメーカーではなくPLEXTORにしたのはPX-128M8SeGNが安定して使えていた実績を評価したのとPX-256M9PeGNの値段(ヒートシンクと合わせても1万円切った)からです。
 値段と性能(ヒートシンクのサイズ)を考えて新しい放熱器はAINEX AIF-08(https://www.ainex.jp/products/aif-08/)にしました。ただ、この汎用部品セットはPCI Expressカード上部がLEDで青く光ります。という余計な機能がついています。筐体内がギラギラに光って隙間から夜間に部屋に光が漏れるのが不気味で嫌なためGTX-1070と同様に実力行使でLEDを除去しました。
まずLEDを6個外します。
 接着剤は使われていないのでハンダを除去するだけでLEDを外せますが仕上がりを考えるとサンハヤトの特殊ハンダSMD-B05等を使用した方がきれいに外せます。もちろん、改造すると返品や保証は一切なくなります。が、値段や元から汎用品で動作保証などあってないようなものなので気にせず通電動作確認前に作業しました。
SSD本体を実装します。
 SSDを固定するナットをボードの裏からネジで止めなければならないのですけど組み立て説明図が付いていないため少し手間取りました。
ヒートシンクをネジで止めますが説明図が無いので少しパズルです。
裏面。
 組み立ててからPC本体に組み込みます。
PCI Expressのスロットに取り付け。
 AmazonのレビューにOption ROMがこのモデルにはないらしいのですけどPRIME Z370-Aに取り付けてWindows10をクリーンインストールして特に問題なく起動しました。Z370が十分新しいだけかもしれず古いM/Bに取り付ける場合は注意が必要かもしれません。ベンチマークを取るとPX-256M9PeGNの方が少し速いようです。といってもSeq Read 1000MB/s以上で差が分かる状況の方が稀かと。
 温度についてもベンチマーク中でも40℃未満で安定しているため大きなヒートシンクが役に立っているようです。

エレクトロニクス

 GW前半の悪天候下でプリウスに載せていたAE-GYSFDMAXBが走行中に頻繁にハングアップしました。ほぼ休憩のため停車するごとに電源を入れ直す有様で毎日コールドリセットコマンドを送ったり9600bpsに落としたり様々な対策を検討しましたけど、完全に出力停止を防ぐことができず、車載GPSロガーとして使うことは断念しました。最悪PhotoMOSで強制的に電源を再投入する対応策も考えはしたもののハングアップ判定までのログが欠損します。さらに電源ラインに余計な素子とプログラム制御を追加することによる信頼性の低下も懸念されるため他のモジュールに切り替えることにしました。据え置きのNTP Server用としてAE-GYSFDMAXBは2ヶ月以上連続稼働しているためこちらは継続使用します。

 次の候補として業務用や研究用で評価が高いスイスu-blox社製のICを組み込んだ
GPS/GLONASS受信機(Galileo/BeiDou可)u‐blox M8搭載 みちびき3機受信対応[GT-902PMGG]通販コードM-12905(http://akizukidenshi.com/catalog/g/gM-12905/)を急ぎで購入しました。取替は簡単でAE-GYSFDMAXBを取り付けていたヘッダにUARTの配線を接続するだけです。仕様上3.0V typ.となっていますけど販売店のWebにも・入出力信号レベル:3V(3.3Vデバイスで使用可)、非同期シリアル信号とありますように3.3V直結で動作に問題は無いようです。若干パワーロスはあるかも。
Raspberry Pi ZeroにGT-902PMGGを接続。試験運用なので熱収縮チューブは被せず仮止めです。
 あと、AE-GYSFDMAXBは1PPS信号の立ち下がりエッジを使用していましたがGT-902PMGGは立ち上がりエッジ(default)になるためそのまま動かすとntpdできっちり100msecのオフセットが生じるため/boot/config.txtを以下のように変更しました。

#dtoverlay=pps-gpio,gpiopin=18,assert_falling_edge=true
dtoverlay=pps-gpio,gpiopin=18

 u-blox M8の性能はさすがです。たぶん載っているCPUとソフトの性能がMediaTek MT3339/3333よりもかなり良さそう。特に山岳国道を中心に数100km走った限り一度も高度がマイナスにならずこれまでのどのGPSロガーよりも高性能で高度も記録できそうです。GT-600, AE-GYSFDMAXB, GYSFFMANCいずれも受信状況が悪化すると丹波高地の山の中なのになぜか海水面下になったり高度データが使い物にならないレベルで暴れます。

 あまりにユピテル社のレーダー探知機GWR103と補足衛星数や挙動が似ているため、検索したところユピテル社、日本の改良型レーダー探知機にu-blox QZSSテクノロジーを選択(https://www.u-blox.com/ja/yupiteru-selects-u-blox-qzss-technology-enhanced-radar-detector-japan)が見つかりました。思ったよりもずっと高性能なモジュールを積んでいたようです。

 このモジュールはかなり使い勝手が良さそうですけど完璧というわけでもなく設定がWindowsPCから専用ソフトでしかできなさそうという点が挙げられます。現状Raspberry Pi Zeroにつなげているモジュールは設定変更無しで電源を入れただけの状態で動作検証中です。また、覆道区間では追従しきれないのはMT3339と同様です。
GT-902(往復分)でも法面や川の中へ突っ込んでいます。
GT-600などではぶっ飛ぶ区間ですのでモジュールの性能というよりは受信状況(アンテナ位置で少しは?)が主要因と思います。法面補強部もそうなのですけど、強固な鉄骨鉄筋コンクリートと車体がLバンドを乱反射させるようです。

 GT-902PMGGについて触れているWebサイトは太陽誘電を含めたMediaTek系と比べて少ないのですけど分解したページがあるようです。
秋月のu-blox搭載GNSSモジュール(GT-902PMGG)を分解してみた(https://qiita.com/chromium_k/items/056f2ac72e81ca054185)

エレクトロニクス

 資金難から安物キーボードばかり使ってきました。しかし、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など)を切るにも良さそうです。