Re: xPC Serial Communication Problems

Walter,

I'll ask a few questions about your system before making a guess
about what's going on here.

Is the receiving machine executing at the 'same' 50 ms rate?
I quote the word 'same' since any such attempt will always result
in drift between the two machines unless something forces them
to stay synchronized.

Is the receiving machine using a read call to its system that can
return exactly 15, or merely up to 15 characters at a time? That is,
does it wait until there are at least 15 characters in the receive
buffer, then return exactly the first 15, or does it return whatever
is in it's buffer, up to 15 characters?

Does the receiver throw away characters until it sees the sync characters,
then read the fixed message length? This will force synchronization,
even when the reader executes when a partial message has been received.
A partial message could be in the receive buffer if the two machines
execute with the right phase shift (receiver looks at the buffer when
a message is partially done).

I suspect you're seeing a timing drift problem, but I can't be sure.

If you connect an oscilloscope to the transmit data wire and measure
the data burst, is it 15 characters long at 115200 baud? With 8 data
bits, plus start and stop, there are 10 bits per character so this
data rate is 15*10/115200 = 1.302 ms. Is it always this length with the
beginning always looking the same? If so, then you're seeing a receive
synchronization problem.

Gordon Weast
xPC Target Development
The Mathworks

Walter Collins wrote:

I'm using RTW with the xPC target to send data from the target
computer to a control console. The data is 15 bytes long and gets
sent every 50 ms (20Hz). The model on the target computer currently
consists of 5 constant source blocks (split off into 15 lines) going
into a pack block that's expecting 15 uint8's and this is fed into a
binary serial send block. The serial send block's message width is 15
with a sample time of 0.05. The rs232 set-up block sets the port up
to be 115.2 kbps with Tx and Rx buffer sizes of 1024, no parity, 8
data, 1 stop, no protocol.

With that out of the way, the problem is this. The code works just
fine for a while. The packet has 6 "synch" bytes at the beginning,
followed by a combination of 0, 255 and 7. Monitoring the serial
stream coming from the target computer, we can clearly see each of
these where we expect them. After some random amount of time,
however, the serial stream changes. The bytes seem to be the right
bytes, but now they're out of order. It's as if we lost some bytes or
added some at some point. Now we'll have some of the data bytes (the
0, 255, 7) at the beginning of the 15 byte packets, followed by the
sync bytes, follewed by the rest of the data. This is causing havoc
on the receiving end, which relies on there being a bit of breathing
room at the end of a packet. Since the packets are now split between
packet trasmissions, we don't have that breathing room.

Has anyone else seen this or have any recommendations on how to fix
it? I've tried looking through the Simulink code for the serial
blocks, but they just refer to "functions imported from the kernel"
so I can't see how they're actually handling the serial communication
on a low level.

Thanks in advance for any help,
Walter
.

Relevant Pages

  • Re: xPC Serial Communication Problems
    ... Everything about the packet looks just fine, ... reasonable facsimile) so the hardware buffer should be 16 bytes. ... Is the receiving machine executing at the 'same' 50 ms rate? ... does it wait until there are at least 15 characters in the receive ...
    (comp.soft-sys.matlab)
  • Re: Serial COM port communication problems
    ... actual number of characters retured by WaitCommEvent. ... signal to know how many subpackages arrived. ... receiving queue, the OVL ... Then parse the returned buffer to find the CR characters yourself. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Serial COM port communication problems
    ... actual number of characters retured by WaitCommEvent. ... actual subpackage, including the CR. ... receiving queue, the OVL ... Then parse the returned buffer to find the CR characters yourself. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: pushing the envelope with sockets
    ... receiving on the socket they are received (upto the buffer size), you can even change what happens if the buffer runs full. ... int read = S.EndReceive; ... class AsyncReader: Reader ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Fundamentals question, is this how it works?
    ... Note the packet may be partially received when you get ... That is what i thought i was saying that it receives it all in a stream ... receving the buffer size each time. ... receiving that many bytes i then break and wait for the next set of data ...
    (microsoft.public.win32.programmer.networks)
Loading