Real term baud rate should be captured/ read by MATLAB

I have interfaced Real term and MATLAB. Now I want to change baud rate of real term form its drop down menu and that baud rate should be captured or read by MATLAB. MATLAB communcation port should also operate on the baud rate that I have selected from realterm. Is this possible ?

[silvia cano]

how you make the connection between real term and matlab

Answer 1

[Walter Roberson]

If you mean that you are using activex or .NET facilities to control a Realterm process from within matlab, then I do not know if it is possible for matlab to be notified when the baud rate changes. Maybe? activex controls do sometimes allow callbacks, so I cannot rule it out at the moment even if I doubt that particular facility would have been developed.

If, however, what you mean is that you are using Realterm on a second host, and are connecting the second host to a matlab session through rs232 or serial over USB cable then:

• changing the serial port rate on a USB port does not change the transmission rate. USB operates at a fixed speed. The serial port setting is sometimes used to estimate the resource buffering priority, but the USB clock speed and packet size stays constant.
• for true rs232 or rs422 or rs485 or TTL, there is nothing in the protocol that communicates transmission speed. If the two sides do not agree on transmission speed, then the receiver experiences framing errors. With proper hardware access and the agreement of both sides, it is possible to have an auto negotiation protocol in which a receiver experiencing framing errors guesses that it needs to switch to the next speed in sequence until eventually it gets something that it can recognize. However, matlab has not had access to that hardware level since early in Windows XP days. I would not rule out the possibility that it could still be done by finding an appropriate driver or operating system call, but it would not be simple.

Speed negotiation is a lot easier if the protocol is to start at the lowest mutually supported rate, and then for the software to communicate a list of supported speeds, and then the remote host sends a software command requesting to switch rates.

[Walter Roberson]

https://realterm.sourceforge.io/#COM_Events

realterm does support some events over ActiveX. However notification of change of settings is not one of the events.

Answer 2

[Tayyaba Abro]

I have done this task

realterm = actxserver ('realterm.realtermintf')
realterm.port = '5'
realterm.portopen=1
s = serial('COM4', 'Baudrate', 57600)
fopen(s)
serial_baudrate = s.baudrate
data = ''  % initialize an empty character array
while (1) 
    new_data = fscanf(s) % read data from the serial port
    data = [data, new_data] % append the new data to the existing data
    realterm_baudrate = realterm.baud
    serial_baudrate = realterm_baudrate
end

[Walter Roberson]

However if it is possible for the user to change the baud rate in the realterm interface then the fscanf() on the matlab side would fail unless the matlab side noticed the rate change and adjusted the serial port speed before the next byte had been sent by the other side.

Note that serial() is now discouraged with serialport() recommended instead. But serialport() has less flexibility to change port characteristics so you might need to delete the serialport and create a new one to change the speed.

[Tayyaba Abro]

Yes Matlab side notified the rate change and have adjusted with the provided code.

[Walter Roberson]

realterm_baudrate = realterm.baud

That statement is inside your loop, and will only be evaluated after the

new_data = fscanf(s)

has finished. However, once the fscanf(s) has started the reading operation, the baud of serial COM4 is locked until the fscanf() call returns. fscanf() does not return until timeout or until it has detected a terminator, or possibly some kinds of error. But if the baud rate of the transmitting system changed, then the receiver will not be able to detect a terminator because the terminator (such as carriage return or linefeed) will be transmitted at a different rate than what is expected.

True RS232 or RS482 or RS485 or TTL serial ports are not adaptive to baud rate changes. To use one of those kinds of ports, the baud rate has to be configured in the hardware first, and then the hardware watches for line level changes on a time scale proportional to the configured baud rate. Once it has detected the level change that introduces a group of bits, it then reads the line level at regular intervals propotional to the configured speed. If there are two bits in a row that are the same value, then the signal does not change -- it holds steady and at the next time interval the hardware samples it again and notes the value. It is not the case that each bit is a separate pulse with different pulse shapes for 0 and 1 such that the bits could potentially be read out whenever they are received: instead, once the beginning of a sequence is detected, it is all about timing proportional to the configured speed.

When there is a mismatch between the configured speed of a sender and a receiver, then the receiver either does not recognize the signal for the start of a group (if the sender is faster than the receiver), or else the receiver will not recognize the signal for the end of a group (if the sender is slower than the receiver). The receiver might be able to detect that there has been a signal error when this happens, but the receiver cannot tell whether that is just due to noise on the line or if the sender is too fast or the sender is too slow. Nothing in the protocols conveys the current speed that might be detectable automatically the receiving hardware: the two ends have to have agreed on speed somehow -- except that there is potentially an "autobaud" protocol where the receiver detects errors and switches to the next speed until it finds a valid signal.

So if you change the rate on the realterm side, then the fscanf(s) might keep waiting until timeout (which requires try/catch to handle), or might maybe be able to detect that an error occured and return what it was able to receive up to that point.

So if you want the program to be able to detect speed changes made at the realterm side, then realterm would have to actively notify the program about the change, using a callback, and the callback would have to flush the serial port and reconfigure it for the new speed. But unfortunately change of speed is not one of the things that realterm is able to actively notify about.

Furthermore, even in the case where the fscanf() is able to return some data, and you ask realterm what the current speed is, your code is only recording the speed and is not reconfiguring the serial port to adjust to that new speed.

Most of this is irrelevant if it turns out that the connection is Serial Over USB instead of being true RS232 or RS482 or RS485 or TTL. USB only changes its transmission rate according to whether it detected that the device is USB1, USB2, USB3.1, or USB3.2 . There is a specific part of the USB cycle where the USB controller sends out a, "Are there any new devices?" query at the slowest possible speed (USB1 rates), and the new device responds at the slowest speed "I'm here, and I can support USB 3.1 rates", and the controller responds, "That's cool. We'll talk at USB 2 rates", and after that each time the controller wants to talk to that device it will use a signal waveform at the rate that was negotiated for that device. There is no baud rate for USB. The only thing that configuring 9600 or whatever does for USB is hint to the ends about what kind of buffering might be needed.