Smartphones contain motion sensors that can expose acceleration, rotation rate, and device orientation. They are not replacements for calibrated instruments, but they can still be useful for exploratory experiments such as comparing vibration at several points on a desk, checking how motion changes with distance from a motor, or seeing the order in which an impact reaches different locations.

With multiple phones, the difficult part is not merely collecting numbers. The devices need a common time basis, consistent mounting, and a realistic understanding of differing sample rates. Wireless Sensor connects up to four phones directly to a PC over WebRTC and records them on a synchronized timeline. This guide focuses on setting up the measurement and interpreting the results responsibly.

What phone motion sensors can measure

Typical browser-accessible values include acceleration without gravity, acceleration including gravity, rotation rate, and device orientation. For vibration, acceleration magnitude is often useful; for tilt, orientation is more relevant; and for rotational motion, rotation rate is the better signal. Choose the signal based on the question you are trying to answer.

Sensor type, internal filtering, maximum sample rate, and even axis behavior can differ across devices, operating systems, and browsers. Two phones observing the same event may not report identical absolute values. Relative questions such as which location vibrates more or whether the same periodic pattern appears are usually a better starting point than treating the readings as calibrated measurements.

Time alignment and mounting matter when comparing several phones

When several locations are measured at once, even a small clock offset between phones can obscure impact order and waveform comparisons. Wireless Sensor estimates clock offset and drift from round trips over the WebRTC DataChannel, then maps each phone onto a shared receiver timeline. It also reports synchronization uncertainty, which should be considered when interpreting timing differences of only a few milliseconds.

Mounting is just as important. Holding a phone by hand introduces human motion into the signal, so attach or place each device as rigidly as practical on the desk, floor, structure, or machine being observed. If you want to compare individual X/Y/Z axes, align the device orientations. When mixed phone models make axis conventions less convenient, acceleration magnitude derived from all three axes is often easier to compare.

Vibration, impacts, and frequency need different views of the same data

For sustained vibration, a single instantaneous point is less informative than metrics over a window such as RMS, peak, and range. For example, placing one phone near a motor and another farther away lets you compare how the vibration level changes by location using the same type of summary metric.

For a short impact such as tapping a desk, threshold crossings can be grouped across phones to show which sensor detected the event first and how many milliseconds later it reached the others. For periodic motion, FFT can reveal dominant frequencies. The usable frequency range is still limited by the actual sensor sampling rate, so a phone cannot measure vibration frequencies beyond what its browser-level sampling supports.

Save enough context to make the recording useful later

Add markers such as “motor on,” “brake,” or “desk tap” while recording so that later waveform review still has context. Naming sensors and storing XYZ positions also makes it easier to connect Sensor 1 or Sensor 2 with the actual measurement location.

Use CSV when you want to analyze the numbers elsewhere, session JSON when you want to reopen the same recording and rebuild the analysis later, and a self-contained HTML report when you want to share a readable result. Measurements are processed in the receiver browser rather than uploaded to a Browser Kitty measurement server. Long multi-phone recordings consume more memory, so saving in shorter segments can be more practical.

Step by step

  1. Connect the PC or tablet and all sensor phones to the same Wi-Fi/LAN and open Wireless Sensor on both sides. Avoid guest Wi-Fi, VPNs, or networks with client isolation.
  2. Choose the receiver role on the PC and the sensor role on each phone, then pair them using QR codes or connection codes. Add up to four phones when needed.
  3. Grant motion-sensor permission on each phone and choose an experiment preset such as impact propagation, vibration comparison, or tilt comparison, or select a measurement mode manually.
  4. Mount each phone firmly at the location you want to observe. Optionally enter sensor names and XYZ positions, and align device orientation if individual axes will be compared.
  5. Start recording and add markers when meaningful events occur. Compare RMS/peak for vibration, arrival-time differences for impacts, and FFT results for periodic motion.
  6. After stopping, review synchronization quality and the analysis, then save CSV, session JSON, or a self-contained HTML report depending on how you will use the data.
Try it in Browser Kitty

Wireless Sensor

Connect up to four phones to a PC as wireless motion sensors for synchronized recording, comparison, impact detection, and FFT analysis.

Open toolView tool details

Tips and limitations

  • On a phone you have not tested before, use Device Check first to confirm that the browser exposes the required motion-sensor APIs.
  • If relative comparison matters more than absolute calibration, using the same phone model, browser, and transmission setting reduces avoidable differences between sensors.
  • Soft cases and hand-held devices can alter high-frequency motion or add extra movement, so treat mounting as part of the experimental setup.
  • During long recordings, screen lock or backgrounding can suspend browser sensor events, so keep display and power-management behavior in mind.

Frequently asked questions

Are the measurements sent to a Browser Kitty server?

No. Connection metadata is exchanged directly by QR code or copy/paste, and sensor samples travel to the connected peer over WebRTC DataChannel. The app also uses no signaling, STUN, or TURN server.

Can a phone provide precise vibration measurements by itself?

Phones can be useful for comparison, education, and exploratory experiments, but they are not substitutes for calibrated accelerometers or vibration meters. Sensor accuracy, internal processing, and sample rate vary by device, so absolute values should not be treated as precision measurements.

Do the PC and phones need to be on the same Wi-Fi?

Same-LAN use is the primary target. Because the app does not use STUN or TURN, cross-network connectivity is out of scope. Even on the same Wi-Fi, guest-network or client-isolation settings can block the connection.

Can it measure impact propagation speed?

If XYZ positions are entered, the app can combine straight-line distance with detected arrival-time differences to show an apparent propagation speed. Sampling intervals, mounting, and synchronization uncertainty affect the result, so this is best treated as exploratory comparison rather than precision material testing.

How high a frequency can the FFT show?

The limit depends on the actual sensor sample rate. At roughly 30 Hz sampling, the meaningful frequency range is generally about 15 Hz and below. Because sample rates differ by device, interpret FFT results together with the acquisition conditions.