serial communication with device

Hello. I have an instrument (konika chromameter CS100A) which is designed to communicate with a computer through the serial port. I bought a serial-to-usb converter to connect it to my macbookpro. The manual of the chromameter says to use a baud rate of 4800, even parity, 7 bits data length, 2 stop bits and a CR+LF terminator. To request a measurement I should send "MES", then read what is sent. I tried to do so with the following code:

 CS100 = serial('/dev/tty.usbserial', 'BaudRate',4800, 'Parity','even',...
    'DataBits',7, 'StopBits',2, 'Terminator','CR/LF');

 fopen(CS100);

 fprintf(CS100,'MES');

 pause(5);

 received = fgets(CS100);

However matlab returns:"Warning: Unexpected Warning: A timeout occurred before the Terminator was reached. "

And I receive: 'ÅÒ00'

Which in decimal is: [197,210,48,48,141,10]

So I have been puzzled by this for different reasons. Because I specified a data format of 7 bits, I shouldn't receive a character higher than 128, no? Also, the manual of the meter says that if a terminator is not sent 5 seconds after a command, or if the command is undefined, the meter will return "ER00". The terminator should be automatically sent by matlab, shouldn't it? I tried to add it after the command ('MES\r\n') but that made no difference. Matlab receives 6 bytes, which seems consistent with receiving ER00 + 2 terminators. The last character is 10, correctly corresponding to LF. And there is a difference of 13 between the characters 1 and 2, as between E and R, which made me suspect that the string should be "ER00". But then, why are characters 3 and 4 "0", as expected?

Does anyone have an idea on how to send the command to the chromameter and read its answer? Thank you very much.

Baptiste

Answer 1

[Walter Roberson]

It appears that the parity bit is not being stripped off.

I cannot promise that the serial interface is correctly generating the parity bits for outgoing data, and I cannot promise that MATLAB is recognizing the 141 as being CR for line termination purposes.

If you subtract 128 from all of the values greater than 128, you get ER00<CR><LF>

I do not know whose fault it is that the parity is not being properly removed, but you have to deal with the aftermath.

As a work-around:

Change the terminator to LF because LF happens to have even parity anyhow.

Take all of the input lines and pass them through a translation routine that removes the parity. This could be as simple as

rmparity = @(S) char(S - (S>128)*128);

Take the resulting string and process it as a string, such as with sscanf() or as required.

For output, do not output anything directly. Instead, format it in to a string, such as with sprintf(), and pass the resulting string through a routine that adds parity. You can fwrite() the result.

The routine to add parity could do an array lookup: have a table with 128 entries, entry #K giving the even-parity version of char(K-1) . For even parity, that table is

evenparity7 = char((0:127)+128*mod(sum(dec2bin(0:127,7)-'0',2),2).');
makevenparity = @(S) evenparity7(S+1);

[baptiste]

Beautiful. You are entirely right.

I send the command with:

fprintf(CS100,makevenparity(sprintf('MES\r\n')));

And read the data with:

response = rmparity(fgets(CS100));

And I now get: OK00 (+data), OK00 being the tag for normal operation.

Of course matlab still displays a warning as it thinks it didn't get the terminators. I changed the terminator to "LF" alone and remove "CR" afterward so that matlab stops transmission before the timeout period and it now works like a charm.

Thanks a lot.

Regards,

Baptiste

[Walter Roberson]

Good, it is nice to see this work out.

This difficulty is one of the problems that can be encountered when you use a USB<->Serial converter. USB is not a good technology to implement serial ports.