SparkFun will be closed Nov 26th and 27th for the Thanksgiving holiday. Orders placed after 2:00pm MT on the 25th will ship out Monday the 30th.


Member Since: July 9, 2007

Country: United States



Engineer, experimenter, FAE

Spoken Languages


Programming Languages

C, Assembly


Johns Hopkins, University of Maryland, Virginia Tech


http://www.hazmat.com/~mjb/ http://www.hazmat.com/

  • I’ve been working on a display using this and a Microchip PIC32- video of it in operation is here: https://youtu.be/XUCN45TIdpM - the text is generated from an ASCII string and being written to the display via DMA, so it should not be very processor intensive. I’ve got it in a Github repo https://github.com/MattAtHazmat/PIC32LEDStrip, but it is way out of date right now, as I’m not quite an expert at Git… I messed something up, and I’ve been spending my time working on the code rather than figuring out Git.

  • I met a gentleman that built turbine controls for model aircraft and drones that used a Microchip dsPIC30. Turbines are amazing, remember to keep the control loop very quick- things can go very badly very quickly, it would be a shame to see this destroyed by a momentary lean condition.

    I am clearly quite envious that I missed this auction- may I ask what it runs for (the turbine sans generator)?

  • Caps over the unused ends of this cable (or shielding) would make virtually unmeasurable changes. The power in the cable in USB is always the same- it isn’t affected by speed. Also, the data rate on the cable is not a factor of the serial port speed you’re running. To really measure the EMI, you don’t really use a scope (you won’t see much at all)- you ought to use a spectrum analyzer.

  • Yes, each packet has CRC, but in my experience, most drivers deal with CRC failure horribly. USB just isn’t designed to run over a lossy medium. There is no “automatic” downshifting to lower speeds if the connection is poor. It is a statistics game, as long as the vast majority of the packets are good, USB works great, but the overall bit error rate that USB is designed for is something like a single bit error in minutes of operation.

    Diagnosing USB cable problems is miserable- I had a bunch of USB 1.x cables that I ended up just cutting up and recycling because they kept getting into the mix and I’d spend a couple hours diagnosing what I thought was a USB driver problem, but turned out to be a non USB 2.0 cable. (It would connect and enumerate, but eventually fail, and the Windows error messages are particularly un-helpful.)

    The issue is not if the situation is ideal or not, it’s a matter of what kind of issues you may be buying yourself into. I’m sure it will work to move data most of the time, but Murphy’s law is even more reliable than Godwin’s law.

    When space is at a premium, this cable is awesome, and I really see how useful it could be, but USB cables are cheap and pretty small. This very well could find its way into my travel bag (for charging), but I will make it a point that a cable of this type should never be in my lab, except hooked up to a network analyzer as a demonstration of transmission line stub filters.

  • Depending on you you talk to, I could be an expert (or not :). Yes, it might fail CRC, but in my experience USB cable issues are absolutely a pain to identify- USB just isn’t designed to run over a lossy medium- I’ll think I’ll post a reply a little higher in the thread so people don’t miss this.

  • I’m not trying to be a whiner or mean- but you really need to read up more on USB. The speed on USB isn’t really variable- it runs at the maximum speed it is capable of at all time: USB low speed is 1.2Mbit/s (not much really uses this- keyboards and mice, maybe), USB full speed (12Mbit/s) and High speed (480 Mbit/s) (and ignoring USB 3). The rate that the individual packets move is always one of the above speeds. If you’re running a serial port at 110 baud over a converter that is connected at USB High speed- the data on the USB cable is running at 480 Mbit/s ALWAYS- there is just a lot of dead time.

  • The issue with signal integrity is that this kind of thing isn’t a problem, until it is catastrophic. The data failure may not happen frequently, it could happen randomly (errors in data are inevitable- they will happen), and the OS may hide them- but it could also be data pattern dependent, as a transmission line stub can look like a very narrow filter, and for certain data patterns (difficult to predict and likely to be different cable-cable), it could fail every time.

    This is a great cable to have around for charging purposes or emergencies, but for every day use, USB cables are way too cheap to run the risk (for me).

  • The signal integrity guy in me shudders at this- while it may be awesome for supplying power, you’re breaking the transmission lines by adding some relatively significant stubs, and will very likely result in data corruption/loss.

  • BitStream, you need to look up the concept of ‘antenna duality.’ Not counting nonlinearities (such as de-sensing of a pre-amp or arcing due to overload), the mathematical properties of an antenna as a transmitter are exactly the same as a receiver.

    I have seen no-one mention the concept of the Fresnel-zone- doing RF at a small distance above a ground plane (like the earth) can cause destructive interference, seriously limiting range.

  • FYI- the dsPIC33 on this has a maximum internal oscillator speed of 80 MHz, which is misleading anyway (clock rate != CPU speed), since it is divided by 2 to get the actual processor instruction clock, this part is really 40 MIPS.

    The dsPIC30 used a 120MHz maximum clock, divided by 4 to get a 30 MIPS CPU.

No public wish lists :(