USB was supposed to rule them all but it’s now a mess of standards sharing the same connector. Different speeds, voltage, charging protocols, alt modes, even the number of pins used is variable… For those asking, the thing is available on Kickstarter

  • Bob Robertson IX@lemmy.world
    link
    fedilink
    arrow-up
    22
    arrow-down
    2
    ·
    2 months ago

    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.

    • Da Bald Eagul@feddit.nl
      link
      fedilink
      arrow-up
      32
      ·
      2 months ago

      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.

    • remotelove@lemmy.ca
      link
      fedilink
      arrow-up
      27
      ·
      2 months ago

      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.

      • quiescentcurrentOP
        link
        fedilink
        arrow-up
        4
        ·
        2 months ago

        Pretty much. I’m not even sure if regular USB ports can talk to pins individually, let alone test them for shorts.

        • remotelove@lemmy.ca
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          edit-2
          2 months ago

          (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.