Definition
MDB (Multi-Drop Bus) is a master-slave serial communication bus protocol developed by the European Vending Association (EVA), widely used for communication between the payment modules, metering modules and the main control units of devices such as vending machines, charging stations, and self-service terminals. MDB uses a 9-bit serial, master-slave polling architecture, supporting data interaction between peripherals such as coin acceptors, bill validators, card readers, and meters with the main controller. In charging station scenarios, MDB is commonly used for communication between the payment modules (card swipe, QR code scan) and the main controller, as well as between metering modules and the main controller, enabling charging billing and payment settlement. In cross-border charging scenarios, MDB devices need to interface with charging platforms and OCPI, reporting metering values and transaction data via cellular networks.
Technical Features and Architecture
The MDB technology architecture includes: Physical layer — 24V differential signal, 9.6 kbps serial communication, maximum bus length about 60 meters; Protocol layer — master controller polls each slave device (Address + Command + Data), slave devices respond; Device types — coin acceptor, bill validator, card reader, display module, metering module, etc.; Data format — BCD coding, fixed frame structure. Combined with metering , MDB can transmit measured values such as electricity quantity and power metering values ; combined with EV charging stations , it can achieve integrated payment and billing. In cross-border scenarios, MDB devices connect to the cloud via IoT SIM cards to report metering values and transaction data to charging operation platforms , supporting cross-border settlement and data synchronization .
Application in IoT and cross-border scenarios
MDB is widely used in: EV Charging Station Payment —— Payment modules inside EV charging stations (card swipe, QR code scan) communicate with the main controller via MDB, metering modules report electricity usage through MDB, the main controller reports metering values and transaction data to the charging platform via cellular network; Self-service Vending ——vending machine payment, dispensing, inventory management; Cross-border Charging ——EV charging stations deployed overseas perform local billing via MDB, and send data back to the domestic charging operation platform via IoT SIM cards, supporting one card in multiple countries to ensure cross-border network connectivity. SimtoLink provides MDB EV charging stations and other devices with connectivity covering over 200 countries to facilitate cross-border charging data return and remote operations.
Master-slave polling only covers the span inside the cabinet
MDB means the controller inside a cabinet or a charger polls slave devices by address. Slaves include bill validators, card readers, display modules, or meters. The controller sends an address and a command, and the slave answers within a set time. A device that was not addressed should not seize the bus. The bus uses a fixed electrical format and frame format, and its length is limited by wiring inside the cabinet. It answers "how does the controller know about this coin or this unit of energy." It does not answer how the charger reconciles with a platform abroad. The cellular module is usually on the other side of the controller, and it sends out a result the controller has already summarized.
MDB requires that slave addresses do not collide, that bus power and the termination match the product's wiring, and that the controller software actually implements the command subset of the slaves in use. Connecting the wires without implementing the commands produces no answer to the poll. If a cross-border charger adds a local card reader, confirm that the controller is already configured with that reader's address and currency scale. The scale and the decimal places are business parameters in the controller. The bus levels cannot express them. A bus fault should be logged locally. There is no need to send every poll frame abroad.
Treating a bus frame as a cloud invoice
Uploading an MDB capture unchanged, and expecting the platform to parse a settlement amount from it, puts the frame in the wrong place. Values in the frame depend on the controller's current scale factor and on the session context. A single frame taken out of the session cannot reconstruct the transaction. Another error is to treat a change in an energy pulse on the bus as proof that the platform bill has already been updated. The platform bill comes from a report the controller summarized under an agreed protocol, and cellular failure can still delay it. Hot-plugging a slave during repair without assigning the address again makes the new card reader collide with the old address, which shows up as random failures to answer.
After a payment module is replaced across a border, changing only the cloud price list and not the scale inside the controller makes the local charge and the platform record differ by a stable factor, and the interface does not report an error. Troubleshooting should read the session summary on the controller first, then the cellular report, and only then the bus waveform. A bus problem should not trigger deactivation of the whole unit. Settlement files exchanged with an external partner go through an agreed interoperability interface. How the charger reaches the platform is networking. Whether polling inside the cabinet is healthy is the earlier of the two segments.
After a slave is replaced, read the address and the scale on the controller first, then run one small local transaction, and only then see whether the platform received the summary. Skipping the local transaction and looking at the cloud cannot tell a bus that did not answer from a report that is only delayed.