Bit Error Rates for USB 3.2

Bit Error Rates and Snoopy’s rejection letters

Bit Error Rates (BER) in wired and wireless communication communicate the “allowable” or target number of errors (rejected or non-transmitted data) that can occur over some given time. Usually this is measured of a period time like a second.

Wired interfaces enable faster speeds because a hard wire has less ways it can be interfered with on the path from one product to another.   Even wired interfaces like USB and Ethernet, basically any wired interface port, generates https://en.wikipedia.org/wiki/Electromagnetic_interference which can interfere with data transmission inside or outside the device.   For example, Electromagnetic Interference (EMI) in PCs is tightly regulated by the FCC in the U.S.  For USB specifically, the BER tolerance is low because it’s a wired interface.

The FCC does not regulate hair dryers and thus can emit enough EMI to bring down a nuclear power plant.

Wireless interfaces tend to be slower.   Wireless signals travel through the air and things like other wireless standards, dry wall, wood beams, steel beams, brick and mortar, microwave ovens, radio signals, x-ray machines and radioactive bananas can interfere with your WiFi or phone signal.

So here on Tuesday, or what I call Pre-Wednesday, we have a blog about USB.

What are the BER allowed by USB? How does USB 3.2 deal with errors?

Short answer: Detect, retry 3 times, let software or user decide to continue to retry or stop the device and return to manufacturer as a defective product.

At the physical layer, (PHY) bit error rate allowed is 1 bit in 10¹² bits.   The lower allowance for BER is because there are several layers that impact this, the transmitting PHY, the receptacle, the cable, the cable quality, the receiving receptacle, and the receiving PHY.

From the USB 3.2 specification, “To provide protection against occasional bit errors, packet framing and link commands have sufficient redundancy to tolerate single-bit errors. Each packet includes a CRC to provide error detection of multiple bit errors. When data integrity is required an error recovery procedure may be invoked in hardware or software.”

Specifically, if the CRC detects an error either the software or the hardware (controller) will initiate a request to re-transmit the data. This is done in the Link and Protocol layers of the controller.  The same request should/can be done by the host controller up to 3 times. After that, the software/driver can take over and either reset and try again, or somehow notify the system that the transmission has failed.

More errors and retries will drive down overall throughput.

A better receiving PHY can clean up issues all along to help receive and reduce the rate of errors. For example in our USB 3.1 PHY. We demonstrated with Keysight how the PHY recovers data with a lot of margin https://blogs.synopsys.com/tousbornottousb/2017/06/09/fabulous-usb-3-1-phy-margins/

At the link layer which is inside the digital logic of the controller the BER is 1 bit in 10²⁰ bits.  The expectation is that once the data is inside the silicon, there should be few errors so strict standard is reasonable.  Again, if an error is detected through CRC, up to 3 retries by the controller can be attempted.

NOTE: The reason the USB-IF allows software to make the decision on the final number of retries or recovery is it is possible to allow for the user proceed even with a bad connection at a slower speed.

On the PHY side, if an error is detected on the PHY

USB defines four general types of transfers.

Control transfers – used to configure the device.  For example, “I am a mouse, and I will be sending you clicks and changes in x,y coordinates as a interrupt transfer.”  Control transfers require little bandwidth and 100% accuracy.  Since the packets are small, USB just retries. If for some reason this data can’t get through when the peripheral is connected, the device will never be recognized and won’t work. It won’t work because the host doesn’t know how to communicate with the peripheral.

Interrupt transfers – used to send short, simple data through like keyboard, mouse, touch pad, touchscreen, or game controller.  A few dropped packets is okay.

In general for Control and Interrupt transfers the amount of data is so small that a few retries will not impact overall throughput.

Bulk transfers – used to transfer data with 100% accuracy. For example, if you print a picture, every pixel must be correct.   For Bulk Transfers, retries need to continue until either the data is transmitted correctly or the device is timed-out by software and informs the user the USB peripheral isn’t working properly.

Isochronous transfer – used to stream data but packets can be “lost”. Used for streaming video and audio.  In this case, packets can be dropped often because the next frame of video or audio must be delivered to keep streaming.   In this case no retries are attempted. This means that lots of BER will mean terrible streaming of the video for incomplete or bad pictures and or poor audio.

That’s it.

Here’s an XKCD that has something wireless transmissions over solar system distances.

https://imgs.xkcd.com/comics/%3F%3F%3F.png

The greatest impediment to writing a weekly column or blog continues to be ideas with depth that speak to the reader. So this week’s inspiration is provided by Snoopy.

It has to do with Rejection Letters and bit error rates.

Here’s the first comic

https://buildingapoem.files.wordpress.com/2015/08/snoopy-on-rejection.jpg

Here’s the second one

https://midmiocene.files.wordpress.com/2016/06/writerc004.jpg

Formal definition of Transfer Types from the USB 2.0 specification

“The USB defines four transfer types:

• Control Transfers: Bursty, non-periodic, host software-initiated request/response communication, typically used for command/status operations.
• Isochronous Transfers: Periodic, continuous communication between host and device, typically used for time-relevant information. This transfer type also preserves the concept of time encapsulated in the data. This does not imply, however, that the delivery needs of such data is always time-critical.
• Interrupt Transfers: Low-frequency, bounded-latency communication.
• Bulk Transfers: Non-periodic, large-packet bursty communication, typically used for data that can use any available bandwidth and can also be delayed until bandwidth is available