Serial (rs232 etc.) to IP

And unduplicated. I see duplicate packets not infrequently on my home wireless network, but I don't ever remember seeing out-of-order packets (though I've never specifically looked for them either).

Any decent serial protocol would deal with out-of-order or duplicated packets, but there are a lot of indecent protocols in use.

--
Grant Edwards                   grante             Yow!  I'm rated PG-34!!
                                  at               
 Click to see the full signature
Reply to
Grant Edwards
Loading thread data ...

I'm not sure if I am missing something, but this seems like a stupid conversation :)

TCP is a connection based protocol and as such it ensures that all data is received in the correct order and without errors.

There is no need to 'use' another protocol like Telnet if all you wish to do is transfer a serial stream of characters from one place to another over IP. That is what TCP/IP does.

Open a socket on one end and listen.

Start sending characters to the remote socket.

TCP uses a sliding window mechanism, which is effectively a buffer of data that has been sent that has not yet been acknowledged. The sender will continue to send until this sliding window is full. As data is acknowledged from the remote end, the window opens up some more and more data can be sent.

The size of the window dictates how much data you can send before you must receive an ACK from the other end.

Every time a SYN is sent, the other end must ACK, unless the remote end has implemented delayed acknowledgement. You can normally decline delayed acknowledgement when the socket is first negotiated.

Job done!

Hope this helps.

Reply to
Sonic

Yes, but in this corner of the thread they are talking about a proposal to not use TCP, but rather use something like UDP to carry some legacy serial protocol that does it's own reliability checking - which leads to comments about how that task is different for different sorts of connection.

Using TCP is a good alternative... it's just not the only one.

Reply to
cs_posting

TCP/IP is useful when you just want to transfer error-free data but without any realtime constraints.

However, in many realtime systems, the TCP/IP is directly harmful due to the unpredictable propagation delay, which sometimes delivers data (say 10 ms) too late, in which case it is useless and the resends just loads the network by sending this outdated data.

Many realtime systems work much better with direct serial or raw Ethernet or UDP systems. If the data frame does not arrive within the expected time, it is simply discarded and the sample is marked as invalid at the receiver end and processed accordingly.

Paul

Reply to
Paul Keinanen

Two manufactures that I know of XPOR and DIgi make ehternet modules that have serial port interfaces. THey both have methods to connect that serial port out and across the internet.

So if you look at their data sheets I'm sure you'll find how that approach this problem.

George

Reply to
GMM50

Right, but how do you set the baud rate and parity? How do you get notified when a break or parity error was received?

You apparently have never used a UART or serial port. There's a lot more to it that "start sending characters".

Hardly.

--
Grant Edwards                   grante             Yow!  YOW!!! I am having
                                  at               fun!!!
 Click to see the full signature
Reply to
Grant Edwards

The number of the port that you use is generally irrelevant other than both ends of the connection need to know which port they are both using.

Specific protocols tend to use specific port numbers and these are referred to as "Well Known Ports"

As you may have seen when using a web browser (HTTP Client), you can actually connect to a web server (HTTP server) using any port that the server is listening on. I think it goes something like http://192.168.0.123:1234, where 1234 is the port you are choosing to connect to the HTTP server on. For this to work, the HTTP server must be listening on 1234 instead of (or as well as) port 80.

Key reasons why you would use a well known port number are: . So your request from the client arrives on a port that the server is listening on . So your traffic is able to break through firewall configurations . So your traffic can be proxied . So your traffic can be routed with quality of service applied

Other than that, you could have a server listening on port 80 (HTTP) for any type of connection, including your stream of serial data.

For socket communication, you create a socket, 'bind' the socket to a port, and then listen on the port.

When a client connects to the port that you are listening on, you can then start reading from the port. You can read one character at a time if you wish. In this way your server (that is receiving data) can receive as much data as it can at a speed that it is able.

The easiest way to choose an 'arbitrary' port is to choose one outside of the well known numbers or choose a well known port for an obscure protocol.

Even if you only send one character, the nature of Ethernet is that your single character might not get to its destination. TCP will ensure that the character is resent until it is either acknowledged or the connection times out.

The telnet protocol does much more than just transferring characters. TCP does that without requiring telnet.

Reply to
Sonic

There is no standar protocol defined for such a thing. The Serial to TCP/IP bridge (given an Ethernet or Wifi based network) just forwards the serial data to a TCP or UDP port using proprietary protocols.

In the case of TCP, the bridge simply waits for incomming connections from a remote host (it acts like a server) or it gets connected to a remote host before sending any data (it acts like a client) on either case there must be another host for the bridge to send/receive any COM data.

In the case of UDP, the same can be implemented plus the ability to "broadcast" or "multicast" serial data. A Windows driver simply mimics a serial COM port as a descriptor for the TCP/IP socket required by the driver pretty similar on how it is done for the USB-to-Serial dongles out there.

A simple serial to TCP/IP bridge can be implemented in the now old Visual Basic 6 with no more than 20 lines of code to send/receive pure raw serial data. I can post the code here if some one is interested.

Reply to
rTrenado

I can not find any mention in this thread of baud rate or parity needing to be maintained over this TCP/IP connection.

If you picture the primitve technology between a PC and a modem, the parity, baud, stop bits, etc. are configured between the serial port and the modem. The modem then negotiates settings with the remote peer. The remote peer has no notion of the fact that the PC is running at 115,200 with 1 stop bit and no parity, or whatever. It is irrelevant. The remote peer has configured its own method of communicating with the telephone line. This might be an Ethernet aggregator, in which case, there is no baud rate unless you consider 100Mbit Ethernet to have a baud rate.

I try not to make those type of judgements about people that I speak with in Usenet, more often than not those judgements would be wrong.

The essence of this thread is that UART is history...how do we get rid of them?

The original author's question was regarding how to transport the serial data over a TCP/IP network. I agree with you that clearly the data being received from the legacy device would be obtained at a particular rate, but I think it is safe to assume that that part of the system has been working for some time...hence the legacy.

What I believe we are dealing with here is that data is arriving at a UART at a given baud rate. We don't care what rate or parity, other than to ensure that we receive it all and don't lose any. Once the data is in the memory of our PC or embedded device, we are then trying to figure out how to transport it over the Internet.

At this point comes my statement...

On the remote peer: Open a socket on the remote peer. Bind that socket to a port Listen on the port for a connection While (not terminated) { Receive data; do your thang; }

At the sender: While (Carrier detect) { Receive serial data (having negotiated all that tedious UART stuff long ago) Send TCP data (to remote port) }

If you use TCP then you could make the window size extremely small or make it larger. You could use delayed ACK or not. You could use selective ACK or NOT.

The problem is just a tuning issue to deal with the environment...which is also something that TCP is extremely good at.

'tis so! :)

Reply to
Sonic

No, but both are things we could reasonably expect might be needed.

It's no the maintenance of baud rate that is important, but the serial side of the converter does need to be configured with the right baud rate (and word length and stop bits and parity setting) somehow. Your options broadly speaking are hard coding, dip switches, auto detect, or a configuration command going over the ethernet side of the link. Similarly, the ethernet side needs to be configured for IP address, port number, protocol etc with similar options for how to do it.

Parity is a possible serial error condition, which if present could need to be reported to the device on the ethernet side. You have to figure out how you will signal that. Similarly hardware flow control. You also may have status and errors from any protocol on the ethernet side, for which it may be necessary to pass through to the serial device somehow.

Hard coding or dip switch configuration and ignoring error conditions can make this all very simple... but that may not be acceptable in the (undescribed) appliction.

Reply to
cs_posting

Those are part of a normal "Serial (RS-232 etc.)" link.

Not sure what you mean "configured between", they're configured in each of the serial port and mode.

But the serial port and the modem must be running at the same baud rate, parity, and stop bits.

I've no clue what you're getting at. When using Ethernet to interface to a UART instead of PCI or ISA bus, you still need a method to control the UART's settings (parity, buad rate, stop bits, flow control, modem control lines, etc) and to read the UART's status (errors, modem status etc.).

This thread is not about getting rid of UARTs. It's about interfacing to a UART via Ethernet instead of PCI or ISA bus. If you've got some magical way of connecting Ethernet to an RS-232 serial data stream without using a UART, I'd like to hear about it.

His original question was about RS-232 Serial via Ethernet.

I've designed and supported serialEthernet products for many years. In the case the OP is talking about (providing a normal "COM port" API to the application), you have to provide all of the normal OOB stuff that a UART supports.

And you've got to provide the application a way to set that baud rate and parity so that you _do_ receive it all and don't lose any. You've also got to provide the application a way to set flow control, read modem status lines, etc. There's a lot more to RS-232 serial ports than data -- which is why all the different protocls (like RFC2217) were invented when people whated to do RS-232 via Ethernet (IP or otherwise).

You seem to be focusing completely on the most trivial part of the problem and doing nothing but hand-waving about the other

90%.
--
Grant Edwards                   grante             Yow!  Where do your SOCKS
                                  at               go when you lose them in
 Click to see the full signature
Reply to
Grant Edwards

Surely it is reasonable to expect that the legacy product already does *all* of that.

This problem is really *really* old.

The scenario: Old product that used to connect via RS232 to a PC about 6 feet away. New product that needs to be connected to PC about 6 degrees away.

Problem: Legacy product must not change.

Solution: Write program on PC 6 feet away that sends data to PC 6 degrees away. 20 lines of code. Modify program on PC 6 degrees away. 20 lines of code.

Note to self: Do not get hung up on tedious baud rate issues...remind self continuously that they are not relevant to the problem.

Reply to
Sonic

Yes, which is why you have to be sure to support what the legacy product expects.

If the legacy product uses parity, you have to tunnel or translate the results of the parity compare over your ethernet link.

If the legacy product uses hardware flow control, you have to tunnel or translate hardware flow control.

If you need to support a variety of possible baud rate or other settings on the legacy product (users are using it in different ways) you must be able to configure your translator's serial side to match.

And you must be able to configure the ethernet side settings of your translator.

If it's a custom one-off, this is easy. The more varied configurations it needs to support, the harder the translation task.

Reply to
cs_posting

Yes I agree Grant.

If indeed the original poster was concerned with developing a device that converted serial to Ethernet then baud rate, etc. would be a problem, as would all the Ethernet issues.

However, the market is already saturated with such devices, and they cost a few pennies, so I do not think someone would be contemplating developing their own.

Hence, I took the view that the poster was actually wanting to write a piece of software that took the data that was received from the serial port of his PC (from the legacy device) and send it out over the Internet to a remote terminal.

Based on that I wave my hand at 90% of the problem because the legacy device is *already* connected to the PC at the correct baud rate and data is

*already* being received.

The 10% of the problem remaining is as I have described...Take the serial data, open a socket, send it.

If the original poster is contemplating designing a serial to ethernet converter then I agree wholeheartedly that at least 90% of the problem remains.

Regards.

Reply to
Sonic

What "legacy product"?

6 degrees away? What does that mean?

Firstly I've never seen that scenario happen. The problem that usually needs to be sovled is:

PC talks to device X via RS-232 port. Now we want to move device X to the other side of the building (or use a PC w/o a serial port).

We are not allowed to

  • modify device X * move the PC or change it's application software.

So we plug a serialEthernet widget into device X's serial port, connect said widget and the PC to "the network", and install a device driver on the PC that makes said widget's serial port appear as a "COM port" in Windows-speak. The PC's application SW still needs to be able control wiget X's serial port configuration and read it's status. We're just replacing the PCI or ISA with Ethernet. Everything that the PC application used to be able to do with the serial port via the old busses needs to be supported via the new one (Ethernet).

You seem to have replaced the legacy product with a PC, and then written custom software for both PCs. The requirements are use the existing legacy product and PC application. You don't get to add extra PCs or re-write the legacy applications.

In my experience, you're never, ever allowed to do that.

You've never done serial stuff in the field, eh? Baud/parity/flow/etc. are a _huge_ part of the serial-communications "problem". The data part of it is trivial.

--
Grant Edwards                   grante             Yow!  Don't hit me!! I'm in
                                  at               the Twilight Zone!!!
 Click to see the full signature
Reply to
Grant Edwards

Said OP says: I am indeed doing a serial to ethernet product, but not stand alone. It is part of a much larger & expansive product. It appears that existing serial to ethernet products let the user decide what TCP or UDP port to use, leaving the decision to the installer. Terminal servers on the other hand are ... well ... terminal servers, and on the IP side use telnet, while allowing the user also to set baud,parity,stop bits, for the terminal servers UART. In my experience I think I've seen just one example where the device on the "far" side of a serial link, let's communications from the other side set its com parameters via the com link, since you will then immediatley loose the connection ... sometimes you might be able to reconfigure the other end, and reconnect, sometimes not... I just have only seen that once, but perhaps it's more pervasive than my experience...

Let's put this thread out to pasture...

-D

S> Yes I agree Grant.

Reply to
packer44

Something has to set the paramaters. You either use something physical (dip switches were traditional when RS232 was king) or you use a soft configuration. With a soft configuration, it has to originate from something with a user interface, which for "device" may well be the computer terminal on the other end of the link.

Pretty much any "device" is going to have one of fixed factory settins, switches, auto detect, remote soft configuration - or have it's own user interface.

Reply to
cs_posting

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.