Link G4+ / G4X / G5

Applies to: IOcan · Standalone controller. What this means

You have a ZF 8HP, a BMW DKG or a Porsche PDK to run and a Link G4+, G4X or G5 managing the engine. There is no preset for Link, so this is a mapped-by-hand integration: you build the user stream yourself. The mapping below is known to work, and covers the torque method and the cut and blip route.

This page covers the ECU side. The transmission side — which controller to add and which transmission preset to pair — is on the per-transmission pages (8HP · DKG · PDK).

Choosing between devices? Which device do I need? settles it in one question, and compares the IOcan CAN gateway with the standalone transmission controller.

Covers the G4+, G4X and G5 lines, and the earlier Vi-PEC i-series and V-series, which share the same CAN architecture.

Compatibility summary
Preset name in the app None — mapped by hand. No Link preset has ever existed; see below
Torque broadcast No
Injector pulse width Yes, via a user-defined stream
Recommended torque method Fuel + Air (arbitrated)
Cut and blip route Hardwired on G4+. CAN should work on G4X and G5 — see below

There has never been a Link preset. A suggested mapping for the G4+ was published alongside the 1.0.17 firmware, which is sometimes remembered as preset support. It was not one, and no Link support of any kind exists in the current firmware — verified across the firmware, the CAN entities and the configuration schema. See Release history — legacy 1.x.

Link publishes no fixed stream carrying what a transmission driver needs, so the ECU side is always a user-defined stream. That is less work than it sounds: Link's CAN implementation uses no hidden or proprietary streams and both transmit and receive channels are fully user-configurable, so you build exactly the frame you want rather than parsing one you were given.

Do not use Transmit Generic Dash for this. It is a compound stream — the first data byte is a frame index and the payload rotates through a long channel list. It is designed for dashes that already know the layout. Build a user stream instead: fewer frames, fixed positions, only the signals you need.

Cut and blip: the G4+ needs two wires

This is the one structural difference from most other integrations on this site.

The G4+ receives CAN perfectly well — it just will not act on it as a command. You can send it values and it will read them. What you cannot do is trigger its gear-shift strategies from a received CAN value: the cut and blip requests have to arrive as a voltage on a physical input.

So the device's cut and blip outputs are wired to Link digital or analog inputs, and Link's own gear-shift functions trigger from those. Plan the harness for this from the start — it is two extra wires that are painful to add after the loom is taped.

Receiving data and being commandable by it are different things, and that is the whole of the difference from the other integrations here. Nothing about the CAN link itself is limited: telemetry flows normally in both directions.

G4X and G5 — the CAN route should work

On the later generations a received CAN value can trigger the shift strategies, so the two wires are not structurally required the way they are on a G4+.

Run them anyway. Two signal wires added during the build cost nothing; adding them to a taped loom because the CAN route did not behave costs a day. Wire them, prove the CAN route on your own firmware, and leave the wires unused if it works.

Generation Cut and blip
G4+ Hardwired only
G4X · G5 CAN should work — verify it, and build the wires in as a fallback

Wiring

  • One CAN bus between the ECU and the device.
  • The bitrate must match on both ends. Link's own defaults vary by document — set it explicitly on both sides rather than assuming.
  • Termination: exactly two 120 Ω terminators, one at each physical end. The device's is software-switchable, so enable it only if the device sits at an end. See CAN bus diagnostics.
  • Twisted pair, routed away from ignition and injector wiring.
  • Two signal wires from the device's cut and blip outputs to Link digital or analog inputs. Required on G4+, and worth building in on G4X and G5 as a fallback.

Setup

  1. ECU Controls → CAN Setup.
  2. Select the CAN module you wired to — CAN 1 or CAN 2.
  3. Set Mode to User Defined and set the Bit Rate.
  4. Pick a free channel, set its Mode to a transmit user stream, set the Transmit Rate and the CAN ID, and set Format to Normal.
  5. Build the stream to carry, at minimum: RPM, MAP, TPS, pedal position and injector pulse width. Add coolant and oil temperature if the driver you are pairing needs them.
  6. Note the byte order you selected. Link exposes this per stream, and it is the single most common cause of a signal that reads plausibly at idle and wrongly under load.
  7. F4 to store to the ECU.

A known-good starting point is a stream base of 0x600 on the device side, entered on the Link side as decimal 1536 and 1537. Link's CAN ID fields are decimal and the device's are hex — mixing the two up is a common first-hour failure.

In the configuration software

  1. Add a CAN bus at the matching bitrate.
  2. Add CAN bus inputs for each signal, matching the frame ID, start bit, length and byte order you set in PCLink. The CAN Analyzer's Custom Input builds these against live traffic, which catches a byte-order mistake immediately rather than under load.
  3. Assign the inputs to what your controller requires.
  4. Assign the gear cut and throttle blip outputs to device outputs, and wire them to the Link inputs.
  5. Set a Timeout and Timeout mode on every input feeding the torque estimate. UsePrevious holds a stale value forever and is the wrong choice on anything safety-relevant.

Configure the cut and blip responses against Link's own gear-shift functions, triggered from the two wired inputs. Start conservative and increase — an over-strong blip overshoots and an over-deep cut is felt as a lurch. See tuning a blip safely.

Torque signal setup and validation

Link does not broadcast an engine torque value, so the device must calculate it.

Recommended, in order:

  1. Fuel + Air (arbitrated) — injector pulse width is available in a user stream, and this method cross-checks it against an air model, so an over-reading injector signal is caught.
  2. Air Model — if the injector signal proves unreliable.

Both need the engine parameters and, for a good estimate, the VE tables. The full method reference, the correction maps and the all-or-nothing VE table warning are on Engine torque estimation.

Validate before driving. The torque value sets clutch pressure, nothing checks whether it is plausible, and under-reporting is the direction that slips and overheats clutches. On a gateway it also sets the depth of every shift cut, because the TCU's requested torque limit is rescaled against it.

Verification checklist

  • [ ] RPM tracks the ECU's own RPM channel.
  • [ ] TPS reads zero closed and full scale at wide-open throttle.
  • [ ] MAP is plausible at idle and tracks load.
  • [ ] Injector pulse width is present and scales with load.
  • [ ] Byte order is correct — check a signal at high value, not just at idle.
  • [ ] Cut and blip wires read at the ECU, confirmed by triggering each from the device with the engine off.
  • [ ] Engine torque is present, changing, and passes the verification points.
  • [ ] No mandatory-input faults are active.