We have a Matlab script that uses a Cedrus Response Pad for user input. The script works fine with an RB-530, but hangs with an RB-540. We’ve tried two different RB-540’s so it doesn’t appear to be a broken hardware issue.
Further info:
The dip switches are all down on all RB devices (XID protocol).
On the RB-530, the LED on the back is lit, but on the RB-540 it flashes twice when plugged in, but otherwise remains off.
Pressing any key on the response pad during the hang results in this error: ‘Roundtrip test did not receive “X” char as expected’, so clearly the code is executing, but not receiving the character that was sent.
Questions:
I can’t find any documentation specific to the RB-540. Does that exist?
Is there any documentation of any protocol differences between the RB-530 and RB-540?
Under Windows Vista and 7, the USB driver should be automatically recognized, but that’s not always the case, unfortunately.
You can download the USB driver from http://www.ftdichip.com/Drivers/VCP.htm. Select the link that says “setup executable” in the Comments column; it’s the easiest way.
Regarding the DIP switch settings, they are different. The RB-540 has a brand new feature that allows it to work in keyboard mode. DIP switch 1 sets keyboard mode when it’s up. DIP switches 2 to 4 on the RB-540 are the same as DIP switches 1 to 3 on the RB-530.
Thanks for the response. We are using Windows XP and the driver seems to be fine since (a) it works with the RB-530 and (b) we also have a StimTracker on the system which is working correctly.
With respect to the DIP switches, for the RB-530, switches 1&2 down = XID and switch 3 down = 115Kbaud.
From your description of the DIP switches for the RB-540, all switches down would be the same configuration (XID, 115Kbaud), correct?
If so, I still don’t see why there is any difference in operation between the RB-530 and RB-540 on the same computer with the same driver yet the RB-540 doesn’t behave the same.
The answer on RB-530 vs. RB-540 drivers is “it depends”. If your RB-530 was purchased after June 2011, then yes, the USB drivers should be the same. But if it was purchased before that date, then the drivers are different. You can make them use the same USB drivers by following the steps on this page, “Reconfiguring RB Series Response Pads”
The RB-530 was purchased well after June 2011, and it is the device that works perfectly, so I don’t see how this is a driver problem.
The RB-540 doesn’t appear to work correctly for the RoundTripTest (e4) command.
Here is the relevant code that is trying to exercise the RoundTripTest function:
function roundtrip = RoundTripTestDev(handle)
global ptb_cedrus_devices;
% Flush the queue:
FlushEvents(handle);
% Perform 100 measurement trials:
roundtrip = zeros(1,100);
for i=0:100
% Wait a bit between each trial:
WaitSecs(0.100);
% Send 'e4' code to initiate procedure:
WriteDev(handle, 'e4');
% Wait for receive completion:
while BytesAvailable(handle) < 1
end;
% Send echo, optimistically assuming we received a 'X':
WriteDev(handle, 'X');
% Get the really received byte and check:
if char(ReadDev(handle, 1))~='X'
error('Roundtrip test did not receive "X" char as expected!');
end
% Wait for receipt of timestamp:
while BytesAvailable(handle) < 4
end;
response = ReadDev(handle, 4);
if response(1)~='P' || response(2)~='T'
error('Roundtrip test did not receive "PT" marker as expected!');
end
response = double(response);
% We throw away the first trial:
if i > 0
roundtrip(i) = 0.001 * (response(3) + 256 * response(4));
end
end
% Store median and stddev of roundtrip time in device struct:
ptb_cedrus_devices{handle}.roundtriptime = median(roundtrip);
ptb_cedrus_devices{handle}.roundtripstddev = std(roundtrip);
return;
That code appears to hang waiting for a response from the RB-540 after sending the ‘e4’. If I press any button at that point (during the hang) I get the following error message:
Roundtrip test did not receive “X” char as expected!
This says to me that (a) the driver is working, and (b) the RB-540 is sending a character when a key is pressed, but NOT sending the ‘X’ character that should be sent after receiving the ‘e4’.
Alas, you are correct that the ‘e4’ command is no longer supported in XID 2.0 or later. This would apply to the RB-x40 response pads and Lumina 3G controller.
One command has been implemented but not yet publicly released. It works differently. There will be more information about it when a firmware update is released, but I don’t know yet when that will be.