Why xPC RS232 FIFO read block produce such big delay? or the delay is due to file write?

Hi,

After long time of signal tracing, I measured that the receving side of the xPC application produces long time delay (5~15ms for different char), while on the sending side, the time delay is small and can be ignored.

I did 2 experiments, both at sampling rate 10K Hz, and FIFO block at sampling rate 1K Hz.

1. I looped the serial cable back from COM1 to COM2. and let COM1 send a char to COM2. I'm using analog data logger monitering the RS232 signal on the cable. I measured the time from a char being sent out to that RS232 signal actually appear on the wire. It's like immediate which doesn't take visible time.

However, I received the char with COM2 about 5ms later. All the time are from xPC timeLog, so should be synchronized. Hence, I infer that the delay is produced on the receving side. I guess it due to the FIFO buffer or software?

2. I connected my target PC to my lab equipment, and let COM1 port send commands to the equipment while monitoring the RS232 signal in the mid-way.

Again, the RS232 signal shows up on the wire at the same time when my target PC sends the command out.

Then the replied signal shows up on the wire after 1 or 2 ms. however, when I looked at the logged data on my target PC, the time stamps of the replies are about 15 ms later on average.

Since it doesn't take long for my lab equipment to reply, it seems that the receiving side of the target PC produces significant and undesirable time delay.

Could anyone explain this? is this normal?

Can this be reduced by parameter setting?

Or this is inevitable?

Thanks

[Yash]

yes it can be,but i dont have that kind of a delay you are examining

[Zhuo Li]

Hi yash,

Thanks for the comments. I asked Matlab tech support. They suggested to try to settle the "hardware FIFO receive trigger level" to 1 to reduce the amount of time delay.

I think this makes good sense and I did further tests. I tried to set the interrupt trigger level to "1", but there is no statistic difference between either trigger level "1" or "half full". So, it seems the interrupt trigger level doesn't affect that much.

Moreover, I used the Speedgoat performance real-time target machine with I/O-504 (dedicated serial broad) to perform the test, there is no statistic difference, either.

Let me state the problem again. I'm sending commands to my lab device. By monitoring the signals on the serial cable with an analog data logger, I can see that my lab device returns a reply within about 5~7[ms] on average. However, the target PC record the data with a time stamp about 15[ms] later than the signal shows up on the wire.

By doing varied experiment, this time lag may vary with the length of the reply, and may take up to 100 [ms] if I keep sending and receiving at a high speed. If I set the FIFO software size small, the FIFO will overflow. If I set it large, it can cache all the data, but the data are logged with a long time delay as stated above.

Hence, to my understanding, this time delay seems to accumulate as the communication goes on, which is like a queue. To verify this, I tried to send the second command later enough after the first one, then, the time delay drop back a little.

Our application has high requirement on timing, that's why I put so much concern on this issue,

[Zhuo Li]

I just think up one thing.

The time at which I see the reply signals appear on the serial cable is the starting time of the ASCII transmission. So for a string of length 24 Bytes (24*8=192 bit), the transmission takes about 10 [ms] at baud rate 19200 [bps]. If including stop bit, it may be a little longer. I think the time stamp of the logged data is the end time of the transmisson.

Thus, it matches the result and explain the phenomenon.

So, the problem left now is just to verify whether the delay accumulates due to the FIFO sampling rate changes.