2
\$\begingroup\$

I am very curious to see how a USB signal looks like but couldn't find any related article and graph still. Is it possible to see the shapes of USB and TTL data signals by using an oscilloscope. Will they be square waves and look like very similar?

My question may sound a bit weird but I always read that USB is very complicated to understand so at least I was hoping to visualize the change in USB signal when it is converted to RS232. The graphical representations in time domain. Time vs Amplitude.

I have many questions in my mind such as: "Is USB serial data less noisy than RS232? ect."(under the same circumstances with RS232) I really want to see how both USB and TTL data looks like.

I found a nice article with waveforms of RS232 and TTL. Here seems TTL is more noisy waveform than RS232 which is converted by MAX232.

But still couldn't find about USB.

\$\endgroup\$
  • 4
    \$\begingroup\$ When you just want an oscilloscope snapshot: here is one \$\endgroup\$ – PetPaulsen May 7 '12 at 18:27
  • \$\begingroup\$ USB 2.0 or 3.0? 3.0 is much faster and requires much more care. \$\endgroup\$ – Brian Carlton May 7 '12 at 20:31
11
\$\begingroup\$

USB - Universal Serial Bus - Signaling (WikiPedia)

The real problem with USB is not in the physical signalling. Say you capture a waveform with a scope right after the device is connected. It's likely to be a part of a Setup packet which is a part of a control transfer which is a part of a descriptor request which is a part of device enumeration, and that's only to have your device recognized by the host. Actual data transfer hasn't even started yet, and it will be wrapped inside transfers (of 4 different kinds) to some endpoint belonging to some interface that implements some device class, standard one like HID or completely custom. It's a lot like trying to understand HTTP by looking at Ethernet signal with a scope. In fact, you'd probably have a hard time finding your UART data even in a USB sniffer log (unlike a TCP/IP sniffer, a USB sniffer may well not know the exact protocol that e.g. FTDI uses to transfer data).

Together with the great USB in a Nutshell tutorial (HTML version), I found this book to be an excellent reference if you actually want working knowledge of USB to e.g. create your own USB devices.

\$\endgroup\$
  • 3
    \$\begingroup\$ "It's a lot like trying to understand HTTP by looking at Ethernet signal with a scope" is very accurate, but only really useful to the small segment of people who know about the Ethernet stack but not the USB stack. Perhaps "It's a little like trying to learn English by looking at a bunch of captchas" or "It's a little like trying to read a book by looking at the output of a paper shredder" would more clearly convey the problem to someone new to communication protocols? \$\endgroup\$ – Kevin Vermeer May 7 '12 at 19:34
  • \$\begingroup\$ Studying any data set (text, code, whatever) by looking at the individual bits? \$\endgroup\$ – Wouter van Ooijen May 8 '12 at 12:46
6
\$\begingroup\$

Electrically, USB signaling occurs serially over a single differential pair (D+ and D-). I think the complexity you are alluding to is at the protocol level. Have you had a chance to read through USB in a Nutshell? It's a decent primer.

\$\endgroup\$
  • \$\begingroup\$ even in that article you gave in the link has NO SINGLE graph of USB data in time domain. I am loosing my hope.. Experiment is important and no graphical results found yet:( \$\endgroup\$ – user16307 May 7 '12 at 18:07
  • 4
    \$\begingroup\$ @cmd1024 IMHO looking at USB signalling with a scope won't help you understand the protocol. You'd probably have to capture and analyze a fair amount of data to observe anything meaningful, even if it's just a few bytes being transmitted to a RS-232 transceiver. You're better off using a USB sniffer. \$\endgroup\$ – lhballoti May 7 '12 at 18:39
  • 4
    \$\begingroup\$ @cmd1024 The link vicatcu gave you was great. I suggest that you go back and read it, word for word, and work at understanding it. Once you do that you'll understand why a scope picture (that shows more than just a couple of signal transitions) isn't very useful. That document also covers other thing, like signal noise and error recovery. \$\endgroup\$ – user3624 May 7 '12 at 18:44
3
\$\begingroup\$

Looking at USB signals will tell you very very close to nothing at all. The correspondence between the TTL output signals from a USB to TTL converter and the corresponding USB signal that produced the TTL signal will be absolutely and completely inobvious to the eye/brain in real time and would bve able to be determined from a recording only by an expert who was absolutely steeped in the subject.

Some eye diagrams for variants of USB may be found via a Google image search such as can be seen here.

Here are eye diagrams for the new USB 3 system as produced by a Le Croy QPHY USB3 analyser

http://www.lecroy.com/images/serialdata/qphy-usb3-tx-rx-03.png


I do not know what system the eye diagrams here are for but they give excellent illustrations of changes in eye shape and amplitude with increasing data rates.

One sample:

enter image description here

\$\endgroup\$
  • \$\begingroup\$ OMG mate, this USB business seems more complicated than I predicted. but thanks for the great information! I don't know how to read or interpret these diagrams by the way. \$\endgroup\$ – user16307 May 7 '12 at 20:25
  • \$\begingroup\$ @cmd1024, these are eye diagrams. They are not the real signals, but real signals put kinda on top of each other to create this shape. Check this blog post out for more info. \$\endgroup\$ – abdullah kahraman May 8 '12 at 7:01
2
\$\begingroup\$

Yes, USB signals are less noisy.

USB's main claim to fame is that it is differential. Instead of having a signal referenced to ground (this is called "single ended"), there are two signals referenced to each other. When one is high, the other is low. This keeps the circuit loop very small, which makes it harder to couple inductively. Since the lines are close to each other, anything that capacitively couples will couple to both lines; so any noise injected onto one line is also injected onto the other line, and the differential receiver can reject it (the receiver's ability to do so is referred to as "common mode rejection range")

Imagine you have two wires, one is 5V the other is 0V. Now lets say a noise spike injects one volt onto both lines. Now they're 6V and 1V. A single-ended receiver would see 6V as a result of this noise. A differential receiver sees the difference between 6 and 1 is the same as 5 and 0, therefore it doesn't see any noise.


What does it look like on a scope? While Russell's eye diagram looks pretty, the eye diagram is more of a diagnostic tool, and not an example of real-world data transmission.

A differential "1" is D+ high and D- low. A differential "0" is the reverse, D+ is low and D- is high. So if you hooked it up to a scope, you'd see the two traces move opposite of each other; when D+ goes high, D- will start going low simultaneously, and vice versa.

Beyond this point, it gets terribly complicated. For instance, USB is an NRZI protocol. Instead of a differential 1 representing a "1" bit from the PC, a "1" bit from the PC is encoded as a transition. So a 1 bit would be either a differential 1 transition to a differential 0, or a diff0 transition to diff1. Meanwhile, a "0" bit is encoded as no transition. These transitions are important because USB's clock is implicit in the data, therefore the USB protocol requires bit stuffing (the act of inserting "fake" "1"s into the data stream) to ensure that a transition happens often enough that the clocks can stay synchronized to each other. Without bit stuffing, a very long string of 0s could result in a loss of synchronization; the host could send 500 "0"s and the device receives 499 or 501 "0"s.

RS232 also has an implicit clock in the data. However, instead of bit stuffing, the start and stop bits will ensure that a transition occurs every so often.

On top of bit stuffing, you have the rest of the software protocol to worry about. RS232 is pretty much just an electrical standard that determines how you signal 1 and 0, and it leaves interpreting those 1s and 0s up to the devices. There aren't any headers, for instance. USB is quite different. A small portion of the USB traffic is not your data, but instead "management". For instance, a data packet has a 16-bit CRC of the data you're sending; this CRC will be used to re-try any non-isochronous transfers that have errors. There are even other packets that are totally unrelated to your device going around on the wire, for instance the sync packet that goes out at the start of every microframe.

Even the very act of sending data to the PC requires first that the PC send an IN token to the device. The PC owns the wire, and the device is not permitted to send any data until the PC asks it to. This IN token is another example of additional traffic on the data line that USB requires and RS232 does not.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.