Why are corresponding USB datalines connected to each other in this USB hub

raspberry piusbusb hub

Background: this is (I think) effectively a USB hub, with built in ethernet. This is the circuit as it is being used in the Raspberry Pi B rev. 2

The USB+ from the upstream port (0) is connected to the USB+ on only one of the two downstream ports (3) through a 360R resistor [seen in the very middle of the image]. The USB- is similarly connected to the same downstream port (but the – line).

My questions – why is this being done, and why to that particular port? Could it be done to the other port (2), or both of them, or none?

Segment of Raspberry Pi Schematic showing USB & Ethernet circuitry

The datasheet for the LAN controller is here: http://ww1.microchip.com/downloads/en/DeviceDoc/9512.pdf

The whole schematic is here: https://www.raspberrypi.org/wp-content/uploads/2012/10/Raspberry-Pi-R2.0-Schematics-Issue2.2_027.pdf

The part I have taken this image from is on page 3 of the schematic.

Best Answer

That's an 0R resistor, a fittable link. It looks like on the Model A there's no hub and only a single port, which is connected straight through. On the model B the resistor is not fitted.

Related Solutions

Electronic – LAN9512 USB hub and Ethernet Controller Problems

I resolved the problem, but it took re-manufacturing the board. The problem seemed to be with the routing and layer stack-up. The USB and Ethernet traces did not have correct impedance due to two reasons.

Firstly, the track geometry was not correct for 90 ohm (USB) and 100 ohm (ETHERNET) differential impedance. If your layout software does not support differential routing (eg: Altium does), then you will need to use something like SaturnPCB to calculate the track geometry and manually route the traces accordingly (I had to do this).

Secondly, and most importantly, the layer stackup was not correct to support USB and Ethernet high speed traces.The stack-up was TOP-INNER SIG-GND-BOTTOM and the high speed traces where routed on top layer. USB and ETH traces require a solid ground plane underneath and since this was not the case on my board it really messed up the signal integrity. Putting a solid ground plane (hence changing the stack-up to TOP-GND-INNER SIGNAL-BOTTOM) fixed the signal integrity issues.

I also cleaned up the placement of decoupling caps around the LAN9512 IC.

After these changes, the new board worked without problems. If you're using the raspberryPi to clock the LAN9512 (as B+ with LAN9514 does), then you also need to configure the Pi to output a clock signal. You can find info on this here: http://www.elektricks.net/raspberry-pi-compute-module-general-purpose-clock/ If you have a separate oscillator for the LAN9512 then ignore this paragraph.

Hope that helps!

Electronic – Hardwire rgb-led-controller instead of Infrared

Both are possible.

IR, first you need an IR receiver setup. Record the signal incoming from the remote. Then setup a simple IR led circuit controlled by a transistor/FET controlled by GPIO. Send the commands you want. It is not pseudo serial, the codes tend to be NEC (Maybe RC5, but NEC is simpler and more common). Any number of IR RPi remote control projects on google will help.

The hard wire, remove the existing IC. Use a level shifter as 3.3V will likely not be enough to exceed the VGS Threshold for a proper low Resistance of Drain-Source, RDS(on). This shift can be a simple npn transistor, but it requires you to invert your logic on the RPI code.

Update:

Yes, you could bypass the IR Receiver. It is as you expect, a Demodulator that removes the 38khz (or so) carrier wave, and passes the data. I believe it should be an active high signal through a pull-up. This allows you to skip the LED transmitter and IR receiver sections. Since the line should have a 5V pull up, all you need is a simple NPN transistor to level shift from 3.3V to 5V. Again, logic is inverted so a logic 1 at the RPI would be a logic low at the MCU input. You must make sure only the data, Unmodulated is sent.

Since you are using LIRC for the RPI, then you need to load it properly:

 sudo modprobe lirc_rpi softcarrier=0

The Softcarrier option disabled to eliminate the carrier wave, only available on lirc_rpi afaik, so you lucked out.

This depends on the specifics of the IR receiver used. A picture of the reverse of the board would help. You would want to disconnect the IR receivers Data to avoid interference.