Troubleshooting Common Issues

Click on your operating system or programming language to see a list of common issues you could be experiencing.

WindowsmacOSLinuxPhidgetSBC

Select your operating system in the tabs above.

• Windows computer's servers are visible, but not their attached Phidgets

If you can see the server for a Windows computer, but not the attached Phidgets, make sure the Network Server isn't being blocked by Windows Firewall. You can change this setting by going to the start menu and searching for "Windows Firewall". In the Windows Defender Firewall, choose "Allow an app or feature through" and add the Network Server to the list (you can find it at C:\Program Files\Phidgets\Phidget22\NetworkServer.exe).

• Software projects are not working after a Phidget22 reinstall

You need to reset your references and library paths. When you reinstall the Phidgets drivers all of the old paths can get broken. Make sure that you are including the correect header files and that you have referenced the correct libraries and that should fix the problem.

• Some third party software prevents communications with Phidgets

Some drivers or software will sometimes mistakenly claim Phidget devices when waiting on some hardware to be connected. This is caused by the drivers taking every HID (human interface device) on the USB bus, effectively stealing them from the Phidgets drivers. When this happens, the device shows up in the Phidget Control Panel at start up but examples and programs are unable to make a connection to the Phidget. This has been known to occur with Logitech QuickCam, Force Feedback Mouse, Nike, Velleman K8055, and some SteelSeries drivers.

Solution: If you suspect this is a problem then try putting your machine in safe mode. If this fixes the problem you can be sure that this is the problem. Try shutting/uninstalling the offending driver/software down or kill its process in the task manager when using Phidgets.

• A corrupt installation fails on uninstall or repair

Solution: If the normal uninstall fails, for whatever reason, you can choose to remove the Phidget drivers manually. Please perform the following:

1. Shut down any programs and processes using the Phidget libraries, including the Network Service and the Phidget Control Panel.
2. Delete C:\Program Files\Phidgets\
3. Remove the Phidgets key from the Registry [-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Phidget22NetworkService].

In most cases this is enough to get the installer working again. If you need to remove all traces of the Phidgets libraries manually, perform the following additional steps:

1. Remove Phidget22.NET from C:\Windows\Assembly\.
2. Delete C:\Windows\system32\phidget22.dll.
3. Delete Phidgets from the start menu.
4. Search for and remove keys mentioning Phidgets from the registry in the following locations:
   • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\]
   • [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\]
   • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders\Phidgets Inc]
   • [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Assemblies\Global\]
5. Reboot

NOTE: You can go through the registry and purge any other keys mentioning Phidgets if you still have problems, but at this point you should be able to reinstall under most cases. There will also be keys relating to the installer, the .NET library and the COM library, but they should not interfere with anything.

• Event data is sporadic/slow/clumped over the Network Server

Windows implements 200ms delayed ACKs for network traffic. When traffic is one-way only - as it is with event data, the data will all arrive in clumps every 200ms because of delayed ACKs.

This can be a great drawback for applications which rely on low latency event data over the network. (source: http://support.microsoft.com/kb/214397)

This delayed ACK behavior can be disabled in windows to decrease event latency as documented here: http://support.microsoft.com/kb/328890

In the future, the Phidgets library may implement this differently, but so far we have been unable to match the performance achieved by disabling delayed ACK.

• Control panel shows Phidgets, but they are all 'busy' when opened, and no other process is using them

It's possible macOS is blocking the Phidgets for security reasons. Go to System Preferences -> Security & Privacy, and under the "General" tab, see if you get the message "Some system software was blocked from loading". Try to click the allow button, and if nothing happens there is a known issue in some versions of macOS where the allow button doesn't work. To get around this, go to System Preferences -> Keyboard -> Shortcuts -> Select "All Controls". Then, go back to System Preferences -> Privacy & Security and press tab until "Allow" is selected and press the spacebar. You may need to close and open the system preferences window in order for the keyboard settings to take effect, and you may need to click the lock and enter your password before pressing tab to select the allow button.

• Linux will only schedule one low-speed interrupt transfer per millisecond

You can find out the type of your Phidget by attaching it and then running dmesg | tail, which will display the type of Phidget from your kernel logs, as described above in the hardware section. The practical consequence of this is if your system has many low speed Phidgets attached, they will each be throttled down. Low speed Phidgets require an interrupt transfer as often as every 8 milliseconds. A Linux system could only have up to 8 of these Phidgets attached.

• The data read from a program, or the first packet on the Network Server, can give a sample overrun error (EEPHIDGET_OVERRUN)

Linux only polls data from the analog inputs on Phidgets when you ask it to. So there is some delay between when you open the device and when it actually attaches when data from those inputs are accumulating...and overrunning the buffer. This is simply in the nature of how Linux polls USB - we recommend catching (but ignoring) this one-time initial error.

• My device doesn't seem to run as expected on a Raspberry Pi

The USB ports on the standard Raspberry Pi are only capable of supplying around 100mA reliably. Since USB specification dictates 500mA of current maximum, many USB devices require several hundred mA to run smoothly. Since the Pi cannot supply this much current it is common to see buggy performance or complete failure to run at all. The get around this you should use a USB hub connected to the Pi that has it's own external power supply. This will allow the devices connected to have as much power as they require.

• Curl doesn't install smoothly

There is an issue with the embedded version of PHP5.3, try forcing it to install the specific version that you need. This can be done with the following command:

apt-get install php5-common=5.3.3-7+squeeze14

• FTDI adapters do not appear to work with the SBC

The 3.1.6 version of the Linux kernel which is used on some versions of the SBC has a bug that causes issues with FTDI drivers and makes them malfunction. To solve this problem you must upgrade the kernel to a newer version. You can find the files here.

• USB Memory Keys mount at more than one location

When you insert a memory key, the SBC will load it as a device (e.g. /dev/sda1) and it will also mount the key for reading and writing within the /media/ directory. The /media/ directory version will be called something like usb0. At times, an inserted memory key will get mounted in more than one location. You can observe if this occurs by checking the currently mounted devices with the command mount:

root@phidgetsbc:~# mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
procbususb on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /media/usb0 type vfat (rw,noexec,nodev,sync,noatime,nodiratime)
/dev/sda1 on /media/usb1 type vfat (rw,noexec,nodev,sync,noatime,nodiratime)

You will note that the same device (/dev/sda1) is now mounted at both /media/usb0 and /media/usb1. To fix this problem as it occurs, you can use umount (notice there is no letter 'n') to unmount the second instance:

root@phidgetsbc:~# umount /media/usb1

In practice, this should not be a problem, because writing to or reading from either usb0 or usb1 will have the same effect on the memory key. However, if you hard-code a media location into your program (i.e. expecting /media/usb0 to be the first USB key you insert and /media/usb1 to be the second key) your program will sometimes work and sometimes fail.

To get around this within code, find the mount point for each device as it appears. The devices, such as /dev/sda1 will always refer to the actual memory key. But, they cannot be written to directly without being mounted, so you will have to parse the mount table (what is returned from mount) within your code to find the device and its corresponding mount point.

This is a problem with the standard embedded Debian automount program, and we have no known fix.

• Perl Locale Errors on SSH - No Locales Installed

By default, no locales are installed on the SBC. If you use apt a lot to install and manage your software on the SBC, you will get messages like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LANG = "en_CA.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

To squelch these messages, you should install and reconfigure your locale like this:

apt-get install locales
dpkg-reconfigure locales

The last command will show you a long list from which you should pick your location, by language. For example, en_CA is english_Canada. Here in Calgary, we use en_CA.UTF-8 and so for the first question we would input locale "114" and for the second (system) question we would input en_CA for the locale.

This might give you a locale undefined error, in which case you can generate the locale (for us, again, it is en_CA):

locale-gen en_CA

• My Cron Job Doesn't Work

It is actually very common for a script or program to work on the command line but then not work as a cron job. The most common reason for this, by far, is that you specify relative paths in your program to access files rather than absolute paths. For example:

• code/project.c is a relative path (bad for cron)
• /root/code/project.c is an absolute path (good for cron)

The cron jobs are not executed from your home directory, or your code directory, so they will not be using the same location you may be using to test your code. So always use absolute paths.

Another common reason is you may be using environment variables or other settings that are true in a terminal but are not true by default in the raw system. You can end up taking many things for granted in a shell, for example the shortcut "~" means home directory in a shell, but not by default in the raw system. The things that get loaded for a shell (but which are not present in the raw system) are:

• The settings loaded by /etc/profile
• Any settings in ~/.bashrc, which is nothing by default on the SBC

On a full Linux operating system, you would use the logs written to by cron to find the error output and debug it. On the SBC, however, cron does not write logs (otherwise, these logs would eat up the SBC memory very quickly even for routine jobs). For short-term debugging, you can write output from your program to a file, and read that file afterwards to figure out what your program is doing.

C/C++LabVIEWMax/MSP

Select your programming language in the tabs above.

• I am using a non US-English version of Windows, and the Visual C/C++ examples run into a linker error

The example projects, by default finds the phidget22.h and phidget22.lib in ${SystemDrive}\Program Files\Phidgets\Phidget22. If you are using a non US-English version of Windows, the Phidget libraries may be installed into a different location. To resolve, you will have to modify the paths to these two files. For instructions, please see your environment/compiler section.

• I cannot attach to an object any more after running my program once

What this means is you probably aborted the VI which stopped the program before the Phidget could be closed. Aborting execution will not release the Phidget device properly and will consequently make it unusable until the Phidgets library (or LabVIEW) has been restarted.

To resolve this, you may open a new VI, place PhidgetResetLibrary.vi, and run it. This will completely reset the current Phidget library, making it possible again to connect to all Phidgets.

Note that this action will close all Phidgets that are currently open in LabVIEW, and should not be used while other Phidgets-related LabVIEW VIs are running.

In order to prevent this from happening you should use a software stop button when possible instead of halting operation. That way the Close subVI gets called and the Phidget will be released.

• When a patch file is closed in the Max/MSP environment, the program crashes

If in your Max/MSP environment, you have more patches(of the same Phidget object) than you have of the actual hardware device, the Max/MSP environment may crash. This is due to the fact that a single Phidget Max/MSP object only corresponds to a single Phidget device hardware. For example, your Max/MSP environment may experience unexpected behavior while you have one PhidgetInterfaceKit device connected to the computer, but you have a two seperate patches opened with a single PhidgetInterfaceKit Max object in each one.

Likely Fix: Please ensure that you do not use more patches(of the same Phidget object) than you have of the actual Phidget device.