I am testing the Phidgets drivers on http://code.tinyclr.com/project/88/phidgets-drivers/
first, I try to turn on the LED on RFID reader. But it shows error.
public static void Main()
{
MyRFID.Attach += MyRFID_Attached;
MyRFID.Tag += MyRFID_Tag;
MyRFID.TagLost += MyRFID_TagLost;
MyRFID.LED = true;
Thread.Sleep(Timeout.Infinite);
why not copy it all as is first and try it?
Because I copy all,debugging, no error.
But can’t find my RFID reader in my domino.
So I think I can turn on the LED for testing.
But error happens.
What I am doing is that I download the source code from the code site,then add the class to my project.
Do I need to create a new class then copy the driver to the class?
I agree with Gus, if you’ve never had the driver/devices working, start from something that should work on it’s own, by using the example code. Then build on things from a known working point, that way you know what you last did broke it 
Do you have this statement somewhere:
static PhidgetRFID MyRFID = new PhidgetRFID();
YES, I use the example code for testing, but can’t find my RFID reader.
most likely then your problem is not code, it’s hardware/wiring. I have no idea what a Phidget looks like so can’t help there I’m afraid :’(
More code would help. I still use this code for my own needs so I know it’s working.
Are you sure that the DeviceConnectedEvent has been fired ? Because _RFID is created in this event handler. So if it’s null, then either the event didn’t fire or the USBH_RawDevice() method has failed.
Do you mean this below?
I set a break point in this Event, but when running, it doesn’t go into the break point.
The RFID is fine for my PC side, so the hardware is ok.
Do I need to create a new class file then copy your code to the new cs file?
For your driver, I just download it to my pc, then add to my project.
private void DeviceConnectedEvent(USBH_Device device)
{
if (device.TYPE == USBH_DeviceType.HID && device.VENDOR_ID == 0x06C2 && device.PRODUCT_ID == 0x0031) // Detect only Phidgets RFID
{
_RFID = new USBH_RawDevice(device);
USBH_Descriptors.Configuration cd = _RFID.GetConfigurationDescriptors(0); // Get descriptors
USBH_Descriptors.Endpoint _RFID_EP = null; // communication endpoint
USBH_ERROR e = 0;
for (int i = 0; i < cd.interfaces.Length; i++) // look for HID class
{
if (cd.interfaces[i].bInterfaceClass == 0x03) // found
{
for (int ep = 0; ep < cd.interfaces[i].endpoints.Length; ep++) // look for input interrupt Endpoint
{
if (cd.interfaces[i].endpoints[ep].bmAttributes == 0x03) // is it interrupt Endpoint?
{
#region Board serial number
// Get the board's serial number
byte[] toto = new byte[0x0C];
_RFID.SendSetupTransfer(0x80, 0x06, 0x0303, 0x0409, toto, 0, 0x0C);
for (int j = 2; j <= 0x0A; j += 2) SerialNumber += (char)toto[j];
#endregion
#region Board name
// Get the board name
byte[] tutu = new byte[0x18];
_RFID.SendSetupTransfer(0x80, 0x06, 0x0302, 0x0409, tutu, 0, 0x18);
for (int j = 2; j <= 0x16; j += 2) Name += (char)tutu[j];
#endregion
//Debug.Print(Name + " detected, serial : "+Serial);
_RFID.SendSetupTransfer(0x00, 0x09, cd.bConfigurationValue, 0x00); // set configuration
_RFID_EP = cd.interfaces[i].endpoints[ep]; // get endpoint
_RFID_Pipe = _RFID.OpenPipe(_RFID_EP); // open pipe
_RFID_Pipe.TransferTimeout = 0; // recommended for interrupt transfers
// This loop is in fact waiting for the RFID board to be ready, that is : not throwing toggle errors
do
{
Thread.Sleep(_RFID_Pipe.PipeEndpoint.bInterval);
try
{
_RFID_Pipe.TransferData(RFID_Data, 0, RFID_Data.Length);
}
catch
{
e = USBHostController.GetLastError();
}
} while (e != 0);
_RFID_Thread = new Thread(RFIDThread); // Create the polling thread
_RFID_Thread.Priority = ThreadPriority.Highest;
_RFID_Thread.Start();
break;
}
}
break;
}
}
}
}
Some things to try :
[ulist]make sure you have external power to your FEZ board. It’s really mandatory with external USB devices.
if you put a Debug.Print (“Event fired”); as the first line of the DeviceConnectedEvent() method, does it print ?
also make sure the PRODUCT_ID of your board is 0x0031. If the event is fired, you can check this by putting a Debug.Print("ProdutID = "+device.PRODUCT_ID.ToString()); statement as the first line of the event handler to see it.
[/ulist]
Hi,
I’m not sure if I should post this on a new thread or not, but since I’m too having some problems with the Phidgets drivers, I guess that it won’t hurt too much to extend this thread just a bit
I’m using the driver with a Cobra board and a Phidgets RFID Reader (P/N 1023) and everything seems to be working OK, as tags are indeed being recognized. What is rather annoying though is that quite a few “first time exceptions” are being thrown - apparently from inside the _RFID_Thread thread running the RFIDThread() method. Generally these exceptions do not halt the application execution, but sometimes they do. These errors look like this:
#### Exception System.Exception - 0xffffffff (4) ####
#### Message:
#### GHIElectronics.NETMF.USBHost.USBH_RawDevice+Pipe::TransferPipe_Helper [IP: 0000] ####
#### GHIElectronics.NETMF.USBHost.USBH_RawDevice+Pipe::TransferData [IP: 001c] ####
#### PhidgetsRFIDReader.PhidgetRFID::RFIDThread [IP: 005d] ####
A first chance exception of type ‘System.Exception’ occurred in GHIElectronics.NETMF.USBHost.dll
Any idea what could be causing this?
Device is different type maybe that what was used before. I do not know a lot about phidgets. Maybe other members know.
Welcome to the community.
Thank you for your feedback, Gus, but I believe it must be something else, since I’m using the exact same RFID reader that the driver was designed for: Phidgets 1023.
I have placed some try/catch blocks around some critical areas, but it didn’t solve the problem. Could it be something inside the GHIElectronics.NETMF.USBHost.dll is breaking? According to the exception message, that is where it is being raised:
“A first chance exception of type ‘System.Exception’ occurred in GHIElectronics.NETMF.USBHost.dll”
Nothing was changed on the USB drivers.
What makes it even harder to debug is that it’s apparently non-deterministic in nature: there’s no fixed way to force the exception - apparently it occurs on and by its own
I’m also having many issues with USBHost_RawDevice. I’m connecting a Dataq DI-149 data aquisition module to the host port on a spider. My biggest problem is the black-box nature of the USBHost dll. The documentation is less than helpfull, as it only parrots the names of each parameter of its methods, giving no explanation as to what the parameter is for. The same goes for all function return values.
int count = pipeOUT.TransferData(info, 0, info.Length);
What in the world does count return? What would zero indicate? a failure? What would an actual failure of this method produce ( -1 … throw an exception)?
I have a valued customer asking me to port an existing WinCE application with far reaching commercial value. Unfortunately, I don’t see this technology as mature enough to take the risk. I know that this is ‘open-source’; but, is anyone working on correcting this lack of documentation?
Hello,
in my code for handling Phidget boards, there’s a loop that deals with “Toggle errors”. These errors does indeed thrown many exceptions for a varying amount of time.
After some time, the device is ready to be used and does not throw toggle errors, hence exiting the loop and becoming available for use.
But this does not prevent other toggle errors while in regular working mode. Maybe you’re seeing such errors ?
They aren’t blocking, neither do they make the device unresponsive, but they may slow down the data transfer if you transfer big amount of data.
Toggle errors are very hard to debug and almost always need an hardware protocol analyzer, though. But even if you find where the error is, you may not be able to correct it (if it’s in the firmware, for example).
Also, exception handling while debugging may look like it’s slowing down everything, but remember that when your FEZ board is running as standalone, it would be much faster than with debugger attached !
Not quite a definitive answer, I admit, but it may help you understand some things ?
Bec a Fuel;
Thanks for your help.
I have your Try/Catch blocks implemented, but theyve never caught any errors?
My device is communicating, but the latency is very unpredictable, even at very low scan rates.
The Dataq device can be set to send unsolicited data (a 16-byte array with leading sync-bit), at a user defined frequency between 11.44hz to several-khz. My requirement is a stable (predictable) 100hz.
I’ve communicated with these Dataq USB-DAQ devices very successfully from both Windows-Mobile (5 and 6), and with Windows7 (.net 4.0, 32-bit and 64-bit) as the USB-host. The device is FTDI-based but presents only a CDC interface.
The problems Im experiencing with the Spider-Host, is unpredictable latency drift (other than GC), and occasional dropped bytes (approximately 1 in 1024 and very erratic in nature).
I can plug this same device directly into my PC and stream bytes at a maximum rate for days at a time, with no errors or dropped bytes. I can use my own custom managed library, or ‘RealTerm terminal software and get the same results.
The GHI-provided CDC driver works very reliably, but unfortunately, its built-in latency is a bit too long for my application. I can only assume that GHI has incorporated a large latency in the CDC driver to cover or smooth-over the issues I’m dealing with in the raw device.
Is there a better hardware solution to handle a USB device like this other than the Spider-USBHost?
Nick
Followup to all;
I’ve switched back to using USBH_SerialUSB for my CDC device, and much more agressing error trapping.
This helped me trap random USB errors related to power. (DataToggle, DataUnderRun)
I was then able to clear up all of my latency and dropped bytes issues by using a stronger external power supply for the Spider.
I had a 9v 500 ma external supply that I guess was just not strong enough for the; Spider, T35, Bluetooth, Compass, USBhost, and Dataq DI149.
A stronger power supply has my application spinning just fine now.
This is very curious, as I was never able to trap any of these errors using the RawUsb driver.
Watch that power,
Nick
Thanks for updating us.