EDIT My Fault - EMU Black flooding CAN bus — 4 stream frames sent at ~800 Hz while RPM (0x600) starved to <100 Hz. Root cause?

EDIT: I was using the analyser in listen only mode, so the stream wasn’t properly properly ACKed. When i turned off listen only the stream was perfect. Leading me to believe the cheap Can Transceiver I was using is CACTUS!!!

Hi all , Hoping someone can help me understand some genuinely strange CAN behaviour on my EMU Black, verified with an independent USB-CAN analyser.

Setup:

  • EMU Black, firmware 2.169 (device name E30318isEMUBLACKv2)
  • CAN bus @ 500 kbps, EMU stream base ID 0x600
  • Bus: EMU + one custom ESP32 dash, correctly terminated (measured 60 Ω, two 120 Ω)
  • “Send EMU stream over CAN-Bus” ✓ enabled

Symptom: I have built an esp32 screen to relay important info for my E30 build (direct can bus). Lambda and other values, like OilP OilT CLT etc. update in real time, but RPM and VSS lag by several seconds and barely register throttle blips. I previously used BTCAN, Same behaviour previously on a Bluetooth/BTCAN setup, so it’s transport-independent.

What the CAN analyser shows (DSD TECH SH-C30A / CANable, cangaroo, listen-only, engine idling):

The EMU is putting ~3,300 frames/sec on the bus — far more than a standard 8-frame stream should. Broken down per ID:

Frame Rate Unique payloads in capture
0x601 (AIN) ~820/s 1 (constant 00 00 00 00 00 00 00 00)
0x603 (lambda/ign) ~800/s changing
0x606 ~850/s changing
0x607 ~770/s 1 (constant)
0x600 (RPM) ~90/s, sometimes 0
0x602 (VSS) ~48/s, sometimes 0
0x604 ~50/s 1

So four frames (0x601/0x603/0x606/0x607) are being transmitted at ~800 Hz each — including 0x601 and 0x607 which are sending the exact same static payload hundreds of times per second — while RPM (0x600) and VSS (0x602) are crowded out to <100 Hz or drop out entirely for up to ~1.3 seconds at a time. There are also ~280 error frames/sec on the bus.

This fully explains my dash symptom: RPM is barely being transmitted, so it can’t be displayed smoothly.

What I’ve already ruled out:

  • Confirmed on an independent analyser with my dash powered completely off — the flood is 100% the EMU/Can, not my hardware/wiring/code.
  • CAN config panel is clean: EMU stream on, base 0x600, terminator internal OFF, BTCAN OFF, OBD2 OFF, Bosch ABS None, CAN dashboard None.
  • ECM keyboard, ECM switch board, and PMU keyboard are all DISABLED.
  • Termination verified correct (60 Ω); tested with analyser terminator both on and off — no change.

My questions:

  1. Why would the EMU transmit four stream frames at ~800 Hz (with static data) while starving RPM/VSS? Is this a known firmware behaviour or bug?
  2. Is there any setting that controls per-frame transmit rate on the Black (V2 software) that I might be missing?
  3. Would updating firmware (2.169 → latest, or V3 software) be expected to fix this? NOT IDEAL, but if proven solution i’ll do it.
  4. Are the ~280 error frames/sec a cause or a symptom here?

Happy to share the raw .asc analyser logs. Any insight appreciated — this has been a long chase and I’ve isolated it to the EMU’s CAN output.

Thanks!

Great find!

Basically, your adapter is not at fault.
If you have only one device on the bus emitting frames and nothing to ACK them, then error frames are emitted. Listen mode of an adapter does not provide the ACK. Just put it in normal mode and everything should be back to normal.

You can use listen mode, but the dash would have to be on and ACK’ing to keep the bus happy.