RS-232 and 921Kbps, is it really possible?

[voidstar78]

I've been messing around with RS-232 recently. I understand why it has limited speed. But just out of curiosity, I did get a pair of USB/serial adapters that do claim to support 921Kbps - but between modern 3GHz i7 PCs and a null-modem adapter between them, I couldn't do a file transfer past 480Kbps.

I've tried several adapters and shorter cables. I also tried increasing the stop bit to 2 between them. A few characters (when typed slowly in a terminal) do make it across at 921Kbps, but most don't and get misinterpreted into some other symbol.

I've seen a lot of other adapters claim 921Kbps, but in their fine-print specifications, they do confess to only being 480Kbps capable. It's one thing to claim it, and be able to select 921Kbps in a terminal and claim it works during slow casual typing, but the real verification is in doing a file transfer stream (like YModem, where at these higher speeds I've found YModem to actually be faster than ZModem once you get past 115200 baud).

So I've found some fancy $60 USB/serial adapters, each of them do claim 921Kbps. They are a more substantial kit, like a box of components the size of a 3.5" floppy drive. Has anyone else tried these? (obviously that's an extreme measure to go through for RS-232, but I'm just curious if they actually achieve that speed even with modern equipment).

My other thought is, I've only been trying with Windows (as the USB drivers install easy and a terminal like ZOC makes it easy to change and test the speed). I recall reading years ago, the Linux core had some changes directly to support higher speed RS-232 (this was probably 20+ years ago). I don't know if that's related. But I can see that even at modern day 3+ GHz speeds, it being hard to manage a full GUI and that kind of intense external serial rate (while using an archaic voltage-swing protocol).

Few weeks ago I tried with PuppyLinux but just wasn't savvy enough to figure out how to get the USB/serial adapters to work and test a TTY/serial data stream under Linux. Maybe in a few weeks I'll get time to try that setup again. But I'm curious if others have truly gotten a 90+ KBps transfer rate across serial at 920Kbps baud? I've managed a confirmed 45KBps across a 460Kbps connection (with Ymodem and ZOC as the terminal software).


Ultimately it's not really all that important - it's questionable to call stuff past 115200 baud really RS-232 anymore. Technically sure, it's still voltage swing, but at rates that the original spec never really dreamed of (or the later C version). And if you need that speed and have USB involved anyway, yep, there are faster ways to exchange data.

Still, just curious on others people experience on this. I thought 921Kbps external serial would be easy-peasy for a 3GHz modern system, but then as I read more into it - I see using any general processor with interrupts as a signal analyzer is a bit of a challenge.

 

[acgs]

The first question I'd want to answer is: what USB version is involved? The fact that you are maxing out at about 480Kbps sounds like the limit of a USB 2.0 connection. No matter how fast the two systems are, USB 2.0 would be a limiting factor.

Have you made sure that you are trying the link up between two USB 3 ("blue" connector) ports?

Perhaps this should be the RS-232-U standard to make it official.

 

[krebizfan]

USB 2 is 480 Mbps which is considerably faster. Even USB 1 low speed got 1.2 Mbps.

Some of the information I have claims that those adapters need to be using RS-422 to achieve the full 931 kbps. Twice the wires; twice the speed. Is every component in the chain rated to transfer 931 kbps?

 

[Chuck(G)]

921Kb/sec on standard RS232C brings up images of very high slew rates (+12 to -12). You might be better off by using TTL levels, not 232C ones.

 

[acgs]

USB 2 is 480 Mbps which is considerably faster. Even USB 1 low speed got 1.2 Mbps.

It was the order of magnitude (K -> M) that seemed curious to me. Does the speed change with a switch from USB 1 to 2 to 3?

 

[jlang]

921Kb/sec on standard RS232C brings up images of very high slew rates (+12 to -12). You might be better off by using TTL levels, not 232C ones.

The spec IIRC says bitrate below 20kbits. 921k is very far out of spec. You can get away with higher bitrate at shorter length but eventually you don't.
The spec also includes slew rate limits (that almost everybody ignores).
TTL would handle the speed but I would go with something like rs-422.

I not convinced the USB adapters can really run that fast. USB3 should but what about the USB to TTL chip in the cable?

 

[voidstar78]

I did misspeak in the original most, meaning "460Kbps" instead of 480Kbps (which yes, USB 1.1 high speed had that 480Mbps number). Some vendors of these USB 921Kbps serial adapters sometimes just call it "1Mbps" (which yes, isn't even as fast as low speed USB 1.0) which offered 12Mbps).

Per the 1969 EIA-RS-232C spec, the voltage swing has been anything greater than +3V and less than -3V. The original Bell 103 used +/- 20V. Later in the spec, it says "Open circuit driver voltage... must not exceed 25 volts with respect to ground."

EIA-RS-232-COCR : Free Download, Borrow, and Streaming : Internet Archive

archive.org

A more concise 1991 revision is here:

https://bitsavers.trailing-edge.com/pdf/datapro/communications_standards/2740_EIA_RS-232-C.pdf

acgs:​

For the older HP laptop involved (~2016), true it may have had humble USB 2.0 ports (both of them are black color, but that system does have a USB-C port also). As mentioned, high speed USB 2 should still handle a "measly" 1Mbps data exchange. But perhaps not. I'll seek out another laptop with verified USB 3 ports .

jlang​

The same manual referenced above state "data signaling rates in the range from zero to a nominal upper limit of 20,000 bits per second" But I'm not sure about slew rate. Is this refering to a slew rate?

"The potential at the interface point must not be less than 5 volts nor more than 15 volts in magnitude when the terminator resistance (RL) is between 3000 and 7000 ohms, and the terminator open voltage (EL) is zero. "
"The effective shunt capacitance (CL), associated with the terminator, must not exceed 2500 picofarads at the interface point."
or this stuff:
"The direction of voltage must not change while in the transition region."
"The time required for a control signal to pass through the transition region must not exceed one millisecond." (1ms is a long time, so this is more of a minimum performance?)
"The time required for a data or timing signal to pass through the transition region must not exceed one millisecond or 4 percent of the normal duration of a signal element on that interchange circuit, whichever is the lesser. "
or most likely:
"The maximum instantaneous rate of voltage must not exceed 30 volts per microsecond" (yea the very last spec, bottom last pg8 on the 1991 spec)



I show how a 386 can get slightly past 115200 bps by using a faster-clocked UART (~7MHz-ish). But the greater point was also showing that a humble 386DX/33 still doesn't have the horsepower to push much past that, even though the serial ISA-card hardware supports and was configured for it. (the limitation either being the general processor speed itself, or maybe also the 30-pin SIMM RAM involved was some kind of bottleneck).

But then using modern laptops that are >100x faster than said 386DX/33, sadly the classic RS-232 interface could only muster a 4x improvement (being stable at the 460Kbps rate). Though to note, the 8x improvement (921Kbps beyond 115.2Kbps) did partially work (about 50% of the alphabet goes across ok in a typed terminal at that speed).


It's just been a curiosity, these 921Kbps RS-232 adapter claims. I'm curious how fast a Pentium-class machine could push at~7MHz equipped UART, but I only have Pentium laptops (so can't as easily insert ISA cards there to try).


NOTE :I've been reading about the 8b/10b protocol, which I think newer USB 3 (maybe 3.1) uses, not sure on the original USB 1 and 2. This protocol had a relationship to an IBM patent from 1983 and used in microchannel (or a variation used in SATA - yet "serial" ATA used 7-pins for data?). Anyhow, that 8b/10b stuff (and variants thereof) is pretty neat, and obviously gets orders of magnitude faster than classic RS-232.

 

[Krille]

I show how a 386 can get slightly past 115200 bps by using a faster-clocked UART (~7MHz-ish). But the greater point was also showing that a humble 386DX/33 still doesn't have the horsepower to push much past that, even though the serial ISA-card hardware supports and was configured for it. (the limitation either being the general processor speed itself, or maybe also the 30-pin SIMM RAM involved was some kind of bottleneck).

An 8088 can do 460 kbps. So I think the bottleneck is the software just being inefficiently coded.

 

[voidstar78]

An 8088 can do 460 kbps. So I think the bottleneck is the software just being inefficiently coded.

On an individual byte basis, sure ( since the high speed serial card is doing the actual transfer ). But for overall throughput, I don't think so.

On an 8MHz system with a ~14MHz clocked UART, we got around 24 KBps. That's just raw transfer (4KB chunk stored to RAM), at some point you have to actually do something with the data (display it or write to a disk), which is going to reduce that throughput.

If you trust the connection (short desktop-to-desktop cables), maybe you can forego the CRC processing. A lot of those old protocols were in the "modem-era" where someone else could accidentally pick up on the line at any time (either locally or at the remote site), so error correction was an important thing. And also the efficiency of any data-stream is relative to the size of buffers chosen (too small gets inefficient - like small MTU sizes in modern networking, while too large might impact flow control).

I noticed LapLink5 has a "7-wire serial mode", so maybe there are more efficient protocols. I still don't see any 8088 sustaining >40KBps data-transfers across a normal RS-232 serial port. But I'd be curious on the setup of one that can, if it's possible.

 

[Svenska]

I did misspeak in the original most, meaning "460Kbps" instead of 480Kbps (which yes, USB 1.1 high speed had that 480Mbps number). Some vendors of these USB 921Kbps serial adapters sometimes just call it "1Mbps" (which yes, isn't even as fast as low speed USB 1.0) which offered 12Mbps).

USB 1.1 provides "low-speed" (1.5 Mbps) and "full-speed" (12 Mbps) modes.
USB 2.0 extends that with "high speed" (480 Mbps).
USB 3.0 extends that with "SuperSpeed" (and the details get ugly and complicated).

Most HID devices (keyboards, mice, joysticks) are low-speed devices, even if they are listed as "USB 2.0". This is correct, "USB 2.0" does not mean "high-speed".

Low-speed devices are limited to control endpoints (not all operating systems enforce that restriction). Most USB-serial adapters use bulk endpoints on their USB side, therefore they must be at least full-speed devices. When operating at 1 Mbps full-duplex, they definitely exceed the USB low-speed bandwidth. So these devices are full-speed devices.

There is no reason to ever use high-speed or SuperSpeed hardware for this. The whole USB 1 / 2 / 3 discussion is meaningless and most likely misleading.

Many USB-serial bridge chips are perfectly capable of running at 921.600 bps / 1.000.000 bps / 2.000.000 bps data rates. I have seen and used 1 Mbps transmissions between some bridge chips and directly connected controllers, but never at ±12V RS-232. That would require some very fast and beefy transmitters.

 

[voidstar78]

There is no reason to ever use high-speed or SuperSpeed hardware for this. The whole USB 1 / 2 / 3 discussion is meaningless and most likely misleading.

Many USB-serial bridge chips are perfectly capable of running at 921.600 bps / 1.000.000 bps / 2.000.000 bps data rates. I have seen and used 1 Mbps transmissions between some bridge chips and directly connected controllers, but never at ±12V RS-232. That would require some very fast and beefy transmitters.

Thanks for clarification on USB. I couldn't check on the specifics while on travel, but in general I agree: USB speeds aren't a concern here. Which mainly is to answer my original question, that No, those $60 devices and USB3 aren't necessary to achieve this speed.

And I can say this now, since I've finally found a USB device that gets past that 460Kbps limit using RS-232. (more on that later)


First, let me show what I mean by "not supporting 921Kbps'. Image below is this initial setup..... USB/serial across two modern HP/Dell laptops (i5 and i7 systems).

Note the system is on the right has to use one of those USB-C to USB-A adapters.

Also note that in between the two USB/serial adapters is a null-modem adapter (invert tx/rx and cts/rts pins) and also a gender-changer. Noted because I realize that gender-changer alone could be a source of signal interference (especially when talking about 921Kbps speed), but it's all I had available at the time.

Next image is showing the "stability" of each of the characters, just casually typing them across a terminal. The system on the LEFT is able to receive these characters more reliably (not sure why). Each row is suppose to have the same character (just holding the key and going to next row for next key). In particular, the "d" "h" and "p" rows are pretty poor (lots of "misinterpretations"). But this is far better than the ~50% "stable" characters I had in my prior connection (different adapters).

So that's evidence that it is true - at these speed, shorter and more solid connection is essential. I would say with this setup the 921Kbps "casual-ASCII" data exchange was about 80% reliable (just look closely at the amount of incorrect characters per row, again the d/h/p rows especially). This was NOT reliable enough to attempt either a YModem or ZModem file transfer (error rate too high).


Someday I'd like to re-test without the gender change (requires a female/female null modem adapter, to then allow a straight through connection of the two USB/serial adapters).

Also note, I'm certain these aren't using +12/-12V swing. I don't have the means right now to put it on a scope - but the RS232 spec is "anything above 3V or below -3V" so this could be swinging at +/-5V (possibly even +/-3.3V).


However, see next message for a setup that did become reliable....

 

[voidstar78]

Clearing out an old closet, I stumbled across some old cables - which I thought were parallel port adapters. But I found a note inside them saying they are actually 25-pin null-modem serial adapters. Since they are BOTH null-modem, connecting them together as-is results in a "regular" cable. So I need to place a null-modem adapter in between them - which I understand isn't ideal, could be a source of noise/interference.

So using the same equipment and software (ZOC) as before, I hooked them up. (image below on the setup)

And to my surprise, there were no drop-out or mixed characters during my simple "casual-ASCII" keyboard test (while both connected at 921Kbps). Like in the prior setup, the d/h/p rows were very poor. In this second setup, everything went across perfectly.


So, what was the file transfer speed??? Next post...

 

[voidstar78]

With various other adapters, I could only get 460Kbps stable connection, and did achieve ~44KBps throughput file transfer as expected (using 8-N-1, so 10-bits per byte and plus whatever overhead of CRC checks and such that ZModem protocol has).


With these black 25-pin "mystery" USB/serial adapters, I can pair the two systems reliably at 921Kbps, but am only achieving a throughput rate of ~69 KBps. That's fine by me, a definite improvement over 460Kbps connection. However, I noticed when the laptop activates screen saver in a few minutes, the transfer generally gets error as I'm bringing the system back awake (which I can understand why, but just noting the multi-tasking effect on this "high-rate-for-RS232" type transfer).

Unfortunately, I don't have any recollection of where I got these USB/serial null-modem adapters from. And they aren't marked in any meaningful way (the plastic shell is just marked "RS-232"). I've checked order history and e-mails, and I can't find any reference to them. The closest guess I have is that they are something like this:
<https://www.amazon.com/Serial-Adapter-Converter-Communicate-Programming/dp/B07KYSQBKX>
(just noted as an example reference, various other places have this for cheaper)
EDIT: something in my mind thinks I got these from StarTech, but I still can't confirm where I got them. Not ready just yet to bust them open to see the exact chipset.

At least this does show that 921Kbps stable data-exchange is possible using the old RS-232 protocol. Again, I doubt these are using +/-12V. Maybe someday I'll put together an inline breakout box to try to scope on the pins, to help verify what voltage they are using.


Now as to why I'm only getting ~67 KBps instead of closer to the expected 90 KBps, I'm not so sure. Maybe it's a limitation of the FIFO buffer this device has (such as if 128 byte only?).
EDIT: According to the Windows driver for these USB/serial adapters, it is "Silicon Labs CP210x USB to UART Bridge" (and only has 16 byte TX/RX FIFO buffer). Another metric we don't really get insight into is the percentage of time CTS/RTS is being used (i.e. number of times it is signaled to "hold pls, buffer is full", which reduces throughput and suggest that a larger buffer might help).

As for tacking on RS-488 adapters onto the RS-232 and/or using other exotic protocols - that's new territory for me. I'm sure it's faster, but not as fun because our vintage systems won't have whatever those exotic protocols are (but I'd be interested to hear about it, if it works along a regular 9-pin or 25-pin serial connector). That's why using Y/ZModem is of interest, just since so many legacy systems have a version of those.


And yes, I realize if USB between two systems is an option, then it's silly to talk about RS-232. Since you can get USB-USB null modem cables, like this
<https://ftdichip.com/products/usb-nmc-2-5m/>
(but I'm not sure how the connection is setup, it won't be a Terminal like connection?)


If modern systems even struggle at 921K RS-232, then I think our beloved vintage systems will struggle with it too. Even if you plug in a high speed serial (with some UART clocked past ~1.8MHz) the system as a whole still might struggle to feed on its buffers. The "sweet spot" would be late model 486s or early Pentium systems that didn't have USB yet.

 

[gslick]

Most HID devices (keyboards, mice, joysticks) are low-speed devices, even if they are listed as "USB 2.0". This is correct, "USB 2.0" does not mean "high-speed".

Low-speed devices are limited to control endpoints (not all operating systems enforce that restriction).

Low-speed devices are limited to control endpoints, and interrupt endpoints, which are necessary for low-speed HID devices.

 

[Chuck(G)]

FWIW, "slew rate" refers to the voltage change per unit time. Usually measured in V/µsec or similar. The idea is that when the driven voltage goes from one level to another, there's a certain amount of charge stored in the system, which must either be dissipated or overcome. This usually involves power at the driver end. Note how this is related to the inductance and capacitance seen by the driver.

Protocols such as RS422 use lower voltages than RS232; V < ±6 maximum. ±3V is not uncommon. Note that use of differential signalling partially overcomes the issue of induced noise. An added benefit is that the power dissipated by the driver is constant (for every - transition on one conductor of a pair, a + transition on the other occurs). Differential signalling is used where speed is an issue (e.g. SATA)..

 

[voidstar78]

I think the 921Kbps RS-232 USB device I used might have been this (and Windows detected them, didn't need any particular special driver)

<https://www.alibaba.com/product-detail/Silicon-Labs-CP2102-CP210x-USB-to-504313929.html>

Is it possible the USB adapters with those little LED lights draws just enough current to impact supporting that 921Kbps rate?? (i.e. the chip could do it, but the integrated package degrades it?)

 

[Svenska]

The chip can handle the rate, but the attached driver circuitry cannot change the voltage on the wire fast enough. This is physics.

Is it possible the USB adapters with those little LED lights draws just enough current to impact supporting that 921Kbps rate??

Very unlikely. Such LEDs are not in the signal path and USB delivers way more power than a PC's serial port.

 

[bakemono]

On an individual byte basis, sure ( since the high speed serial card is doing the actual transfer ). But for overall throughput, I don't think so.

A small assembly language loop that polls a status register and then transfers a byte between a data register and memory can easily handle RS-232 speeds on a slow CPU. If we're talking 460Kbps on a 4.77MHz 8088, that's close to 100 CPU cycles per byte which is plenty of time. Using interrupts instead of polling will add latency and slow you down, as will having other interrupts (timer int, keyboard int, context switch in a multitasking OS, etc.) enabled while your serial code is running. But if you're using a packet based protocol where the other side has to wait for an ACK at some point, or you have the extra control lines to signal ready/busy status, then you can stop and do disk access (or checksum/CRC, or handle user input, etc.) without messing up communications, so you don't need interrupts.

In a terminal program (or some other realtime, interactive program) the situation might be different. Data can come in at any time and you'll want to be using interrupts so you can buffer that data while you are busy scrolling the text screen or something.

 

[jlang]

"Now as to why I'm only getting ~67 KBps instead of closer to the expected 90 KBps, I'm not so sure."

Some time is consumed by checking and acknowledging the received packets. You will never get 100%.
The sender is waiting for the ack. Even with a sliding window for ack there will be some dead time.
Also consider how the program is counting bytes. Each byte is 10 bits on the wire. if you count 10 bits per character you are a lot closer to the 90K you expected.
Each character includes a start bit and a stop bit so you loose 20% just in framing bits.

 

[Plasmo]

I have a Z80 SBC called Simple80 that can be overclocked to 29.5Mhz due to its simplicity. The serial port is the standard SIO has default speed of 460800N81 when Z80 is at 29.5Mhz. At the default 460Kbps it can run CP/M and Xmodem/CRC file transfer no problem. Instead of theoretical 46KB/sec file transfer, the effective file transfer rate is 17KB/sec due to the time it takes to write CF disk mostly because CP/M is not efficient when writing to disk. I just patched the SIO initialization to up serial baud to 921K and it communicates with console just fine and it can receive Intel Hex file OK (no checksum error), but hung when running Xmodem in CP/M, most likely because the serial port is too fast for overhead associated with Xmodem and CP/M. I think Xmodem transfer at 921K is possible with hardware handshake.
My serial port is TTL level signaling over few feet of wires, the USB-serial device is the cheap ($2) CP2102 adapter. My terminal emulator is TeraTerm and workstation is old 2.4Ghz Q6600 running Windows Vista.
Bill