serial communication shows huge batch istead of steady small bursts

Hello i am sending threw my microcontroller to MATALB 4 uint8_t variables

0x2F,0x06,0x8F,0x3F and for signalling the end of the stream LF '\n' which Matlab sees it as 0A for some reason

I connect to matlab with the code shown bellow:

sObject=serial('COM4','BaudRate',115200,'TimeOut',10,'Terminator','LF')
sObject.BytesAvailableFcn={@callbackSerial};
fopen(sObject)

I use a callback function as shown bellow,instead of giving me small peaces of 2F 06 8F 3F ,i wait a lot of time and get a huge burst of data which consists of these elements.

How to make matlab to stop storing a lot of data not showing NONE and then ofter a while to show a huge burst of the waited data?

Thanks.

function callbackSerial(ser,~)
global time;
val=fread(ser);

val(1,1);
dec2hex(uint8(val))



%time(16)=pnumval;
%time(1)=[];
%disp(time);
%figure(1),plot(time);
end

[Rik]

You should have posted this as a comment to your previous question, instead of posting it as a new question.

[Walter Roberson]

for signalling the end of the stream LF '\n' which Matlab sees it as 0A for some reason

https://en.wikipedia.org/wiki/Newline#Representation

You will see in the representation table that \n has been encoded as 0x0A for for 60-ish years.

Remember that the escape characters such as \n in format strings are not sent literally, as their role in format strings is to signal that what follows is an extended character sequence standing in for something else. For example \t for tab, \g for bell.

Answer 1

[Walter Roberson]

I predict that COM4 is not a true RS232 or RS422 port, and is instead a USB port with Serial over USB.

Serial over USB is defined by the USB standards that the driver must buffer characters until one of the following occurs:

• the buffer fills up, in which case the buffer is released to be schedule for transmission the next time that the USB Master polls the device for work (and the sending device does not have anything higher priority to send)
• a certain amount of time has elapsed since the last request to send a character was made, in which case the buffer is released to be schedule for transmission the next time that the USB Master polls the device for work (and the sending device does not have anything higher priority to send)
• the transmitting software sends a USB "Push" request to the device driver, in which case the buffer is released to be schedule for transmission the next time that the USB Master polls the device for work (and the sending device does not have anything higher priority to send)

USB is not RS232 or RS422 protocol. USB always tranmits in "packets" that have type and sizing and identifier information and optionally some data as well. USB never never just transmits the bytes like RS232 does: they are always wrapped in a packet. And the packet is not eligible to be sent until the USB controller specifically asks that particular device whether the device has anything it wants to send. And, as I discussed above, the packet would not even be queued to send until one of those three conditions -- buffer full, timeout, or Push request.

With your moderately high baud rate, and your continuous stream of data, timeouts are unlikely, so if the microprocessor software is not making Push requests to its USB hardware, then the data is probably not going to be transmitted until the buffer fills up.

This is not something that MATLAB can possibly configure: it has to be the sending software on the microprocessor that requests the Push.

Also, for USB 1 and USB 2, the polling rate at which the USB Master asks devices to work, is 1000 Hz. If you were to arrange for the microprocessor to issue Push requests after every 5 bytes, then you would be able to transmit a maximum of 1000*5 = 5000 bytes per second (about 50000 "baud" in traditional terms). This is a primary reason why the rule is that devices must buffer data unless they are specifically asked to release it: high per-packet overhead, somewhat low rate of polling for available data.

[fima v]

Hello Walter I am using FTDI cable which is intended for uart usb communication

the data sheet shown bellow,I have connected the controller with TXD TXD and GND as shown in the photo bellow.

on the other side of the cable (the pc usb connection) i have COM4 wich is defined as shown bellow.

i have written software before which reacted to \n and send me small burst of data cutting at \n that what LF is for ,to stop at \n character.

firther more i have a stream from PCOMM software which shows me a stream of packets of 4 parts each.

So given the follwoing data you still say i have the wrong cable connection?

Thanks.

https://www.mouser.co.il/datasheet/2/163/DS_C232HD_UART_CABLE-4313.pdf

[fima v]

Why MATLAB is not reacting to \n at all I dont get live stream of small bits. Instead i get a large delay and a huge block of data on the terminal as shown bellow. Where did i go wrong? Thanks.

[Walter Roberson]

I do not know. I am busy studying the USB specifications to see if I have missed anything in my previous readings, to see if the various reference works I have read in the past were incorrect and that perhaps there really is a way that have been previously told did not exist that would permit characters to be transmitted immediately instead of (as I have read in multiple sources) requiring that characters be buffered. I expect it will take rather some time. Check back with me in about two years.

[fima v]

Hello Walter , i appricieate your effort i gave you all the data.

I would give more data if you need,to help you figure out why matlab callback doesnt react to \n

[fima v]

Walter the callback worked before when i send a single commands it recived them fine.

the problem starts when i send all the time its stops reacting to \n

[fima v]

I'm pretty much just guessing at this point but if we rule out a buffer delaying the data then another possibility could be that Matlab doesn't actually react to \n at all but instead is waiting to see an EOF (End Of File)

how can i switch it back so if a send it a stream of bytes separated by \n byte then it will not store all of them? But will send threw when reaches \n