Vending Mechine - MDB Port. RRS feed

  • General discussion

  • I need to interface with a vending machine.  I am told I can connect to the MDB port via a RS232 cable.  But I have been told that it is not a standard RS232 serial connection and 9 bits not 8 bits are used.  Can I set this within software or do I need to have a special serial port include in my board design? 



    Monday, December 27, 2010 8:56 AM

All replies

  • I don't know what an "MDB port" is. Without that knowledge, I think we're just taking guesses.  Surely the device to which you are connecting has a specification for this port, if they expect you to use it to communicate with the device.  Perhaps there is additional hardware that you can use to connect directly from a device to the MDB port on the equipment.  Look at this thread:

    Without information, you'll never make it work so start actually trying to understand the port.

    Paul T.

    Monday, December 27, 2010 3:58 PM
  • Hi Paul

    We were provide this link from Pepsi.




    Monday, December 27, 2010 11:00 PM
  • A quick glance in the pdf shows that the protocol uses 1 extra bit, a
    mode bit. The RS232 cable probably has one extra wire in it that you
    connect to a GPIO that you use to control the mode bit during standard
    RS232 transactions.
    This should be a pretty standard addition to a cable, and software wise
    it's pretty easy to implement as well.

    Good luck,

    Michel Verhagen, eMVP
    Check out my blog:

    Microsoft Embedded Partner
    Consultancy, training and development services.
    Monday, December 27, 2010 11:36 PM
  • The way I read it, there were actually 9 data bits in the serial stream sent on the TX wire, rather than 8. The 9th bit is the mode bit, as you said, but I don't think it's a different signal on the cable.  Page 59 has a connector diagram.  For whatever reason, these guys did something really dumb by making it so hard to do this communication with an ordinary serial port. 

    National Instruments has a short article about their hardware and LabVIEW that might be useful, as it talks about using MARK/SPACE parity bits to read/write the extra data bit used by this bus.  It's not detailed and tells you nothing about to implement this on your hardware or inside Windows CE, but should give you a little better idea of what you're actually going to be doing:

    To make this work on your hardware, you're going to need to create a customized serial driver.  The driver will have to do something on each send/receive to handle setting/getting the state of the MODE bit from the serial data stream.  If you plan to return the bit to an application and have the application implement the protocol for communicating with the bus devices, you'll have to create a new driver interface to handle that. 

    I'd be inclined to create a simple stream driver and create some custom IOCTL values to send complete commands and receive responses to an RS-232 port, adjusting the parity handling to implement the extra data bit.  That is, the driver would know all about where the MODE bit is supposed to be set and cleared, would handle sending packets in the right format, verifying the responses, checking for time outs in receiving replies from peripherals, and would then return just the important data from the responses to the application. The application can then completely ignore the low-level communications and worry only about what commands and what data associated with them it needs to send to the driver.  For example, to poll a peripheral you might create the following code in the application:



    poll.peripheralAddress = 6;

    if ( DeviceIoControl( mdbDriverHandle, POLL_PERIPHERAL_IOCTL, &poll, sizeof( poll ), &resp, sizeof( resp ), &bytesRet, 0)  )


        // Handle successful result.




        // The call failed.  The driver might have indicated a failure, the handle to the driver might be wrong, there might have been a bus

        // time out, or the data passed might be invalid.  You can call GetLastError() to get an error code to help you diagnose the error.


    What's going on here is that we've created some structures designed to hold data passed to the bus by our custom driver and to receive data returned from the bus.  We've created a set of IOCTL code values that our driver understands and that the application uses to command various things to happen.  After opening the driver, we can start sending MDB bus commands to the driver in this way.  The driver handles detecting 5ms time outs, verifying that the data format returned by the polled peripheral is correct (returning an error code otherwise), and handling the encoding of the MODE bit into the serial data stream.

    Paul T.

    Tuesday, December 28, 2010 3:56 PM
  • Hi, you could be use a interface for MDB protocol, there are a few of this interfaces, I would recommend to you a interface specially designed for Visual Studio, the interface name is EasyMDB

    ingeniero electronica

    Monday, April 21, 2014 1:59 PM
  • Hi,

    I have seen some microcontrollers which uses 9-data bits. The ninth bit is used to indicate that this byte is address byte. So that the processor or controller is interrupted for this byte and not for the rest of the next sequence of data bytes.

    For example the sequence will be as below

    ADDR Byte DATA Byte -0 DATA Byte -0 DATA Byte -1 DATA Byte -2 DATA Byte -N
    9th Bit Set 9th bit not set 9th bit not set 9th bit not set 9th bit not set 9th bit not set

    If you see above for the first byte in a data stream 9th bit is set. For the rest of bytes its not set. So that all the devices connected on the bus will check with the address set on the device. If the address didn't match then the processor will not be interrupted for the rest of the bytes.

    For more information you may refer to Page-48.

    If looks the MS API's itself doesn't support a 9-Data Bits in RS-232. I guess it may not be possible to change the number of data bits using MS API's.



    Wednesday, April 30, 2014 6:09 AM