Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
view the rest of the comments
Out of curiosity, is there a reason that this couldn't be an Android app? I would think that there should be some way to check a cable's functionality by plugging it into a phone and a computer.
It could be, but I imagine the reported capabilities would be limited by the connected devices. So if your phone doesn't support USB SuperSpeed 80gbit/s, it wouldn't be detected by the app.
Cable testers can bypass all of the standard driver and USB negotiation bullshit before anything else. I would imagine building a device to manually control when and how the connections are made is much easier than fighting for low level device control on systems like Windows, macOS and Android.
Pretty much. I'm not even sure if regular USB ports can talk to pins individually, let alone test them for shorts.
(thinks out lound..)
If you could force different speeds and different voltages, you can make some guesses as to what the cable might support.
USB packets use CRC checks, so a bad checksum may indicate a speed or physical problem. (Besides stating the obvious, my point is that doing strict checks for each USB mode gives CRC more value.)
I just looked over the source code for libusb (like I knew what I was looking for, or something) and it seems that some of the driver(?) components hook really deep into the kernel. There might be a way to test specific parts of any type of handshake (for dataflow or voltage negotiation) to isolate specific wires that are bad by the process of elimination.
I think my point is that a top-down approach is likely possible, but it's probabilistic.