kingkevin
/
usb_cable_tester
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

add README with hardware design choice and export information

master
King Kévin 2019-12-01 18:08:49 +01:00
parent df2f0b7983
commit f48d77d156
1 changed files with 163 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

163
hardware/README.md 100644
View File

@ -0,0 +1,163 @@
purpose
=======
the name of the device says it all: "USB cable tester".
it will test what kind of USB cable it is by checking which signals on the connectors are inter-connected by the cable.
this helps identifying if a cable can transmit data or just deliver power.
Apple's lightning connector is also supported although it is not strictly a USB connector.
for more details about the product in general, refer to the project's README.
this README will provide details about the hardware design.
design choice
=============
micro-controller
----------------
to check if signals are connected by a cable, only input/output pins (I/Os) are required, as provided by any micro-controller.
since each signal of the each connector will be tested, a large number of I/Os is required.
there are several solutions to get plenty of I/Os:
- Serial-In-Parallel-Out (SIPO) and Parallel-In-Serial-Out (PISO) shift registers
- analog or digital multiplexers
- I/O expanders
- large pin-count micro-controller
I decided to go with a large pin-count micro-controller (MCU) because it's simpler (no need to design in hardware how to combine the signals), requires less components (no additional parts, except some decoupling capacitors), is more flexible (I/Os can be reconfigured), and is not much more expensive than additional devices (even less).
the micro-controller should have USB to be able to re-flash it and get detailed report.
since I am quite familiar with the STM32F1 family, I picked the largest one available: an STM32F103ZC, with 144 pins, including 112 I/Os.
here the number of USB signals required (including 3.0 data lines, shield and individual ground/power):
- host A: 10 (9 for USB 3 + 1 shield)
- host C: 25 (24 with each VCC/GND, + 1 shield)
- device A: 10 (some rare cables are A-A, as for PCIe riser card)
- device B: 10 (9 for USB 3 + 1 shield)
- device mini-B: 6 (4 for USB 2, 1 shield, 1 ID)
- device micro-B: 11 (9 for USB 3, 1 shield, 1 ID)
- device C: 25 (24 with each VCC/GND, 1 shield)
- lightning: 8 (including both differential pairs and ID lines)
- total USB: 105
- MCU USB: 2 (to flash and get detailed report/advanced testing)
- SWD: 2 (to flash and debug the MCU)
- I2C: 2 (to display the cable test result)
- display control: 1 (to power off display at the end)
- total: 112
pins could be shared amongst host and device connectors to save pins, but that would complicate the detection of the used connector and reduce the cable connector combination possibilities.
since there are just enough pins, we can test all signals individually.
display
-------
only two pins are available to show the cable test report on a display.
this is enough for I²C.
there are I²C OLED screens, for example the 0.96 in., with 128x64 pixels.
I was already familiar with this device and had some spare ones.
but they are rather small and can't display a lot of text.
alternatively, 2 lines x 16 characters LCD modules can also be used, called LCM1602.
they are large, easy to read from, ubiquitous and easy to get.
be aware that you need one which can operate at 3.3V.
this is not the case from the most common models which operate at 5.0V.
3.3V models have an additional voltage regulator on the board.
this was also a good opportunity to get familiar with them and learn about the Hitachi HD44780 protocol.
the HD44780 protocol interface requires more than 2 signals to be controlled, but I²C adapter boards exist.
they use a PCF8547 I/O expander, providing 8 lines.
these adapter boards even include a potentiometer to set the LED contrast, and transistor to control the LED backlight.
since I²C is a bus, both screens can be controlled individually without requiring additional signals.
either or both displays can be mounted.
battery
-------
the USB cable tester should be able to be powered over USB, but also to be operated on it's own.
for that, a battery is required.
AA and AAA batteries are ubiquitous and sufficient to power the device, but they require a more complicated voltage step-up converter to boost it from 1.0-1.5 V to 3.3 V.
alternatively, Li-Ion batteries are becoming very common.
the most wide-spread form factor is 18650.
18650 batteries are large, but the device is already lager enough because of the number of connectors and LCD screen already required on the board.
18650 batteries can deliver large currents, but this is not required by this low-power device.
alternatively, a smaller battery pack can be connected using the 2-pin connector next to the battery holder.
a simple low-dropout voltage regulator (LDO) is sufficient to convert the 3.6-4.2 V provided by the battery to the 3.3 V required by the micro-controller.
the same LDO can be used for the 5.0 V provided by the USB port.
a single-cell Li-Ion battery charger is included to recharge the battery.
I wanted to try them since they are not complicated and inexpensive.
a battery protection circuit should be included in the battery since none is present on the board.
the switch next to the USB port is used to select which power source to use to power the micro-controller.
it also allows to completely disconnect the battery from the circuit, by selecting the USB port as power input, preventing even the tiny stand-by current draw.
the USB cable tester will shut down after 5 minutes to save battery.
schematic
=========
library
-------
almost all of the symbols and footprints used in the schematic and board layout are defined in the [QEDA](http://qeda.org/) 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:
~~~
make lib
~~~
this will use the parts definition (.yaml files) in the `library` to generate [gEDA gschem](http://wiki.geda-project.org/geda:gaf)/[Lepton EDA](https://github.com/lepton-eda/lepton-eda) symbols (.sym files) in the `geda/symbols` folder, and [coralEDA pcb-rnd](http://repo.hu/projects/pcb-rnd/) footprints (.lht files) in the `coraleda/subc` folder.
only the QEDA parts in subfolders within `library` come from the [QEDA library](https://doc.qeda.org/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 `usb_cable_tester.sch` file is the schematic source file.
it has been drawn using [Lepton EDA](https://github.com/lepton-eda/lepton-eda).
it uses standard symbols, and the ones in the `geda/symbols/` folder.
only `bordered-A1.sym` and `title.sym` are hand drawn.
all other symbols are generated by QEDA as described above.
to export the netlist (in tEDAx format):
~~~
make netlist
~~~
to export archive (with symbols included in schematic) and pdf:
~~~
make schematic
~~~
board
-----
the `usb_cable_test.lht` file is the board layout source file.
it has been drawn using [coralEDA pcb-rnd](http://repo.hu/projects/pcb-rnd/).
it uses the symbols from the `coraleda/subc/` folder.
`oshw_logo.lht` is just the Open Source Hardware Logo.
it been generated from https://oshwlogo.cuvoodoo.info/.
all other symbols are generated by QEDA as described above.
to export gerber file for PCB manufacturer (and photo preview + overview document):
~~~
make board
~~~