Live data from Hacker News

USB Cheat Sheet

fabiensanglard.net

121–130 of 174 posts

Re: USB Cheat Sheet

#121

Earlier quoted context omitted.

Desktop speakers do this still. Instead of simply being a USB speaker set, they use the line out jack for audio and a USB plug for power.

There's actually a reason for that. Standard USB can (obviously) only transfer digital audio, and most speakers are "dumb" devices designed to just amplify an analog signal. In order to convert digital to analog, you need a DAC (Digital-to-Analog-Converter), and good DACs are still a nontrivial cost to a manufacturer, so whatever DAC you already have in your computer is probably better than the crappy one that would…

Funny enough, USB-C can transport analogue audio over USB cable though :)

Tends to be too expensive for the cheapest of products.

Re: USB Cheat Sheet

#122

Earlier quoted context omitted.

I created a cheat sheet for Ethernet, when I built my home network: https://github.com/ProZsolt/runbook/blob/master/ethernet-cab...

shoud 100, 400, 800G be added, yes a bit earlier for 800G but I think 100/400G are already in use at data centers.

This only covers twisted pair, as I only use this as reference when I need new endpoints in my or my parents house.

I'll update the guide when I rewire my house with fiber optics (currently I don't even use the full potential of cat 6), but contributions are welcomed.

Re: USB Cheat Sheet

#123

Earlier quoted context omitted.

The cheap ones are using hardware JPEG encoders. The associated micro isn't powerful enough to do it in firmware alone.

Surprised they don't use a hardware video encoder, is it because the well and efficiently supported formats are all MPEG, and thus have fairly high licensing cost on top of the hardware? Or because even efficient HVEs use more resources than webcams can afford? Or because inter-frame coding requires more storage, which (again) means higher costs, which (again) eats into the margin, which cheap webcam manufacturers co…

MJPEG is just a very simple "video" format that needs very simple and cheap electronics to work. Video encoding blocks are mostly part of bigger SoCs and comes with licensing costs.

Same goes on the other hand for the receiving end - decoding a stream of JPEGs is just much simpler in both CPU use and code complexity than dealing with something like H.264.

Re: USB Cheat Sheet

#124

Earlier quoted context omitted.

I thought OTG was just changing up where the host controller is sitting in the USB relationship? So you can have a device that acts like a client when hooked to a computer, or a master when hooked to a thumb drive/webcam/etc...?

Yeah it just allows you to use a B port as a host (if supported). It's still the USB protocol.

AFAIK, according to the standard you still cannot use the B port as a host, it should instead be an AB port (a socket in which both A and B plugs fit).

Re: USB Cheat Sheet

#125

Earlier quoted context omitted.

USB 3 and previous standards are completely separate connections and software stacks - the USB 1/2 D+/D- pair does not interact at all with SSRX/SSTX. You should be able to literally cut the D+/D- wires in an USB 3 cable and it should still work as a USB 3 cable.

I doubt any normal hosts will enumerate a USB device without the USB 2 data lines. PD will definitely not work. You might be able to get an alt mode running.

They probably would enumerate just fine, because the SuperSpeed enumeration is completely independent from the USB 2.x enumeration. USB-PD uses a separate pin/wire, not the USB 2.x D-/D+ pair, and you cannot get an alt mode running (except the special analog audio and debug accessory modes) if USB-PD doesn't work, since alt mode enumeration goes on top of USB-PD.

Re: USB Cheat Sheet

#126
post #112

Earlier quoted context omitted.

Apple just released a €159 cable

3m is beyond the max cable length specified by Thunderbolt, so it requires active extenders (they're hidden in the plugs) and tight manufacturing and shielding. You're paying extra for the ability to break that max length spec, and it's one of only a handful of products that do it. The only other one I'm aware of is the Corning Active Optical Cable series which costs $360 for a 10m Thunderbolt 3 cable or $479 for a 3…

Can you use USB3 (whatever gen crap it is) for this application maybe?

I can drive an occulus quest2 via 8m of USB3 cable. The cable contains a fiber optic with a repeater hidden inside the female end. The total bandwidth this way is enough for the occulus quest2 at 90fps.

Re: USB Cheat Sheet

#127
post #112

Earlier quoted context omitted.

3m is beyond the max cable length specified by Thunderbolt, so it requires active extenders (they're hidden in the plugs) and tight manufacturing and shielding. You're paying extra for the ability to break that max length spec, and it's one of only a handful of products that do it. The only other one I'm aware of is the Corning Active Optical Cable series which costs $360 for a 10m Thunderbolt 3 cable or $479 for a 3…

Can you use USB3 (whatever gen crap it is) for this application maybe? I can drive an occulus quest2 via 8m of USB3 cable. The cable contains a fiber optic with a repeater hidden inside the female end. The total bandwidth this way is enough for the occulus quest2 at 90fps.

The goal here is wireless, a single thinner cable would be better but it's better to not have to worry about wires at all. And I'm not willing to set up a facebook account just for a Quest.

The Vive Wireless Adapter (VWA) is a PCIe card (single slot/low profile/mitx length). The output from the card is an SMA connector with a RF signal that goes to the antenna, max official length is 2 meters (and it isn't another SMA on the other end, it's hardwired into the antenna, so you have to use an extension, meaning multiple SMA connectors in the middle). I've seen people use some fairly long extension cables, but that attenuates the signal somewhat. It's probably fine but it's undesirable.

There are USB wireless adapters (TPLink makes one iirc) but generally they are agreed to be an inferior solution in various respects - higher CPU usage, higher latency, worse signal quality, a green bar on the top, etc. This is basically an ideal use-case for WiGig, it was literally designed to be a wireless display transmitter, and that's what the Vive Wireless Adapter uses inside, it's actually an off-the-shelf Intel WiGig card. The TPCast uses a much lower-bandwidth solution and compresses it much harder and that requires more latency, more oomph on the PC, and still gets a worse signal quality.

But, the WiGig card only has a short cable to the antenna. Solution: put the card in an enclosure and mount the enclosure on the wall, run the cables to the PC. Problem: thunderbolt also only runs 2 meters. Solution: optical thunderbolt cables. The rest is solvable from there.

The other reason I haven't raced into it is that HTC hasn't kept it up with the newer hardware. The Vive Pro has a higher-res screen and the VWA can only run at (iirc) 3/4ths resolution. It's still a better screen, there's less Screen Door Effect, but when you're talking about dropping around $1000 to get wireless working flawlessly and tucked away into the walls, it better be fucking flawless. On paper the WiGig actually has three channels and should be able to send on all three at once, but this doesn't seem to be implemented...

Honestly the TPCast is probably a 90% solution, it probably chokes on the Vive Pro as well but maybe for $200 instead of $1000 that's acceptable. But it's tough for me to accept "good enough" when there's a technically better solution. The VWA is an absolutely ideal solution here. At one point there were some updates pushed that looks like Valve was working on it, but (with apologies to South Park)... in typical Valve fashion, "they just sort of got high, and wandered off..."

And then, the Index is just an all-around better headset... but it doesn't have a wireless solution at all right now (apart from maybe the TPCast?). It kinda sucks, drives me up the wall that there's no "perfect answer" here. Every solution has some large downsides.

Re: USB Cheat Sheet

#128

Earlier quoted context omitted.

No, some of your rates are wrong. The so-called 5 Gb/s USB has a data rate of 4 Gb/s. The marketing data rates for Ethernet are true, i.e. 1 Gb/s Ethernet has a 1 Gb/s data rate, but a 1.25 Gb/s encoded bit rate over the cable. The marketing data rates for the first 2 generations of PCIe, for all 3 generations of SATA, and for USB 3.0 a.k.a. "Gen 1" of later standards, are false, being advertised as larger with 25% (…

I should add Nominal vs Raw vs Effective speed to the table. Can you confirm with the rule to be used. Raw Speed = Nominal / Encoding UMS Speed = Raw / UMS overhead In the case of 3.0 that would be: Nominal = 625 MiB/s Raw = 625 - 20% = 500 MiB/s UMS = 500 - 20% = 400 MiB/s

The names for the various bit rates vary between authors and standards.

I believe that the least confusing names would be:

Data bit rate = the rate at which the data bits provided by the user are sent

Signaling bit rate = the rate at which bits are sent over the physical communication medium

The 2 rates are not the same because the user data bits are encoded in some way before being sent. The signaling bit rate does not have any importance, except for those who design communication equipment. For the users of some communication equipment, only the data bit rate matters.

The data bit rate is equal to the signaling bit rate multiplied by the ratio between data bits and the corresponding encoded bits.

For example, for USB 3.0 (single link Gen 1):

Signaling bit rate = 5 Gb/s

Data bit rate = (5 * 8 / 10) Gb/s = 4 Gb/s

Data byte rate = (4 / 8) GB/s = 500 MB/s = 477 MiB/s

5 Gb/s corresponds to 625 MB/s, but for a signaling bit rate it is completely useless to convert bits to bytes, because groups of 8 bits on the physical communication medium do not normally correspond to bytes from the data provided by the user. Only for the data bit rate it is meaningful to be converted to a data byte rate.

For USB 3.1 (single link Gen 2):

Signaling bit rate = 10 Gb/s

Data bit rate = (10 * 128 / 132) Gb/s = 9.7 Gb/s

Data byte rate = (9.7 / 8) GB/s = 1212 MB/s = 1156 MiB/s

Re: USB Cheat Sheet

#129
post #124

Earlier quoted context omitted.

Yeah it just allows you to use a B port as a host (if supported). It's still the USB protocol.

AFAIK, according to the standard you still cannot use the B port as a host, it should instead be an AB port (a socket in which both A and B plugs fit).

i cannot find any examples of this kind of port, can you share a link?

Re: USB Cheat Sheet

#130
post #124

Earlier quoted context omitted.

Yeah it just allows you to use a B port as a host (if supported). It's still the USB protocol.

AFAIK, according to the standard you still cannot use the B port as a host, it should instead be an AB port (a socket in which both A and B plugs fit).

It is one of these connectors:

https://en.wikipedia.org/wiki/USB_hardware#USB_On-The-Go_con...

But every OTG device I have ever used has just used the USB-A port.

Post reply on HN