Turn “it shakes at speed”
into a measurement.

No, and we are deliberate about that line. RidePulse is a measurement evidence tool, not a diagnoser. The app captures four-corner vibration, runs a 512-point FFT, and surfaces the dominant peak, harmonics, 4-corner RMS gap, speed band, and likely tire-order or driveshaft-order candidates. It then packages all of that into a one-page PDF, a CSV trace, and a sidecar JSON.

What it does not do is tell you "replace the right rear hub bearing." That kind of decision requires a hands-on inspection — wheel-off, torque checks, driveline play, tire teardown if needed — and that belongs to a qualified mechanic. Our job is to make that mechanic's job easier by handing them repeatable, time-stamped numbers instead of "it kind of shakes around 100 km/h."

Think of RidePulse the way a clinician thinks of an ECG: it captures a clean signal, highlights the suspicious patterns, and lets the human expert make the call.

A full RidePulse session uses four BLE accelerometers running at ±2 g full-scale and 200 Hz per-channel capture, mounted one at each suspension corner — FL (front-left), FR (front-right), RL (rear-left), RR (rear-right). Four corners is not a marketing choice; it is what makes the 4-corner RMS gap meaningful. With one sensor you can tell that the car shakes; with four, you can tell where it shakes worst, which is the first real diagnostic clue.

The four sensors come from RidePulse as a matched, pre-configured set — each one calibrated to the ±2 g / 200 Hz spec, labelled by corner (FL/FR/RL/RR), and ready to pair over BLE out of the box. There is no part-number hunting or compatibility guesswork: the sensors are tuned to the app and to one another, so a session reads the same on every kit.

Mounting is unglamorous but it decides signal quality. Rigid contact with the suspension knuckle or strut tower beats the cabin floor every time, because the cabin floor is already a low-pass filter that smears the very peaks you are trying to read. The kit ships with the magnets and VHB mounts for exactly this: clip each sensor to a clean steel surface or a known-flat boss near its corner, and keep the axis orientation consistent across all four. The in-app setup guide then walks you through the precise mounting point and orientation for each supported chassis, with photos. Get the mount solid and everything downstream — FFT peaks, the 4-corner RMS gap, order candidates — comes out sharper.

The current app is Android-native: Jetpack Compose, Material 3, minimum Android 11, and the BLE stack we build on top of is the standard Android one. We chose Android first for two practical reasons. The first is BLE flexibility — Android lets us hold four simultaneous low-latency BLE connections with relatively few platform restrictions, which is exactly what a four-corner capture needs. The second is hardware reach: in our target markets (Korea, North America, EU enthusiast scene, and shop floors) Android phones with USB-C and headphone jacks are easier for a shop to standardize on as "the diagnostic phone."

iOS is on the roadmap but explicitly after the Android beta closes and the measurement pipeline (FFT, harmonic detection, RPM correlation, report generation) is locked. Porting an unstable measurement spec to a second platform is how you end up with two half-broken apps instead of one good one.

If you only have an iPhone today, the practical path is to borrow or buy an inexpensive Android phone — even a refurbished mid-range device works fine, since the heavy lifting is BLE and FFT, not graphics. We will announce the iOS timeline once Android beta exits.

Every artifact RidePulse produces — the raw CSV trace, the sidecar JSON metadata, and the one-page PDF report — is written to your phone's app-private storage. Nothing is uploaded to a RidePulse server in the background. There is no telemetry of session contents, no "auto sync to cloud" toggle running silently, and no third-party analytics SDK reading your captures.

Data leaves the device only when you explicitly share it: the standard Android share sheet for sending the PDF to a mechanic over KakaoTalk, email, or messaging; or an explicit Export action that hands you the raw files. The default we picked was "the user always presses the share button," not "the user opts out of cloud upload."

Practical implications: if you uninstall the app without exporting, the captures are gone. If you reset the phone, the captures are gone. We are looking at an opt-in encrypted cloud backup for the production release, but it will always be off by default and the keys will stay with you. The vehicle vibration of your car is, in our view, your data — not ours, not your insurer's, not an ad network's.

A finished RidePulse session shows you four things on the same screen: the dominant peak (the strongest frequency in the 0–100 Hz FFT, with 0.39 Hz bin resolution), its harmonics (integer multiples — a wheel imbalance at 12 Hz typically shows a partner at 24 Hz), the 4-corner RMS gap (which corner is loudest in g-rms over the band), and the speed band in which the peak lives.

From those, the app derives candidate orders. Tire-order means the peak frequency tracks 1× (or 2×) the wheel rotation rate — so a peak at 12 Hz at 90 km/h on a typical wheel circumference is a textbook 1st-order tire candidate, often imbalance or a flat-spotted tire. Driveshaft-order means the peak tracks the propshaft rate, which on a typical RWD passenger car sits at a different speed-vs-frequency line. The app draws both lines on the speed-frequency chart and shows you which one your peak is hugging.

Two pieces of guidance from real testing: first, repeatability beats magnitude. A 0.08 g peak that comes back at the same frequency on three back-to-back runs is more diagnostic than a 0.20 g spike that only appeared once over a pothole. Second, the 4-corner gap is what tells you where — equal energy at all four corners is body-mode or driveline; one dominant corner is local (wheel, hub, brake rotor). The PDF report restates these rules in plain language so the mechanic on the receiving end has the same context you do.

The beta is free. You install the RidePulse beta on an Android 11+ phone, pair our four BLE sensors, and you are running. We are not metering captures, locking the PDF behind a paywall, or rate-limiting features during the beta period. The deal is simple: you get the app at no cost, we get a real-world dataset to harden the measurement pipeline against vehicles, road surfaces, and shop conditions we have not yet seen.

Production pricing is TBD and we are saying that on purpose. Until we have closed-loop validation across more chassis families, naming a number would be guessing. Our working sketch is a free tier for occasional drivers (limited sessions per month, full functionality), a paid tier for enthusiasts and shops with unlimited sessions and report branding, and a separate shop/fleet tier for multi-vehicle workflows. Beta participants will be offered grandfathered terms when production launches.

To join: there is a beta sign-up form on this site. Field testing access is also extended on request to mechanics, NVH engineers, and instructors who can give us structured feedback. Approved testers get access to the beta build.

The beta is built around mainstream passenger vehicles — front-engine sedans, hatches, and crossovers in rear-, front-, and all-wheel-drive layouts. Sixty-plus chassis profiles ship with the app — a curated subset of the catalog of 200+ make-model profiles — refined against beta sessions across German, Korean, Japanese, and American cars, and every release passes a regression suite covering that fleet before it ships.

For other vehicles the app exposes an auto-tune flow: you tell it the wheel circumference (or tire size) and the final drive ratio, and the speed-frequency lines re-derive themselves. That covers the large majority of front-engine, rear- or all-wheel-drive passenger cars. The auto-tune flow has been validated against German sedans, Korean SUVs, Japanese hatches, and a couple of pickup trucks, and the patterns hold across that mix.

EVs are supported: tire-order behavior is essentially identical (mass and rotation are mass and rotation), and instead of engine-order content you get a clean motor-order line that the app does read as EM1 — provided you give it an RPM source that represents motor speed. Motorcycles and single-track vehicles fall outside the four-corner geometry RidePulse is built around, so we do not currently support them. Heavy and commercial trucks are on the roadmap — but as a separate, multi-sensor solution. They carry more axles than a passenger car, so they need more measurement points than four, and Bluetooth's cap on simultaneous connections rules out simply adding more BLE sensors. That class will get a dedicated, higher-channel sensor setup built for more axles, rather than being forced into the 4-corner BLE rig.

The ±2 g full-scale and 200 Hz sample-rate choices are matched to passenger-vehicle vibration content. On-road suspension corners almost never see sustained accelerations beyond ±1.5 g; widening the range to ±8 g would simply waste ADC resolution on signal we do not generate. At ±2 g, a 16-bit MEMS accelerometer gives roughly 60 μg per LSB, which is comfortably below the noise floor of the road itself.

200 Hz per channel gives a Nyquist of 100 Hz, and that is exactly the upper edge we publish for the FFT. Tire-order, driveshaft-order, brake-judder, and most NVH harmonics drivers actually feel live below 50 Hz; engine-order content above idle (typically 800–7000 RPM, i.e. 13–117 Hz at 1st order) is also covered up to 100 Hz. With a 512-point FFT at 200 Hz, bin resolution lands at 0.39 Hz, which is fine enough to distinguish a 12.1 Hz wheel-imbalance peak from a 12.5 Hz neighbour.

Where this rig misses things is the obvious flip side: high-frequency NVH (gear whine into the kHz range, very high-order brake squeal, tire tread roar) is outside our band, and very low-amplitude phenomena buried under road-input noise need many runs to surface. We are explicit about both limits in the report. If your symptom is a 4 kHz whine, RidePulse is the wrong tool — a microphone-based NVH analyser is the right one. If your symptom is a 14 Hz steering-wheel shimmy at 110 km/h, RidePulse is well inside its design envelope.

The honest answer: a session involves a phone, four BLE devices, and a moving car, and that combination requires care. RidePulse is designed so that the driver does not need to interact with the phone during the run. You mount the sensors before you set off, start the session at a stop with the parking brake on, and end it the same way. While the car is moving the screen can stay locked; capture continues in the background.

If you have a passenger, the cleanest workflow is "driver drives, passenger holds the phone." The passenger can watch the live waterfall and mark events ("potholes here", "shimmy starts now") without taking the driver's attention. If you are alone, dock the phone in a fixed cradle, glance only at speed, and treat any in-app interaction as a stop-the-car action — exactly as you would with any other phone usage behind the wheel.

Two practical guardrails. First, do your test runs on a road and at a speed where the symptom actually appears, but pick a route where you can safely hold a steady speed for 20–30 seconds — that is what the speed-band correlation needs. A closed track, an empty industrial road, or a quiet expressway lane between exits all work; congested city traffic does not. Second, do not chase the FFT live: trust the post-session report instead of staring at peaks while you drive. The data is there when you stop.

Yes, and shops are one of the audiences we are explicitly building toward. The current beta already covers the single-bay case nicely: a customer comes in saying "something rumbles around 90 km/h," the technician spends ten minutes mounting four sensors, runs a structured test loop (steady-speed sweeps, coast-down, road-input control), and walks back with a one-page PDF that pins the symptom to a frequency, a corner, and a candidate order. The PDF goes into the customer's file and clarifies the "is this real or am I imagining it" conversation in seconds.

For multi-vehicle / fleet workflows we are working on a shop-tier featureset for the production release: per-vehicle history (so you can A/B a session before and after a balance job on the same VIN), branded PDF reports with the shop name and logo, batch export to a shop directory or shared drive, and a lightweight roster view that lists which vehicles have an open vibration ticket. White-label theming and an API for shop management software (Mitchell 1, Shopmonkey, Korean equivalents) are on the roadmap, with priorities driven by which shops sign up first.

If you want to be in that prioritization conversation, the easiest path is to join the beta and tell us how you currently document NVH complaints. Partnerships and bulk hardware sourcing — for example, a four-sensor kit pre-validated against the app — are open topics. Use the beta sign-up form on this site and tell us you run a shop when we follow up — that routes you to the shop track.

RPM matters a lot, because some peaks track wheel speed (tire-order, driveshaft-order at the wheel side) and others track engine speed (engine-order: combustion firing pulses, accessory drives, balance shafts). Without RPM you can still see the peak; with RPM you can tell whether it is locked to the wheels or to the crankshaft, and that distinction often decides whether the conversation goes to the tire shop or to the engine bay.

RidePulse brings RPM in from two sources. The first is OBD-II via a Bluetooth ELM327 dongle, which gives you a clean reported RPM signal from the ECU at roughly 5–10 Hz. The second is microphone-based engine-order detection: the app listens to the cabin mic, picks up the firing harmonic, and back-solves the RPM. The mic path is the one we invested the most in, and a Manual Engine RPM input is also available for cases where neither OBD nor the mic is reliable. The selection logic is deliberately plain: when a fresh OBD reading is available the app uses it, otherwise it falls back to the microphone estimate — and Manual RPM stays available as the explicit override (see How the measurement works above). The detection respects cylinder count too, with an idle band that auto-adapts to 3, 4, 6, and 8-cylinder engines.

Practical setup advice: if your car has an OBD port (anything 1996+ in the US, mid-2000s+ in Korea/EU), an ELM327 dongle is the lowest-friction option and gives the cleanest data. If you do not want to use the OBD path — leased car, classic, racing application — let the mic detection run, and use Manual RPM as the fallback when the engine bay is unusually noisy or has aftermarket induction that shifts the harmonic content.

No, and we want to be straight about why. Vibration evidence narrows the suspect list. It does not — by itself — pick a part out of that list. A 1st-order tire-side peak with the FR corner dominant points at the front-right wheel assembly: imbalance, a flat-spotted tire, a bent rim, a worn hub bearing, a sticking caliper warming a rotor, even an alignment shift that loaded the corner asymmetrically. Vibration cannot tell those apart. A wheel-off inspection can, in about five minutes.

The category of products that promise "replace this part" from a phone signal alone tend to fail in two ways. They overfit to the cars they trained on (your make/model is just close enough to confuse the classifier), and they push consumers toward expensive replacements that the underlying data never actually justified. We have watched that pattern in adjacent industries and explicitly do not want to be that product. The PDF report wording reflects this: it says "1st-order tire candidate, FR dominant" and stops there. The next sentence belongs to a mechanic standing next to the car.

What we do aim to deliver, and what the closed-loop beta is collecting data toward, is shorter the-mechanic-confirmed-X stories with each release. Every time a beta tester tells us "the report said FR 1st-order, mechanic found a bent rim, here are photos," that becomes a structured datapoint we can use to tighten ranking — not to skip the mechanic, but to make sure the right candidate is at the top of the suspect list when they walk up to the car.