Published 2026-10-30 · DIYCarPlay Engineering Team · 14 min read
Read the Head Unit Off the Bus: How a Diagnostic Port Settles the Platform Code Before the Order
Three routes to the same answer are already in use across this catalogue: look at the head unit and read its shape, open its menu and read the version screen, or check the build plate and the parts catalogue. A fourth route exists and it is the fastest one on a car that is standing in front of you. The head unit answers a standard diagnostic read on the vehicle's own diagnostic connector and returns the part number and software version the factory wrote into it. No trim comes off, and nobody has to find a document.
A retrofit module for the same platform then does the same job in reverse. It wakes the head unit over the vehicle network, reads what answers, and drives the factory screen from behind it. That is the point of a plug-and-play decoder built on a Linux embedded system with an automotive-grade Sunplus chipset: the factory screen, the original steering wheel buttons and the reversing camera all stay in the car, the phone arrives over 5GHz dual-band WiFi, and the only thing that has to be right is the platform code written on the purchase order.
What a diagnostic read actually returns
The read is a request in a standard format. Unified Diagnostic Services, defined by ISO 14229 and inherited from the older KWP 2000 family, places its messages in the upper layers of the vehicle network and lets them travel over CAN, over the K-line of older cars, over FlexRay, or over automotive Ethernet. The service that carries the request is 0x22, ReadDataByIdentifier, and the head unit answers with 0x62 followed by the identifier and its value. The identifiers that matter for identification live in a reserved block, and the standard ones are the ones a workshop already relies on: 0xF190 for the VIN, 0xF18C for the ECU serial number, 0xF18B for the installation date, 0xF199 for the programming date, and a group of software version identifiers beside them. A manufacturer fills its own block with the part number of the unit and the version of the software running on it.
Two things decide whether that read succeeds. The first is the session. A control unit starts in its default session and releases more of its services once an extended diagnostic session has been requested through service 0x10, and a tester that is not sending traffic has to keep the session alive with service 0x3E or the unit drops back and may go to sleep. The second is the negative response. A head unit that does not publish an identifier answers with the negative response code 0x7F followed by 0x31, which means the identifier is outside its range, and a protected identifier answers 0x33, which means the session is not cleared for it. Those two answers are normal, and a technician who reads them as a fault will chase the wrong thing.
Why a generic scan tool cannot do this
The cheap OBD-II dongle sold everywhere covers the emissions side of the car and nothing else. The generic standard talks to the engine control unit at one fixed address and answers requests for stored emissions faults and live sensor values. Everything a buyer actually needs from a head unit lives outside that layer, on the modules the manufacturer chose to address in its own way, and the responses come back over manufacturer-specific protocols that the generic adapter does not implement at all. A budget clone adapter adds a second layer of failure: the timing commands needed to reach extended module addresses fail silently on the copy silicon, and a version string printed on the case regularly describes firmware the chip does not run.
The tools that work are the ones written for the marque. They know the module addresses, they know the transport, and they know which identifiers carry the generation. What comes back is a control unit list, and the head unit appears in it with its part number, its software version and the address it answers on.
What each marque needs to reach the head unit
The route into the head unit differs by marque because the network layout differs. The table below sets out what a workshop on each of these groups uses, how the request reaches the head unit, and what comes back in the answer.
| Marque group | Workshop tool | How the read reaches the head unit | What the answer gives |
|---|---|---|---|
| BMW and MINI | ISTA with the ENET cable | The ENET cable is a passive adapter that puts Ethernet into the OBD socket. Behind it the central gateway routes a request by a one-byte address to whichever module was asked for, and the head unit is reached over that Ethernet link. Recent cars use DoIP with discovery on UDP 13400 and a TCP connection on the same port before routing is activated. | Head unit part number, software version, and the hardware revision line |
| Volkswagen Group | ODIS Service with a VAS interface | Control unit identification is read out of the modules behind the gateway. Older vehicles still answer on the K-line with the 5-baud initialisation and the KWP 2000 block protocol; later ones use the transport protocol on CAN and then Unified Diagnostic Services on top. | Diagnostic address, hardware and software part numbers, installed software version |
| Mercedes-Benz | XENTRY with the Star interface | The head unit is a coded module on the vehicle network. A part read reaches it through the command and audio gateway, and the answer is tied to the vehicle it was coded in. | OEM number of the unit, software level, and whether the unit is still coded to this car |
| Toyota and Lexus | Techstream with TIS for part coding | The head unit is reached over the marque's own network rather than over the emissions connector. After a swap the unit needs an audio initialisation, and region coding runs through the parts information system. | Part number of the audio unit, hardware line, and the software release it carries |
Two details in that table decide real orders. The Mercedes row is the sharpest: the same vehicle range carries several head unit revisions that differ by production date, by the software pre-loaded at the factory, or by regional variant, and each one has its own OEM number. The Toyota row is the second: the head unit part number is the audio unit number, not a head unit number, and the audio unit is what the retrofit harness has to match.
The number on the unit beats the name on the invoice
Every head unit in these cars carries its own identifier, and that identifier is what the retrofit order has to follow. A generation name such as MMI 3G or PCM 3.1 describes a family. The part number describes the unit in the car. When a buyer orders by the family name, a car that left the line with a different variant of that family arrives, the harness does not match, and the part comes back. When the order carries the number that the diagnostic read returned, that failure stops at the order.
This is also where the read exposes a car that has already been altered. A head unit fitted by a previous owner reports its own identity, not the identity the car was built with, so a read that does not match the build plate and the parts catalogue is telling the buyer that the car is not the configuration the paperwork describes. A physical inspection would not have found that as quickly, because the unit looks entirely correct in the dash.
The four routes, and what each one cannot settle
None of the four routes is complete on its own, and the order of preference changes with the situation. The table below sets them against each other.
| Route | What it needs | What it proves | What it leaves open |
|---|---|---|---|
| Look at the unit | A photograph of the dashboard | The button layout, the controller and the screen size of the fitted unit | Whether the unit is the one the car shipped with |
| Read the version screen | Access to the car and a menu path | The software generation string and the hardware line | The audio variant, the trim equipment and any earlier replacement |
| Check the paperwork | The VIN, the build plate and the parts catalogue | What the factory records say was fitted | What is actually in the car today |
| Read the diagnostic port | A marque tool and a vehicle network connection | The part number and software version of the unit that is in the car | The connector variant and the trim equipment behind the screen |
The reason the fourth route is worth the setup cost is the ambiguity underneath all of them. Across the fitment sheet, 50 model names sit under more than one platform code, and for 10 of them the year windows are identical, so a nameplate and a model year cannot pick between the codes that cover the car. The platform code and model year guide works through where those numbers come from. A diagnostic read settles those cases directly, because it does not consult the model name at all. It reads the unit and reports what it is.
Where the diagnostic read stops
A read is a strong answer with a specific edge, and the edge is worth stating plainly to a buyer before an order is placed. The read tells the buyer which unit is in the car. It does not describe the connector that reaches it, and it does not describe the trim equipment behind the screen. The Land Rover and Jaguar codes split by screen size and by audio brand, with the earliest group running the Bose system and the later groups running Harman, so a correct unit number can still be paired with the wrong harness if the audio variant is not confirmed separately. The head unit version screen guide sets out where each marque prints the generation, which remains the cheapest way to read the trim line.
The read also does not replace the harness. Once the code is settled, the retrofit connects to the head unit over the vehicle network, so the module has to match the connector, the video path and the reverse trigger on the specific unit. That is the part the factory bench verifies: every harness is tested against the head unit it is built for, on a real unit rather than on a drawing, with the CAN bus wake frame, the reverse trigger and the audio routing all exercised together.
What the confirmed code buys in the car
With the code settled, the install itself is short. The harness plugs into the factory head unit, the display wakes, and the phone appears on the original screen. Nothing is replaced and nothing is flashed on the vehicle side. The table sets out the difference in approach between a decoder module behind the original display and an aftermarket unit that replaces it.
| Point of comparison | Decoder module behind the original display, Linux embedded | Aftermarket Android unit |
|---|---|---|
| Original display and bezel | Kept in the car | Removed and replaced |
| Factory buttons and steering wheel | Kept and still working | Lost with the original unit |
| Reversing camera | Original camera and trigger retained | Depends on the replacement unit |
| Operating system | Linux embedded on an automotive-grade Sunplus chipset | General-purpose Android system |
| Long-term behaviour | No application cache builds up behind the interface, and there is no operating system to update years after the fitment | Application cache builds up behind the interface over the years |
| Phone link | 5GHz dual-band WiFi with 2.4GHz fallback, low latency for the video stream | Depends on the unit and on the link it provides |
The point of reading the code before ordering is that the rest of this table only happens if the right module arrives. A Linux embedded system on an automotive-grade chipset does not accumulate an application cache behind the interface, so there is no long-term slowdown to plan for, and the hardware carries the smoothness rather than the operating system. Over 5GHz dual-band WiFi, with 2.4GHz available as a fallback, the video stream stays low-latency and sharp, and the factory screen, the original steering wheel buttons and the reversing camera all stay where the car left them.
Ordering once the code is confirmed
Stock is available from 10 pcs, and mixed models are allowed in that opening order. Private label runs from 500 pcs per model, and a full OEM programme with custom firmware runs from 1000 pcs per model. Samples are built and shipped in 7 to 15 days by DHL or FedEx express, and a production run of 500 pcs or more takes 15 to 20 days. The sample fee is credited against the first large-volume order, so a distributor who starts with one unit of each code is not carrying an unrecoverable sample cost.
Payment is by T/T, 30% deposit with the remaining 70% against a copy of the bill of lading. A quotation comes back within 12 hours of the vehicle list arriving, with the platform code named for every car on the list so that a read taken on the customer's driveway can be checked against it before anything is shipped. Coverage spans 300+ vehicle models and series from 2006 to 2025, and the fitment sheet is built on the platform codes those reads return.
Frequently asked questions
Can a scan tool read the platform code directly?
No. The tool reads the part number and software version of the head unit, and the platform code is derived from that by consulting the fitment sheet. The read is the ground truth; the code is the label the order is written in.
Which tool works on a car that has already been modified?
A marque tool with a network connection reaches the unit that is fitted, whichever unit that is. That is the strength of this route: it reports the car as it is now, not as the build record describes it.
Does the read need the ignition on and the car running?
The car needs to be awake and the network connected. On most of these cars that means the ignition on and the head unit powered, which is what a workshop already does before any other check. Some head units drop back to sleep if the tester stops sending traffic, so the session has to be held open.
Does the retrofit change anything the customer relies on?
No. The original display, the factory buttons and the steering wheel controller, and the reversing camera all stay in the car. The module sits behind the head unit and adds the phone projection to the screen that is already fitted. The vehicle fitment finder confirms whether a given car is eligible before anything is ordered.
What is the fastest way to confirm a code before ordering?
Take the read on the car, write the returned part number against the vehicle on the order, and let the fitment sheet return the code. Where a car cannot be brought in, the version screen and the build plate together settle most cases, and the parts catalogue closes the rest.
How is the fitment confirmed before an order ships?
The vehicle list goes through the fitment sheet and comes back with the platform code named for each car, within 12 hours. Sending the list, the quantities and the target market through the inquiry form returns a quotation with the code, the volume tier and the lead time for every vehicle on it.
Next step
A diagnostic read takes minutes on a car that is standing there, and it removes the single largest source of wrong modules: an order written against a model name when the car carries something else. The sequence is short. Read the unit, write the returned number against the vehicle, and let the fitment sheet name the code. Coverage spans 300+ vehicle models and series from 2006 to 2025, and the code decides the harness and the firmware that ship in the box.
Need the Module From This Guide?
Wholesale from 10 pcs (mixed models OK), samples in 7–15 days (DHL/FedEx express). Fitment confirmation within 12 hours.
Request Pricing Check FitmentRelated Resources
- CarPlay Collections — browse by marque family (German, British, Italian, Japanese, luxury)
- CarPlay Fitment Checker — find the module for your car
- CarPlay Decoder FAQ — 34 answers on compatibility, install and wholesale
- CarPlay Retrofit Buying Guide — platform identification & selection
- Wholesale, Private Label & OEM Program — MOQ, lead times, payment terms
- All installation & technical guides