The PhidgetRFID C API has a function CPhidgetRFID_set_OnOutputChange_Handler which I guess sets a callback handler to be called after a CPhidgetRFID_setOutputState has actually brought the output pin up or down.There is a CPhidgetRFID_setAntennaOn, which does not have a matching callback, and calling CPhidgetRFID_getAntennaOn immediately shows me CPhidgetRFID_setAntennaOn returns before the antenna is actually turned on (or off). What is the expected way of handling this? Busy loop until CPhidgetRFID_getAntennaOn returns expected value, sleep for a given amount of time (if this - how long?), something else, or am I misunderstanding something here?

And while we're at it: I have a read-only 1023_1. Is there some way to programatically know that calling CPhidgetRFID_write makes no sense for this device?

After changing the antenna state, you can poll CPhidgetRFID_getAntennaOn until it reflects the new state - this function is reflecting data as returned from the device itself. Latency should be ~50ms or less.

The write functions will return EPHIDGET_UNSUPPORTED on 1023 - you just need to check your return codes.

Patrick wrote:After changing the antenna state, you can poll CPhidgetRFID_getAntennaOn until it reflects the new state - this function is reflecting data as returned from the device itself. Latency should be ~50ms or less.

OK, so a relativly short-lived busy loop it is (could sleep 10ms between tries, to be nice to the system..)

But I want to know it without risking writing anything on systems that DO support writing. After your reply, my first thought was to pass NULL as tagString. To be absolutely sure, I checked the source, and it seems this will fail for all devices. I can fool the system by passing an invalid protocol (like, -1 or similiar). Read-only will return EPHIDGET_UNSUPPORTED, Read-Write will return EPHIDGET_INVALIDARG. Does this sound good to you? (I'm making a generic system, and don't want a Write-button for devices that are Read-only)