General Troubleshooting

Why You're Here

Although Phidgets are designed to be easy to use, they actually are a complex system with many levels of interfacing between the Phidget, cables, possible networking, operating systems, USB ports, the Phidget Libraries, and ultimately your code.

Operating System Troubleshooting

macOS

First, make sure you have followed the getting started guide on the macOS page.

You should now have the latest Phidget software installed and have the Phidget Control Panel running. If your device is not listed in the Phidget Control Panel, verify that your computer is detected the Phidget via USB. To do that, follow these steps:

1. Navigate to the Apple Menu and select About This Mac

2. Click on the System Report button. Find your Phidget in the USB section.

If you can see your Phidget in the USB list, take a moment to check the basics:

• You are using macOS X 10.5 or newer
• No other programs, drivers, or processes are using that USB port in software (including other programs trying to use Phidgets)
• Your Phidget libraries are up-to-date

If your problem is not solved, there might be a communication issue.

Communications Troubleshooting

To determine whether the problem is a communications problem, check operation using the shortest, most direct connection you can, including both:

• Data connections, and
• Power connections

If you believe a connection may be at fault:

• Use short USB cables (<5 m)... long wires lead to poor sensor data and/or inadequate power
• Use powered USB hubs or direct connections to a computer.
• Try unplugging everything on the hub except the Phidget.
• Try plugging the Phidget directly into the computer instead of using a hub. If this solves the problem, either the hub is at fault, or the added length of cable from the hub to the computer may have caused instability.
• Make sure any cables between Phidgets are correctly connected. Helpful pictures can be found on the User Guide for your device
• If your Phidget needs external power, such as the motors and relays, the proper way to provide it can be found on the product page for your device on our main website

Communication problems come from either (a) power issues, or (b) connection issues. Once everything is plugged in and powered properly, there is not a whole lot that can go wrong with cables.

The one exception to communications problems being only from power or connections is if you're using a wireless internet connection to the Single Board Computer. Help for setting up and troubleshooting that Wifi connection can be found on the SBC operating system page.

Code Troubleshooting

To determine whether the problem is in your code, you should run the provided examples for your programming language.

• If the examples run, the problem is within your code.
• If the examples do not run, the problem is at a lower level in the system. Read on to the operating system troubleshooting section below.

If the problem is in your code:

• Syntax help can be found in the Phidget22 API and code snippets for your programming language
• High-level concept help (logging, catching errors, using the API) is on the General Phidget Programming page
• Compiler help (linking libraries, running code) can be found on the page for your language
• Ensure you wait enough time for the Phidget to respond to your requests, such as when switching between ratiometric and non-ratiometric sensing, or to get and set device data.

To download and run the examples, visit the page about your programming language. The API section on the product page for your device on our main website will tell you the software object -- and thus example file name -- for your Phidget. Make sure to use either that object-specific example or the '"HelloWorld" example if one is available.

When debugging, it helps to extract from your code what is known as a Minimum Reproducible Unit (MRU). This is the minimum lines of code that can reproduce the issue. We can help with this. An MRU will allow you to find what part of your use of Phidgets in code is causing the problem. Extracting an MRU is a powerful process which can not only isolate the problem, but also allow you to examine and organize your code. Also, it helps us debug your problem faster if you can show exactly what the problem is in the part of your code that deals with Phidgets.

If you have found problematic lines and want to see what is wrong, you can turn on Phidget logging. Logging can save and display many different levels of messages (errors, debugging, or even individual Phidget library actions) to either a file or the program console. You can find help to turn logging on and off in the Logging, Exceptions, and Errors page.

Note: We do not offer services to debug general (non-Phidgets) programming projects, or to develop code from scratch. We do, however, support any and all questions and suggestions about Phidgets and their use. So, if you have ideas for helpful examples, more documentation, or other useful material we could provide, we welcome them!

Network Server Troubleshooting

To determine whether the problem is with the Network Server, check whether the Phidget can run without the Network Server by directly connecting it to one of the computers and running Phidget code locally on that system.

• This will be possible at least for the computer hosting the direct connection to the Phidget
• You can use a local version of the open() function, or use our examples as described in the Code Troubleshooting section above
• For the platform remotely controlling the Phidget, this direct test may not be possible (such as for iOS or some Android devices)

If the Phidget works locally but not over the network, the problem is with the Network Server. If the Phidget does not work locally either, it is probably not the Network Server, and is instead your code, your operating system, your connections, or the device itself. Use this Troubleshooting guide on the local system to diagnose the problem.

If the problem is within the Network Server:

• Make sure the Phidget library and Network Server versions are the same on both computers. Different Network Server versions do not work together. Find the Network Server download on the page for your operating system
• Wait some time (a few seconds, to start) before trying to do things with the Phidget upon first connecting remotely, sometimes delay occurs over a network
• Check the network setup on both sides. Typos can occur in the IP address, port number, server name, and password.

Slowing your program down by using a sleep or wait function will allow you to test whether network lag is at fault. Network delay will primarily affect (a) how quickly you can use the Phidget after opening and attaching it, and (b) the speed of reading continuous data from the device. Putting wait delays in your code especially in data-reading loops will prevent the network from being totally overloaded, and let you see whether you can get 'any' data through.

Another problem might be an error in the details that need to match on each computer. You either need an IP address and port, or the server name (when using muticast DNS from Bonjour on Windows and OS X or avahi on Linux). The server name is set at the Network Server start up, or it will default to the name of the computer with the direct connection. Double-checking all of these details may uncover the problem.

Finally, if you suspect multicast DNS may be the problem, use the IP address and port form of the open() function to directly connect to the computer controlling the Phidget. On Linux, the use of mDNS can be compiled out of the Network Server, and the Network Server can be tested without it.

Version Mismatch

If you are experiencing a "Version Mismatch" error this is due to either end of the connection having an out of date version of the Network Server. To fix this make sure that both ends are fully updated and try again. Note that on the SBC this means you will need to go to the System->Packages tab and upgrade all of the systems packages. For more information on upgrading the SBC refer to the SBC's User Guide.

Device Troubleshooting

To determine whether the problem is with the Phidget itself, check whether the Phidget works on a different computer.

If you suspect the problem is with the hardware:

• Move the setup to a different operating system. If it appears on another system, you'll want to debug your original system starting with Operating System Troubleshooting
• Check what your device can and can't do (power, functionality, etc) - this will be found on its product page on our main website.
• Make sure all the pieces are hooked up correctly. Helpful photos can be found on the Getting Started page for your device in its user guide.
• If you're trying to do something especially involved, become well-versed in your hardware. We provide lots of information on our primer pages.

It may be tempting to assume that a device "not working" indicates a problem with the hardware. But this troubleshooting page itself shows that even something as simple as a device "not working" could be due to a problem at several different points. The best place to start if you haven't worked through our documentation yet would be the Getting Started guide for your device, found in its user guide.

Diagnosing Hardware Problems

An easy way to tell you have a new problem with your device is that it suddenly stops working. If you run the same code, on the same system, with the same libraries, and the same Phidget and suddenly it doesn't do the same thing anymore, you almost certainly have a hardware problem. This can happen especially on boards and/or components that handle some form of external power (motors, relays, etc). It is important to make sure you don't overload the board, or you could do some serious damage. Check the specs for your device and remember, be conservative.

Heat

One of the surest ways to discover a problem is as simple as touching the board. When current flows through electronics it will generate heat, this is a fundamental fact with all electronics. The more current that you are pushing, the more heat that will be generated. As a result of this the instance where you have the most current possible flowing (a short circuit) will also generate the most heat. So much heat that it will likely be painful to the touch so be careful when poking and prodding the various parts of the board. Keep in mind that some heat build up is to be expected, but if you can find a part of the board that is unusually hot then there is a strong possibility that there is a short circuit somewhere in that section and the board has been damaged. You should contact us if this is the case.

Checking Voltages

If you have a multimeter at your disposal another good way of checking your board is to check that all of the ICs on the board are getting the power they should. If you look at the labelling on the top of the ICs you should be able to get the part number of the chip. If it is too small or hard to read you can always look at the high resolution product images on our website to get a better look. Failing that, contact us and we can give you the part number. Once you have it search the internet for a data sheet for the part. The data sheet will have a pin diagram from which you can determine which pins are V_cc and Gnd. Take your multimeter and measure the voltage between those pins. Does the chip appear to be getting the voltage it should be? If not then it is possible there is a short somewhere in the power line.

EMI

One of the most difficult hardware related problems to diagnose and debug is electromagnetic interference or EMI. In fact, it is such a complex topic that we have a guide devoted entirely to it. If you think you may be having EMI difficulties or if you don't know what kind of difficulties you might be having (an apparent lack of other explanation is a good sign your problems might be EMI related) you should read our guide for addressing EMI issues.

Contact Us

If you are still having trouble after working through this guide, please contact us.

It helps if you can you can give us precise information about your issue, such as:

• Minimal code to reproduce the problem
• What part of the system you think the issue might be in, and why
• Photos or even videos when necessary