Somehow I needed a hub long ago, preferably with a large number of ports and with a fairly convenient form suitable for embedding instead of a floppy disk drive into the 3.5 ”bay. A quick look at the flea market threw the model D-link DUB-H7, and even in the combination “2 for the price of 1”. External inspection did not give anything special, the hub as a hub, made soundly, a major "printer" USB AM-BM on the back and 3 A power supply. As always, first of all I took it apart, rejoiced at a small number of empty spaces instead of elements, along with high-quality soldering, and calmed down. True, just in case, I went to the Internet to see what the hub was and if there were any interesting projects with its participation. There were no projects, user reviews 50/50, in general, no dynamics. For 5-7 years, the hub worked reasonably well and performed its task, then moved smoothly to the electronic junk box and quite possibly would have disappeared as a result along with unknown adapters, adapters, etc. But in my life, an event occurred that made me dig in bags with old junk, find this, as it turned out, a unique D-link, and shaking off the dust to remove it into the light of God. If it's interesting to listen to why - welcome under cut.
With the advent of small convenient SoC routers (like the lovingly described clone of the popular Chinese mini-router Hame A15, aka “unbranded A5-V11” ) and the widespread adoption of openwrt for managing a host of devices (in absolute majority cases, these are devices connected via USB) the task of managing the power supply of various modems, card readers, usb-rs232 converters, etc., etc. becomes a very urgent task. The most common is the need to control the port when working with GSM emami (to restart, for example). In principle, the people have already developed a sufficient number of solutions . For these purposes, ranging from the use of free GPIO pins in the router, and ending with ready-made relays. There are solutions from third-party manufacturers. This is for example a programmable USB hub for 4 ports from Acroname , which is also rich in software and software, but costs about $ 300.
There is a cheaper option, a smart switchable hub with the pleasant name Yupkit YKUSH for only € 35:
The most economical ones can use a bundle from the cheapest usb hub, a normally closed 5V relay, and any of the Arduino-k to disconnect power from the usb port if necessary. The cost of such a decision <$ 10, excluding the time spent on soldering and programming Arduino.
It would seem a dead end. Either expensive and beautiful, or just plain and snotty . But it turned out there is a third option. Moreover, the solution is as old as the USB 2.0 specification for hubs in which it is described.
It is not necessary. Bus-powered hubs are required to have power switches. If you are a group of gangs, you can connect to one or more ports. A hub indicates the field of power in the wHubCharacteristics. If a hub is supported, it is a request for the port. Port power If a hub is supported, it receives a SetPortFeature (PORT_POWER) request. It is not a state of mind.
...
Although it is not necessary to implement power switching, it’s necessary to support the state of all ports. Additionally, it is necessary to implement the USB System Software (PbwrCtrlMask (all bits set to 1B)).
Translating into Russian, it turns out that the USB standard has already spelled out the ability to control the power of the ports, using the so-called. Per-Port Power Switching (PPPS) , but to meet a device that would support this feature is not just hard, but very hard. To implement PPPS functionality, additional components (field-effect transistors and piping) are needed, which are not installed in hubs in order to save.
Sensitively responding to market demands, some manufacturers indicate PPPS in the hub specifications, but in reality the case on the box does not go further. And in principle, it is difficult to find fault, because many chips inside the hubs support this function, but it is impossible to implement it without additional switches (transistors) (most often USB ports are directly connected to the + 5V line).
I even specially disassembled several small USB hubs that I planned to use together with the A5-V11 router. Inside it turned out: the GL850G chip and the hotly beloved by the Chinese FE1.1s . Naturally, only the controllers themselves were found inside with a minimum of details. In view of the miniature size of the board, it is difficult to place even a hinged wiring of the transistor and the parts that have joined it. I had to calm it down. Although, depending on the chip, if there is a mention of over-current detection or an individual or ganged power control in the datasheet , it is possible to carry out an operation on the smart of such a device according to the method described in the article . A friend used a combination of a transistor and a bunch of resistors to enable PPPS in his hub.
Also reading the documentation, you catch yourself in that there is no-no and yes there is a mention that the port control mode can be implemented by adding some AIC1526-0 or MIC2026 (Dual-channel power distribution switch) to the circuit.
Overwhelmed with gloomy thoughts about buying Chinese hubs with unknown functionality ("the cat in the bag") and the impossibility of checking them beforehand, I inadvertently came across an article about setting up openwrt for power management of a USB hub, moreover, the example, abandoned, and the forgotten D-Link DUB-H7 in a gray package.
After examining the hardware, it became clear that on board the hub, in addition to the fairly advanced Philips ISP1521BE controller, there is also a whole bunch of those dual-channel power distribution switches AIC1528-0 for a full power switch. Although judging by the datasheet, the chip with a minimal body kit itself can control the power of downstream ports (and there are still a lot of things that, as it turned out, are not implemented, for example, indication of upstream port activity using GoodLink technology, or a USB 1.1 host to correctly support mix 2.0 and 1.1 on downstream ports, etc., etc.).
By the way, for those who decide to repeat the path I have gone through, I will immediately say that the modern versions of the D-Link DUB-H7 (in a glossy black case) are not as useful as the old men of gray.
According to information from wikidevi.com ( 1 , 2 , 3 , 4 ) there are several revisions of this hub, with a different set of components on board, and accordingly with different functionalities (A1 / A5 - ISP1521BE 7-port, B1-2xGL854G 4-port, C1 - 2xGL850Z 4-port).
Attention to the D-Link DUB-H7 is also drawn because, in addition to its good functionality, it is also the most affordable option (both in price and in prevalence) in our area. From the models that could be mentioned along with "Per-Port Power Switching", you can additionally mention, for example, the following:
I didn’t look for the devices mentioned, because I was once lucky with revision A5. But now, if I had to buy such a hub, I would try to find revision B1 , because besides the port power management, the chip on which it is built (GL854G) has such a thing as a Multi Transaction Translator inside.
A small digression to tell what this Multi Transaction Translator (MTT) is and why it is so important and necessary. The operation transmitter (transaction transactionator, TT) is an important component of any high-speed hub that provides communication between the upstream and downstream ports of the hub, especially in the case when these ports operate at different data rates. In fact, TT separates low- and medium-speed devices from high-speed devices (especially USB 2.0, for example) and is responsible for operating at USB 1.1 speeds.
Transmitter operation can be of two types - single (English Single Transaction Translator, STT) or multiple (English Multiple Transaction Translator, MTT). In the case of STT, one transmitter is used for all ports, and in the case of MTT, each port has its own transmitter. It is clear that the first option is cheaper and simpler, where the main drawback of this option comes from - in the case of connecting several USB 1.1 ports to the hub, they will all work through a single “bottleneck”. I think you can imagine what will happen with the speed of exchange.
In simple terms, STT hubs have a limit on the number of devices that can be used simultaneously. Otherwise, it is fraught with packet loss due to conflicts in scheduling data transmissions, overloading the hub (especially when using actively communicating devices, such as sound cards), etc. Therefore, it is better when choosing a hub to immediately focus on devices with MTT, and not to look after the cause of instability in the work. If there is already a hub, and unfortunately it turned out to be from the STT, all that remains is to carefully check the standards of the devices connected to the hub and, if possible, reduce the number of connected USB 1.1 to one.
Unfortunately, the vast majority of low-cost hubs built on low-end chips (fe1.1s, GL850G, and my A5 hub’s ISP1521BE) have STTs on board that are more expensive and advanced (GL852G, GL854G (B1 revision discussed by D-link DUB-H7), GL3520, VL812, VL813, SMSC USB2514) are running MTT.
You can check the type of transmitter operation either by reading the datasheet on the chip (but often the Chinese cannot or do not want to tell the chip's brand), or by connecting the hub to a computer with * nix and running the lsusb -v command and finding the piece of service information related to the hub being investigated name). The line DeviceProtocol will indicate either Single TT or Multi TT . It is clear that it is better to buy only with Multi :)
Bus 001 Device 005: ID 2001: f103 D-Link Corp. DUB-H7 7-port USB 2.0 hub
Some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x2001 D-Link Corp.
idProduct 0xf103 DUB-H7 7-port USB 2.0 hub
bcdDevice 1.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self powered
Remote wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage type data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
When you run the lsusb -v -t command, you can see a nice hierarchical structure of connected usb-devices.
Instead of lsusb, you can use the hwinfo utility with the --usb key (it is advisable to install it first via sudo apt-get install hwinfo ). Then the output of information about usb devices will look a little different:
lab @ lab-G: ~ $ hwinfo --usb
23: USB 00.0: 10a00 Hub
[Created at usb.122]
Unique ID: zFuK.sOcBcpBDhs4
Parent ID: k4bc.9T1GDCLyFd9
SysFS ID: /devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0
SysFS BusID: 1-8: 1.0
Hardware Class: hub
Model: "D-Link DUB-H7 7-port USB 2.0 hub"
Hotplug: USB
Vendor: usb 0x2001 "D-Link"
Device: usb 0xf103 "DUB-H7 7-port USB 2.0 hub"
Revision: "1.00"
Driver: "hub"
Driver Modules: "usbcore"
Speed: 480 Mbps
Module Alias: "usb: v2001pF103d0100dc09dsc00dp01ic09isc00ip00in00"
Config Status: cfg = new, avail = yes, need = no, active = unknown
Attached to: # 21 (Hub)
In general, briefly with the peculiarities of the low-speed devices work out and now it's time to go to the software part.
I’ll say right away that I couldn’t find a way to implement PPPS functionality in a Windows environment (at least out of idle interest). Maximum - enable / disable the device using the devcon utility. I would be glad if someone from the readers corrected and supplemented. In the meantime, all procedures are carried out on the example of Ubuntu (in the case of openwrt, the algorithm is similar, although in the last trunk it should already be included in the "distribution").
So, the Per-Port Power Switching (PPPS) or " Port Power Switching " feature is implemented on hubs with hardware support for this function using the hub-ctrl program or its descendant uhubctrl . I will consider them in turn.
The program was written by a Japanese fighter for independence engineer Niibe Yutaka back in 2006. But it works without problems now. For installation we need any * nix and libusb-dev library. For example, Ubuntu 16.04 LTS algorithm is as follows:
Install ext. packages: sudo apt-get update && sudo apt-get install libusb-dev git gcc Download source: git clone https://github.com/codazoda/hub-ctrl.c Compile with gcc: cd hub-ctrl.c && gcc -o hub-ctrl hub-ctrl.c -lusb
If the address is unavailable, you can manually download the sources from here or from here and compile with the command described above.
The program has a fairly simple command-line syntax that goes into the following description:
./ hub-ctrl [{-h HUBNUM | -b BUSNUM -d DEVNUM}] \ [-P PORT] [{-p [VALUE] | -l [VALUE]}]
where HUBNUM is the hub number, BUSNUM bus number, DEVNUM device number, PORT port number
To find out these parameters, just run the lsusb command:
By the way, the hub-ctrl program can act as a kind of “probe” of a usb hub for the fact that it has the ability to manage port power. It is enough to run it with the -v key. We get a list of supported hubs in the system (the INFO line) and the status of the ports (in my case, all the ports are turned off)
lab @ lab-G: ~ / hub $ sudo ./hub-ctrl -v
Hub # 0 at 001: 006
INFO: individual power switching.
WARN: Port indicators are NOT supported.
Hub Port Status:
Port 1: 0000.0000
Port 2: 0000.0000
Port 3: 0000.0000
Port 4: 0000.0000
Port 5: 0000.0000
Port 6: 0000.0000
Port 7: 0000.0000
This is what the configuration will look like when all ports are turned on:
lab @ lab-G: ~ / hub $ sudo ./hub-ctrl -v
Hub # 0 at 001: 006
INFO: individual power switching.
WARN: Port indicators are NOT supported.
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0100 power
To enable any of the ports you need to run the command sudo ./hub-ctrl -h 0 -P 1 -p 1 , where -h indicates which hub is used (0th in my case), -P tells which port (1- th port in my case), and -p indicates the status (0-off, 1-on).
To get the configuration as in the picture above, it was necessary to execute the following commands sequentially (for the ports that were initially disabled):
sudo ./hub-ctrl -h 0 -P 2 -p 1
sudo ./hub-ctrl -h 0 -P 4 -p 1
sudo ./hub-ctrl -h 0 -P 6 -p 1
Accordingly, it is not difficult to write a script that will cause the LEDs to flash for fun in the desired sequence. Examples of such things already exist and successfully function:
Morse code on a usb hub, Christmas tree lights , etc. etc. From the possibilities of hub-ctrl, I didn’t have enough of the function of cyclic inclusion for the realization of my momentary lighting fantasies (so as not to waste time writing the script, etc.). This annoying flaw is eliminated in the successor - uhubctl.
The uhubctl program is an optimized analogue of the hub-ctrl and has some cosmetic differences (and of course it supports more devices).
Theoretically, the utility can be compiled to run in the windows environment, but ... But for now it interacts with devices via the winusb.sys driver, which cannot directly access the hub. Also, the program claims USB 3.0 support (USB 3.0 hubs supporting Per-Port Power Switching, by the way, is much more than USB 2.0 hubs with similar functionality). When working with a USB 3.0 hub connected to a USB 3.0 upstream port, the program defines it as two independent virtual hubs: USB 2.0 and USB 3.0, and the USB devices themselves will be connected to one of them depending on their capabilities and connection speed . Accordingly, to control such devices, the program turns on / off power on virtual hubs by default (you can switch the utility to manual mode by adding the –e switch to the start command).
Important: the addressing system for USB ports can cause some confusion (it is similar for hub-ctrl and uhubctl). During operation, it uses the same addressing method similar to that in the Linux kernel: bx.yz, where b is the USB bus number and x, y, z are the port numbers of the node chain, starting with the root USB hub for this bus. If there is more than one managed USB hub, you can determine the correct parameters by running uhubctl with the -l (location) parameter. I note that this addressing is semi-stable — it will not change if you unplug and plug the USB devices back to the same physical port.
The algorithm for compiling a program is similar to the algorithm for hub-ctrl. Except for the exception that you additionally need to install the library libusb-1.0 (version 1.0.12 or later) by the usual command sudo apt-get install libusb-1.0-0-dev , and then compile the binarik with the command make .
The syntax for running the program next
uhubctl -a off -p 2
This command shuts off power (-a off, or -a 0) on port 2 (-p 2). Supported off / on / cycle (or 0/1/2) commands. The cycle key turns off the power, waits for a while (determined by the -d key) and turns it back on. Those. Now the hub can easily replace the microcontroller.
And it follows from this that there is a “secret” in the old hub from D-Link. The use of the described technology (PPPS) is quite reasonable when it is necessary to remotely control an array of devices connected to the USB bus. Moreover, this method is already used to disable hard drives , webcams and GSM modems (such as in the picture):
Although, as for the modems and the D-link DUB-H7 mentioned by me, there are people who question the performance of such a bundle (when working with the hub-ctrl program).
"... experiments using Dlink DUB H-7 showed that hub-ctrl -p 0 only lowers the voltage to 1.47 V. At the same time, after inserting the modem into such an" off port "the LED does not blink, but the / dev / ttyUSBx files for this modems appear in the system. They can even be opened. However, writing commands and reading responses from this port does not end in success. "
The utilities described in the article (lsusb, hwinfo, hub-ctrl) can be a great help when choosing the next USB hub, especially if there is no access to viewing the internal device. At the Habré, user ideas and expectations from ideal usb hubs were already described ( here and here ). In my opinion, the described algorithms for checking existing hubs will perfectly complement and dilute the approaches described by the authors. Well and so, after, the hero of my article (D-link DUB-H7 ver. A5) in my opinion looks very good from the point of view of circuit solutions. On this, perhaps, I will take my leave :)
Sergey Besarab ( Siarhei V. Besarab )
PS After the question to the members of the habr-community, who suddenly quite accidentally stumbled around the same as my D-link DUB-H7 in a gray case.
What are the details installed on the circled positions (and maybe someone even saw the scheme)? Elements RP1 ... RP2 are especially interesting (I suspect a resistor assembly of 0 resistances).
Addition : if suddenly someone needs a firmware dump for the EEPROM 24C02 chip, it looks like this:
Source: https://habr.com/ru/post/430220/
All Articles