Help with what we cannot see.
A cyclist behind a van. Braking two cars ahead. Combine nearby radio cues with the sensing vehicles already use.
V2X / PRIVACY / FREEDOM OF MOVEMENT
Safer roads.
Freedom intact.
Simple enough to spread.
Private enough to earn trust.
I want an open, voluntary safety system that people can afford and trust. Simple equipment lowers the effort to join; privacy and owner control give people reasons to keep it enabled. Wider participation could make useful warnings available in more encounters—including hazards involving people with no equipment.
Start with supported phones, useful accessories and suitable hardware already in vehicles. Share what helps with the nearby hazard. Build safety people choose while preserving their freedom to travel.
THE DESIGN GOALSAFETY + FREEDOM
A CONSTRUCTIVE ALTERNATIVE
Build the useful alternative early.
My NearSense and Echo-V2X notes return to one idea: make the useful safety layer simple enough to spread, and design its privacy and owner control from the beginning. An open specification and reference devices would let people build, compare and improve it.
Keep the owner in control.
The supplementary layer should be switchable. Losing an optional warning must not turn into losing permission to use the vehicle.
Make participation easy.
A small beacon should have a useful role. More capable equipment can add sensing and warnings without making everyone buy a complex system.
These are the requirements I am advocating, not claims that Echo-V2X is a finished standard or that any specific hardware already meets them.
SIMPLICITY + PRIVACY → PARTICIPATION → SAFETY
Make safety easy to choose.
Give people reasons to trust it.
A safety system's value depends on both the help it provides in an encounter and how often that help is available. My proposal is to make useful cooperation affordable, easy to keep running and respectful of the people using it. Privacy and owner control belong in the safety strategy: people concerned about tracking need reasons to participate too.
Easy to use.
Simple equipment, existing hardware, modest power needs and little upkeep lower the practical barriers.
Worth trusting.
Minimal disclosure, no required travel account and the owner's ability to switch it off address reasons people may avoid a connected safety system.
- 01More willing participants
Low effort and confidence in privacy give people reasons to join and stay enabled.
- 02More useful coverage
More encounters can benefit. Shared sensing can also reveal road users with no radio.
- 03More chances to prevent harm
Timely, reliable cues could help people and vehicles respond to hazards sooner.
Simplicity and privacy can reinforce safety. A modest, effective aid that many people willingly use could deliver more total benefit than a more capable system that few adopt or leave enabled. The useful minimum should stay accessible while capable vehicles add optional shared sensing and cooperative features.
This is the causal argument to test. Measure how price, privacy, upkeep and warning quality affect continued use, then measure safety outcomes at those participation levels. The simplest radio must still meet the task's reliability, timing and security requirements; wider use cannot rescue misleading warnings.
REASONS TO CHOOSE IT
A benefit people can recognize.
- Be easier to notice. A small beacon could help an equipped vehicle recognize that a cyclist or pedestrian is nearby.
- Receive something useful. A vehicle that queries nearby devices can also respond to them, contributing to reciprocal awareness.
- Fit ordinary life. Explore integration into a bicycle light or other useful accessory. Aim for no subscription, no account and little upkeep.
- Earn continued use. Prioritize relevant cues, understandable controls and few nuisance alerts. Let people switch it off.
IIHS observed higher activation rates with less intrusive alert modes. That supports investigating useful, tolerable warnings; it does not establish who would adopt this proposal. [10]
START SMALL / USE WHAT EXISTS
Start with what people already own.
The first version could be an app. The next could disappear into a bike light. A capable vehicle could contribute its existing sensors. Explore these paths together so participation does not depend on buying a new car—or even a new device.
A first step in your pocket.
Prototype a simple beacon and nearby message exchange on supported phones. A phone could give an older car, cyclist or pedestrian a way to participate using hardware they already carry.
Prove first: reliable behavior with the screen locked, the app in the background and the phone in a pocket or vehicle. A phone app is a starting point to test, not a validated safety device.
Built into something useful.
A bike light, helmet, mobility aid or powered car accessory could include the same small radio role. Reuse its enclosure and power where practical, and make participation easy to enable and maintain.
Earn continued use: useful cues, little setup and low upkeep. The owner chooses; no travel account or subscription should be needed.
Put onboard hardware to work.
Manufacturers could explore suitable radios, computers and cameras already in vehicles such as Teslas. Where supported, software integration could add cooperation; other vehicles could use a small accessory.
Check the actual vehicle: radio support and access to perception vary. Existing Bluetooth does not prove that a software update—or a third-party app—can implement this system.
A RADIO CANDIDATE
Explore long-range Bluetooth.
Bluetooth LE Coded PHY can extend communication range by trading data rate for more robust reception. It is optional: both ends and their software need to support the required operation. Longer message reach does not mean accurate distance measurement. Measure performance in traffic before choosing the radio. [12]
What a phone-first prototype needs to establish
Check each phone's radio capabilities and operating-system support. Android provides checks for coded-PHY support, and both Android and iOS have specific rules for Bluetooth work in the background. Test permissions, battery use, timing and missed messages on the intended devices; support cannot be inferred from a Bluetooth version label alone. [13]
A native app could test local participation without requiring an account or a cloud trip history. That does not give it access to a car's cameras, braking data or safety controls. Tesla's public vehicle-command tools demonstrate some Bluetooth connectivity, not an open interface to the vehicle's perception system; that richer path needs manufacturer-supported integration. [14]
LOWER THE BARRIER / BROADEN PARTICIPATION
A small radio. A useful role.
Start with hardware people already own. A compatible phone app could be an early prototype; a light, helmet or inexpensive accessory could make participation easier. These roles describe what the system does, not a new gadget everyone must buy.
FUNCTIONAL BUILDING BLOCKSCONCEPT, NOT A PRODUCT
THE SIMPLEST ENTRY POINT
Help an equipped vehicle notice you.
Start by testing a compatible phone app as a responder for a pedestrian, cyclist or wheelchair user. Later, integrate that role into a light, helmet or accessory. A short reply to a nearby query need not describe the whole road scene.
- Protocol role
- Beacon responder
- Equipment to explore
- A phone’s existing radio, processor, antenna and battery where the hardware and operating system support the prototype; otherwise a simple responder in an accessory.
- Personal benefit
- Another opportunity for equipped vehicles to notice your presence, including when you are hard to see.
- Keep it simple
- No screen or warning interface is needed for this basic role. Test phone background behavior and energy use; carrying a phone alone does not establish dependable operation or ranging.
One shared protocol, different capabilities. A beacon responds. A vehicle can query and respond. Perception from cameras, lidar or radar is an optional extra—not a requirement for joining.
What still needs engineering?
These are proposed roles and prototype directions, not a finalized radio standard. A simple long-range Bluetooth approach is worth prototyping. Bluetooth LE Coded PHY, often called Bluetooth LE Long Range, is an optional capability: both ends need compatible hardware, and the operating systems must expose the required behavior. An existing Bluetooth label does not establish that support.
Longer communication range and accurate distance measurement are separate capabilities. Sending a short message does not establish dependable ranging. Bluetooth Channel Sounding may require newer hardware. Compare suitable Bluetooth, Wi-Fi or other local radios against the actual task rather than assuming a software update is sufficient.
Range, timing, congestion, obstructions, energy use, interoperability and resistance to misleading signals all need measurement. Vehicle warnings need an appropriate interface and validation. Simpler equipment is valuable only if it performs its intended task reliably.
Direct local communication is a design choice shared with other approaches, including direct C-V2X links. The proposal's goal is a useful, accessible and privacy-conscious system; it does not claim that local communication alone is unique or prevents tracking.
THE ENGINEERING CASE
Enough information to notice a hazard.
Less information to follow a person.
My hypothesis is that a small, local exchange can add useful awareness beyond a vehicle's own view, without routinely broadcasting a globally referenced journey. The engineering challenge is to preserve that useful margin while measuring what we lose in precision, trust and reliability.
FIRST SAFETY REQUIREMENT
Notice a plausible hidden hazard early enough to help.
Start with a cyclist behind a van or abrupt braking beyond the immediately visible car. A useful cue must arrive before ordinary perception resolves the situation, with uncertainty small enough to change attention or preparation. A late or ambiguous cue may add nothing. A false warning can distract or provoke a bad response.
Compare each case against the same vehicle using only its own sensors. Measure extra warning time, missed hazards and nuisance alerts. The initial role is supplemental awareness; a radio reply alone should not authorize braking, closer following or a claim that the road is clear.
One encounter, five jobs.
- 01 / QUERY
Ask nearby.
An equipped vehicle requests a local response when useful. Scheduling and congestion control must prevent repeated queries from overwhelming the channel.
- 02 / REPLY
Declare a little.
A willing responder returns its broad type and a temporary encounter handle. These are claims, not proof of identity or position.
- 03 / MEASURE
Estimate locally.
The receiver obtains whatever range or direction its hardware supports. Receiving a packet does not itself provide dependable distance.
- 04 / COMBINE
Check the scene.
Compare radio cues with visible objects and plausible hidden regions. Retain competing interpretations when association is uncertain.
- 05 / EXPIRE
End the encounter.
Discard stale observations and short-lived associations. Local deletion cannot erase copies made by another listener.
Walk through the proposed message exchange
A report about someone else is a different message.
An equipped bus may see a car or cyclist that your car cannot. A relayed observation would describe that object relative to the bus, with uncertainty and age. The hidden person needs no beacon. This extends the potential benefit to nonparticipants, but their consent and privacy still matter.
Measuring the bus's radio does not verify its report about the cyclist. The receiver also needs the bus's relative position and orientation to translate the observation. Distance plus the bus's own heading alone does not determine where the bus is around the receiver. Bearing, reliable sensor association or other positioning evidence is still needed. A second report helps only if it is sufficiently independent.
Proposed information, and why each part would exist
These are purposes to specify and test, not an interoperable packet format. Bit lengths, update rates, expiry periods and security fields remain unsettled.
- Query
- Request a nearby response and define its scope. Establish scheduling, freshness and reply matching without creating a durable interrogator identity.
- Responder description
- Broad object type and temporary handle to distinguish concurrent encounters. The handle is not an owner ID, authentication mechanism or anonymity guarantee.
- Local measurement
- Estimated range or bearing, observation time and uncertainty. Keep receiver-derived measurements distinct from the sender's assertions.
- Optional richer report
- Explore motion or hazard information only where its added usefulness justifies its bandwidth and tracking exposure. Do not make it a requirement for a simple beacon.
- Relayed observation
- Reporter reference, object type, relative bearing/range, observation age, uncertainty and a short-lived reporter-local track handle. No raw image is required for the illustrated cue.
A developing design, with a consistent purpose.
My 2024 NearSense notes explored rough distance, broad object types, temporary identifiers and on-demand replies, assisted by cameras. Later Echo-V2X notes explore richer optional information. An August 2026 collaborative design session considered time-of-flight ranging and separate relative reports about pedestrians or cyclists without transponders; it rejected truncated GPS coordinates.
These are evolving research directions, not one finished specification. Earlier RSSI ideas do not establish the feasibility of later time-of-flight designs. The common goal is useful local cooperation that remains optional and resists becoming a travel identity system.
COMPARE THE SAME SAFETY TASK
What would make this preferable?
Established approaches address real safety and security needs. C-V2X's direct PC5 mode can work independently of cellular-network coverage, so local communication is already an available design choice. [15] Basic safety messages describe motion and position; SCMS supplies pseudonym credentials and misbehavior handling. Collective perception also considers objects without their own V2X equipment. The comparison must include these strengths. [1] [2] [9]
Compare the whole design, not just the radio. DSRC and C-V2X provide communication; message contents, security credentials, retention and authority over the vehicle are further design choices. Existing DSRC platooning research and C-V2X's LTE/5G development also address more demanding cooperative applications. My proposed minimum serves a narrower first task; it is not yet an interoperable replacement for those systems. [15] [16]
| Dimension | Own sensors only | Direct V2X with richer safety messages | This local, minimal proposal |
|---|---|---|---|
| Useful information | Independent observations within sensor coverage. | Other vehicles' motion and position; optional shared perception. | Nearby presence, measured proximity and selected observations. |
| Blind spots & limits | Occlusion can hide a hazard. | Can describe hidden participants, subject to reception and message quality. | May flag a hidden hazard; coarse cues may not resolve its lane or trajectory. |
| Trust | Depends on sensing and interpretation. | Credentials support authentication and revocation; signed claims still need plausibility checks. | Physical consistency checks help; authentication, replay and abuse defenses remain unresolved. |
| Partial participation | Can see unequipped road users directly. | Direct messages need equipped peers; shared perception can include others. | Simple responders and optional relays aim to widen useful encounters. |
| Reasons to participate | No extra radio to carry; sensing capability depends on the vehicle. | Richer safety functions offer value. Equipment cost, usability and confidence in privacy influence acceptance. | Target inexpensive, useful devices with low upkeep and credible privacy. Test whether that earns wider, continued voluntary use. |
| Information exposure | No safety radio broadcast required; recordings and uploads depend on implementation. | Richer broadcasts need privacy protections; changing credentials do not defeat continuous observation. | Fewer disclosed fields is the aim; radio observation and sensor correlation may still enable tracking. |
| Owner independence | Depends on the vehicle's controls and service design. | Direct exchange need not require a live network. Credential revocation does not inherently disable driving. | Make voluntary use, no central permission to travel and independent ordinary operation explicit requirements. |
| Road trains | Can react to visible traffic; lacks radio reports from farther ahead. | Richer exchanges can support cooperative following, with a separately validated controller. | Explore an earlier cue about braking two cars ahead. Automated close following requires a richer, separately validated application. |
The proposed advantage combines useful warning value, affordable equipment and trust earned through privacy and owner control. Together they could increase willing participation and extend the benefit to more encounters. Compare both equal-participation performance and realistic voluntary uptake: measure what richer messages add, what the minimum loses, and whether reduced disclosure and wider use produce a better overall result.
EVIDENCE / OCTOBER 2026
What has been explored—and what has been demonstrated?
| Record and status | What it establishes |
|---|---|
| August 2024 Reported qualitative simulation | My “V2v, v2x” note reports that camera/map association narrowed possible locations of obstructed beacons, even with simple RSSI distance. No runnable model, setup or quantitative results accompany that passage. It motivates a reproducible test. |
| May 2025 Validation plan | “V2x ideas” calls for defining packet types and use cases, then building a simulation to validate and refine performance. That is a plan, not a completed result. |
| August 2026 Collaborative design | A Claude-assisted Echo-V2X session develops relative relay fields, corroboration and bystander privacy concerns. It supplies design reasoning, not measured performance. |
| These webpage demos Illustrations | They explain encounters, information exposure and design choices using invented scenes. Working controls and tested webpage logic do not validate a radio protocol or establish crash reduction. |
No reproducible engineering result is presented here yet. A technical evidence package needs the model, assumptions, test cases, results and code for independent repetition.
WORKED ENCOUNTER / INFORMATION FLOW
What crosses the radio—and what stays local?
Walk through a car querying a cyclist’s optional beacon, checking its own measurements, and receiving an optional sensor report about an unequipped pedestrian.
An illustrative exchange, not an implemented protocol. The field names and example handles below explain the design questions. They are not a finalized packet format, a radio simulation, or measured performance.
Assume usable ranging, a plausible camera association and aligned report coordinates. These capabilities still need validation.
STEP 1 OF 5 · CAR → NEARBY BEACON
Ask only when there is a local use.
A car starts a local query. The trigger, listening schedule, contention rules and maximum query rate still need specification and testing.
Sent over radio
Conceptual fields in the car’s query; not wire-format bytes.
- Message
- Local query
- Exchange tag
- Q7 · temporary example
- Requested reply
- Road-user type
Computed locally
The car decides whether to query. Nothing has been located yet.
- Select a query trigger and a bounded listening interval.
- A query alone supplies no position, range or hazard assessment.
Retained locally
Temporary working state in this illustration.
- Q7 and a local deadline for this exchange.
No cue yet.
Sending a query is not evidence that a road user is present.
Keep the claims separate. Receiving a reply is not authenticated trust, a radio range is not a direction, and a plausible match is not a confirmed identity. This example does not implement cryptographic authentication, qualified ranging or sensor fusion. A sensor report needs age and uncertainty checks, an association between its temporary reporter reference and the actual reporter, and alignment from that reporter’s frame into the receiver’s frame. Those mechanisms—and rejection rules—need an actual specification.
“Expired” means removed from this illustration’s local encounter state. It cannot erase copies made by a listener. Temporary handles can still be linked during an encounter, and reporting an unequipped pedestrian raises privacy concerns even without a name or image.
ROAD TRAINS / LOOK FARTHER AHEAD
What if you knew the car two ahead was braking?
This is another goal in my notes: learn about a slowdown beyond the car immediately ahead. The leading car need not have a radio. An equipped middle car could observe its braking and pass back a brief, local report.
That could provide another source of awareness. It does not establish a safe following distance or turn a basic beacon into an automatic braking system.
THREE-CAR WORKED EXAMPLE
Your view, plus a view from ahead.
The lead car brakes in this fictional scene. Compare what the rear car sees with a report from the middle car.
ILLUSTRATION · NOT TO SCALETRAVEL →
- Your carEquipped receiver
- Middle carSees the lead car
- Lead carBraking · no radio
Middle car → your car: report available for assessment.
Straight lines represent views; the curved line represents a report. They are explanatory marks, not measured directions or a defined radio range.
OWN VIEW
The middle car obscures the lead car.
Your car still uses its own sensing and normal controls. In this drawing it has no direct view of the lead car’s braking cue.
What is assumed: the middle car’s observation, source checks, freshness and association are accepted only in the usable branch. No sensor, radio or controller is simulated; no response-time, stopping-distance or crash-reduction result is claimed. In every branch, this optional information layer supplies no driving command.
A RICHER, OPTIONAL APPLICATION
Could this eventually help road trains?
My longer-term ambition is temporary, voluntary cooperation that could support smoother traffic, closer coordinated following and lower aerodynamic drag. Those are hypotheses to test—not benefits demonstrated by this page.
Automated close following would need a separate controller and a richer, qualified exchange. A minimum type/proximity beacon alone does not provide lane-level positioning or the information needed to control braking.
Test authenticated fresh messages, correct vehicle and lane association, delay and loss, braking capabilities, how disturbances propagate through the group, vehicles cutting in, and joining or leaving. Loss of cooperation needs a tested transition strategy; a safe gap cannot be assumed to appear instantly.
Research on cooperative adaptive cruise control similarly calls for evaluating communications and controller behavior together. [16]
Cooperation should be local and time-limited, with owner choice and no central travel permission. Protecting privacy and control could make people more willing to participate, creating more opportunities for useful safety cues; that adoption benefit still needs evidence. Any richer exchange must justify its additional fields and retention; efficiency goals do not remove the privacy problem.
EXPLORE THE DESIGN
See the benefit. Test the tradeoffs.
Try a nearby warning, then change who participates and what their sensors can share. Finally, examine the information trail and the power a future operator could inherit. These are fictional design models, not measured safety results.
The demos run locally in your browser. They request no location and send no interaction data.
DEMO 01 / WHAT SAFETY BENEFIT?
A useful heads-up, beyond the driver's view.
A cyclist approaches behind a parked van. An on-demand nearby signal could prompt extra attention before the cyclist becomes visible. Move through the encounter, then try switching that signal off.
FICTIONAL ENCOUNTERDriver's view: blocked
Approach → hidden → visible → encounter ends.
Extra cue: a cyclist is nearby.
The local range is decreasing while the cyclist is hidden. Pay attention; this signal does not establish a safe path.
Owner control: the cyclist can turn off their beacon. Ordinary vehicle operation does not depend on that optional signal; the driver and onboard sensing still have to look for hazards.
What does this heads-up need?
- Shared in this example
- Derived locally
- Nearby · getting closer
- Not included
- Name, GPS coordinates or a persistent identifier
- After this encounter
- The local cue expires; this model keeps no trip history.
The picture shows the cyclist's exact position to explain the encounter. The car does not receive that position in this example. A proximity cue alone cannot tell it exactly where the cyclist is or whether a collision will occur.
Less data is a starting point. Nearby listeners may still correlate signals and infer a location. Explore that remaining risk →
A design target, not a safety test. This sketch assumes a working local radio exchange and ideal relative-distance information within a fictional boundary. Real ranging, obstructions, congestion, malicious messages and useful warning behavior need testing. The signal supplements attention and onboard sensing; it does not drive or brake the car. Switching it off never requests permission to travel. The cyclist is a voluntary beacon user here; sensing or relaying information about bystanders raises separate consent concerns.
02 / HOW DOES PARTICIPATION HELP?
Useful to join. Helpful even if you haven't.
Partial participation can still add useful cues. Cameras or lidar can notice vehicles and people with no radio, and an equipped vehicle can share selected observations. An equipped car could pass back a warning when it sees an unconnected car ahead brake. Here, try a hidden car or cyclist: the bus can share what your car cannot see.
ONE SCENE · SIX OTHER ROAD USERSHidden car: shared observation
Your receiving car is always equipped. The hidden road user's choice is separate.
A heads-up about a car with no beacon.
The bus sees the hidden car. Its optional radio shares a brief observation with your car; the hidden car needs no V2X equipment for this cue.
ROAD USERS WITH AN AVAILABLE CUE
5 / 64 seen by your car + 1 additional user
- Own cameras / lidar
- 4
- Direct beacon cues
- 2
- Shared sensor observations
Cue sources overlap. The total counts each road user once; it is not a safety score or a count of crashes prevented.
Useful before everyone joins.
Lower cost, less charging and fewer setup steps could widen voluntary use. Useful, calm warnings give owners a reason to keep it on. Shared awareness can also include unequipped cars and other road users.
What is shared—and what is assumed?
Proposed short-lived report: object type, an estimated relative location with uncertainty, and observation age. No raw image, face, plate or persistent identity is needed for this illustrated cue. The viewer sees true positions; real sensors would make uncertain estimates.
Repeatable, fixed scene: the slider adds the near car, bus, motorcycle, pedestrian, then far car. Your car sees four users; the bus blocks the selected hidden road user and far car. The bus's illustrated sensor boundary includes the selected user, not the far car. Only this bus supplies shared observations. The total uses known identities in this invented scene to avoid double counting; matching sensor sightings to beacon responses in real traffic may be uncertain.
A further possibility to test: associating visible vehicles with their beacon responses could help narrow down which remaining cues belong to unseen road users. Matches may be wrong or ambiguous. This example does not implement that inference.
Idealized delivery: all chosen radios can exchange local messages. Occlusion and sensor coverage are simple drawing geometry, not measured camera, lidar or radio performance. This snapshot assumes fresh observations; the proposed system would expire reports after the encounter and keep no trip archive.
Real usefulness depends on range, timing, errors, congestion, trust and driver response. Observing and relaying a nonparticipant still raises privacy and consent questions; these need testing, even without names or images.
More opportunities for awareness, not guaranteed protection. This compares available cues in one invented scene. It does not model braking, collision avoidance, radio ranging accuracy or the real-world adoption rate. With all optional radios off, the car still operates and senses visible users.
KEEP THE BENEFIT. QUESTION THE INFORMATION.
Useful cooperation still needs a privacy test.
More participation and richer observations can also create more information to misuse. A useful cue should expire; it should not quietly become a durable identity or a record of movement.
03 / WHAT INFORMATION LEAVES A TRAIL
A new ID. A familiar path.
Follow the labels on the road. Changing a label does not erase a journey’s positions and timing.
FICTIONAL ROADSTEP 12 OF 12
Step 12 of 12
Drag or use arrow keys. Only captured steps appear.
Playback is off for reduced motion. Use the slider or step buttons.
Gold links suggest continuity; they do not prove identity. Gaps limit observations, but do not prove anonymity.
CAR'S CURRENT LABELM9
Inside receiver coverage.
12 / 12steps captured so far
3different labels captured
Changing the label does not remove the positions and timing already observed. In this simple scene, adjacent samples remain plausible links.
Inspect captured packets
| Step | ID | x, y | Seen by |
|---|
Model assumptions and limitations
One car, 12 synthetic broadcasts with positions, perfect reception inside the drawn circles, and shared receiver records. A possible link requires consecutive captured steps and a movement of at most 52 arbitrary units. No competing cars, packet losses, radio obstructions, or identity checks are modeled. The gray road and car show the simulation, not information necessarily available to an observer. No link crosses a missed step. This illustrates information exposure, not a re-identification algorithm, a real deployment, or Echo-V2X.
Explore a harder privacy question: can relative distances reveal location?
SUPPORTING EXAMPLE / WHAT STILL NEEDS TESTING
Less direct disclosure still leaves location clues.
Omitting a coordinate field avoids handing out that position directly. Compare it with ideal distance measurements to see why the remaining clues still need testing.
THE LISTENER'S VIEW
A circle of possibilities
The listener knows its own position and a distance to the cyclist. Every point on that circle fits the measurement.
- Road user
- Cyclist
- Absolute position shared
- No
- Ideal measured distances
- L1: 26.6 model units
- Position inferred
- A circle, not a unique point
Omitting coordinates reduces direct disclosure. It does not remove every clue about location.
Assumptions: This is geometry, not an implementation of Echo-V2X. Each listener knows its own location, has an exact distance measurement, and can match measurements of the same cyclist at the same moment. Obtaining those measurements reliably is a separate engineering problem. Real errors and ambiguous matching change the result; radio signal strength alone is not assumed to provide an accurate distance. Distance is in arbitrary model units.
04 / WHAT POWER DOES THE DESIGN CREATE?
What would a future operator inherit?
Test two separate choices: what records survive a trip, and whether driving depends on approval from a central service.
A retained trip archive
A central record of vehicle DEMO-07, River Hall, and 08:12 is initially limited to safety use. A later rule allowing searches of past visits can make that same record available for another purpose.
Local, short-lived encounters
In this model, a nearby warning is processed locally and its encounter record expires. A later rule cannot retrieve that trip from a central archive that was never created. Other observers or future collection remain possible.
RETAINED AFTER THE TRIP
| Vehicle ID | Time | Place |
|---|---|---|
| DEMO-07 | 08:10 | West Road |
| DEMO-07 | 08:12 | River Hall Lookup match |
| DEMO-07 | 08:15 | East Road |
The stored fields stay the same when the rule changes.
No central trip archive
No retained vehicle ID, destination, or trip timestamps in this model.
During an encounter, local memory holds a temporary tag, relative distance, and road-user type. That record expires after the encounter.
TODAY · SAFETY ONLY
The archive already exists.
The current rule limits use to safety. The three identified observations are still stored, ready for a future policy or access change.
A limit on today's use is different from a limit on what the system retains.
A SEPARATE CHOICE / WHO CAN WITHHOLD MOBILITY?
A safety connection should not become a travel permit.
My design goal is an optional safety layer that owners can switch off while ordinary vehicle operation remains available. Compare that with a hypothetical design that adds a central-approval requirement.
Connection available · the difference becomes visible when it is withdrawn.
Independent operation My design goal
Vehicle operation continues
The optional warning channel is available; it is not permission to operate.
Central approval required Hypothetical dependency
Vehicle operation available
An added dependency makes continued operation conditional on the service.
Turning off optional warnings removes an extra source of awareness. Safe operation still requires the vehicle's normal sensing and controls. Trip storage and remote permission are separate design choices. V2X credentials do not inherently immobilize a car; the dependency shown here is hypothetical. Keeping it out of a design removes this particular route to control, not every possible form of coercion.
Model assumptions: Both designs can deliver a useful nearby warning; this is not a safety-performance comparison. The archive design deliberately retains identified trips. It does not represent every V2X deployment. All records are invented.
No central archive does not mean anonymity. Nearby broadcasts can still be collected and linked by other observers. Future operators might compel new collection or change the architecture. Data minimization changes what is available to misuse; it is not a legal or privacy guarantee.
01 / THE STAKES
A car is more than a node in a network.
Owning a car gives us the practical freedom to leave, to change plans, and to choose our destination. Privacy is part of that freedom.
Automating a driving task does not mean handing over the decision about where we may go. Likewise, accepting a collision warning should not mean consenting to a lasting record of our movements.
This has been a concern in my transportation notes since 2015. Delegating the task of driving must not silently surrender the freedom to choose a destination. By 2024, I was proposing an alternative to V2X designs that broadcast precise positions and linkable identifiers. I want technology that increases our freedom as well as our safety.
“As inventors, we have a responsibility to think about the effect our idea will have on our neighbors.”
My transportation notes, July 2015
What is V2X?
Vehicle-to-everything covers communication between vehicles, roadside infrastructure, and other road users. A car might receive a warning about hard braking beyond its line of sight or a hazard around a blind corner. Basic safety messages can include position, speed, and heading. That information can help prevent a collision; it can also be useful to an observer. [1]
V2X is a family of technologies. Direct local radio exchange, cloud telematics, and remote vehicle control are different capabilities. We should evaluate the data and powers of each actual design, rather than assume every connected car works the same way.
02 / HOW SAFETY DATA BECOMES A TRAIL
Removing your name is only a start.
A privacy review needs to follow the information beyond the packet.
Observe
Nearby receivers can hear safety broadcasts. A short radio range limits each listener, but a network of listeners can cover a much larger area.
Connect
Position, timing, speed, and direction can help link observations even after an identifier changes. Predictable routes and sparse traffic can make anonymity harder. [3]
Associate
A repeated home-to-work journey or a connection to another identifying observation may reveal whose car it is. Visits can then become clues about a person's private life.
This is a threat scenario, not a claim that every deployment already performs these steps. The question is how much easier the design makes them.
03 / DESIGN FOR A CHANGE OF HANDS
Good intentions are not a permanent safeguard.
The test: what could a future operator do with the system we build today?
I want V2X to resist government capture: the repurposing of safety infrastructure into a mechanism for monitoring or controlling people.
Today's operators may be careful and well intentioned. Tomorrow's could face different incentives, new demands for access, or pressure to connect previously separate databases. A useful safety service can become difficult to refuse once it is built into everyday travel.
Privacy engineering already exists. Its limits matter.
The Security Credential Management System (SCMS) design uses changing pseudonym certificates and separates sensitive functions among organizations. These are meaningful protections. Its designers also acknowledge that continuous observation can reconstruct a vehicle's path and that large-scale receiver networks require additional defenses. [2]
My concern is what happens when organizational independence fails, records are combined, or rules change. We need protection against misuse by a future authorized operator as well as an outside hacker. The aim is to make surveillance require substantial new collection or an explicit redesign, instead of merely a new use for capabilities that are already in place.
Keep a safety credential from becoming permission to travel.
Revoking a device's credentials is intended to stop trust in its messages. That is different from immobilizing a car. I do not claim that V2X inherently provides a remote kill switch. My objection is to coupling those systems—or making ordinary mobility depend on remaining in good standing with a central service.
There is already a separate warning from connected-car data collection: in January 2026, the FTC finalized an order settling allegations that GM and OnStar collected and sold precise location and driving data without informed consent. That case concerns telematics, not proof of a V2X flaw. It shows why assurances about beneficial uses deserve scrutiny. [4]
04 / WHAT I AM ADVOCATING
Make privacy a requirement
of the design.
These are the conditions I want engineers, manufacturers, and public agencies to work toward.
Share the minimum
Require a specific safety justification for every transmitted field, its precision, range, and frequency. Avoid persistent identifiers and unnecessary location disclosure. Test any reduction against real safety needs.
Keep encounters local
Prefer local processing and short-lived encounter data. A warning about a nearby hazard should not routinely generate a centrally stored travel history. Publish and enforce retention limits.
Test the powerful observer
Evaluate continuous receivers, correlated datasets, colluding operators, and compelled access—not only a casual listener. Publish what remains linkable and under which assumptions.
Preserve independent mobility
Keep ordinary vehicle operation independent of a cloud account or remote approval. Design safe behavior for network outages and credential failures. Reject the conversion of safety credentials into a general travel permit.
Keep this safety layer optional
The supplementary system I am proposing should be switchable by its owner. Ordinary vehicle operation must remain available with its normal controls and sensing. Do not turn an optional warning service into permission to travel.
Put limits on power
Separate safety messaging from enforcement and movement control. Require independent scrutiny, transparent governance, and enforceable limits on secondary use. Policy should reinforce technical protection.
05 / A CONSTRUCTIVE DIRECTION
From a proposal
to a tested standard.
Prove the usefulness of the warning. Measure what remains linkable. Make the implementation open to scrutiny.
My work began as NearSense in 2024 and later developed into Echo-V2X. The idea is to explore nearby, on-demand beacons that communicate a road-user type and support relative-distance estimation, without directly broadcasting an identity or absolute GPS coordinates. It is intended to supplement onboard sensing, especially where a pedestrian, bicycle, or vehicle is obscured. I described the early direction publicly in 2024. [6]
This is a research direction, not a validated replacement standard. Relative measurements and short identifiers can still leak information. Reliability, spoofing, congestion, accessibility, and tracking by multiple receivers all need testing. Simply rounding GPS coordinates or changing an ID is not enough.
Privacy must also cover people who never opted in. If a vehicle relays a sensor observation of a pedestrian or cyclist, that person cannot turn off someone else's sensor. My later design work calls for minimal descriptions and short-lived, locally scoped references to those observations, with their remaining tracking risks still subject to testing.
Other researchers are working on stronger privacy too. One published V2X credential proposal aims to protect pseudonym unlinkability even when certificate authorities collude. That addresses an important layer; it does not by itself hide the physical path disclosed by messages. [5]
An open specification and reference implementations would let others reproduce experiments, test inexpensive beacon designs, and challenge the privacy assumptions. Practical cost, battery life, interoperability and reliable ranging remain engineering work. The goal is a useful alternative people can choose before a more intrusive architecture becomes entrenched.
1 · Prototype on supported phones
Test minimum local messages using existing hardware. Publish the protocol and a simple accessory reference design; measure which safety tasks each can support.
2 · Test a real encounter
Measure missed cues, false warnings, radio congestion, privacy leakage and power use. Include people without beacons.
3 · Earn wider use
Make devices interoperable and easy to maintain. Study voluntary use and publish failures alongside benefits.
This is proposed development work; no completed standard or validated safety performance is implied.
BEFORE THE INFRASTRUCTURE BECOMES PERMANENT
Ask what the system makes possible.
When a V2X deployment is proposed, ask what safety task it serves, what it broadcasts, who can collect it, who can change the rules, and what happens if a driver disconnects. Help develop and test an open alternative that preserves independent mobility.
Safety should expand our freedom to travel. Let's build it that way.
Discuss the design Email Peter Gransee · welcomes technical critiques and alternativesREAD FURTHER
Sources & background
The principles above are my advocacy position. These references support the technical distinctions and documented examples.
- NHTSA: Improving Safety and Mobility Through V2V Communication Technology2014 · Historical technical background on basic safety messages and warning applications; not a statement of today's spectrum rules.
- Brecht et al.: A Security Credential Management System for V2X Communications2018 · Section II-A1 explains privacy protections, continuous-observation limits, and large-scale receiver threats.
- Higashida & Sato: Evaluation of a pseudonym change scheme using LSH for location privacy in V2X communication2025 · Research on anonymity limits when trajectories are predictable or too few vehicles change pseudonyms together.
- FTC: Final order concerning GM and OnStar location and driving dataJanuary 2026 · A connected-car telematics case, distinct from V2X broadcast messaging.
- Hicks & Garcia: A Vehicular DAA Scheme for Unlinkable ECDSA Pseudonyms in V2X2020 · Research addressing colluding certificate authorities; not a guarantee against trajectory tracking.
- Peter Gransee: “tweak to spec that addresses some of the concerns?”August 17, 2024 · My public NearSense proposal. Performance and privacy claims in that early proposal remain hypotheses requiring validation.
- USDOT: National V2X deployment plan announcementAugust 2024 · The safety case and deployment ambitions motivating this discussion; plan targets are not evidence of completed deployment.
- Bluetooth SIG: Channel SoundingMessage exchange and dependable ranging are separate capabilities. Channel Sounding may require upgraded radio hardware; this is not evidence that existing vehicle radios meet this proposal.
- ETSI: Collective Perception Service2023 · Describes sharing observations from cameras, lidar and radar, including objects without V2X equipment. It does not validate this proposed privacy-minimizing design.
- IIHS: Fewer drivers are opting out of lane departure preventionOctober 2024 · Observational evidence that warning design and usability affect whether people leave safety features enabled; not an adoption forecast for Echo-V2X.
- Lucas-Estañ et al.: ADAS and V2X participation levels in cooperative safety2026 repository version · Studies a highway emergency-braking scenario. Supports investigating participation and sensing together; no numerical result is transferred to these demos.
- Bluetooth SIG: Bluetooth LE primerLE Coded PHY is optional and uses error correction to improve communication range at a lower data rate. Actual device support and road performance need testing.
- Android: Bluetooth background communication · Android: coded-PHY support check · Apple: Core BluetoothPlatform capabilities and background behavior shape what a phone app can do. Check current APIs and the intended phone/OS combination.
- Tesla: official vehicle-command toolsSupports certain vehicle commands over Bluetooth or the Internet. This does not establish public access to camera perception or support for the proposed cooperative protocol.
- 5GAA: C-V2X explainedDirect PC5 communication can operate independently of cellular networks. Local exchange is a shared capability, not by itself a distinguishing privacy guarantee. Checked October 9, 2026.
- USDOT: Evaluation of cooperative adaptive cruise control and platooning2019 summary of a 2017 FHWA report · Existing five-vehicle DSRC research and requirements for communication, controller and failure testing. Supports separating supplemental awareness from automated close following; it does not validate this proposal. Checked October 9, 2026.
This essay draws on my transportation journals, DS Notes, and public writing. Private source documents are not published here. Technical references checked October 6, 2026; technical overview, adoption argument and road-train discussion updated October 9, 2026.