Improving Phidgets Hardware Reliability

From Phidgets Support

This document is meant to be used as a first line of defense by customers who find their Phidgets system is not stable, or who are designing a system and want to understand common sources of instability.

The most common issue is device resets. A reset is commonly seen as a Detach event, usually followed by an Attach event. Your program should be written to handle these events cleanly, and you can easily test your program by forcing these events to occur by unplugging and replugging the USB or VINT cable during normal operation. Our recommended best practice is to cleanly handle detaches in your code, AND resolve the source of detaches.

Device Resets (Due to Low USB Voltage)

1014 multimeter.jpg

The most common source of detaches is low USB voltage. These detaches are deliberately executed by the USB Phidget device to guard against any possibility of erratic behaviour. Multiple factors are at play, and usually several are required to create a low voltage situation. If you suspect this issue, debugging begins by setting up the worst case scenario for power consumption (turn on relays, etc) and measuring USB voltage on the Phidget that is detaching.


Specific USB Phidget

Older designs of Phidgets that use Cypress microcontrollers need to set a very high reset threshold to guard against erratic behaviour; the device will reset (detach) if USB power drops below 4.55 volts. A complete list of Phidgets with Cypress microcontrollers follows (omitting the revision number, this applies to all devices with the base part number). Click on the [Expand] next to your Phidget listed here to see where to measure with a multimeter if you suspect an issue.


1002 - PhidgetAnalog 4-Output

1002 TestPoints.jpg



On the underside of the board, test the USB connector's power and ground pins as pictured.


1010 - PhidgetInterfaceKit 8/8/8 Mini-Format

1010 TestPoints.jpg



Test any 'G' pin and any '5V' pin.


1011 - PhidgetInterfaceKit 2/2/2

1011 Testpoints.jpg



Connect the cable to the 1011 and measure between any red wire and any black wire.


1012 - Phidget InterfaceKit 0/16/16

1012 Testpoints.jpg



Test any '5V' and any 'G' pin.


1014 - PhidgetInterfaceKit 0/0/4
1014 2abc Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.

1014 2 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.

1014 01 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1017 - PhidgetInterfaceKit 0/0/8
1017 1 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.

1017 0 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1018 - Phidget InterfaceKit 8/8/8

1018 Testpoints.jpg



Test any '5V' and any 'G' pin.


1040 - PhidgetGPS

1040 Testpoints.jpg



On the underside of the board, test the USB connector's power and ground pins as pictured.


1045 - PhidgetTemperatureSensor IR
1045 1 Testpoints.jpg


On the top of the board, test the USB connector's power and ground pins as pictured.

1045 0 Testpoints.jpg


On the top of the board, test the USB connector's power and ground pins as pictured.


1046 - PhidgetBridge 4-Input
1046 2d Testpoints.jpg


On the top of the board, use the test points as pictured.

1046 0abc Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.

1046 0 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1047 - PhidgetEncoder HighSpeed 4-Input

1047 Testpoints.jpg



Test the '5V' and 'G' pin.


1048 - PhidgetTemperatureSensor 4-Input

1048 Testpoints.jpg



On the underside of the board, test the USB connector's power and ground pins as pictured.


1051 - PhidgetTemperatureSensor 1-Input
1051 2a Testpoints.jpg


On the top of the board, use the test points as pictured.

1051 2 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.

1051 01 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1054 - Phidget FrequencyCounter

1054 Testpoints.jpg



Test any '5V' and any 'G' pin.


1055 - PhidgetIR

1055 Testpoints.jpg



On the underside of the board, test the USB connector's power and ground pins as pictured.


1057 - PhidgetEncoder HighSpeed

1057 Testpoints.jpg



Test the second and fifth pins on the encoder connector, either where the bent pin enters the plastic housing on top, or where the pins are soldered on the underside.


1061 - PhidgetAdvancedServo 8-Motor
1061 1 Testpoints.jpg


On the top of the board, test the USB connector's power and ground pins as pictured.

1061 0 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1062 - PhidgetStepper Unipolar 4-Motor
1062 1 Testpoints.jpg


On the top of the board, test the USB connector's power and ground pins as pictured.

1062 0 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1064 - PhidgetMotorControl HC
1064 1 Testpoints.jpg


On the top of the board, test the USB connector's power and ground pins as pictured.

1064 0 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


1065 - PhidgetMotorControl 1-Motor

1065 TestPoints.jpg



Test the 'G' pin and '5V' pin.


1066 - PhidgetAdvancedServo 1-Motor
1066 1 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.

1066 0 Testpoints.jpg


On the underside of the board, test the USB connector's power and ground pins as pictured.


USB Phidgets other than those listed here have a much lower reset threshold, and would require a very unlikely scenario to produce a low voltage reset.

USB Cable

USBconductors.jpg

Some USB Cables have thin power conductors or a poorly bonded shield braid. This is unlikely to be an issue on a 30cm cable, but a longer USB cable needs to be properly built.

The maximum length for a USB cable is 5 meters. We don’t recommend using USB extenders, repeaters, or USB over Ethernet products because they are often a source of instability. Implementing control of Phidgets over long distances or wireless is best done with the HUB5000 if your system is exclusively VINT, or the SBC3003 if you also need to use some USB Phidgets.

USB Supply Voltage

Unpowered USB hubs can really reduce the USB supply voltage. The power to the hub is shared across multiple devices, and the hubs will often use inexpensive passive fuses that strongly reduce the voltage as current increases. Early versions of the Raspberry PI would typically provide such a low voltage that many USB Phidgets were prevented from working at all. If you suspect this is a problem in your system, try using an externally powered USB hub.

Pulsed Power Consumption

Some sensors and controllers produce heavy spikes of power consumption, which can cause the USB voltage to flicker.

  • Motors that run from USB power will consume much more power during fast acceleration from standstill, and stall conditions. Luckily, most Phidget motor controllers are externally powered (the 1066 is a notable exception).
  • Infrared distance sensors (e.g. Sharp Distance Sensors, 1103) will typically flash an LED with a pulse of current. The Sharp Distance Sensors have such an extreme pulse of power that the 1101 adapter board was specifically designed to buffer this pulse. The 1103 uses much smaller pulses, but still requires care if several of them are running on a single USB interfacekit.


Notice the additional 50-100mV of noise present on the InterfaceKit's 5V power signal when connected to several 1103 sensors.


You should only be concerned if the product documentation for your device mentions a high pulse load, and you are deploying multiple devices. Assurance that your devices are well above the reset voltages can be done in several ways:

  • Monitor USB voltage during operation with an oscilloscope. Make sure USB stays above 4.75 volts (if your USB device uses the Cypress Microcontroller, listed above)
  • Change the USB cable to a longer cable, run the system for several hours, and then swap back to a shorter cable for deployment.
  • Call application engineers at Phidgets Inc.

Device Resets (Due to Grounding Issues)

Heavy flows of current on USB cables can reduce effective USB voltage, and in severe cases, interfere with signaling. Products more likely to experience problems are non-isolated USB Phidgets that connect to external power supplies or externally powered loads. Examples of USB Phidgets that are more likely to be wired in a way that produces issues are:

  • 1012 - PhidgetInterfaceKit 0/16/16
  • 1032 - PhidgetLED-64 Advanced
  • 1061 - PhidgetAdvancedServo 8-Motor
  • RCC0004 - PhidgetAdvancedServo 8-Motor
  • 1065 - PhidgetMotorControl 1-Motor
  • SBC3003 - PhidgetSBC4 (And older SBCs)
  • HUB5000 - Wireless VINT Hub
  • HUB0003 - 7-Port USB Hub

Don’t panic! Just because there is a power supply or battery in your system, doesn’t mean grounding is a problem.

  • If your power supply or battery is only attached to this device, grounding will not be a problem.
  • If your power supply is shared with other devices, but at most one device is not isolated, you cannot have a grounding problem.
  • If you have multiple non-isolated loads that share a power source - look out.

Here's a few scenarios that you might find in your system. Note that only the ground connections are shown in these diagrams for simplicity's sake.

Ground1.jpg Scenario A:
  • Only one possible path for current to flow
  • This layout has many "arms" but no loops
  • No grounding problems in this scenario
Ground2.jpg Scenario B:
  • Computer and Phidget are both powered from the same power outlet or bar
  • Possible grounding problem if power supply ground is not isolated from computer ground
  • See scenario C for solutions if there is a grounding problem
Ground3.jpg Scenario C:
  • Externally powered Phidget and connected SBC both sharing the same power supply
  • Definite grounding problem here
  • Possible solutions:
  1. Break the loop: Switch out the USB Phidget and SBC for a VINT SBC and a VINT device such as the DCC1000. VINT devices are isolated, so no current can flow back through the SBC. Alternatively, you can get a 3060 - USB Isolator and put it between the SBC and the Phidget as indicated in the diagram, but this solution will be more expensive than using VINT.
  2. Use short wires between the most current-heavy Phidgets and the power supply ground, so that current will have an obvious path to ground. The problem with this solution is that the system may still function if these heavy connections fail to prevent a ground loop. In this case, the system would become unreliable or could even destroy the devices. It's safer to design with isolation, especially since VINT devices offer low-cost, effective isolation.
Ground4.jpg Scenario D:
  • Many powered Phidgets connected to the same powered USB hub, all sharing the same power supply
  • So many ground loops!
  • Possible Solutions:
  1. The best solution is to switch to VINT devices (in this case, the REL1101 or DAQ1301 would replace the 1012). Not only are these newer devices more fully-featured, they also come with plastic enclosures and cost less than their USB counterparts, even when you add the cost of the VINT Hub.
  2. Install the 1012s physically close to power supply and use copper braid or heavy gauge wire for ground.
  3. Put USB isolators between all devices and the USB hub (Ouch, this could get expensive!)

Device Resets (Due to Cable to Cable Interference)

Wrapping cables together to create huge bundles may look neat and attractive, but it can increase electrical noise. Most wiring doesn’t have enough noise to cause problems, but here is a breakdown of some typical cables:

Cable Noise Generation Noise Vulnerability Comments
USB icon.jpg USB Low Low USB and Ethernet are well balanced electrically, able to function in reasonably strong interference and not cause problems for other cables in close proximity to them.
Ethernet icon.jpg Ethernet Low Low
Coax icon.jpg RF (Coaxial) Cables Low High RF (Coax) Cables are very unlikely to cause interference, but are vulnerable if bundled tightly with cables that are creating even moderate interference.
DIAI icon.jpg Digital Input or Analog Voltage Signals Low High Unlikely to cause interference, but can very easily pick up interference. This type of signal can easily be shielded (we sell multi-conductor shielded cable), but can also be easily filtered by the product receiving the signal. Fortunately, the designers at Phidgets have long since learned how to properly filter incoming signals.
Pwr icon.jpg Power Distribution Lines Moderate Low Unlikely to be affected by any interference received. Noise levels are typically in the hundreds of millivolts - possible to interfere with other cables in the vicinity, but should not be noisy enough to cause communication resets on buses like USB.
Motor icon.jpg Motor Controller Outputs High Low Heavy generators of noise. The wires between a stepper motor and its controller (running at 24 volts in our example) look like 24 volts of high frequency noise to other wires in the vicinity.
PWM icon.jpg PWM Power Signals and Outputs High Low Pulse-width modulated outputs from boards like LED Controllers (1032, LED1000) and generic controllers like REL1101 also produce very large amounts of noise at high frequencies.

Wires prone to high noise emissions should be kept short (well less than a meter) and not be routed closely with other wiring. USB and VINT are able to function in close proximity to these noise sources, especially for prototyping. When deploying systems, arrange your data cables perpendicular to power cables to minimize crosstalk to buy extra margin, just to be safe.

ParalellPerpendicularWire.jpg

Device Resets (Caused by Sharp “Cracks” of Interference)

Static Discharge

People are commonly charged with upwards of tens of thousands of volts of static electricity as we walk across carpet, get in and out of our cars, etc. We are effectively high voltage capacitors that occasionally discharge into the electronics we touch. When electronics designers plan for ESD (Electrostatic Discharge), the first priority is to ensure the survival of the circuit. The second priority is to cleanly recover in a reasonable amount of time.

Any circuit designer worth their salt can design a smallish circuit board like found in most Phidgets to cleanly ride through an extreme electrical shock like an ESD event. The challenge is usually on the communication buses, like USB. The system response to this burst of sudden errors will be to reset the device. This is a major reason why we recommend our customers code to cleanly handle device detaches/attaches. All our devices are designed and tested to reattach cleanly, but application code has to handle this when it happens.

Anything else that generates a spark

Plugging in an extension cord, power supply, or opening/closing a mechanical relay will create a small spark, and a blast of interference. Under normal conditions, a system built from Phidgets will easily ride through, automatically correcting any communication errors. At worst, devices will detach/re-attach.

In our experience, poor shielding will make a system much more vulnerable. Metal in close proximity to cables will pick up the interference, and strongly amplify the noise into the cables. If metal enclosures are used, they must be designed to operate as a Faraday cage - particularly in the range of 10-200Mhz. This is well outside the scope of this document - our generic recommendation is to shield cables if necessary, and not attempt to shield Phidgets and the system as a whole.

In our experience, the shield of a cable must be connected to ground on each end. This recommendation is exactly opposite to what many engineers have learned. In fact, the original USB 1.0 specification called for not connecting USB shield to ground at the device - they have since changed their tune!

Use of Ferrite Beads

Ferrites are useful for damping out electrical ringing on cables. Every cable will have preferred frequencies - mostly determined by cable length. External noise couples into wires, providing the stimulus for the ringing. The longer ringing carries on, the higher the chance of interrupting communication and triggering a device reset. Standard USB Cables already have ferrite beads installed- adding more will not hurt, but this is typically not required.

USB ferrite.jpg Phidget ferrite.jpg

If there's space inside the ferrite bead, you can loop the cable through multiple times to increase the effect.

Ferrite beads will not help to reduce noise on wires carrying PWM signals or motor control. The noise is far too strong for ferrites to help. Adding ferrites to power distribution wires will reduce noise, and should be placed close to the source of interference. Only do this if there are specific symptoms, for example interference on a radio. Phidgets Inc. is very careful to filter power supply noise created by our devices before the noise has a chance to leave the board.

In conclusion - Ferrites beads are not normally required on a system built with Phidgets. Use ferrites on communication lines if devices are detaching because of electrical noise.


General Recommendations

Prototype and Lab bench systems

Just build it. Chances are very high you won’t have any problems. Use VINT devices as much as possible, especially for devices that need external power. If there is any chance a VINT device will benefit from isolation, then we’ve already built it in. Avoid the temptation to tidy up all the cables into bundles.

Production systems

The spark from a BBQ lighter creating interference on the USB power of a nearby Phidget.

Use VINT devices as much as possible, especially for devices that need external power. If there is any chance a VINT device will benefit from isolation, then we’ve already built it in. Be careful with PWM outputs (including LEDs), motor outputs. If possible, keep these wires short, and away from other signals. Bundling wires that aren’t being deliberately pulsed is usually ok. Don’t spend extra for metal enclosures unless you have expertise with shielding. Minimize USB cable lengths, by buying cables that are the minimum length for your application. Cutting and resoldering a USB cable is a bad idea.

If you are deploying USB Phidgets that use the Cypress Microcontroller (listed earlier), maximize the USB power consumption in the system, and check USB voltage at each Phidget. If you see a voltage less than 4.75V, contact us.

Use a BBQ lighter to create electrical interference to test if your system can recover gracefully. Don't let the spark directly contact the system though- these sparkers generate a huge power spike that can damage components on the board.

Test your code by unplugging and replugging devices, and cycling external power (if that can be done without bringing down the entire system)