Verified on a vehicle · September 8, 2026

Original Tech2 DTCs.
Running on Android.

The Pixel 7 runs the original Tech2 and CANdi firmware in our Rust emulator, connects directly to VCX Nano over USB, and displays the original diagnostic menus. We completed a DTC read and a separate, operator-requested clear through that path.

Original result screen

Five DTCs displayed

BCM, RRDM, TPMM and UEC faults appeared in the guest's own DTC Information page.

Original clear workflow

Clear completed

Real ECU replies and the physical ignition transition led to “Vehicle DTC’s Cleared.”

Direct connection

Pixel → USB → Nano

Both firmware CPUs run locally. This Android path uses no Windows host or OEM J2534 DLL.

This follows the September 7 startup investigation, when the native adapter bridge was still missing. These results are specific to our tested Saab 9-3 / Nano configuration.

The firmware's actual display

Pixel screenshot showing original DTC Information: BCM B0092 05, RRDM B3210 06 and B3205 06, TPMM C0777 5A, UEC B2575 04; USB console below. — Native Android read session. Touch keys drive the original menu; the console records firmware TX and USB activity.

Pixel screenshot showing the original Clear Vehicle DTC’s page with Vehicle DTC’s Cleared and OK. — Separate clear session, after the original key-to-LOCK prompt and a real CIM response. These are captured screens, not reconstructed results.

Three channel names, one physical route

CANdi's native channel number, the emulated controller index and the Nano channel number are different namespaces. Passing one through as another misroutes traffic.

Observed native mapping and implemented Nano routes
Native channel	Controller / window	Bus	Nano channel
`4`	`0 / 0x200000`	P-bus, 500 kbit/s	`0`
`2`	`1 / 0x201000`	Middle channel	Not enabled in this profile
`0`	`2 / 0x202000`	I-bus, approximately 33.3 kbit/s single-wire CAN	`1`

For the observed single-wire wake request, CAN ID 0x100 has zero data bytes. Preserve the firmware's GPIO electrical state: J2534 expresses high-voltage TX as 0x0400, while our Nano USB encoder uses 0x1000. Normal single-wire traffic uses neither flag. These values belong to different transport layers; a Chipsoft USB envelope is not a Nano command.

The route validates controller, timing and GPIO mode together. Unsupported combinations are rejected. The mapped controller interrupts are levels 4 / 3 / 2, vectors 28 / 27 / 26, respectively.

Commands we can now identify

The following bytes are Tech2 ↔ CANdi serial frames, not vehicle CAN payloads. Valid complete frames have an additive 8-bit checksum of zero. The serial boundary also needed the original space-parity zero delimiter and receive break/framing-error status.

Serial bytes	Meaning / observed reply
`90 03 6D`	Device information. Reply `91 03 …` identifies “CANdi Application”.
`80 09 01 45 85 AC`	Observed baud-change request; reply `81 09 00 76`.
`88 0E 6A`	Native channel 0 wake request; `89 0E 00 69` acknowledges the command, before CAN TX is confirmed.
`2E D2`	Receive-queue poll across channels; `2F D2 FF` means queue empty.
`80 0C …`	Firmware inventory request family; replies begin `81 0C …`. Ellipses are omitted bytes, not a complete packet.

The console now distinguishes serial command acceptance, original CANdi TX intent, USB submission/completion, received CAN frames and guest filter acceptance. USB-write compatibility completion and J2534 software loopback are not measurements of electrical CAN acknowledgement. A fresh ECU response and the resulting original screen are separate evidence.

What made the DTC flow work

Let the original firmware select the vehicle and check ignition. The read path was Diagnostics → All → DTC → F0: Vehicle Check / Read. It passed vehicle, key-position and transport-fuse checks using incoming vehicle traffic.
Follow the original prompts. The guest requested “Turn Ignition Key to LOCK if Possible” during the read. The operator changed the physical key state; no host-generated ignition reply bypassed that check.
Keep the result in the guest. It displayed BCM B0092-05, RRDM B3210-06 and B3205-06, TPMM C0777-5A, and UEC B2575-04. That scan reported ECM and TCS/ESP missing and continued through the original prompt; it was not a complete all-module scan.
Give clearing its own explicit mode. F1: Clear Vehicle DTCs retains the original Yes confirmation. This workflow sends GMW3110 service 04 (observed CAN payload 01 04 plus padding) and receives positive 44. It also needs the observed A9 81 0A status read, which the earlier command gate had rejected.
Preserve response-pending and key transitions. CIM P-bus returned NRC 78 before a positive reply roughly 84 seconds after the first clear request; ESP took roughly 34 seconds. The guest then requested LOCK for CIM/SCL clearing, passed the physical key check and reached the final clear screen.

The successful read recorded 168 original CAN writes; the successful clear recorded 108. Clear replies covered 21 distinct (channel, response-ID) pairs—not 21 unique ECUs. Examples include HS 7E8 (ECM), HS 645 (CIM) and SW 641 (CIM). Both runs released USB and reported clean shutdown.

What the screen does and does not establish

A raw CIM response decoded as C0547-04, status 11, reached the native receive filter but was omitted from the guest's displayed read summary. We preserve that distinction. The final clear screen confirms the firmware completed its workflow; a fresh post-clear scan is still needed to establish which faults return.

Where this leaves OpenSAAB

The working boundary is now original firmware → emulated CANdi controllers → adapter-specific USB transport → vehicle, with real replies returning through the firmware's receive path. This gives other adapters a concrete integration target. Chipsoft Pro, MDI and iOS wireless support still need their own transport and hardware validation.

A separate Android security-collection run also produced the original 714-byte pre-auth SSA block with ten populated records after the firmware's LOCK/key-removal sequence. That proves collection; API processing and a completed vehicle unlock were not part of that run.

Live engine data remains unfinished: the original 42-item page was reached, but sensor values were not validated. That investigation is paused. We are not presenting placeholders as measured temperature or airflow.

Read the reproducible findings and command map in the published technical notes. Background references: NXP MC68331 manual, GMW3110 (2010), and the J2534 flag definitions.

Evidence: September 8 native Android DTC read and clear sessions; shared emulator checkpoints 0baccf2 and f459f9d. Raw captures, vehicle identity, security material and proprietary firmware remain private. These findings describe observed behavior, not a universal adapter compatibility claim.