Binary: [1 1 0 1 1 1 1 1] [1 0 0 0 0 0 1 1]
This unsolicited report reports that the DTE (computer) sent data to the Slink-e too fast for the Slink-e to take it, ignoring RS-232 handshaking.
The Slink-e is limited in how fast it can take data on the programming interface. It has a finite buffer for storing data received and there is a fixed rate at which it can send data out the other side as port messages. Therefore, it uses RS-232 CTS/RTS handshaking. It asserts CTS (Clear To Send) only when it is able to accept data (it has buffer space available). When it is almost out of buffer space, it deasserts CTS, which tells the DTE to stop sending as soon as possible. When the Slink-e has buffer space again, it asserts CTS again and the DTE can resume sending.
The overrun error can occur only if the DTE ignores CTS and keeps sending in spite of it. It is usually possible to configure a DTE serial port to ignore CTS, and that would cause this problem. With a traditional UART, a serial device driver is responsible for noticing that CTS is not asserted and refraining from sending. In unix, you can use the stty program to turn CTS/RTS handshaking on and off in the device driver and query its state.
Modern UARTs have a small buffer within themselves, so the operating system device driver cannot shut the stream off immediately. Therefore, DCEs such as Slink-e allow a margin of buffer space.
Slink-e Version 1.0 has a 55 byte receive buffer and deasserts CTS when it has 32 bytes left, so the DTE has a margin of 32 bytes in which to stop sending. Nirvis says its testing shows that this is more than sufficient for operation in Windows 95 and Windows NT 4.0.
Nirvis documentation says the Slink-e sends one Command Data Overrun report for each byte it must discard due to overrun, but it also says that the Slink-e enters the Needs Resume state when it recognizes the error, which is a contradiction, because that would prevent Slink-e from recognizing any further overrun after the first byte.
Note that by the time you see this report in high levels of your Slink-e control program, you've probably already sent a lot more data from that level. It's hard to tell exactly where the overrun occurred.
This is always unsolicited. It reports a synchronizing error.