MDB compliant, still not talking: the failure modes you actually meet
The machine doesn't see the cashless device. The reader works on one model and not another. It fails only during a transaction. Here is what actually causes MDB interoperability failures, and the order to diagnose them in.
Our explainer on the MDB protocol opens on a promise: any compliant coin mechanism should drop into any compliant machine. That promise is the entire reason the standard exists.
In the field it does not always hold. The device says “MDB compliant” on the box, the machine says “supports MDB” in the datasheet, you put them together, and nothing happens. Or worse — it works for a week and then stops.
The cause is usually not the one people reach for. This is what it actually is, and the order to look in.
Why “compliant” is not a guarantee
MDB is a document. What ships inside the machine and inside the device is firmware.
Two engineering teams read that document independently, years apart, and write code. Where the document is explicit, they agree. Where it is silent, marks something optional, or admits two readings, they choose differently. Interoperability dies in exactly those gaps.
So what you are usually looking at is not a fault. It is two defensible interpretations failing to meet. That distinction is practical, not philosophical: hunting a fault gets working hardware returned, hunting an interpretation gap finds the problem.
Diagnose from the bottom up
Most calls arrive as “the device is dead”. Almost none of them are. There are four layers, and you have to start underneath — start at the top and you will RMA a perfectly good unit.
1. Power — the most common, the most misdiagnosed
The MDB harness carries power as well as data. A peripheral draws very little at idle and a lot while working: reading a card, lighting a display, and especially bringing up a cellular link.
If the machine's MDB rail cannot supply that peak, the rail sags at precisely the moment of the transaction. The device browns out, the controller loses it, it comes back.
The symptom is diagnostic on its own: the device is fine at idle and only dies mid-transaction. The service menu says the device is present; the moment a customer taps a card it is gone. This looks exactly like a software problem, and a great many healthy units have been returned because of it.
Long harness runs make it worse — the voltage drop along the cable peaks at the same moment the load does.
2. Bus — wiring and addressing
MDB is opto-isolated and polarised. A reversed pair will not damage the device, and it will not communicate either. Nothing happens, silently.
On the addressing side the classic error is this: the cashless class has two addresses, 0x10 and 0x60. A machine already has one cashless device fitted, a second is added, and both talk on 0x10. Two devices answering the same poll turn the bus into noise, and the controller loses both. The symptom misleads because the device that used to work is now broken too.
3. Enumeration — what happens at power-up
The controller decides which peripherals exist at start-up: it polls the addresses in turn and records who answers. That window is short.
If a device has not finished its own boot before the window closes, the controller marks it absent and does not ask again until the next reset. The device is working perfectly. Nobody is talking to it.
The symptom is familiar: “power-cycling the machine fixes it”, or “it works if we power the device first and the machine second”. Every installation ritual involving a sequence is an enumeration problem wearing a disguise.
Reset behaviour lives here too. After a bus reset, does the device re-announce itself, or wait to be asked? Where the document is not explicit and the two sides chose differently, the device sits in an inactive state forever.
4. Session — where the money goes missing
This is the expensive layer, because here the device is working. Only the ordering is wrong.
A cashless sale is a short state machine: authorise → dispense → settle. The protocol deliberately takes the money after the product drops. But when something goes wrong in between — a spiral jams, the machine reports a failed vend, or the link drops at that exact moment — the question becomes who reverses the session, and when.
If the two sides interpret that reversal point differently, you get one of two outcomes: the customer is charged and gets nothing, or the product goes out and nothing is charged. The second one goes unnoticed for weeks. It shows up as a cash reconciliation that never quite balances.
This is a protocol problem dressed as an accounting problem. It is worth checking before anyone starts recounting the cash box.
And: optional commands
The specification marks some commands optional. If a controller treats an optional command the device never implemented as mandatory, it rejects the device outright.
The symptom is unmistakable: the same device works flawlessly in one machine model and not at all in another. Both are healthy. They simply cannot meet.
Where this knowledge comes from
Between 2005 and 2020 we worked with vending manufacturers' engineering teams to identify MDB interoperability problems in the field and get them resolved in firmware. Every item above comes out of hours spent standing in front of a machine.
DMS Tech is registered in the European vending data transfer standard (EVA DTS) under the manufacturer code DMS — serial numbers and fault codes on units in the field carry that prefix.
It is better now — but the machines are still out there
Honestly: most of these show up less often than they used to. Manufacturer implementations improved, the specification matured, and the gaps it used to leave open have narrowed.
The installed base did not refresh on the same schedule. A machine commissioned in 2008 or 2012 is still earning, and every item above still applies to it.
Which is why the real question is usually not “how do I fix this MDB problem” but “is this machine worth upgrading”. If the answer is yes, the path is clear: Hero Nexus joins the bus as a cashless peripheral, the machine's own controller is left untouched, and the machine starts taking cards, contactless, meal cards and QR. If the machine itself needs to move on, that is where Smart VMC comes in.
If the answer is no, we say that too. In a thirty-year-old protocol, not every fault is worth fixing.