Main Site Documentation

UART transferring a few kB


#1

I just successfully transferred one byte from one Cobra to another.
Now I have a question. If I want to transfer data from few bytes to few kB is it safe to just read on receiver all bytes available or it would be better approach to transfer first integer, how many bytes will be send, and then read correct count of bytes.

I know that when using sockets, you never know how many bytes will you receive on DataAvailable (all or just part of them).
How is it when using UART protocol. If I send 10kB will I receive on SerialPort.BytesToRead 10kB or any delay is possible?

I hope someone will understand what I am trying to ask.


#2

XMODEM is simple to implement and gives some small resilience to errors. If you wanted to get fancy, you could implement XMODEM-CRC which is only a tiny bit more complex, and gives much better resilience to errors.


#3

Is it possible, that the data transferred over UART is not correct?


#4

Sometimes when speed is setup wrong you might get “garbage”.


#5

Yes, it is possible, though probably unlikely if you’re working with short distances. In a noisy environment, it might be more likely, but I wouldn’t sweat it TOO much.


#6

Is is possible, but highly unlikely if you have good cables. Noise is not your friend, but paranoia is.

You should always be prepared for something to go wrong. :smiley:


#7

That was quick. Almost like a chat. :slight_smile:

What is short distance? Where is the limit?

What can be wrong speed? What is recommended speed?

Is UTP bad cable?


#8

Centimeters are probably not a problem. Meters might be. It really depends on things like speed and environmental noise.


#9

By wrong speed I mean programmatic error when one end is set-up with one speed and the other end with different speed.


#10

Of course, the faster you go, the more likely the chance of error.
Generally, I go as slow as possible, depending upon the application requirements.

If you want to go a long distance, with a serial interface, then converting the TTL levels to RS-232 is recommended.
RS-232 I believe can go 50 feet. Been a while since I have actually done long RS232 cables.

With TTL 3.3V I would only go a few feet.


#11

Are you experiencing the issue or just educating yourself?


#12

Understand. Thank you. I just educating myself and thinking what can go wrong.


#13

I don’t need speed. Mostly the data length will be a few bytes. But from time to time a few kB.

My distance is approximately 2m (2 meters = 6.56167979 feet) maybe less.

The data transfer will be between Spider and Cerb40. I don’t like the idea of buying 2 RS232 module but if this is the only option to get safe…


#14

it’s not “the only way to get safe” but it’s a tried and proven method using commodity cables. TTL level signals will be affected by resistance and capacitance in the cables and RS232 removes a lot of that sensitivity


#15

Using the pure TTL signals without transceivers is (EMC based) only usable on board, and then still you have to follow the rules…
2 meters in a violent environment (50hz power is qualified as violent for this) is living on the edge :wink:

RS232 is good for “some” meters, RS485 is “great” for violent environment and longer distance, CAN is also “great”


#16

It is possible to implement a software solution.

To each message you need to add a checksum. The receiver can then recalculate the checksum and verify the integrity of the message.
If the message has been corrupted, then the receiver needs to send a message to the transmitter to re-transmit. If the message is OK,
the a message needs to be sent to the transmitter acknowledging the received message. The transmitter can then discard the message.

It is also possible to package the message in an error correcting protocol. Additional bits are added to the message that allow for the
detection and correction of errors. The more error correction bits, the more errors that can be corrected.

If 100% reliability is required, then software is necessary to insure accurate delivery of messages.


#17

I have seen this in different applications i have to support at the moment but if you need to have a reliable and economical solution i would suggest to adapt the industry standards and go with at least a RS232 solution and leave the verification to lower layers in the OSI model.


#18

@ David@ Emrol - " leave the verification to lower layers in the OSI model."

Yes. The ack/nak scheme I was suggesting is OSI level 2 (link).


#19

is layer 123 not always handled by the protocol?

I have some apps here where people implemented a CRC on a higher level (should check but think 5 or 6) and it’s a real pain…


#20

For a direct machine to machine connection, a link protocol (level 2) should suffice.