MDB protocol: how it works

What MDB is for

A vending machine has one controller — the VMC — and a set of payment devices around it: a coin changer, a bill validator, a card or contactless reader. MDB is the common language between them. Because it is a published industry interface rather than a vendor protocol, a reader from one supplier can be fitted to a machine from another.

That is the practical reason the bus matters to an integrator: it is the seam along which an existing machine can be upgraded without replacing the machine itself.

Master and slaves

MDB is strictly master-slave. The VMC is the master and is the only device that may start a transfer; every peripheral is a slave that answers when polled and never speaks first. A slave that has something to report — a coin inserted, a card presented — has to wait for its next poll to say so.

The consequence for anyone writing firmware against the bus is that responsiveness is bounded by the poll interval, not by your own code. A design that assumes it can interrupt the master will not work.

Serial frame format

MDB runs as an asynchronous serial link at 9600 bit/s with nine data bits, no parity and one stop bit. The ninth bit is what makes the bus work: the master sets it to mark the first byte of a message as an address, and clears it for the data bytes that follow. Every slave therefore knows immediately whether a byte starts a new transaction addressed to someone, or continues one.

This is the single most common stumbling block when people try to bit-bang MDB from a general-purpose microcontroller: a standard UART configured for eight data bits cannot express the mode bit, and the usual workaround is to press the parity bit into service as the ninth bit.

Peripheral addresses

Each class of peripheral has a fixed address on the bus, so the master knows what it is talking to without any discovery step. The addresses an integrator meets most often:

Two cashless addresses exist precisely so a machine can carry two independent readers — which is how a fiscalization module can be added to a machine that already has a card terminal.

How a cashless sale runs

The sequence is short and worth knowing, because most integration bugs are a step performed out of order:

• The master resets the reader, reads its configuration, and enables it.
• The reader waits, polled continuously, until a customer presents payment.
• The master asks the reader to approve a specific item and price.
• The reader answers approved or denied; only then does the machine dispense.
• The master confirms the outcome so the reader can complete or void the charge.

The last step is the one that gets skipped, and skipping it is how customers get charged for product they never received.

Where our modules fit

FisLight sits in the harness between the machine controller and its serial periphery: it carries two independent UART channels and an inhibit line, so a fiscal device or printer can be added to a machine whose controller has a single free port. It plugs into the existing IDC harness instead of forcing a rewire.

Board-level documentation

Connector pinouts, terminal assignments, supply requirements and firmware notes are issued per board and per firmware revision, so they are sent on request rather than published as a page that can silently go stale. Tell us the machine and the board you are designing around and we will send the matching set.