Avian’s Blog

In conclusion of my recent series on the simple matter of USB cable resistance, I would like to attempt the question of what is a good USB cable. After having a reliable measurement of a cable's resistance, the next obvious question is of course whether that resistance complies with the USB standard and whether such a cable is suitable for powering single-board computers like the Raspberry Pi. Claims that most cables don't comply with the standard are quite common whenever this topic is discussed. I'm by no means an expert on USB, but luckily USB Implementers Forum publishes the standards documents in their on-line library. I went in and studied some of the documents on the Cable and Connector Specification topic which, among other things, specify cable resistance.

I've started my reading with USB 2.0, because micro- and mini-USB cables I tested in my previous post are unlikely to be older than USB 2.0. The standard is now nearly 20 years old and over the years it seems to have received many revisions and updates. Hence it's hard to pick up a random cable from the pile and say with certainty with which document it should comply. In addition, I find that the text of the standard itself often isn't particularly clear. For example, the following text implicitly defines the maximum allowable cable resistance in the Universal Serial Bus Cables and Connectors Class Document, revision 2.0 from August 2007:

Image by USB Implementers Forum

Initially I thought this means voltage drop over the pair of wires. As in, total voltage drop over VBUS and GND wires should be less than 125 mV at 500 mA (effectively 250 mΩ round-trip resistance). However the fact that most cables seem to be around 500 mΩ suggests that manufacturers read this as 250 mΩ per wire (500 mΩ round-trip).

A later document amends this definition somewhat and makes it clearer that the voltage drops are for each wire separately and that this voltage drop includes contact resistance. The following is from Universal Serial Bus 3.0 Connectors and Cable Assemblies Compliance Document, revision 1.0 draft from October 2010. Also note that both the measurement current and the allowable voltage drop were increased. The measurement must now be done at 900 mA, however maximum effective single-wire resistance is still 250 mΩ, same as in USB 2.0:

Image by USB Implementers Forum

An even later document addresses cable compliance with older revisions of the standard. USB 3.1 Legacy Cable and Connector Revision 1.0 from 2017 contains this calculation:

Image by USB 3.0 Promoter Group

This equation clearly shows that the 250 mΩ figure from the other documents is supposed to be combined from two 30 mΩ contact resistances and a 190 mΩ wire resistance. It also multiplies the voltage drop by two due to the round trip through both VBUS and GND wires.

USB type C specification tries to make this even clearer and comes with schematics that explicitly show where voltage drop must be measured. Since in USB type C you can have different types of cables that are rated for different currents, that standard only specifies maximum voltage drop. Note also that in type C the requirements for the VBUS line were relaxed compared to previous standards. Previously, for a cable delivering 1 A of current, the VBUS line must have had a maximum resistance of 250 mΩ while in type C up to 500 mΩ is allowed.

Image by USB 3.0 Promoter Group

7 out of 12 micro USB and 5 out of 6 mini USB cables I found at my home have less than 500 mΩ round-trip resistance. So according to my understanding of the standard for pre-type C cables, roughly 70% of my cables comply with it. Here are my resistance measurements plotted versus cable length. I've also included measurements published by Balaur on EEVblog and martinm on their blog. Points in the shaded area represent cables that comply with the standard.

So strictly according the USB standards, the situation out there isn't perfect, but it doesn't look like the majority of cable are completely out of spec either. This seems a bit at odds with the general opinion that finding a good cable for running Raspberry Pi is hard. However, things start getting a bit clearer when you look at what exactly Raspberry Pi boards demand from these cables.

In the following table I've extracted maximum required power for all Raspberry Pi model Bs from the Wikipedia article. These boards will display the infamous under-voltage warning when their power supply voltage falls under approximately 4.63V. Assuming a perfect 5 V power supply, this is enough data to calculate the maximum allowable cable resistance for powering these boards:

Raspberry Pi model Bs after version 2 appear to require cables with resistance well below 500 mΩ that the standard requires for micro USB cables. Only 3 cables from my collection would be able to power a Raspberry Pi 3 model B. Raspberry Pi 4 gets a pass because the type C standard is flexible enough and doesn't directly specify cable resistance (although its type C implementation has other power-related issues). Yet, since type C cables have 750 mV maximum voltage drop at rated current, it requires a cable rated for 3 A or more according to this estimate (I'm not sure if Raspberry Pi 4 uses the same APX803 voltage monitor as earlier versions).

Also note that this calculation is for a perfect 5V power supply, which is optimistic. Power supplies don't have perfect regulation and the calculations in the USB standard assume worst case 4.75 V at the source. Such a worst case power supply, even if it provides sufficient current, would require practically zero ohm cables to power a Raspberry Pi without under-voltage warnings and associated CPU throttling.

To sum up, yes there are USB cables out there that are out of spec. However based on this limited sample, most micro and mini USB cables do seem to actually comply with the standard. Also worth noting is that shorter ones tend to have a better chance of being compliant. On the other hand, at least part of the blame for the grief surrounding USB cables appears to fall onto the Raspberry Pi itself since they designed their boards with an requirement for better-than-the-standard cables and power supplies.

After I made my USB cable resistance tester I naturally wanted to measure some cables. I searched my apartment and ended up with a big jumble of 18 micro and mini USB cables of various lengths and origins. I didn't imagine I would find that many, but I guess today just about everything comes with one and I apparently never throw away anything. In fact some cables were in a very bad shape and already had insulation flaking off from old age.

I measured the resistance of each cable at 1 A using the voltage ratio method I described in my previous post. The following table lists the results. For a lot of cables I don't know their origin and they must have came bundled with various devices. I've listed the brand if it was printed on or if I knew for certain which device the cable came with. I'm afraid this comparison isn't very useful as a guide which cable brand to buy, but it does give an interesting statistic of what kind of cables can be found out there in the wild.

Unsurprisingly, two short 30 cm cables came out as best in terms of resistance, measuring below 200 mΩ. A bit more unexpected was finding out that the 2 m CellularLine isn't far behind. This is a fancy and laughably overpriced cable I bought in a physical store not so long ago, the only one on this list that I'm sure didn't come bundled with any device. It appears in this case the price was at least somewhat justified.

I was also a bit surprised that some cables that came bundled with devices measured pretty high. The white Amazon was for charging a Kindle 3 and it had the highest resistance among the micro B cables I tested. On the other hand, it was also in pretty bad shape, so it might be that it was damaged somehow. Cables bundled with an HTC phone and Google Chromecast also measured more than 500 mΩ.

Other measurements I could find on the web seem to roughly agree with mine. martinm lists measured values between 289 and 1429 mΩ. Balaur on EEVblog forum measured between 276 and 947 mΩ on his cables. The only report that was really off was this forum post by d_t_a where most of the cables listed are lower than 200 mΩ.

Another thing I was interested in was how repeatable these measurements were. I mentioned several times in my previous posts that contact resistance can play a big role. Since each time you plug in a cable the contacts sit differently and have a slightly different resistance, contact resistance behaves like a random variable in the measurement results. When I was doing the measurements above this was quite obvious. Minimal movements of the cable caused the voltage displayed on the voltmeter to dance around.

I repeated the measurement of cable 16 from the table above 10 times. Before each repetition I unplugged and re-plugged both ends of the cable. Above you can see the histogram of those measurements. The results only vary for approximately ±1%, which is much less than I thought they would. This is about the same as the expected error of the measurement itself due to the accuracy of the reference resistor. Of course, this was all done over a short period of time. I'm guessing the resistance would change more over longer periods of time and more cycles as contacts deteriorate or gather dirt.

I also checked how the measurement is affected if I plug something between the tester and the cable. Gino mentioned in a comment they used an adapter and an extension cable in their measurement. So I repeated the measurement of cable 1 from the table with a short type A-to-type A extension in series. Just for fun, I also tested how much resistance a cheap USB multimeter adds:

As you can see from the results above, both of these added quite a lot. With the excellent 200 mΩ cable, both more than doubled the total resistance. Even with an average 500 mΩ cable, this multimeter would add around 240 mΩ or approximately 50% on top. Battery-powered devices like smartphones adjust their charging current according to the voltage drop they see on their end. Hence they might charge significantly slower when the multimeter is in series with the cable compared to just using a cable. This puts some doubt on the usability of these USB multimeters for evaluating USB cables and power supplies.

Back in June I did a short survey of tools for measuring resistance of power supply lines in USB cables. I was motivated by the common complaint about bad cables, often in the context of powering single board computers like the Raspberry Pi. I wasn't particularly happy with what I found: the tool wanted to buy was out of stock, and I've seen various issues with others. Having already dug too deep into this topic I then set out to make my own tool for this purpose.

So roughly two months later I have a working prototype in my hands. It works as designed and I spent a few hours measuring all the USB cables I could get my hands on. I'm reasonably happy with it and can share the design if anyone else wants to make it.

As I mentioned in my previous post, I really liked the approach of FemtoCow's USB cable resistance tester and I basically copied their idea. Since USB type C is gaining in popularity I've added connectors so that A-to-C and C-to-C cables can be tested in addition to A-to-mini B and A-to-micro B, I've taken care that even with the added connectors, the voltmeter still has Kelvin connections in all combinations. I've also added proper 4 mm test sockets for all connections.

The principle of operation is very simple. Electrically, the resistance tester consists of two parts. On one end of the cable is a reasonably accurate 1 Ω resistor in series with the cable's VBUS and GND lines. The other end only shorts the VBUS and GND lines together. The power supply is used to set a current through the cable. The measured resistance of the cable, which consists of the sum of the four contact resistances and resistances of the two copper cores, can then be calculated as:

Or, if set current is 1 A, the voltmeter reading in volts directly corresponds to the measured resistance in ohms:

The nice thing about this approach is that the cable can be tested at an arbitrary current. If the first equation is used, the accuracy of the method does not depend on the accuracy of the current setting. It even doesn't depend much on the calibration accuracy of the voltmeter: since a ratio of similar voltages is used, any linear error cancels out. The only requirement is that the voltmeter is reasonably linear over the 0.1 V to 1 V range. Since Kelvin connections are used, the resistance of the PCB traces has negligible effect on measurements as well.

The only critical component is the reference resistor. 1% resistors are widely available, so getting to that kind of measurement accuracy should be trivial. With some more effort and a bit higher price, 0.1% current sense resistors aren't that exotic either. For my tool I went with a cheap 1% thick-film resistor since I considered that good enough.

After measuring a pile of cables, some shortcomings did become apparent that I didn't think of earlier: I really should have added a switch for the voltmeter instead of having four test sockets. Constantly re-plugging the test leads gets tiring really fast. It also affects the measuring accuracy somewhat since it's hard to re-plug the cables without moving the tool slightly. Since moving the connectors results in slightly changing their contact resistances, it's hard to measure both voltages in the exactly the same setup. The errors because of that seem minimal though.

Another thing I noticed is that with my analog power supply, setting the current to exactly 1 A wasn't possible. Since I have only one knob that goes from 0 to 25 V in one rotation, setting low voltages requires very small movements of the knob and isn't very accurate. Hence I mostly used the ratio equation for my measurements. My power supply also tended to drift a bit which was a bit annoying. The power supply at work with a digital interface worked much better in that respect.

Finally, I'm not sure how harmful this kind of test is for type C cables that contain active parts, like the electronically marked power delivery cables. I didn't test any so far. All schematics I could find show that the power delivery ID chip is powered from the V_CONN line, which is left unconnected in this tool, so that should be fine. On the other hand, the active cables that do signal conditioning do seem to be powered from V_BUS. It's possible, although I think unlikely, those could respond weirdly or even be damaged by the low voltage applied during this test.

If you want to make a tool like this, you can find all required Gerber files and the bill of materials in the GitHub repository. While it might be possible to etch and drill the board yourself, I highly recommend using one of the cheap PCB prototyping services instead. The USB C connectors require very small holes and SMD pads that I think would be pretty challenging to get right in a home workshop. There are some more notes in the README file regarding that. On the other hand, the Würth connectors listed in the BOM are solderable with only a soldering iron, so manual assembly is reasonably straightforward with no hot air station required. However again the type C ones can be pretty tricky due to the fine pitch.

At work I use a Rigol DS2072A oscilloscope. It's quite a featureful little two-channel digital scope that mostly does the job that I need it for. It can be buggy at times though and with experience I learned to avoid some of its features. Like for example the screenshot tool that sometimes, but not always, captures a perfectly plausible PNG that actually contains something different than what was displayed on the physical screen at the time. I'm not joking - I think there's some kind of a double-buffering issue there.

Recently I was using it to capture some waveforms that I wanted to further process on my computer. On most modern digital scopes that's a simple matter of exporting a trace to a CSV file on a USB stick. DS2072A indeed has this feature, however I soon found out that it is unbearably slow. Exporting 1.4 Msamples took nearly 6 minutes. I'm guessing exporting a full 14 Msample capture would take an hour - I've never had the patience to actually wait for one to finish and the progress indicator indeed remained pegged at 0% until I reset the scope in frustration. I planned to do many captures, so that approach was clearly unusable.

Luckily, there's also an option for a binary export that creates WFM files. Exporting to those is much faster than to the text-based CSV format, but on the other hand it creates binary blobs that apparently only the scope itself can read. I found the open source pyRigolWFM tool for reading WFM files, but unfortunately it only seems to support the DS1000 series and doesn't work with files produced by DS2072A. There's also Rigol's WFM converter, but again it only works with DS4000 and DS6000 series, so I had no luck with that either.

I noticed that the sizes of WFM files in bytes were similar to the number of samples they were supposed to contain, so I guessed extracting raw data from them wouldn't be that complicated - they can't be compressed and there are only that many ways you can shuffle bytes around. The only weird thing was that the files containing the same number of samples were all of a slightly different size. A comment on the pyRigolWFM issue tracker mentioned that the WFM files are more or less a memory dump of the scope's memory which gave me hope that their format isn't very complicated.

After some messing around in a Jupyter Notebook I came up with the following code that extracted the data I needed from WFM files into a Numpy array:

import numpy as np
import struct

def load_wfm(path):
    with open(path, 'rb') as f:
        header = f.read(0x200) 
        
    magic = header[0x000:0x002]
    assert magic == b'\xa5\xa5'
        
    offset_1 = struct.unpack('<i', header[0x044:0x048])[0]
    offset_2 = struct.unpack('<i', header[0x048:0x04c])[0]
    n_samples = struct.unpack('<i', header[0x05c:0x060])[0]
    sample_rate = struct.unpack('<i', header[0x17c:0x180])[0]
    
    assert n_samples % 2 == 0
    
    pagesize = n_samples//2
        
    data = np.fromfile(path, dtype=np.uint8)
    
    t = np.arange(n_samples)/sample_rate
    x0 = np.empty(n_samples)
    
    # Samples are interleaved on two (?) pages
    x0[0::2] = data[offset_1:offset_1+pagesize]
    x0[1::2] = data[offset_2:offset_2+pagesize]
    
    # These will depend on attenuator settings. I'm not sure
    # how to read them from the file, but it's easy to guess 
    # them manually when comparing file contents to what is
    # shown on the screen.
    n = -0.4
    k = 0.2
    
    x = x0*k + n
    
    return t, x
    
t, x = load_wfm("Newfile1.wfm")

Basically, the file consists of a header and sample buffer. The header contains metadata about the capture, like the sample rate and number of captured samples. It also contains pointers into the buffer. Each sample in a trace is represented by one byte. I'm guessing it is a raw, unsigned 8-bit value from the ADC. That value needs to be scaled according to the attenuator and probe settings to get the measured voltage level. I didn't manage to figure out how the attenuator settings were stored in the header. I calculated the scaling constants manually, by comparing the raw values with what was displayed on the scope's screen. Since I was doing all captures at the same settings that worked for me.

I also didn't bother to completely understand the layout of the file. The code above worked for exports containing only channel 1. In all my files the samples were interleaved in two memory pages: even samples were in one page, odd samples in another. I'm not sure if that's always the case and the code obviously does not attempt to cover any other layout.

Here is a plot of the data I extracted for the trace that is shown on the photograph above:

I compared the trace data I extracted from the WFM file with the data from the CSV file that is generated by the oscilloscope's own slow CSV export function. The differences between the two are on the order of 10^-15. That is most likely due to the floating point precision. For all practical purposes, the values from both exports are identical:

Anyway, I hope that's useful for anyone else that needs to extract data from these scopes. Just please be aware that is only a minimal viable solution for what I needed to do - the code will need some further hacking if you will apply it to your own files.