FRB実験ログ #68 — スマホは18Hzに気づけなかった。でも、揺れた瞬間は見えていた
はじめに
FRBではこれまで、ESP32 + 加速度センサーを用いて、釣り竿の振動を計測し、FFT解析やPeak Timeline、Fluxなどの表示を使って、ロッドごとの振動構造差分を見ようとしてきた。
しかし、ふと考えた。
スマホには加速度センサーが入っている。
では、スマホだけでFRB Liteの入口を作れないだろうか。
いきなりESP32や配線やDIYを要求すると、どうしても参加できる人が限られる。
でも、スマホなら多くの人が持っている。
つまり、
みんなのスマホを、実験装置に変えられるかもしれない。
そう考えて、普通のHTML + JavaScriptだけでスマホの加速度センサーを読み、振動を見るためのWebページを作ってみた。
今回作ったのが、
FRB Sensor Check Mobile
である。
URLはGitHub Pages上に配置し、スマホブラウザで開いて試せる形にした。
https://tamasub.github.io/FRB/tools/frb_sensor_check_mobile/
Android14 + Chrome で動作確認。
iphoneは動作対象だが未検証。Safariで許可が必要と思われる。
最初の狙い
最初に期待していたのは、かなり単純だった。
スマホの加速度センサーで、どこまで周波数が見えるのか？
特に気になっていたのは、100Hz、200Hz、300Hzといった領域だった。
ただし、ナイキスト周波数の問題がある。
ナイキスト周波数とは、サンプリングしたデータから元の信号を正確に再現できる最大の周波数の目安である。
基本的には、
ナイキスト周波数 = サンプリング周波数 ÷ 2
となる。
つまり、
100Hzを見るには、最低200Hzサンプリング
200Hzを見るには、最低400Hzサンプリング
300Hzを見るには、最低600Hzサンプリング
が必要になる。
スマホブラウザでそこまで出るとは思っていなかった。
しかし、実際にどこまで出るのかは試してみないと分からない。
見えたら事件。
見えなかったとしても、それは境界確認になる。
作ったWebページ
今回のWeb版では、最初はいくつかの窓を用意した。
・Time Series
・Band Timeline Investigate Scale
・Flux
・Spectrum Snapshot
・Peak Timeline
しかし実験を進める中で、スマホWeb版に必要なものと、そうでないものが見えてきた。
最終的には、情報を絞る方向にした。
現在の公開版では、主に以下を残している。
・Sensor Diagnostics
・Time Series
・Flux
・Peak Timeline
Spectrum Snapshotは廃止した。
Band Timeline Investigate Scaleも、スマホWeb Lite版では廃止した。
理由は単純である。
読者に見てほしいところを、端的に伝えたいからだ。
スマホWeb版はFRB本測定器ではない。
そのため、本丸ESP32版と同じ窓を全部載せればよいわけではなかった。
実効サンプリングHz
まず重要だったのは、スマホブラウザで実際に何Hz程度で加速度データが取得できるのかである。
手元のAndroid端末で試したところ、結果はだいたいこうだった。
UMIDIGI G9 5G：実効サンプリング 約57Hz
古いHuawei：実効サンプリング 約56Hz
端末が違っても、かなり近い値になった。
つまり、今回の環境では、スマホブラウザのDeviceMotionEvent経由で得られる加速度データは、おおむね56〜57Hz程度だった。
この場合、ナイキスト周波数は約28Hzになる。
ただし、スマホWeb版ではdtのばらつきもある。
dtとは、センサーデータが届いた間隔である。
たとえばdt平均が17ms前後なら、1秒あたり約58回程度データが届いているという意味になる。
ただし、dtばらつきが大きいと、周波数解析やPeak Timelineは不安定になりやすい。
つまり、理論上は28Hz程度まで見える可能性があるとしても、実用的にはもっと低めに見た方がよい。
ここでまず分かった。
スマホに加速度センサーはある。
しかし、ブラウザ経由で高周波振動が見えるとは限らない。
Time Seriesはよく見えた
今回の実験で、最も素直に反応したのはTime Seriesだった。
Time Seriesは、ブラウザ経由で取得したスマホ加速度データを、時間方向にそのまま眺めるための窓である。
厳密には、ESP32でセンサーから直接読むような完全な生データではない。
OSやブラウザを通って渡される加速度イベントである。
しかし、それでもスマホが大きく揺れた瞬間は、かなり分かりやすく見えた。
スマホを手で揺らす。
机をトントンする。
大きな衝撃を与える。
そうすると、Time Seriesははっきり反応した。
これはかなり大きな収穫だった。
スマホWeb版は、高周波的な細かい振動構造の分析には向かない。
しかし、
振動がデータとして見える瞬間
を体験する入口としては、かなり機能する。
つまり、スマホWeb版の勝ち筋は、精密な周波数解析ではなく、まずTime Seriesにあった。
Fluxは期待通りには動かなかった
Flux窓も残している。
ただし、今回のWeb版ではFluxも期待通りの反応にはならなかった。
FRB本測定器では、Fluxは重要な参考窓である。
ざっくり言えば、Fluxは振動状態がどれだけ変化したかを見るための窓である。
衝撃を与えた瞬間。
振動状態が急に変わった瞬間。
そういう変化に反応しやすい。
私は普段、ESP32 + 加速度センサーで取得したログを見るとき、Fluxをよく参考にしている。
しかし、スマホWeb版では事情が違った。
理由はいくつかある。
・実効サンプリングHzが低い
・dtにばらつきがある
・センサー取得がOSやブラウザに依存する
・スマホ本体が重い
・微細振動よりも手持ち揺れや筐体全体の低周波揺れに支配されやすい
その結果、FRB本測定器で期待するようなキレのあるFlux反応は出にくかった。
ただし、これはFluxが弱いという意味ではない。
Fluxが弱かったのではなく、
スマホWeb版という条件でFluxの限界が見えた。
これが今回の重要な実験エビデンスである。
スマホWeb版におけるFluxは、評価窓というより、FRB本丸で使っている「振動の変化を見る」という考え方を紹介しつつ、Web版の限界を確認するための窓として扱うのがよさそうである。
Peak Timelineも期待通りにはならなかった
今回の主役のひとつがPeak Timelineだった。
Peak Timelineでは、加速度センサーFFTから検出した主ピーク候補を時間方向に並べて表示する。
現在のWeb版では、主ピーク候補上位4つを青い点で表示している。
青● = 加速度センサーが実際に拾った主ピーク候補
点が大きく濃いほど強いピーク
期待Hzも入力できるようにした。
ただし、期待Hzは青●を出す条件ではない。
期待Hzは背景のガイド帯として表示するだけにした。
これは大事な設計変更だった。
最初は、期待Hz付近に入った点だけを青くする仕様にしていた。
しかし、それでは意味が混乱した。
何も入力していないのに青●が出るように見えたり、期待Hzだけを見てしまったりする。
そこで、Peak Timelineはあくまで、
スマホ加速度センサーが実際に拾った主ピークを見る窓
に戻した。
期待Hzは、人間が比較するための目安である。
18Hzを入力してみた
実験では、PC + Bluetoothスピーカー + N4P2を使い、答えが分かっている低周波入力をスマホに直接与えてみた。
たとえば18Hz付近を大きな音量で入力し、Peak Timeline上で青●が期待Hz帯に乗るかを見た。
期待としては、
18Hzを入れる
↓
Peak Timelineの青●が18Hz付近に出る
という流れだった。
しかし、実際にはそうならなかった。
青●は18Hz付近に安定して乗らず、0〜8Hz付近の低周波側に多く出た。
つまり、スマホは音源の周波数を見ていたのではない。
スマホは、音源の周波数ではなく、
スマホ本体が実際に揺れた周波数を見ていた。
これが今回の大きな発見だった。
18Hzを鳴らしたからといって、18Hzの振動がスマホ加速度センサーに主ピークとして届くとは限らない。
途中には、いろいろなものが挟まる。
Bluetoothスピーカー
N4P2
机
空気振動
手持ち状態
スマホ本体の重さ
スマホ筐体の揺れ方
その結果、入力した周波数とは別の低周波揺れに支配されてしまう。
これは失敗ではない。
むしろ、
スマホWeb版では、期待周波数を入れてもPeak Timelineにそのまま表示されるとは限らない
という境界が見えた、重要な実験エビデンスである。
もし表示できた人がいれば教えてほしい
今回、私の環境では、期待周波数をPeak Timelineに安定して表示することはできなかった。
しかし、これは端末、ブラウザ、スピーカー、固定方法、入力方法によって変わる可能性がある。
もし、あなたの環境で、
入力した期待周波数がPeak Timelineに表示できた
という結果が出たら、ぜひ教えてほしい。
たとえば、
・iPhoneではどうなるのか
・別のAndroidではどうなるのか
・スマホをスピーカーに直置きしたらどうなるのか
・別のBluetoothスピーカーではどうなるのか
・有線スピーカーではどうなるのか
こうした条件違いは、すべて実験データになる。
FRB Lite Mobileは、正解を配るためのものではない。
問いを配るためのものである。
スマホWeb版で見えたもの
今回の実験で、スマホWeb版の役割がかなりはっきりした。
まず、Time Seriesは非常によく反応した。
スマホを揺らしたり、机をトントンしたりすると、かなり分かりやすく波形が動く。
つまり、
揺れがデータに変わる瞬間
は体験できた。
一方で、FluxやPeak Timelineは、FRB本測定器で期待するような動きにはならなかった。
これは、スマホWeb版の限界である。
しかし、その限界もまた実験結果である。
Time Seriesでは揺れが見える。
Fluxでは本丸ほどキレよく反応しない。
Peak Timelineでは期待周波数がそのまま主ピークになるとは限らない。
この差分こそが、今回の収穫だった。
スマホWeb版は測定器ではない
今回の結論はこうである。
スマホWeb版は、ロッド感度を精密に測る測定器ではない。
少なくとも今回の実験では、スマホWeb版で高周波的な細かい振動構造を分析するのは厳しい。
100Hz、200Hz、300Hzはかなり難しい。
18Hz付近ですら、入力経路によっては主ピークとして安定して捕まえられなかった。
しかし、それで価値がないわけではない。
スマホWeb版は、
振動がデータになる瞬間を体験する入口
としては十分に意味がある。
スマホを揺らす。
机をトントンする。
Time Seriesが反応する。
その瞬間、読者は気づく。
あ、揺れってデータになるんだ。
これがFRB Lite Mobileの役割である。
スマホで体験の発火。市販センサーで一歩踏み込む。ESP32で本流に入る。
今回の実験を通じて、FRBの読者参加型導線も見えてきた。
スマホで体験の発火。
市販センサーで一歩踏み込む。
ESP32で本流に入る。
いきなりのESP32や配線は、どうしてもハードルが高い。
しかし、スマホなら0円で試せる。
スマホで振動がデータになる瞬間を体験する。
ただし、スマホでは見えないものがあることも知る。
その次に、市販Bluetooth加速度センサーやTWELITE、USB ADXL345などへ進む。
さらに本格的にやるなら、ESP32 + 加速度センサーへ入る。
この階段を作れれば、FRBは「研究者だけの測定器」ではなく、読者参加型の実験文化になれるかもしれない。
まとめ
今回の実験で分かったことを整理する。
・スマホWeb版で加速度センサーは読めた
・Android 2台では実効サンプリングは約56〜57Hzだった
・ナイキスト周波数は約28Hz程度
・dtばらつきがあり、FFTやPeak Timelineは安定しにくい
・Time Seriesは大きな揺れやトントンに非常によく反応した
・FluxはFRB本測定器ほど期待通りには動かなかった
・Peak Timelineも期待周波数をそのまま表示するものにはならなかった
・スマホは音源の周波数ではなく、自分自身が実際に揺れた周波数を見ていた
つまり、
スマホWeb版は、精密な周波数測定器ではない。
しかし、振動がデータになる瞬間を見せる体験の発火装置にはなる。
今回のFRB Sensor Check Mobileは、測定器として完成したわけではない。
むしろ、見えないものが見えた。
スマホに加速度センサーはある。
でも、見たい振動が見えるとは限らない。
だからこそ、問いが立ち上がる。
あなたのスマホでは、何が見えるだろうか。
あなたのスマホでは、何が見えないだろうか。
FRB Lite Mobileは、その問いを配るための入口である。
おわりに
スマホは18Hzを見なかった。
でも、揺れた瞬間は見えていた。
これは、かなり大きい。
まず、振動がデータに変わる瞬間を体験してもらえばいい。
そこから問いが生まれる。
自分のスマホではどうだろう？
市販bluetooth加速度センサーならどうだろう？
ESP32ならどこまで見えるのだろう？
この問いこそが、読者参加型FRBの入口になる。
測定器を配るのではない。
問いを配る。
そして、その問いに近づく階段を用意する。
スマホで体験の発火。
市販bluetooth加速度センサーで一歩踏み込む。
ESP32で本流に入る。
FRB Sensor Check Mobileは、その最初の一段である。
感度とは、人間が認識可能な構造として現れる振動の和音構造である。
感度とは、単純な振動の強さではない。
感度は分かち合って初めて本物になる。
FRBは、ロッドの「優劣」を決めるためではない。
「基準振動」を用いて、ロッドごとの振動構造差分を比較・可視化し、選択と体験共有のための共通言語を目指している。