OpenBikeSensor records the echo stream. The rider marks the pass.

An OpenBikeSensor mounted below a bicycle saddle in Ulm, Germany. The outward-facing ultrasonic transducer measures lateral clearance, but the device still relies on the rider to identify which readings belong to overtaking vehicles. Photograph by Norbert Schulz, 2021, via Wikimedia Commons, CC BY-SA 4.0; resized from the original.[9]

A close pass lasts only a few seconds. By the time a cyclist can describe the car, the road width, the painted lane and the feeling of being squeezed, the vehicle is already ahead. OpenBikeSensor gives that fleeting event a durable trace—but it does so with an unusually honest division of labor. Ultrasonic sensors measure what is beside the bicycle. GPS records where the bicycle is. Firmware keeps the timing aligned. The rider presses a button to say, “an overtake just happened.”[1][3]

That last action is not a primitive feature waiting to be automated away. It is the boundary that makes the whole open-source project intelligible. A ranging sensor can hear an echo from a car, wall, pole, pedestrian or another bicycle. It cannot infer the traffic event from distance alone. OpenBikeSensor therefore records broadly and labels narrowly, preserving both the machine observation and the human judgment that gives it meaning.[1]

The project publishes far more than a gadget. Its repositories include firmware, circuit boards, printable enclosures, documentation and the code for a geospatial data portal.[2] That full chain matters now because researchers are using OpenBikeSensor data beyond one-off advocacy rides: recent studies have linked its observations to road characteristics, formalized collection protocols and made explicit decisions about filtering, GPS uncertainty and event definitions.[6][8] The attraction is not an infallible number. It is an inspectable route from street encounter to research claim.

Image context: the cover photograph shows the device in its working position below a saddle, not isolated on a bench. The black ultrasonic transducer faces into passing traffic; the cable leads toward the rider's display and button. Ulm City Hall remains in the background because this is civic measurement in a real street, not an abstract Internet of Things demo.[9]

Five facts have to meet before a dot reaches the map

OpenBikeSensor Classic centers on an ESP32 microcontroller, left- and right-facing ultrasonic ranging modules, GPS, a microSD card and a separate display/button unit. The project's parts list specifies the ESP32, two JSN-SR04T modules, GPS and SD-card hardware; the surrounding repositories publish the PCB and enclosure designs needed to reproduce the device.[2][10] Each part owns a different fact:

Layer	Fact it can establish	What it cannot establish alone
Ultrasonic ranging	An echo returned after a particular flight time	What object reflected it, or whether an overtake occurred
Rider button	The rider identified a recent moment as an overtake	The clearance without a corresponding sensor reading
GPS	The bicycle occupied an approximate place and time	The exact lane geometry or the passing vehicle's path
Track file	Measurements, metadata and confirmation are kept together	Whether the collection protocol was consistent
Portal	Many tracks can be processed, queried and mapped	Whether an apparent hotspot is causal, representative or safe

The device manual makes the measurement geometry concrete. Before a ride, the user enters an offset derived from the bicycle and sensor position, then checks the unit against open space and a wall. A wall within roughly 2.5 metres should produce a plausible reading after the configured offset; open space should show no distance. During a ride, the device measures on both sides and stores the track continuously.[1][11]

At the lowest level, distance begins as time. An ultrasonic pulse leaves the transducer, reflects from an object and returns as an echo. The track format preserves raw left and right echo durations in microseconds along with the conversion factor, while the already corrected Left and Right fields hold minimum distances in centimetres.[3] Keeping both representations is a strong open-data decision. A future parser can revisit the raw measurement instead of inheriting only a rounded display value.

It also makes calibration debt visible. A wrong offset shifts every nominal clearance. A sensor aimed slightly upward may see a different surface from one aligned with a vehicle body. A loose mount can change angle during a ride. Open source exposes the arithmetic, but the physical installation still determines what enters it.

The button supplies semantics, not distance

The ultrasonic modules run whether or not a vehicle is passing. The manual warns that their useful range contains buildings, posts, other cyclists and pedestrians as well as motor vehicles. When a rider recognizes an overtake, a short button press logs the event. If a usable left-side detection exists, the firmware links the confirmation to the retained minimum left-side reading from the recent window; the documentation allows roughly five seconds so nobody needs to reach for the control at the most dangerous instant.[1][3]

The CSV makes this relationship auditable. Its Confirmed field does not contain another distance. It contains the index of the raw measurement associated with the rider's confirmation. A typical file has about one row per second, but a row can repeat when more than one measurement is confirmed in the interval. Each row may also carry multiple timestamped left/right echo triplets, with the metadata declaring the maximum number and data-format version.[3]

This design creates a human-factor failure mode that aggregate maps can hide: selective pressing. If riders mark only frighteningly close passes and ignore comfortable ones, the resulting distribution is not a sample of all overtakes. The project explicitly instructs users to mark adequate-clearance passes too.[11] It also says personal safety comes first and that skipping a measurement is acceptable when pressing would distract from traffic.[1] Both statements are correct. Together they mean missing events are part of the method, not an inconvenience to be wished away.

An independent 2025 sensor project makes the tradeoff especially clear. SenseBike retained ultrasonic ranging but added a rear-oriented detection system so overtaking events could be triggered automatically; its authors contrast that arrangement with OpenBikeSensor's handlebar button.[7] Automation reduces rider workload, but it introduces a new classifier with its own geometry and false positives. OpenBikeSensor makes the opposite bargain: a person labels the event, while the file preserves enough timing evidence to inspect what was labeled.

The track is an audit trail, not a verdict

OpenBikeSensor's internal format begins with URL-encoded metadata, then a semicolon-delimited CSV header and data rows. Metadata records such things as firmware and data-format versions, handlebar offsets, the sensor type, privacy mode, device and track identifiers, and the maximum valid echo time. Parsers are told to ignore unknown metadata keys, an important compatibility rule for a format expected to evolve.[3]

The rows combine several scales of observation: date and time; latitude, longitude, altitude, course and speed; GPS quality fields such as HDOP and satellite count; battery level; minimum left and right distances; the confirmation index; privacy state; and the raw echo series.[3] This is richer than a map pin because it retains clues about why a pin might be wrong. A weak GPS fix, depleted battery, missing echo or unmatched confirmation can remain evidence during cleaning rather than disappearing behind a rendered symbol.

The portal maintains the same separation of concerns. Its API accepts track uploads and preserves the original track files. A worker transforms their observations and extracts relevant events. PostgreSQL with PostGIS holds the geospatial records; database functions generate vector tiles; a React frontend renders them with MapLibre.[5] Each boundary gives operators a place to ask a precise question: Was the ride uploaded? Was the raw file parsed? Which events survived processing? Did a database query aggregate them correctly? Did the map style merely make one class look more prominent?

Privacy also belongs in the measurement chain. The riding manual recommends beginning and ending away from home or configuring privacy zones.[1] The firmware configuration supports geographic areas with a radius and privacy behavior, but the same configuration may contain Wi-Fi credentials and a portal token in plain text, so its own documentation warns against casually sharing backups.[4] Publishing a cleaned map is therefore different from publishing the raw route or device configuration. A responsible group decides which layer collaborators actually need.

Research quality arrives after the sensor reading

Two independent studies show why inspectability matters more than the appearance of precision. A 2026 Austrian analysis joined georeferenced OpenBikeSensor events to national road data. The authors buffered road geometry by one metre to accommodate small GPS discrepancies and excluded lateral distances at or below 0.30 metres as likely misreadings or non-standard situations.[6] Neither step was performed by the ultrasonic transducer. They were analytical decisions, documented so another researcher could challenge or repeat them.

A 2024 Stuttgart study made different choices. One rider used consistent equipment and a defined riding protocol across about 790 kilometres, marking 4,081 overtaking manoeuvres on 14 routes. The paper states which passing situations counted, which were excluded, how the rider positioned the bicycle and how observation periods were scheduled.[8] Those details matter as much as the resulting distances. The sensor made thousands of events measurable; the protocol made comparisons defensible.

This is also the boundary on what an OpenBikeSensor event proves. It can support a claim that a rider marked an overtake and the device recorded a particular lateral echo near a GPS position. By itself it does not identify the vehicle, measure its speed, reconstruct the whole cross-section, establish driver intent or prove why the pass happened. Repeated events at one location can motivate investigation. They do not make road design, traffic volume and rider behavior interchangeable causes.

The most useful reading is therefore neither “citizen data is only anecdote” nor “a map settles the argument.” OpenBikeSensor makes an experience available for systematic scrutiny. Good research then adds a collection protocol, exclusions, uncertainty treatment, context and a claim no broader than the evidence.

A pilot should standardize people before scaling devices

OpenBikeSensor fits cycling groups, transport researchers and municipal partners willing to own both fieldwork and data stewardship. A solo builder can assemble and test a device, but a credible multi-rider pilot needs someone to maintain hardware revisions and calibration, someone to define the event protocol, and someone to protect, clean and interpret the resulting routes. Those roles may belong to the same small team; none disappears because the source code is public.

A defensible first deployment is deliberately limited:

Record the exact hardware revision, firmware version, sensor type, mounting position and offsets for every unit.
Run the documented open-space and wall checks before collection, then repeat them on a schedule and after any impact or remounting.[11]
Define an overtaking event in writing. Train riders to mark ordinary as well as close passes, while making clear that traffic attention always outranks data completeness.
Ride one known route with overlapping units or riders before expanding. Compare missing confirmations, implausible values, GPS placement and device-to-device differences.
Preserve raw files separately from processed exports, and version every cleaning rule. Do not silently delete readings simply because they weaken the expected story.
Configure privacy zones, restrict raw-route access and strip credentials from any shared configuration backup.[4]
Publish the method beside the result: who rode, when, how events were defined, what was excluded and what the map cannot show.

The project is a poor fit for somebody seeking a collision-warning appliance. A manual confirmation system cannot promise to alert a rider, identify a threat or capture every pass. It is also not a turnkey municipal evidence service; operating the portal requires a geospatial database, an identity service, track processing and the organizational capacity to govern public data.[5]

OpenBikeSensor succeeds by refusing to collapse those boundaries. Echo time is not yet clearance. Clearance is not yet an overtake. An overtake is not yet a hotspot. A hotspot is not yet an explanation. The project's open hardware, firmware, file format and portal let every transition be inspected. The small button on the handlebar is what keeps that chain honest: the machine records the street's echoes, and a person remains visible inside the evidence.

cronfeed.work