2024年3月23日土曜日

MagSafe対応モバイルバッテリーを買ってみた。

 飛行機とか新幹線で移動するときはどうしてもiPhone 12 miniだと微妙にバッテリーが心もとないのでモバイルバッテリを持ち歩いたりしていたんだけど、もっと手軽に充電できるようにしたいということでMagSafe対応のモバイルバッテリを買ってみた。途中でバッテリ切れるとチケットとか切符、電子マネーもiPhoneなので大変だし…

PPCXM06A

公式のやつは高いのでそこそこのメーカーでそこそこの価格帯のやつを探してみたらBaseusのやつがアマゾンでセールをやっていたのでそちらにしてみた。3000円ぐらいで購入できた。

PPCXM06A
付属しているケーブルはType Cのケーブルだった。
今回は6000mAhのにしてみたので結構小型。これならiPhone 12 miniからはみ出さないかも。重さは140g。
PPCXM06A
裏面は20Wって書いてあるけど、MagSafeは7.5Wらしい。Type C接続だと20Wの充電器相当の出力が出る。
PPCXM06A
Type C接続時の対応電圧は端子のところに書いてあった。LEDは4つあってオレンジは電源インジケータ(点灯はTypeC、点滅はMagSafe)であとの3つは3段階のバッテリ残量表記っぽい。
ワイヤレス給電もType C出力もボタンを押さなくても自動で開始される。説明書には開始されない場合はボタンを押すように書いてあったけどiPhoneではどちらも自動で開始された。
何も繋いでいないときにボタンを押すとバッテリ残量が30秒間表示される。
iPhone 12 miniに装着すると薄いケースをつけた状態で横幅ぴったりだった。端子のところが少し出っ張る感じ。持った感じはいいと思う。

あとはパススルー充電に対応してるのでこのまま充電器に繋いでオッケーなのが便利。iPhoneのバッテリが100%になると自動で止まってくれてたし。充電するときにモバイルバッテリの上にiPhoneを乗っけて置けば勝手にどっちも100%になっていた。

ちなみにType C出力の方は例によって電流が流れなくなると自動で出力が止まるタイプなので超低消費電力なデバイスは30秒で勝手に電源が切れてしまう。ESP32-CAMにはちゃんと給電できたけど、Raspberry Pi Picoは消費電力が低すぎて30秒で自動で電源が切れてしまった。(スケッチによるかも?

2024年3月3日日曜日

ユピテルのレーダ探知機でFlashAirを使ってみた。

 この前購入したユピテルLS320をFlashAirでWiFi対応にしてみた。昔買ったFlashAir W-03が余っていたのでとりあえず試してみることに。購入時は16GB版を2500円ぐらいで買ったんだけど、生産終了してからだいぶ高くなっているらしい?

FlashAir W-03

しばらく放置していたのでFlashAirのアップデートからやってみた。アップデート前にとりあえずフォーマットをして全部データを消しておいた。
アップデートツールは日本語のサイトからは消えてしまったようなので、英語のサイトからダウンロードしてきた。ツール自体は日本語が使えたので指示通りに3回ぐらい安全な取り外しと抜き差しを繰り返してアップデートすることができた。
アップデート後はDCIMフォルダだけ自動で作成されていた。

そんでもってお次はレーダ探知機のSDカードからデータをコピー。LS320には8GBのmicroSDが使われていて、中身は全部で2GBぐらいのデータだった。コピーしたデータをFlashAirに書き込んだらレーダ探知機のSDカードスロットにFlashAirを差し込んで準備完了。

LS320

電源を入れてみるとちゃんと起動した。FlashAirが刺さっていると外部機器メニューのWLANのグレーアウトが外れて押せるようになる。ちなみに自動登録っていうボタンはWPSっぽい。とりあえず検索で家のWiFiに接続してみた。接続して再起動するとデフォルト設定で公開取締情報が自動でアップデートされるようになっていた。これは結構一瞬で終わるのでいいかも。

ちなみにWiFiのアクセスポイントは複数台登録できるみたい。iPhoneからのテザリングとかで3台登録してみたんだけど、最後に登録されたSSIDが一番優先度が高そうな感じがする。

家のWiFiが外まで届いてると良いんだろうけど現実的にはテザリングを使っての運用になりそうな感じ。でもテザリングをオンにした状態でエンジンをかけると自動でつながって公開取締情報をアップデートしてくれるのは便利かも。ずっとWiFiに繋がっていれば2時間おきにアップデートがないかチェックするらしい。

そういえば、レーダ探知機の固定はいつもジェルマットを使っていたんだけど、やっぱり加速時に倒れるのでなんかいいのがないかなと探していたら面ファスナーが良いという書き込みを見たので試してみることに。
オートバックスでエーモンの面ファスナー(No.7954)が110円で売っていたのでこれを半分にカットして貼り付けてみた。位置を確認したらダッシュボードにはふわふわの面を貼り付けて、台座には硬い方を貼り付けて装着。たしかに多少揺れるけどしっかりと固定できている。
とりあえずはこれで様子見をしてみよう。たしかに剥がすときは台座を両面テープでそのまま固定するよりは剥がしやすそう。

2024年3月2日土曜日

ユピテル LS320を買ってみた。

 友人にもらって使っていたGWR73sdが突然寒い日に音量ボタンを連打したような感じになったのを最後にタッチパネルが一切操作できなくなってしまって音量MAXの状態で固定された…

さすがにうるさいのと、もらってから9年も経っているので、ユピテルのLS320の中古を買ってみた。ちなみにA370とかGS303も同じ物らしい(付属品とか販売店が違う?)ので中古品探すときに紛らわしい。Z120Lはベースカラーが1色多いとかなんとか…


MSSS対応の新しい機種とかも良さそうだと思ったんだけど、レーダー探知機はとりあえずつけてるけど時計とGPSスピード計としてしか使っていないような気がしたので2022年の取り締まり情報が入ってるやつが出品されていたのでとりあえずこれでいいかなとか思ったり。前につけていたのも一切更新してなかったし…

OBD2アダプタも昔買ったOBD12-RDをそのまま使うことに。これはGWR51sdを買ったときに購入して、GWR73sdでも使っていたやつをそのまま流用。OBD12-RDとOBD12-Mの違いは本体に刺さる端子のL時の向きだけなのでそのまま刺さるっぽい。ただしOBD12-RDをLS320に接続するとケーブルが上に向いてしまうので電源スイッチが操作しにくい。さらに現行品のOBD12-MⅢになると使える機能が増えるみたいなんだけど、自分の車だとブレーキを踏むとアラームを解除する機能ぐらいしか変わらなかったのでOBD12-RDのままでいいかなとか思ったり。12年前に購入したのがそのまま使えるのはありがたい。

LS320

もはやOBD2メーターとしての使用をメインにしてもいいんじゃないかというかそうなりそう。ブースト計は純正のインフォメーションディスプレイと同じ最大1.6まであるし。

さらにこのレーダ探知機、WiFi対応SDカードを装着するとWifiに接続できる。ユピテルの無線LAN機能付SDカードはどうやら中身がTOSHIBAのFlashAirのようで、レーダ探知機に付属のSDカードの中身をFlashAirにコピーすると純正の無線LAN機能付SDカードと同じように使用できるらしい。
ちなみにユピテル純正Wifi対応SDカードのOP-WLSD16は技適番号(005-101348)がFlashAir W-04と同じなので中身はFlashAir W-04と思われる。そんでもって今はなき8GB版のユピテル OP-WLSD08は販売時期によって技適番号が違うみたいでW-02もしくはW-03の場合がある模様。

今はFlashAirも生産終了で高騰してるのでファイルコピーとかの手間を考えるとユピテルの純正品買ったほうが安いのかな。でもまぁ昔買ったW-03の16GBがあるので次回試してみようかな。

取り付けの粘着テープはとりあえずは以前使っていたセルスターのRO-105を洗ってつけてみようと思うんだけど、ユピテル純正は売り切れっぽいのでコムテックのZR-06がサイズ的にちょうど良さそう(40mmx40mm?)

LS320
以前TLで見かたんだけど、SDカード内のuser\logoフォルダの1.jpgを差し替えて、画面設定でオープニング画像を静止画に設定すると起動画面が変更できるみたい。ということでインターナビと同じ画像に設定してみた。

次回は非公式だけどFlashAir W-03を使ってWiFi対応化してみようかな。


2024年2月24日土曜日

µStreamerをラズパイZero Wで動かしてみた。

 ラズパイZero WにUSBカメラを繋いでリアルタイムストリーミングをやってみた。前回BBBlueで試したときかなり低遅延でCPU負荷も軽かったし、mjpg-streamerは更新されていないっぽいのでuStreamerを使ってみる。

久しぶりにRaspberry Pi Zero Wを引っ張り出してきたらOSのアップデートが大変そうだったので新規インストールすることに。

Raspberry Pi Imagerを使ってRaspberry Pi OS Lite(32bit)のBookwormをインストール。あらかじめWiFi設定やSSHの有効化ができるので最近は便利だなぁ。

dtoverlay=sdtweak,overclock_50=100

とりあえずsudo nano /boot/firmware/config.txtでSDカードオーバクロックだけ追加した。

ustreamerはapt-getからもインストールできたりするんだけど、バージョンが古いらしくフォーラムとかを見ていてもビルドを推奨されてるようだったのでビルドしてみた。GPUアクセラレーションのM2Mとかを使う場合もビルドしたバージョンじゃないと対応してないみたいだし。

sudo apt-get install libevent-dev libjpeg62-turbo-dev libbsd-dev git
git clone --depth=1 https://github.com/pikvm/ustreamer
cd ustreamer
make
sudo make install

とりあえずこんな感じで5分ぐらいでビルドできた。

インストールが終わったらカメラを接続してテスト。このuStreamerだとカメラ側のハードウェアエンコーダーをそのまま使えたりするので、カメラの情報を確認する。

v4l2-ctl --list-formats-ext

このコマンドで今接続してるカメラの対応してるフォーマットと解像度が一覧で見れる。

Logicool C270を接続してみたんだけど、このカメラの場合はYUYVとMotion-JPEGに対応していた。ということでuStreamerでMotion-JPEGを使って配信してみる。

ustreamer -m MJPEG -f 30 -s 0.0.0.0 -p 8080

これで640x480の30fpsでストリーミングを開始できる。ブラウザからhttp://ラズパイのIP:8080にアクセスして/streamをクリックするとストリーミングを確認することができる。

画面にストップウォッチとストリーミング映像を並べて表示してカメラでストップウォッチを撮影してスクリーンショットするという手法で遅延を測ってみた。

WiFiルータにラズパイZero Wの内蔵無線LAN経由で接続して廊下を挟んで隣の部屋のルータにつながっているけど遅延0.16秒ぐらいでサクサク動く。

ラズパイZero WでもustreamerのCPU使用率は5%ぐらいでほぼ負担がかかっていない。UVCのkworkerも3%ぐらいだし。カメラのハードウェアエンコーダに頼っているのでラズパイZero W側ので処理はHTMLでデータを流すだけだし。

ちなみにHD解像度でも試してみた。

ustreamer -m MJPEG -f 30 -s 0.0.0.0 -p 8080 -r 1280x720

これで1280x720のワイドな解像度で配信できる。

遅延も相変わらず約0.16秒。ワイドだとより視野角が増えてロボットに乗せるのには良さそう。ちなみにこの遅延、前回試したところによるとカメラ側の性能にも左右されるのでもっと速いカメラもあるかも?手持ちの中ではLogicoolのC270とC310が一番良かった。(C310のほうが0.01~0.02秒ぐらい速いことも)

このぐらいの低遅延で映像が送れてCPU側の負担も少ないので動く系のロボットとかで使えそう。他の処理にCPUとメモリを割り当てられるし。帯域は解像度によるけど、あんまり多くない。音声が送れないのが少し残念な点かもしれない。

FPVみたいな使い方をする場合はもう少し広角レンズがほしいかもしれない。BuffaloのBSW505MBKとかは120°な広角レンズを搭載しているっぽいけども、まずはC270のレンズ交換を試してみないとな…


2024年2月4日日曜日

パルワールドの鯖をLinuxで立てて落ちたら自動で再起動。

 最近友人とパルワールドをプレイしてるんだけど、Linux鯖で鯖を立てていても地味に落ちていて自分がいないときにみんながプレイできなくなるパターンがあったので自動で再起動するようにしてみた。
ダンジョンに入った瞬間に落ちたりすることが多いかも。

パルワールドの鯖の建て方は公式に載っているので割愛するけど、SteamCMDをHomeディレクトリに入れておいて、Homeディレクトリ内のpalworldディレクトリから起動するようにしている。

./steamcmd.sh +force_install_dir palworld +login anonymous +app_update 2394010 validate +quit

鯖のインストールもアップグレードもとりあえずはこの1行で行っている。

設定ファイルはこの場合で言う、palworld直下のDefaultPalWorldSettings.iniにデフォルトの設定が保存されるので、このファイルの中身をコピーして、./Pal/Saved/Config/LinuxServer/PalWorldSettings.iniの中身に貼り付けて必要な設定を変更する。とりあえずServerNameとServerPasswordだけ変更した。

そんでもってPalServer.shを起動すれば鯖が立ち上がるんだけど、4人ぐらいでプレイしていても2時間置きぐらいにセグったりして落ちているので、自分が先に寝たりすると友人が入れなかったりで(地味に夜通しでやってるやつも居るし)ということで対策してみた。

まえにどこかで見た手法何だけど、とりあえずいちばん簡単なシェルスクリプトでwhileを使って実装してみた。

#!/bin/bash
cd palworld
count=0
start_time=$(date +%s)
while :
do
  ./PalServer.sh
  echo "Server Down"
  end_time=$(date +%s)
  run_time=$(((end_time - start_time) / 60))
  count=$(expr $count + 1)
  echo $count
  echo $run_time
  sleep 10s
done

とりあえずこんな感じでhomeディレクトリにpal.shとかで保存して実行権限を与えれてScreenで実行してる。落ちた回数と稼働時間もコメントするようにしてあるけど、実際はwhileの中でPalServer.shを呼んでいるだけ。落ちると10秒待って何度でも実行される。

一応こんな感じで簡単に実装したんだけど今のところちゃんと動いてる。1日に5回ぐらい落ちてるけど…。

アップグレードが来たら自動で更新できるようにしたいなぁ

2024年2月3日土曜日

candleLightファームウェアをWindowsでビルドしてみた。

 candleLightはSTM32F0シリーズのUSB2CANとかで使えるファームウェアなんだけど、STM32G431とかでも使えるように改良してる人がいたのでWindowsでビルドしてみた。
というのもCANFDが使えるというからといって購入したCANable 2.0のデフォルトファームウェアでCANFDがうまく使えなかったので…

Windows側で必要なのはcmakeとmingw64(makeに使用)とgcc-arm-none-eabi-8-2019-q3-update-win32-sha2.exeだった。

とりあえずこれらをインストールして、gcc-arm-none-eabi-8-2019-q3-update-win32-sha2.exe以外は環境変数に入れて呼び出せるようにしておく。

pgreenlandさんのcandleLightブランチをとりあえずZipでダウンロードして展開。

cmakeフォルダの中のgcc-arm-none-eabi-8-2019-q3-update.cmakeをWindows用に少し変更

set(TOOLCHAIN gcc-arm-none-eabi-8-2019-q3-update)
set(CMAKE_MAKE_PROGRAM "C:/mingw64/bin/mingw32-make.exe")

set(TOOLCHAIN_BIN_DIR "C:/Program Files (x86)/GNU Tools ARM Embedded/8 2019-q3-update/bin")

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_C_COMPILER "${TOOLCHAIN_BIN_DIR}/arm-none-eabi-gcc.exe" CACHE INTERNAL "")
set(CMAKE_CXX_COMPILER "${TOOLCHAIN_BIN_DIR}/arm-none-eabi-g++.exe" CACHE INTERNAL "")

set(CMAKE_EXE_LINKER_FLAGS "" CACHE INTERNAL "")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

SET (CMAKE_C_COMPILER_WORKS 1)
SET (CMAKE_CXX_COMPILER_WORKS 1)

コマンドプロンプトでCMakeLists.txtがあるディレクトリに移動して

mkdir build
cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi-8-2019-q3-update.cmake -G "MinGW Makefiles"
make

こんな感じでビルドできた。WindowsでのポイントはcmakeがnmakeでVisualStudioの環境を作ってしまうようなデフォルト設定になっているので、-G "MinGW Makefiles"をつけるところ。一旦このオプションをつけないで実行してしまうとエラーが出てしまうのでbuildフォルダを削除してやり直し。一番ココでハマった…

というわけでCANable2_MKS_fw.binってのがSTM32G431用のバイナリファイル。しかもこれ、CANable2の公式ファームウェアではCAN FD対応していないらしいけどこっちは対応してるっぽい。

Windows上だとCangarooで使う場合はデフォルトでインストールされるWINUSBドライバでいいけども、Python-CANとかでgs_usbを使う場合はZadigとかでlibusbKに変更する必要がある。その時は(Interface0)が付いてる方だけど変更すること。(OptionのList All Deviceを有効にしないと出ないかも)

ファームウェアを書き込むときは前はdfu-utilでやっていたけど、ブラウザから書き込みができるWebUSB DFUを使うと便利かも。Vender IDは0x0483。




2024年1月26日金曜日

ブラーバ380jのバッテリの中身を入れ替えてみた。

 以前ブラーバのバッテリをEneloopに交換したんだけど、またエラーが出るようになってきたのでバッテリを交換してみた。今回も赤点滅7回のバッテリエラー。

前回はEneloopを使ったんだけど、Ni-MHバッテリが昔より高くなってる?8本パックって1900円ぐらいだったのに…
ということで代替を探してみると富士通のニッケル水素電池って実はEneloopとおなじくFDKで作られているということで実質おなじもの?スペックも同じだし。ということで富士通にしてみた。

6本必要なので2本パック4本パックにしてみた。これで1500円ぐらいだったので当時購入したEneloopと同じぐらいのお値段。
以前Eneloopに詰め替えたバッテリ、下に切り目をいれて抜き出したのでテープで貼っていたんだった。
バラバラにする前にヒューズとかジャンパの位置を確認しておく。写真を取っておいた。
6本まとめてテープで仮止めするのが意外と大変。形が崩れると入らなくなるし…
良い子は真似してはいけないダイレクトハンダ。一瞬で決めてる。今回は削らずにも結構ハンダが乗りやすかった。本当はスポット溶接しないとだめなんだけどね。
赤いケーブルは外から回すんだけど、間違って中に通してしまった…
やり変えるのも面倒なのでそのまま行くことに。
バッテリパックに戻して完成。

とりあえずこれでブラーバでもエラー7が出なくなったので正常に充電できてそう。純正バッテリと特性が違ったりするのでおすすめはしないけどEneloopで3年ちょい使えてたので今回も大丈夫だと信じたい。
純正じゃないのでやってみたい人は自己責任ですな。