Hi,
what is an acceptable error rate between 2 RS 232 devices running at
9600 baud, at distance less than 2 meters ( about 6 american feet) using only 3 wires.Or, is it guarantied that for such short distances a speed like that is going to deliver the data to the other end.
TB
: what is an acceptable error rate between 2 RS 232 devices running at : 9600 baud, at distance less than 2 meters ( about 6 american feet) using : only 3 wires.
: Or, is it guarantied that for such short distances a speed like that is : going to deliver the data to the other end.
with modern rs232 hardware etc I'd say you'd have a very very very low error rate - infinitessimal. BUT.....
If it is really important, then checksum your data and have some retransmission method, or run IP over the link with slip or ppp and use TCP for your connection
Jim
That depends on the protocol in use. Some protocols can tolerate high error rates, and some can't tolerate any.
Under benign electrical conditions, I would expect error rates very, very close to zero (certainly a BER of less than 1 in
1e9). I've run ports continuously in a setup similar to what you describe for months with zero errors.
--
Grant Edwards grante Yow! It's a lot of fun
at being alive... I wonder if
visi.com my bed is made?!?
In a lab environment, that means :
-no common mode voltage/splikes
-no rf interference (mobile phone, bluetooth, WLAN off)
-shielded metal cases
I'd expect no errors, say < 1 : 1e9
In order to make an RS232 EMC compatible, the print needs 1nF caps to earth for each pin on both ends. A shileded cable is recommended.
In a practical application you should check whether the data is correct or not.
Rene
-- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Electrically very low if there are no noise or interference sources, and you do not have a ground loop between the units.
Logically, asynchronous transfer (commonly misnamed RS-232) consists of just abandoning the bytes onto the wire and trusting that the peer is fast enough to catch them. So, you may lose or garble data if the receiving end is not ready to grab a byte when it comes in.
-- Tauno Voipio tauno voipio (at) iki fi
assuming the 2 machines communicating over the described link have a stable locked clock and assumed 'sterile' env (no external source of energy) - then u should experience no errors even at much higher rates.
in case yr env is noisy - u should use a covered twisted 3 lines (RX, TX, GND)
it is assumed that the RS-232 ports are served by ISRs rather than by polling sw
there is another mean u may consider if yr HW supports and u can configure the low level driver to use - buffered ports. thus, if the processor doesn't have the opportunity to respond on time (if interrupt fashion served - there may be higher priority interrupts that will employ the processor in a spike, or if polling fashion served - then higher priorithy thread may inhibit the serving sw from having the processor on time to fetch received data). buffered ports will allow such cases be handled w/o a lose of data).
in addition to CheckSum and re-transmit mechanism u should implement in the data-link layer (to detect and request retransmission) - as mentioned by previous responders, i would recommend to implement another mechanism - each remote manage errors statistics - once a treshold is crossed (#of-errors per #seconds) then a remote will request the other end to lower the rate (e.g. 38400 => 19200) (this is fully transparent to application).
I once spent a weekend transferring gigabytes over a 115 kBaud link of roughly that length, with no problems. However I was using Zmodem protocol to do the transfer. So I don't really know if transient errors occured, and didn't really care. They certainly weren't common enough to visibly affect the transfer speed. The files were all zipped or arjed to reduce transfer time, and no errors showed up on decompression.
The mantra is "verify, don't guess".
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
With 9600 Baud, about 1000 byte the second, this means about one error every 10 days - seems ok for me.
Some years ago, I found a little layout problem with a processors PLL oscillator, because an error rate of about 1 byte every hour at 38400 made me suspicious. After switching to a crystal, the test was run for a week without any error. In a lab environment, that is.
Andreas
-- Though the adage does go: 'Engineers do. Scientists talk.'
In the real world, a little higher is typical. In our POS systems, we expect a couple hundred bytes with errors per day on each connection at 9600 bps. We find that even a simple checksum and three retries will get us through most of the normal noise. Occasionally we have to troubleshoot a site where the noise prevents reliable transfers at all. Even one retransmit can add half a second to the response time at the terminal. That becomes an issue when we need to ring up a thousand lunches in less than an hour on a cluster of five registers sharing a serial line.
Lets see, mesages average a little over 200 bytes per, with two or four per transaction, so roughly 1.2 M bytes per day with 200 errors is not even cause for a service call.
All of our new cash registers have Ethernet jacks in the back. No more RS-232 with modems.
Bob McConnell N2SPP
Ethernet can have it's own problems. The place I worked at 10 years ago had the whole place networked up nicely. This was until the graphics department got some whizzy new machines to do animation. Everything was going fine until they started transferring animations during lunch. The amount of data flowing stopped the cash registers in the canteen. Even these days with faster links and switches I have seen a single faulty machine bring down an entire network.
We still use RS422 in some sensitive areas especially where the user wants a secure network. You can evesdrop on the RS422 data coming out but you can't hack into the user's system.
Peter
Peter
Which should indicate the need to look at the network topologies so that areas that are mission critical do not get disturbed by areas that are data intensive. Where I am at present there are many separate networks as each has its speciality. They do link up within the server cluster though so we still have all the interconnectivity we need.
Always a useful consideration.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/********************************************************************
In the real world the error rate is never zero
Yes, we know that making the switch simply opens a different can of worms. But, at least in most cases, using TCP based sockets ensures reliable delivery, and the retry delays are much less than on RS-232 connections. Many of our RS-232 servers are at the end of a network connection already, so we are simply removing one layer.
Overloaded switches and poor to non-existant subnet design are the new issues. But with over 600 systems installed, we only had one where the IT staff was totally incompetent, and they finally got replaced from top to bottom. Arrogance on the network support desk is the biggest problem we fight with these days.
Bob McConnell N2SPP
If you have no electrical noise and and don't lose any data due to software not reading the UART buffer in time, I think the only thing left that results in no absolute guarantee is device metastability. At low data rates this is practically insignificant.
Regards
Paul Taylor.
-- Remove _rem_ before replying by email.
The PIC chips mention it in their datasheet.
I believe its 1.72% theoratical error rate at 9600 baud. Theoratical being the key word I guess.
You are confusing it with the timing error introduced by running the PIC with a crystal that isn't the perfect frequency. Most receivers in UARTs will be able to cope with a small amount of timing error.
The level of acceptable error is the level of error that you are prepared to accept in an application. 6 of your american feet will approach an error level of 0 with good cable in a normal environment.
However if you are operating an arc welder, RF heater or spark gap transmitter nearby then your error rate may climb.
If you are worried about errors then use error detecting and/or re-transmitting. The simplest scheme is to put a checksum on and ask for a retransmit if the checksum fails. Or for one way comms. use forward error correction that can work out which bits are corrupted and fix them without needing a retransmit.
Peter
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.