As we push forward building in-car XR experiences, one problem keeps coming up again and again: Why is it so hard to get real-time vehicle data from modern EVs? If you’ve worked with traditional cars, you might expect to just plug into the OBD-II port and read everything—speed, RPM, throttle, steering… But with EVs, that assumption breaks.

Let’s break down why.

1. A Quick History of OBD-II

OBD-II (On-Board Diagnostics II) was introduced in the 1990s as a standardized diagnostic interface for vehicles. Its original purpose was not entertainment, not apps, and definitely not real-time UX—it was:

  • Emissions monitoring
  • Fault detection
  • Regulatory compliance

Key characteristics:

  • A standard physical port (16-pin connector)
  • A set of standardized diagnostic protocols
  • Access to fault codes (DTCs) and limited sensor data

Over time, developers realized that, we can read real-time vehicle data from here. And that’s how OBD-based apps, dongles, and dashboards became popular. But this was never the original design goal.

2. CAN Bus: The Nervous System of Traditional Cars

Inside almost every internal combustion vehicle, communication is powered by CAN Bus (Controller Area Network). Think of CAN as: A shared communication highway where ECUs (Electronic Control Units) broadcast messages. Typical signals on CAN: Vehicle speed, Engine RPM, Steering angle, Brake status...

And importantly: Many of these signals are continuously broadcasted, which makes passive listening possible. This is why OBD-II tools can often “see” live data—they’re really just tapping into CAN.

3. EV Architecture: A Fundamental Shift

Electric vehicles don’t just replace the engine with a battery—they often redesign the entire electronic architecture. Modern EVs tend to move toward:

  • Domain-based or zonal architectures
  • Centralized computing
  • High-speed automotive Ethernet
  • Strict software-defined control layers

Instead of: “Everyone talks on CAN”. You now have: “Everything talks through controlled gateways or central computers”.

Why EVs Move Away from CAN (for External Access)

CAN still exists—but:

  • It’s often segmented into multiple internal networks
  • Protected behind gateway ECUs
  • Not exposed externally

Reasons include: Security (prevent hacking / unauthorized control); Safety certification; Data ownership & monetization; System complexity management.

4. What This Leads To

This architectural shift has major consequences:

  1. No More Rich Real-Time Data:
    • Many signals are not broadcasted publicly
    • Data is filtered or completely blocked at the gateway
  2. CAN Sniffing Becomes Useless:
    • You may see very limited or meaningless traffic
    • Critical signals are hidden or encrypted
  3. No Vehicle Control via CAN
    • Sending CAN messages can no longer works

5. Why EVs Still Keep the OBD-II Port

Interestingly, almost all EVs still include an OBD-II port. But its role has changed. Today’s OBD-II Port is Mostly For:

  • Reading VIN (vehicle identification number)
  • Accessing standardized fault codes (DTCs)
  • Regulatory compliance across global markets

What it is not anymore:

  • A reliable source of real-time vehicle telemetry
  • A developer-friendly interface

So the port remains—but its usefulness is minimal for advanced applications.

6. Our Real-World Attempts (and Why It’s Hard)

We didn’t just stop at theory—we tried everything. We performed CAN sniffing across multiple EV models, attempted to reverse engineer signal mappings, and collaborated directly with suppliers and OEMs to gain deeper access to vehicle data.

While the reality is : For most EVs (except Tesla), data is locked behind proprietary systems, and accessing it typically requires internal documentation, firmware-level integration, or direct OEM cooperation. In fact, we have paid over $50,000 USD per vehicle to partner with an EV manufacturer just to enable CAN data output—and even then, it required custom firmware modifications, internal engineering support, and a non-scalable integration approach.

This approach is not reproducible, not scalable, and not cost-effective—you simply cannot ship a product that depends on modifying every individual car.

Final Thoughts

The shift from traditional vehicles to EVs is not just about energy—it’s about control of data and systems. Whereas old cars were open, broadcast-based, and relatively hackable, new EVs are closed, centralized, and software-defined. For developers building AR navigation, in-car VR, or smart dashboards, this means we can no longer rely on OBD-II or CAN as our primary data source. Instead, the future likely lies in vision-based understanding, sensor fusion, OEM partnerships, and cloud-connected vehicle APIs.