Talk:Serial communication

Misc

I am proposing to make ATM a subsection under "Packet-based communications", as I think it's useful to compare the general concepts for TDM and packet-based. Each of these would list and link to the corresponding articles: T-1, E-1, SONET, etc. for TDM, and Ethernet, Frame Relay, ATM, X.25, etc. for packet-based. Is this the appropriate article for this?Bert490 04:07, 16 August 2006 (UTC)

ATM networks has nothing to do with serial communication, which is a physical layer issue. I have removed it as well as TDM.

Packet mode communication or packet oriented communication is an alternative name to your article. What you suggest is also described in statistical multiplexing, asynchronous communication and packet switched communication. Mange01 21:49, 7 November 2006 (UTC)

There's a page for serial port and one for serial communications. There's one for parallel port, but none for parallel communications, which redirects to parallel port. IMO it would be best to combine the first two and turn one into a redirect, but I'm not sure and I'm not necessarily knowledgeable enough to do it. Any comments? Fpahl 14:51, 14 Sep 2004 (UTC)

I disagree. Serial communications is much more broad, and doesn't necessarily involve a serial port. Also, many kinds of serial communications ports are not called "serial" ports, but are given more appropriate names like "Ethernet" ports. --Rick Sidwell 2 July 2005 00:20 (UTC)

I've got to second that disagreement:- Serial Communications are a pretty broad concept, used in all manner of places. On the other hand, a serial port is a computer connector (and associated bits). To draw an analogy, we wouldn't merge USB with serial communications even though USB is a method of serial communications. If anything, parallel communications needs a writeup. Mike1024 (talk/contribs) 23:36, 13 September 2005 (UTC)

Okay, I created a parallel communications stub. Bushing 07:19, 22 March 2006 (UTC)

Is this an RS232 or a serial communications page? I propose that RS232C stuff be moved to its own page. At least, right before "COMMON BAUD RATES" make a section that delves into RS232.

Like RS-232? --IanOsgood 18:19, 11 December 2006 (UTC)

Frame-based vs. stream-based

Hi. I came here looking for information on frame-based (is this packet-based?) vs. stream-based, and didn't see anything. If I knew anything, I'd write it in, but I don't. —The preceding unsigned comment was added by 210.80.157.192 (talk) 00:22, 8 February 2007 (UTC).

I agree that Wikipedia should have a few words somewhere about continuous streams / circuits; vs. packets / frames / files. I see that many articles -- streaming media, pipeline (Unix), connection-oriented communication, stream (computing), Transmission Control Protocol, datagram, network packet, bytestream, etc. -- already allude to this dichotomy. Should this article link to those articles and discuss frame-based vs. stream-based communication? Is there already some other article that compares and contrasts frame-based vs. stream-based communication? --DavidCary (talk) 01:51, 3 May 2019 (UTC)

Merge

Serial communication and serial transmission should be merged, like parallel? Djmr (talk) 14:47, 11 February 2009 (UTC)

Yes. Serial transmission is a 2-sentence stub anyway with only a few links to it. --Wtshymanski (talk) 15:38, 11 February 2009 (UTC)

Underlying "physical layer" specification?

Both specifications documents for IEEE1394 and USB call out the same underlying serial communications physical layer but the standards have different packet formatting. Both specifications are not public per se but one can find copies. I would like to reference the physical layer but can't locate my spec sheets right now. Shjacks45 (talk) 16:31, 27 October 2013 (UTC)

"Bit jitter"

. The reference to clock skew in serial vs parallel isn't quite right. In fact "bit jitter" is addressed in the USB 3.0 Standard, it is an issue with any synchronous communications over wire. Bit jitter refers to the fact that although electrons travel at "the speed of light" over a wire, the speed at which higher frequency (or more rapidly changing signals) is slower than lower frequency signals. This "velocity factor" is used in designing RF circuitry (e.g. antennas and transmission lines). A Parallel example would be output from a counter: the LSB changes rapidly but the MSB changes slowly, if the data is sync'ed to the counter clock, the MSB data arrives earlier than the LSB signal. Circuit board traces, twisted pairs in cables, act as transmission lines (used as delay lines) also introducing delays. Of course one of the examples of serial (narrow bus) being "better" than parallel is the infamous RAMBUS memory, holding that 16-bit wide memory can be reliably clocked at higher speed than 128-bit wide dual channel RAM. Shjacks45 (talk) 17:05, 27 October 2013 (UTC)

Challenging the diagram bit order

@Kjerish @AmenophisIII @SyamilAshri

(1) Parallel versus serial communication.

(2) Serial and parallel data transmission of the letter "K" (01001011₂). Standard bit sequence shall be least significant bit first (b1 to b8 in acending order). b1 is received first via serial transmission. All bits are received simultaneously via parallel transmission.

The current diagram (1) could be read as if the bits are lined up in decending order on the wire; D7 (MSB) about to be received by "RX" first, next comes D6 etc, and D0 last.

But FIPS standard bit sequence shall be least significant bit first (b1 to b8 in acending order). b1 is received first.

Thus I would suggest a new diagram (2) with appropriate description.

See also

• Image:Parallel and Serial Transmission.gif, which states explicitly "MSB first", which I think is plain wrong, but seems to never got called out. (1) is just a vectorization of this GIF which happens to also mirror RX and TX.
• Image:Rs232 oscilloscope trace.svg, where the arrow depicts the passing of time from left to right and not the direction of transmission from TX to RX (here).

Aeroid (talk) 22:10, 28 December 2022 (UTC)

@Aeroid: I'm fine with that, no problem. Thanks – Kjerish (talk) 23:59, 28 December 2022 (UTC)

You are right that LSB is more common in many applications but almost every U(S)ART can be configured either way, for example. So it is not wrong in any way and from a didactic point of view it has the advantage to bring up the problem of endianess. People looking at this diagram *should* be triggered and understand that there is a choice to make between LSB and MSB first, just like there is a choice which channel holds which bit in the parallel case. I have no idea what "FIPS" standard you are talking about but it is kind of irrelevant. This is a very generic diagram not related to any standard or technology at all. You can do the same thing with smoke signals too. I've been using it in teaching an embedded systems course in an intro to UART, SPI and I2C.

The "MSB first" on the gif is not wrong. You are just not reading it correctly. Look at the direction of data flow. That's one of the many reasons I created the SVG in the first place.

BTW, using subscript for the indices - the most important parts of the whole diagram - is... not exactly ideal.

@Kjerish, BTW, I really dislike your changes. The word "example" is completely redundant in the original gif and your conversion, the borders I made (similar to the shadows in the original) are very important on projectors, the colors are now less distinctive, the overall headline was generic enough to remain part of the actual diagram to make it clear this is indeed a generic example no matter what a caption says, and I chose the fonts deliberately to be a) free, b) highlight the important parts. Your version looks very odd in most applications because of all of that.

@Aeroid your upload to commons indicates that it is your own work. That's... not exactly nice.

And that's why I rarely come back to this site. Feel free to do whatever. AmenophisIII (talk) 08:29, 23 March 2023 (UTC)

I don't really have an opinion here, but you're free to do whatever you thinks conveys the point better Kjerish (talk) 12:15, 23 March 2023 (UTC)

@AmenophisIII didn't mean to claim anything here. Let me check that make the change... I'm traveling right now.

Thanks for noting! Aeroid (talk) 12:38, 23 March 2023 (UTC)

@AmenophisIII It was certainly not my intention to devalue your contribution and somehow want be responsible for you not coming back. I simply thought I could take a great diagram and build an (what I thought to be) improved version of it. As I wasn't quite sure if others thought this would be an improvement I uploaded it as a separate file and wrote this note asking for feedback.

Your original CC0-work has been attributed to by "derived from" in the source field nonetheless. (Anything wrong with that?). Altough it looks very similar, its actually a handcoded SVG completely rewritten from scratch. But to play nice, I have now added your name to the author field as well ("derived from work by"). Is that what you would expect? I actually think the attribution would have been enough, but please let me know.

How is your perception of my contribution to yours different compared to yours based on User:SyamilAshri 's File:Parallel and Serial Transmission.gif and not mentioning him/her either?

While we are at that, how can you make your work CC0 if you derive if from a CC-SA and GPL work? --Aeroid (talk) 22:32, 23 March 2023 (UTC)

@Aeroid: I think this is an improvement. I would label bits as in the existing diagram starting with D₀, not b₁. I would not use "K" as example data since this unnecessarily brings in ASCII; just leave off the label as it is in the original.