Open-source OBD-II

Alongside Tweak Management, DuoDash is intended to support an open-source OBD-II dongle platform developed by SenseTechLab — open at both the software and hardware levels, so developers can experiment with vehicle data directly rather than only at the application layer.

What is planned for release

Unlike a closed accessory, the OBD-II dongle is intended to be open at both the software and hardware levels. SenseTechLab plans to publish the source needed to build and modify the firmware, together with the hardware design files needed to understand, reproduce, modify and extend the device.

Where applicable, the open-source release may include:

• Firmware source code.
• Hardware schematics.
• PCB design and layout files.
• Bill of Materials (BOM).
• Pin assignments and electrical interface documentation.
• Build and flashing instructions.
• Communication protocol documentation.
• DuoDash integration documentation.
• Reference examples for reading and publishing supported vehicle data.

The repository structure, supported hardware revisions, toolchains and open-source licence will be documented with the official release. None of them are decided yet, and the licence in particular should not be assumed.

What you could build with it

The goal is to give developers a second integration layer: not only application-level tweaks, but direct experimentation with vehicle data and custom hardware. Possible uses include:

• Additional OBD-II PID support.
• Vehicle-specific data decoders.
• New telemetry sources for DuoDash.
• Custom diagnostic or monitoring features.
• Alternative communication transports.
• Firmware optimizations.
• Support for additional microcontrollers or hardware revisions.
• Experimental sensors or peripherals.
• Application-specific vehicle-data integrations.

Developers may also fork the reference design and build their own compatible hardware, subject to the terms of the applicable open-source licences.

How it fits with Tweak Management

The OBD-II platform complements the Tweak Management architecture rather than replacing it. A typical data path:

Vehicle / OBD-II Bus
        │
        ▼
SenseTechLab Open-Source OBD-II Dongle
        │
        │ vehicle telemetry
        ▼
DuoDash Vehicle Data Interface
        │
        ├──────────────► DuoDash Core Feature
        │
        └──────────────► Third-Party Tweak
                              │
                              ▼
                       Application / UI

Which means one developer can work both sides of the ecosystem at once:

Open Hardware / Firmware
          +
DuoDash Developer Interface
          +
Third-Party iOS Tweak
          =
Custom Vehicle Integration

For example, you could add support for a vehicle-specific parameter in the dongle firmware, then write a DuoDash tweak that consumes that value and presents or uses it in an application-specific way.

Vehicle data interface

DuoDash should expose a documented interface between the dongle and software consumers, rather than requiring developers to depend on private internal implementations. The final interface is expected to document concepts such as:

Device discovery
Connection state
Protocol version
Vehicle data identifiers
Value type
Value unit
Timestamp
Validity
Update frequency
Error state

The actual transport and API are implementation-dependent and will be documented when finalised.

Custom firmware

Because the firmware is intended to be open source, developers may modify it for their own requirements — adding supported PIDs, changing polling strategies, adding vehicle-specific parsing, implementing additional telemetry, changing communication behaviour, or adding experimental functionality.

Custom hardware

Publishing the hardware design allows developers to study and modify the physical dongle as well as the firmware. Possible modifications include different board dimensions, different connectors, alternative components, additional sensors, development and debug headers, different enclosures, and revisions for research or specialized vehicles.

Compatibility and versioning

The platform is intended to use explicit hardware, firmware and protocol versions:

Hardware Revision:        1.x
Firmware Version:         1.x.x
Protocol Version:         1.x
DuoDash API Compatibility: 1.x

Check protocol compatibility rather than assuming all dongle firmware versions behave identically. Where practical, protocol changes should preserve backward compatibility or provide a clear migration path.

Contributing

Because the dongle is intended to be an open-source project, developers may be able to contribute improvements back — bug fixes, additional vehicle support, additional PID definitions, firmware performance improvements, documentation improvements, hardware fixes and new reference integrations.

Contribution requirements, coding standards, pull-request policies and licensing requirements will be published in the official source repository.

Safety and responsibility

Do not transmit arbitrary or undocumented commands to vehicle control modules without fully understanding their effects. Prefer read-only telemetry wherever write access is unnecessary.

SenseTechLab cannot guarantee the safety, reliability, compatibility or behaviour of modified firmware, modified hardware, third-party forks, or integrations developed independently from the official project.

You are responsible for testing your implementations safely, and for complying with applicable laws, regulations, vehicle warranties and licensing requirements.

Repository and licence

To be published when the project is released. It will cover the repository location, the open-source licence, the hardware licence, supported hardware revisions, firmware build instructions, the PCB design tool and version, flashing instructions, the communication protocol specification, and DuoDash integration examples.

← Back to the developer guide overview