kingkevin
/
board
1
0
Fork 0
Code Issues Pull Requests Projects Releases 37 Wiki Activity
board/README.md

9.5 KiB
Raw Blame History

The micro-USB cable tester verifies if a USB 2.0 cable with micro-B plug can be used to transfer data, or just for charging.

purpose

Have you ever plugged in a device using a micro-USB cable and wondered why you can't see it on your computer? Especially when you are developing the USB stack of a micro-controller. This tiny gadget will test the cable and confirm if it can be used to transfer data. Now you can be sure your USB implementation needs some tweaking, and not waste time because this cable was only for charging.

usage

Pictures of the device are available on the wiki.

Ensure a CR1220 coin cell is present in the holder on the back of the board. A CR1220 coin cell is provided with the tester.

Plug in the USB type A of the cable at the top, and the USB type micro-B at the bottom:

  • when the red POWER LED lights up, the cable can be used to power a device (with up to 500 mA, according to USB 2.0 specification)
  • when the green DATA LED lights up, the cable can be used to transfer data
  • when the blue SHIELD LED lights up, the cable can be used for data transfer with High Speed devices (480 Mbit/s), else this cable should only be used for Full Speed devices (12 Mbit/s). If the DATA LED is not on at the same time, the cable is defective
  • when the orange B.CHG (battery charging) LED lights up, the cable can be used to charge a device (with up to 1.5 A, according to USB Battery Charging 1.2 specification). This cable can not be used to transfer data. If the POWER LED is not on at the same time, the cable is defective
  • when the white OTG LED lights up, this is a On-The-Go cable meant to connect a device (i.e. a memory stick) to a host with micro-B port (e.g. a phone). Such adapters can be tested without plugging in the type-A side

battery charging

Normally USB cables capable of data transfer should always be used (USB specification compliant cables), and the charger port the cable is plugged into indicates the device can draw up to 1.5 A by shorting the data lines (D+ and D-). This is known as a Dedicated Charging Port (DCP). Because most USB ports capable of providing more than 500 mA are common practice now, some penny pincher though it was a good idea to short the data lines directly in the micro-B plug, and save the cost of the two additional wires for data transfer (along with shielding and controlled impedance). Such cables are often provided to charge battery operated devices. As described in purpose, I built the tester mainly to identify such cables and avoid using them for data transfer.

tip

After identifying the cable with this tester, I write the result using a marker on the cable with a letter: P for power only, C for battery charging, D for data without shield, S for shields cables, and O oft OTG adapter. This allows me to immediately know what the cable is capable of next time I use it.

mode of operation

Here the methods used to test the different capabilities of the cable:

  • POWER: ensures the VBUS and GND wires are present in the cable, required to power a device. Signal path: VCC -> micro-B_VBUS -> A_VBUS -> LED -> A_GND -> micro-B_GND -> GND.
  • DATA: ensures the D- wire is present in the cable, required to transfer data. The D+ is also required, but when D- is present, I expect D+ to also be. This is not the case if the cable is broken though, but this is not in the scope of this tester. Signal path: VCC -> micro-B_D- -> A_D- -> LED -> A_GND -> micro-B_GND -> GND.
  • B.CHG: checks if D+ and D- are shorted in the micro-B plug. Signal path: VCC -> micro-B_D- -> micro-B_D+ -> LED -> GND.
  • SHIELD: ensures the shell of the plugs are connected on both sides of the cable. This does not ensure if there is really a shield in the cable, or just a wire. It also can't ensure the shell is simply shorted to GND. These limitations are outside of the scope of this tester since I haven't seen any cable cheating this way. Signal path: VCC -> micro-B_VBUS -> A_VBUS -> LED -> A_GND -> micro-B_GND -> GND.
  • OTG: checks if the ID pin is connected to ground, indicating the "device" that it should act as host. Signal path: VCC -> LED -> micro-B_ID -> micro-B_GND -> GND.

All details are in the schematic.

design choice

v2

  • LEDs have the same brightness

v1

  • production friendly design (not through hole devices, or double sided load)
  • each LED/status should have a unique color

v0

  • the connectors need to have through hole mounting tabs to ensure they don't break from the board, particularly the micro-B receptacle.
  • to power the LEDs I used small batteries I had around: CR2032. They are plenty sufficient to power LEDs, especially because I provide them with less than 0.5 mA. Thus the battery should last testing cables for years, unless you leave them plugged in.
  • to keep the board small, I decided to put the battery holder on the back of the board. This requires you to solder it last, else it would cover the hole for the USB-A receptacle.
  • I did not specify the colors of the LEDs, or the value of the resistors, in the schematic, since I wanted to try out alternatives while assembling them.

changelog

sometimes there is a battery connection issue. this is because the CR2012 hole is small, and the HASL is thinner as the silk screen. this has been fixed by making the pad larger, and adding the solder paste (not sure if this is a good idea for such a large pad though).

v2

in v1 I mixed the LEDs for OTG and B-CHRG. I used the opportunity to improve on other aspects:

  • the USB A is shifted to the left to cover mouse bites
  • the USB micro-B can be shifted a bit to the bottom to allow for large plug assemblies
  • the white OTG LED was too bright
  • the green LED was too bright
  • the blue LED was too dim
  • the QR code is white solder mask on green silk screen can't be read by all readers because it's inverted

v1

v0 needed dual side hand assembly, though hole soldering, and lead cutting. v1 is an assembly friendly redesign. it now uses only parts which can be SMD soldered. all parts are on the top side of the board. because the coin cell holder is also on top, I used a CR1220 holder instead of a CR2032 holder, so the board remains small. for quick and infrequent cable tests, a 35 mAh CR1220 is sufficient. since the battery can be side loaded, instead of top loaded, the holder is even smaller. I also used different color LEDs for each test.

v0

first prototype, used as proof of concept. I used parts I already had in my inventory.

parts need to be solders on both sides of the PCB. first, solder the LEDs and resistors on the top side. then solder both USB connectors on the top side. the tabs of the USB connectors need to the soldered on the bottom side, and provide rigidity. cut the leads of the USB connectors so the bottom side is flat again. finally, place the battery holder on the bottom side, and solder the leads on the top side.

requirements

release archives with production output files are available on the wiki.

to be able to generate the outputs you need following software:

  • rake: the central script taking care of generating the output files (Makefile is too cumbersome to parse files)
  • QEDA: to generate footprints for the parts
  • Lepton EDA: for the schematic capture
  • pcb-rnd: for the board layout the output generation is automatized.

compiling

library

almost all of the symbols and footprints used in the schematic and board layout are defined in the QEDA format and generated for the CAD software. the library folder contains the QEDA parts definitions.

to install QEDA using NPM from the official repository:

sudo npm install -g qeda

to install QEDA from the sources:

git clone https://github.com/qeda/qeda
cd qeda
npm install
sudo npm install --global

to generate the parts:

rake library

this will use the parts definition (.yaml files) in the library to generate gEDA gschem/Lepton EDA symbols (.sym files) in the geda/symbols folder, and coralEDA pcb-rnd footprints (.lht files) in the coraleda/subc folder.

only the QEDA parts in subfolders within library come from the QEDA library, but the files are included in this project for simplicity and archiving purposes. all other parts are custom and written for this project.

schematic

the .sch file is the schematic source file. it has been drawn using Lepton EDA.

it uses standard symbols, and the ones in the geda/symbols/ folder. most symbols are generated by QEDA as described above.

to export the netlist (in tEDAx format):

rake netlist

to export as pdf:

rake print

BOM

to export the bill of material (as CSV):

rake bom

board

the .lht file is the board layout source file. it has been drawn using coralEDA pcb-rnd.

it uses the symbols from the coraleda/subc/ folder. most symbols are generated by QEDA as described above. oshw_logo.lht is just the Open Source Hardware Logo. it been generated from https://oshwlogo.cuvoodoo.info/.

to export gerber files for PCB manufacturer (and photo preview + overview document):

rake fabrication