Matlab Serial Errors with Psychtoolbox using RS232 device and fast screen updates

(Previously posted on Mathworks/Matlab answers: Serial Reading Continuous Data in Matlab - Inconsistent Responses 6/10/2005, http://au.mathworks.com/matlabcentral/newsreader/view_thread/342780#939295 )

Apologies for the length of the question, but best to start at the beginning...

BACKGROUND

I have set up a user-reaction response system for psychology students based on what is known as a KSS response scale. The script is written in Matlab and uses the Psychtoolbox functions to control the display, and a response box, a USB-connected RS232 device, that continually transmits characters designed around an Arduino device.

This system consists of a response box which consists of two buttons and continually transmits a character. If no button is pressed, a '32' char is transmitted, if button one is pressed it transmits a '33' char, and if button two is pressed it transmits a '34' char. This unit transmits characters at approximately 1800 chars per second (or 0.000625 secs between characters). This device is connected to the PC via a USB-RS232 adapter.

The script starts by asks few questions of the users who responds by a scale 1-9 on the keyboard, then the reaction test starts. The reaction test is basically a stopwatch which displays a blank screen for a few seconds, then the stopwatch appears that counts upward. The script check the incoming characters from the response box (COM port) for a 'key press' and the stopwatch will stop when the first one is seen. The time for the stopwatch display is obtained by the Psychtoolbox 'GetSecs' command. When a timeout time is reached, the stopwatch will stop and pause, sound a beep error, then reset for the next trial. After a total test time has elapsed, the system stops and saves the data to file. The typical total test time is 10 minutes.

I have setup two versions of the script:

• one that polls the serial port during the reaction tests (DIRECTREAD),
• one that uses the Matlab recommended continuous serial read (BUFFERREAD).

CURRENT TEST METHOD

As the participant reaction time can be variable, I have rigged-up a 'robot' participant that looks that the screen and when the stopwatch numbers appear (or hit a certain number) it triggers the response box to transmit the keypress character - this is by displaying a circle on the screen and sensed by an LDR sensor.

Hence the current round-trip sequence is:

1. Response Box - Transmit '32' character
2. PC - Display BLANK for 2-10 sec (random selection)
3. Sensor - no trigger
4. PC - Display stopwatch value (from GetSecs)
5. PC - When 200msec is reached, display circle under sensor, SKIP to 7.
6. REPEAT to 4.
7. Sensor - detect circle and trigger to Response Box
8. Response Box - Transmit '33' character
9. PC - Senses the '33' character and STOPS counting
10. PC - save data
11. REPEAT until time is up.

THE ISSUE

With the DIRECTREAD version, the time between the display of the circle and the STOP of the PC is fairly consistent. => Generally between 9 and 17 msec. Each update of the stopwatch on the screen is done by Psychtoolbox Screen('FLIP') command, this can take up to 15ms.

With the BUFFER_READ version, the time between the display of the circle and the STOP of is INCONSISTENT. You can have tests that record a 15 to 35msec difference, but to others can be 90 to 120msec out! As the BytesAvailableFcnCount size used is 32, it could be an additional 16msec before the buffer is full and ready to read by the READ function as BUFFER_READ only deals with complete buffers of integral size BytesAvailableFcnCount. However, this does not explain why the numbers can occasionally be so high!

Could it be another process in the PC is preventing the serial callback from executing when it is triggered and hence data could be lost? (TBC)

If the serial callback-generated interrupt is missed, is it re-queued or is it ignored?

Can this serial callback be safely executed as fast as possible (by say reducing the BytesAvailableFcnCount value to say 32) and reliably not miss any data? i.e. for a character speed of 1800cps, the time between each callback executing could be as fast as ~16msec.

(BTW I have been experiencing some random 'crash' issues with Matlab and the Psychtoolbox in the DIRECTREAD version, which is why I moved temporarily to the BUFFER_READ version. But it could be that the BUFFER_READ version is losing data! I have not been successful in isolating these 'crash' issues - looking like due to Psychtoolbox on certain machines).

Serial Port Open:

     %Open Port
      if strcmp(Selection, 'OPEN') %Open Port
        if isempty(objPSTPort)
           Clear_PSTPort_Serial(COMPort); 
        end

        objPSTPort=serial(COMport);
        objPSTPort.BaudRate=19200;
        objPSTPort.Terminator=' ';
        objPSTPort.ByteOrder='bigEndian';
        objPSTPort.InputBufferSize=2^18; %262144
        objPSTPort.BytesAvailableFcnMode='byte';
        objPSTPort.BytesAvailableFcnCount=readbuffersize; %512; 2^10 = 1024 -> 0.5s data
        objPSTPort.UserData.newData=[];
        objPSTPort.UserData.isNew=0;
        objPSTPort.UserData.keydetected=0;

        %open serial port (if not open)
        arg1='a';
        if strcmp(objPSTPort.Status,'closed'), 
            fopen(objPSTPort);
        else
            disp('port is open')
        end
        %Can only assign BytesAvailableFcn AFTER fopen
        objPSTPort.BytesAvailableFcn={@getNewData,arg1};
        Endtime = GetSecs-StartTime;
        %return values
        retValue1 = 0;
        retValue2 = [ 0 ];
        retRoutineTimeTaken=Endtime;
    end

Direct Read Code:

if strcmp(Selection, 'DIRECTREAD')
    bytecount = 0;
    dummy = [ 0 ];
    if objPSTPort.BytesAvailable
        [ dummy, count ] = fread(objPSTPort, objPSTPort.BytesAvailable, 'char');
        bytecount = bytecount + count;
    end
    for (iCount = 1:bytecount)
        if ( (dummy(iCount)) == 33 || (dummy(iCount) == 34) )
            break;
        end
    end
    %translate 32, 33, 34 char to [1 0] or [0 1] or [0 0]
    CharsToReturn = [];
    if dummy(iCount) == 33
        CharsToReturn = [ 1 0 ];
    elseif dummy(iCount) == 34
        CharsToReturn = [ 0 1 ];
    else
        CharsToReturn = [ 0 0 ];
    end
    Endtime = GetSecs-StartTime;
    %return values
    retValue1 = [ bytecount ];
    retValue2 = [ CharsToReturn ];
    retRoutineTimeTaken=Endtime;
end

Buffer Read Code:

if strcmp(Selection, 'BUFFERREAD') 
%Read buffer saved by callback fcnGetNewData
    retValue1 = 0;
    newData=0;
    if objPSTPort.UserData.isNew==1
        newData=objPSTPort.UserData.newData';
        %clear newdata flag
        objPSTPort.UserData.isNew=0;
    end
    values=objPSTPort.ValuesReceived;
    Endtime = GetSecs-StartTime;
    %return values
    retValue1 = objPSTPort.BytesAvailable;
    retValue2 = newData;
    retRoutineTimeTaken=Endtime;
end

The callback used is:

%getNewData, the serial Callback (i.e. BytesAvailableFcn)
function getNewData(objPSTPort,event,arg1)
global readbuffersize
 [Dnew, Dcount, Dmsg]=fread(objPSTPort, readbuffersize, 'char'); %%1024 array? fscanf
if objPSTPort.UserData.isNew==0
    %copy Dnew to UserData.newData (i.e. start newData)
    objPSTPort.UserData.newData=Dnew; %copy data first
    objPSTPort.UserData.isNew=1; %set data new flag
else
    %append Dnew to UserData.newData
    objPSTPort.UserData.newData=[objPSTPort.UserData.newData Dnew];
end
return

[David Barker]

ADDITIONAL 11/4

With the BUFFERREAD version, as the getNewData callback can effectively be executed in its entirety at any time, it is possible that (and I have seen it) that the callback getNewData can trigger in the MIDDLE of the BUFFERREAD after the data is read, and before the isNew flag has been cleared.

This is the sequence of: BUFFERREAD reads current data, the callback appends the data to current data, the BUFFERREAD then sets isNew=0, the next execution of the callback will clear the current data (including the appended data) and start with a blank array! Yes looks like data can be lost this way!

I have trialed a few control flags to prevent the callback from clearing the data, but holding up the callback in any way loses even more data!

MORE INFORMATION 12/4

Via other enquiries, I have determined that for the continuous mode, if you wish to save all the incoming characters which may span multiple BytesAvailableFcnCount in size, you cannot use the continuous stream callback method as there is no guarantee that you will receive ALL the data when using a USB-connected RS232 device. (i.e. Other processes can interrupt each callback whereby data can be missed.) RS232 when emulated on USB does not behave the same as true RS232 and is at the mercy of the supplied USB driver. A dedicated RS232 hardware card can likely get around this, but makes system a little less portable.

However, when polling in the continuous mode, you CAN receive all the data, but you need to ensure that the serial.InputBufferSize is large enough to hold enough data if there is any code-based delays between each port read.