USB Cable shield continuity
in [Design]
|
Prev: conservation of Euros
Next: Heat effect on FR4?
From: Baron on 11 Jun 2010 17:10 Paul E. Schoen Inscribed thus: > The manufacturer might be able to apply a drop of conductive paste at > the junction point that would provide a decent connection and also > exclude moisture and other contaminents. But there may be no reliable > way to fix these cables as they are. > > Paul I forgot to mention, a temporary fix was to give the bit of plastic, where the cable enters the plug, a tap with a hammer. It doesn't last long though, a few flexes and its as bad again. -- Best Regards: Baron.
From: Martin Riddle on 11 Jun 2010 18:32 "Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message news:NqjQn.97996$0B5.94512(a)newsfe05.iad... > I have been having seemingly random noise problems where my PIC-based > USB device will go into a USBSuspendControl state, and it requires the > cable to be removed and replaced to reestablish communication. The > problem usually occurs in the field where there is switching of high > current and high voltage, but I was able to duplicate it to some > extent by running the USB cable along an AC power line to a current > source which I switched on and off. > > Recently I suspected that the USB cable itself might be at fault, > because I had bought a batch of 100 pieces for $0.69 each (but now > about $1.50) from www.CableWholesale.com, and several of these were > sent to a customer who reported problems, while a previous customer > with an older cable did not seem to experience this very much, and > another customer replaced his cable with a longer one, and he said his > unit was working OK. > > So, I dissected one of the new cables by removing the PVC jacket in > the middle, and I found a substantial tinned copper braid shield, and > an aluminized Mylar wrap under that. When I removed the shield I could > see that the four USB conductors were twisted together, which is > generally good for noise induced by strong magnetic fields. So far, so > good. > > But when I measured continuity from the connector shells to the > exposed shield, I got intermittent readings of about 3 to 30 ohms and > sometimes an open circuit. Then I measured the continuity from shell > to shell on a couple other USB cables I had been using, and I found > that one showed an open circuit and the others showed intermittent. > This was the case for two new cables from different sources. Yet I > measured the shells of a USB cable for my Nikon digital camera (with a > mini-USB on the camera end), and I got a solid connection of less than > 1 ohm. > > I still need to do more testing and I may also purchase a high grade > cable with gold plated connectors and better shielding. They are about > $20. I will also have my customer check the continuity and try a > better cable. Perhaps a USB 3.0 cable will work better. > > I removed the PVC molded cover for the male type "A" connector, and > there is a metal shell that extends back and tapers to a smaller > "neck" where the cable is clinched or crimped. By bending the ears on > the crimp I was able to separate part of the metal housing to reveal > where the shield has been folded back and exposed so that the inner > surface of the housing presses against it. But it seems that the > jacket of the cable is a continuous molding that fills the shell of > the connector, and the crimp mechanism can only apply light force to > the exposed part of the shield. So the actual connection may degrade > with time as a non-conductive film may form on the metal surfaces, and > mechanical flexing may further degrade the connection. > > Here are pictures of the cable after dissection and exposure of the > crimped > shield connection: > > http://cygnus.smart.net/~pstech/photos/USB_Cable_23.JPG > http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_26a.JPG > http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_27.JPG > http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_28.JPG > http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_29.JPG > http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_30.JPG > > I think this is a design defect and I should be able to get a refund > or credit for the unused cables. It may not be the reason for the > problem but I should be able to determine that if my customers replace > the cables with high performance versions and their problems are > greatly reduced. > > Anyone else have experience with this? One member of the Microchip > forums reported that he found the following with some new cables he > had on hand: > > Poundland 1.8 m A-A(F) yellow 8 ohms > Signalex 1.5 m A-A(F) white OPEN CIRCUIT! > Signalex 1.5 m A-B white OPEN CIRCUIT! > CPC 1.8 m A-B translucent yellow 18.5 ohms > IXIOS 3 m A-A(F) translucent/silver grey gold plated > connectors <0.5 ohms > > Paul Interesting, I have the same problem with a PIC project. Right now I'm moving to the latest Mchip USB stack. I did find a well placed Ferrite bead suppressed the problem, but it still occurs once in a while. Eventually I plan on programmatically Detaching the device and re-enumerating, after a set period of inactivity. This problem does not occur with other USB devices in the system. Cheers
From: Paul E. Schoen on 11 Jun 2010 19:39 "Martin Riddle" <martin_rid(a)verizon.net> wrote in message news:huudh9$v9t$1(a)news.eternal-september.org... > > > "Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message > news:NqjQn.97996$0B5.94512(a)newsfe05.iad... >> I have been having seemingly random noise problems where my PIC-based USB >> device will go into a USBSuspendControl state, and it requires the cable >> to be removed and replaced to reestablish communication. The problem >> usually occurs in the field where there is switching of high current and >> high voltage, but I was able to duplicate it to some extent by running >> the USB cable along an AC power line to a current source which I switched >> on and off. >> >> Recently I suspected that the USB cable itself might be at fault, because >> I had bought a batch of 100 pieces for $0.69 each (but now about $1.50) >> from www.CableWholesale.com, and several of these were sent to a customer >> who reported problems, while a previous customer with an older cable did >> not seem to experience this very much, and another customer replaced his >> cable with a longer one, and he said his unit was working OK. >> >> So, I dissected one of the new cables by removing the PVC jacket in the >> middle, and I found a substantial tinned copper braid shield, and an >> aluminized Mylar wrap under that. When I removed the shield I could see >> that the four USB conductors were twisted together, which is generally >> good for noise induced by strong magnetic fields. So far, so good. >> >> But when I measured continuity from the connector shells to the exposed >> shield, I got intermittent readings of about 3 to 30 ohms and sometimes >> an open circuit. Then I measured the continuity from shell to shell on a >> couple other USB cables I had been using, and I found that one showed an >> open circuit and the others showed intermittent. This was the case for >> two new cables from different sources. Yet I measured the shells of a USB >> cable for my Nikon digital camera (with a mini-USB on the camera end), >> and I got a solid connection of less than 1 ohm. >> >> I still need to do more testing and I may also purchase a high grade >> cable with gold plated connectors and better shielding. They are about >> $20. I will also have my customer check the continuity and try a better >> cable. Perhaps a USB 3.0 cable will work better. >> >> I removed the PVC molded cover for the male type "A" connector, and there >> is a metal shell that extends back and tapers to a smaller "neck" where >> the cable is clinched or crimped. By bending the ears on the crimp I was >> able to separate part of the metal housing to reveal where the shield has >> been folded back and exposed so that the inner surface of the housing >> presses against it. But it seems that the jacket of the cable is a >> continuous molding that fills the shell of the connector, and the crimp >> mechanism can only apply light force to the exposed part of the shield. >> So the actual connection may degrade with time as a non-conductive film >> may form on the metal surfaces, and mechanical flexing may further >> degrade the connection. >> >> Here are pictures of the cable after dissection and exposure of the >> crimped >> shield connection: >> >> http://cygnus.smart.net/~pstech/photos/USB_Cable_23.JPG >> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_26a.JPG >> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_27.JPG >> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_28.JPG >> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_29.JPG >> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_30.JPG >> >> I think this is a design defect and I should be able to get a refund or >> credit for the unused cables. It may not be the reason for the problem >> but I should be able to determine that if my customers replace the cables >> with high performance versions and their problems are greatly reduced. >> >> Anyone else have experience with this? One member of the Microchip forums >> reported that he found the following with some new cables he had on hand: >> >> Poundland 1.8 m A-A(F) yellow 8 ohms >> Signalex 1.5 m A-A(F) white OPEN CIRCUIT! >> Signalex 1.5 m A-B white OPEN CIRCUIT! >> CPC 1.8 m A-B translucent yellow 18.5 ohms >> IXIOS 3 m A-A(F) translucent/silver grey gold plated >> connectors <0.5 ohms >> >> Paul > > Interesting, I have the same problem with a PIC project. Right now I'm > moving to the latest Mchip USB stack. > I did find a well placed Ferrite bead suppressed the problem, but it still > occurs once in a while. > Eventually I plan on programmatically Detaching the device and > re-enumerating, after a set period of inactivity. > > This problem does not occur with other USB devices in the system. I found that I had to put a jumper from an unused pin (24 = RB3) on the PIC18F2550 to the D+ line of the USB connector to effect a reliable detach and reattach. When the device is stuck in the USBSuspendContol state, I use a countdown which eventually disables interrupts, changes the pin from an input to an output and drives it low to force a disconnect. Then I do a SoftDetach(), run a delay loop for about 5 seconds, and then a program reset. However, this causes a problem on a new installation where the driver must be installed. I found this from a customer. I already had the driver installed, so it enumerated before the timeout, but without the driver it went into a loop which prevented it from being installed. There may be a way to pre-install a driver, but that could be tricky. I switched to the new stack (2.6) recently, and found several changes needed to be made. There also seems to be a bug in the code if you are using a PIC2450 as I have on one of my older boards. I have two versions of PIC code, one for a CDC and another that uses the generic mchpusb.sys driver. There is supposedly a bug in the Microsoft supplied usbser.sys driver, but I have found that both work equally well (or not well), and the errors seem to be random. These are comm errors where the USB port seems to stop receiving data for a second or longer, or where characters are skipped. The SuspendControl lockup is a separate problem which seems noise related. Paul
From: Martin Riddle on 11 Jun 2010 20:57 "Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message news:yOzQn.98284$0B5.24423(a)newsfe05.iad... > > "Martin Riddle" <martin_rid(a)verizon.net> wrote in message > news:huudh9$v9t$1(a)news.eternal-september.org... >> >> >> "Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message >> news:NqjQn.97996$0B5.94512(a)newsfe05.iad... >>> I have been having seemingly random noise problems where my >>> PIC-based USB device will go into a USBSuspendControl state, and it >>> requires the cable to be removed and replaced to reestablish >>> communication. The problem usually occurs in the field where there >>> is switching of high current and high voltage, but I was able to >>> duplicate it to some extent by running the USB cable along an AC >>> power line to a current source which I switched on and off. >>> >>> Recently I suspected that the USB cable itself might be at fault, >>> because I had bought a batch of 100 pieces for $0.69 each (but now >>> about $1.50) from www.CableWholesale.com, and several of these were >>> sent to a customer who reported problems, while a previous customer >>> with an older cable did not seem to experience this very much, and >>> another customer replaced his cable with a longer one, and he said >>> his unit was working OK. >>> >>> So, I dissected one of the new cables by removing the PVC jacket in >>> the middle, and I found a substantial tinned copper braid shield, >>> and an aluminized Mylar wrap under that. When I removed the shield I >>> could see that the four USB conductors were twisted together, which >>> is generally good for noise induced by strong magnetic fields. So >>> far, so good. >>> >>> But when I measured continuity from the connector shells to the >>> exposed shield, I got intermittent readings of about 3 to 30 ohms >>> and sometimes an open circuit. Then I measured the continuity from >>> shell to shell on a couple other USB cables I had been using, and I >>> found that one showed an open circuit and the others showed >>> intermittent. This was the case for two new cables from different >>> sources. Yet I measured the shells of a USB cable for my Nikon >>> digital camera (with a mini-USB on the camera end), and I got a >>> solid connection of less than 1 ohm. >>> >>> I still need to do more testing and I may also purchase a high grade >>> cable with gold plated connectors and better shielding. They are >>> about $20. I will also have my customer check the continuity and try >>> a better cable. Perhaps a USB 3.0 cable will work better. >>> >>> I removed the PVC molded cover for the male type "A" connector, and >>> there is a metal shell that extends back and tapers to a smaller >>> "neck" where the cable is clinched or crimped. By bending the ears >>> on the crimp I was able to separate part of the metal housing to >>> reveal where the shield has been folded back and exposed so that the >>> inner surface of the housing presses against it. But it seems that >>> the jacket of the cable is a continuous molding that fills the shell >>> of the connector, and the crimp mechanism can only apply light force >>> to the exposed part of the shield. So the actual connection may >>> degrade with time as a non-conductive film may form on the metal >>> surfaces, and mechanical flexing may further degrade the connection. >>> >>> Here are pictures of the cable after dissection and exposure of the >>> crimped >>> shield connection: >>> >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_23.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_26a.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_27.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_28.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_29.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_30.JPG >>> >>> I think this is a design defect and I should be able to get a refund >>> or credit for the unused cables. It may not be the reason for the >>> problem but I should be able to determine that if my customers >>> replace the cables with high performance versions and their problems >>> are greatly reduced. >>> >>> Anyone else have experience with this? One member of the Microchip >>> forums reported that he found the following with some new cables he >>> had on hand: >>> >>> Poundland 1.8 m A-A(F) yellow 8 ohms >>> Signalex 1.5 m A-A(F) white OPEN CIRCUIT! >>> Signalex 1.5 m A-B white OPEN CIRCUIT! >>> CPC 1.8 m A-B translucent yellow 18.5 ohms >>> IXIOS 3 m A-A(F) translucent/silver grey gold plated >>> connectors <0.5 ohms >>> >>> Paul >> >> Interesting, I have the same problem with a PIC project. Right now >> I'm moving to the latest Mchip USB stack. >> I did find a well placed Ferrite bead suppressed the problem, but it >> still occurs once in a while. >> Eventually I plan on programmatically Detaching the device and >> re-enumerating, after a set period of inactivity. >> >> This problem does not occur with other USB devices in the system. > > I found that I had to put a jumper from an unused pin (24 = RB3) on > the PIC18F2550 to the D+ line of the USB connector to effect a > reliable detach and reattach. When the device is stuck in the > USBSuspendContol state, I use a countdown which eventually disables > interrupts, changes the pin from an input to an output and drives it > low to force a disconnect. Then I do a SoftDetach(), run a delay loop > for about 5 seconds, and then a program reset. > > However, this causes a problem on a new installation where the driver > must be installed. I found this from a customer. I already had the > driver installed, so it enumerated before the timeout, but without the > driver it went into a loop which prevented it from being installed. > There may be a way to pre-install a driver, but that could be tricky. > > I switched to the new stack (2.6) recently, and found several changes > needed to be made. There also seems to be a bug in the code if you are > using a PIC2450 as I have on one of my older boards. > > I have two versions of PIC code, one for a CDC and another that uses > the generic mchpusb.sys driver. There is supposedly a bug in the > Microsoft supplied usbser.sys driver, but I have found that both work > equally well (or not well), and the errors seem to be random. These > are comm errors where the USB port seems to stop receiving data for a > second or longer, or where characters are skipped. The SuspendControl > lockup is a separate problem which seems noise related. > > Paul I'm using the 4550, as a HID device. A hard reset is not an option for me. But the USBSuspendControl state is an annoyance. Have you tried a pull down resistor on D+ ? I could detach my device and reattach it, since I don't need a driver with the HID model and my application will happily ignore it. I have a early USB stack, and the 2.7 seems to be really finicky. I just got it to enumerate, but that's all it does at the moment. Have yet to debug it, but I haven't seen any comm errors while using the HID. Yes it is noise related, I can reproduce it by discharging a hand held Tesla coil to earth ground near by ;) Cheers
From: Martin Riddle on 14 Jun 2010 18:54
"Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message news:yOzQn.98284$0B5.24423(a)newsfe05.iad... > > "Martin Riddle" <martin_rid(a)verizon.net> wrote in message > news:huudh9$v9t$1(a)news.eternal-september.org... >> >> >> "Paul E. Schoen" <paul(a)pstech-inc.com> wrote in message >> news:NqjQn.97996$0B5.94512(a)newsfe05.iad... >>> I have been having seemingly random noise problems where my >>> PIC-based USB device will go into a USBSuspendControl state, and it >>> requires the cable to be removed and replaced to reestablish >>> communication. The problem usually occurs in the field where there >>> is switching of high current and high voltage, but I was able to >>> duplicate it to some extent by running the USB cable along an AC >>> power line to a current source which I switched on and off. >>> >>> Recently I suspected that the USB cable itself might be at fault, >>> because I had bought a batch of 100 pieces for $0.69 each (but now >>> about $1.50) from www.CableWholesale.com, and several of these were >>> sent to a customer who reported problems, while a previous customer >>> with an older cable did not seem to experience this very much, and >>> another customer replaced his cable with a longer one, and he said >>> his unit was working OK. >>> >>> So, I dissected one of the new cables by removing the PVC jacket in >>> the middle, and I found a substantial tinned copper braid shield, >>> and an aluminized Mylar wrap under that. When I removed the shield I >>> could see that the four USB conductors were twisted together, which >>> is generally good for noise induced by strong magnetic fields. So >>> far, so good. >>> >>> But when I measured continuity from the connector shells to the >>> exposed shield, I got intermittent readings of about 3 to 30 ohms >>> and sometimes an open circuit. Then I measured the continuity from >>> shell to shell on a couple other USB cables I had been using, and I >>> found that one showed an open circuit and the others showed >>> intermittent. This was the case for two new cables from different >>> sources. Yet I measured the shells of a USB cable for my Nikon >>> digital camera (with a mini-USB on the camera end), and I got a >>> solid connection of less than 1 ohm. >>> >>> I still need to do more testing and I may also purchase a high grade >>> cable with gold plated connectors and better shielding. They are >>> about $20. I will also have my customer check the continuity and try >>> a better cable. Perhaps a USB 3.0 cable will work better. >>> >>> I removed the PVC molded cover for the male type "A" connector, and >>> there is a metal shell that extends back and tapers to a smaller >>> "neck" where the cable is clinched or crimped. By bending the ears >>> on the crimp I was able to separate part of the metal housing to >>> reveal where the shield has been folded back and exposed so that the >>> inner surface of the housing presses against it. But it seems that >>> the jacket of the cable is a continuous molding that fills the shell >>> of the connector, and the crimp mechanism can only apply light force >>> to the exposed part of the shield. So the actual connection may >>> degrade with time as a non-conductive film may form on the metal >>> surfaces, and mechanical flexing may further degrade the connection. >>> >>> Here are pictures of the cable after dissection and exposure of the >>> crimped >>> shield connection: >>> >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_23.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_26a.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_27.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_28.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_29.JPG >>> http://cygnus.smart.net/~pstech/photos/USB_Cable_Conn-A_30.JPG >>> >>> I think this is a design defect and I should be able to get a refund >>> or credit for the unused cables. It may not be the reason for the >>> problem but I should be able to determine that if my customers >>> replace the cables with high performance versions and their problems >>> are greatly reduced. >>> >>> Anyone else have experience with this? One member of the Microchip >>> forums reported that he found the following with some new cables he >>> had on hand: >>> >>> Poundland 1.8 m A-A(F) yellow 8 ohms >>> Signalex 1.5 m A-A(F) white OPEN CIRCUIT! >>> Signalex 1.5 m A-B white OPEN CIRCUIT! >>> CPC 1.8 m A-B translucent yellow 18.5 ohms >>> IXIOS 3 m A-A(F) translucent/silver grey gold plated >>> connectors <0.5 ohms >>> >>> Paul >> >> Interesting, I have the same problem with a PIC project. Right now >> I'm moving to the latest Mchip USB stack. >> I did find a well placed Ferrite bead suppressed the problem, but it >> still occurs once in a while. >> Eventually I plan on programmatically Detaching the device and >> re-enumerating, after a set period of inactivity. >> >> This problem does not occur with other USB devices in the system. > > I found that I had to put a jumper from an unused pin (24 = RB3) on > the PIC18F2550 to the D+ line of the USB connector to effect a > reliable detach and reattach. When the device is stuck in the > USBSuspendContol state, I use a countdown which eventually disables > interrupts, changes the pin from an input to an output and drives it > low to force a disconnect. Then I do a SoftDetach(), run a delay loop > for about 5 seconds, and then a program reset. > > However, this causes a problem on a new installation where the driver > must be installed. I found this from a customer. I already had the > driver installed, so it enumerated before the timeout, but without the > driver it went into a loop which prevented it from being installed. > There may be a way to pre-install a driver, but that could be tricky. > > I switched to the new stack (2.6) recently, and found several changes > needed to be made. There also seems to be a bug in the code if you are > using a PIC2450 as I have on one of my older boards. > > I have two versions of PIC code, one for a CDC and another that uses > the generic mchpusb.sys driver. There is supposedly a bug in the > Microsoft supplied usbser.sys driver, but I have found that both work > equally well (or not well), and the errors seem to be random. These > are comm errors where the USB port seems to stop receiving data for a > second or longer, or where characters are skipped. The SuspendControl > lockup is a separate problem which seems noise related. > > Paul I tried some experiments with decoupling (2.2uf tant) the Vusb output pin. Some improvement which leads me to believe there is a noise related problem with the internal USB core. ( I don�t use the Vusb pin, and apparently the USB core runs on 3.3v ) Also I see that there is another lockup beside the SuspendControl, I haven't dug deeper since I was successful in detaching and Attaching to the USB bus. But this is a bandaid fix, and I'm sure most will find this not acceptable, but in my system its acceptable. I was able to detach by setting UCON=0 and UIEF=0 ,waiting 1sec and reattaching by setting USBEN=1 and UPUEN=1 and initializing the stack. I left my version 2.1 stack in the code, since 2.7 required a little more work and we don't have any other problems with it. I added a com timeout to handle the unknown lockup, since it is not related to the SuspendControl lockup. Now everything happily recovers, without a hard reset, when that 120vac relay switches in the system. Cheers |