# Circuitry for sending and receiving bit streams in networking

To my little knowledge , I know that digital signals are transferred over continuous EM signals . At the receiver end a bit 1 is detected when the amplitude crosses a certain threshold and a bit 0 is detected when the amplitude falls below a certain signal .

But in networking streams of bits ,packets, are what communications take place over and a packet is simply a stream of bits .This packet is what contains various information about related to the protocol , the source and the destination .

At hardware level , how is this stream of bit sent and received ?

If the detection of bits is being done on the basis of EM signal amplitude , then does the gathering of bits involve checking the amplitude of the signal at different intervals of time ?

I see that I could be more specific and elaborate . So let me explain what I need in a bit more detail :

When do we detect a bit 1? when a signal amplitude exceeds a certain threshold ,right ? Now a packet will have a bit stream like 1,0,1,0... but how is this bit stream detected . Is there a circuit which detects a starting bit and then keeps on gathering amplitudes in frequent intervals of time till the end bit and hence constructs a bit stream ? As such is there a time-limit for which the hardware performs this gathering of amplitude process ?

• Hello Erwin Kairos and welcome. I'm not quite sure what you're asking. Is it a) how data bits are encoded onto the physical medium? or b) How packets are made out of bit streams? Apr 11, 2019 at 16:24
• @jonathanjo : To some extent both (a) and (b) would help with what I want to know.But let me try explaining my need in more detail . When do we detect a bit 1? when a signal amplitude exceeds a certain threshold ,right ? Now a packet will have a bit stream like 1,0,1,0... but how is this bit stream detected . Is there a circuit which detects a starting bit and then keeps on gathering amplitudes in frequent intervals of time till the end bit and hence constructs a bit stream ? Apr 11, 2019 at 16:40
• Actually, that depends on the physical medium and the protocol used. Some detect voltage changes, some modulate a carrier. Different protocols do it differently, and some protocols can use different media and do it differently on each medium. You really need to be more specific. Also, this question is really more suited to Electrical Engineering. Apr 11, 2019 at 16:48
• @RonMaupin : Whether , they modulate a carrier or detect voltage change , in the end they assign a bit value 1 depending on the crossing of a certain threshold right ? And So ,there must be some time till it can continue this periodic gathering for a packet , right ? Apr 11, 2019 at 16:52
• @RonMaupin : On a second thought , I could doubt about my understanding that in every case bit 1 or 0 is assigned is based on amplitude. I do not have an alternate scheme with me but I feel there sure might be a different one . But to detect a stream of these bits , signals have to be sampled over certain time ,right ? Apr 11, 2019 at 16:57

There are a great number of line encoding schemes which deal with different special cases. I'm just going to talk about the simplest ones.

At base, don't think about it like software: "we keep checking it to see if it changes". The electronics is more like a spring which is unhooked when an event happens, such as a voltage exceeding a certain level. Or pushing something off a table: it doesn't "keep checking" to see if there's something under it: there's a force stopping it moving downwards. When the force is removed, it falls.

The simplest line encoding in common use is NRZ ("non-return-to-zero", a name which doesn't help much until you already understand it.) This is used in RS-232 and many other things. A line is at some voltage, say 5V. When it falls below say 1V, we start a timer. Suppose the bits are going to be one per second: we start a timer for half a second -- we should be in the middle of the here-comes-a-byte "start bit". After this half a second, we wait another second: now we're in the middle of the first bit: we just check the voltage. Wait another second, check the voltage and we have the second bit. Do this eight times till we have a byte.

You'll see that process is built of three mechanisms:

• waiting until an event occurred (voltage falling below a value)
• waiting a fixed amount of time (half or whole bit time)
• sampling the line at a given moment

That process normally happens in hardware, but sometimes firmware. All the details vary: the voltages, the speeds, whether high voltage is a one or a zero, whether the first bit is the low-value or the high-value bit. See Wikipedia for more.

It's true that the first of those (wait until signal is low) could be done by a processor sampling at speed. But it is more usually done by circuitry which performs an action after an event, perhaps by the signal feeding a latch which holds some timer chip in reset.

Once we have bytes there will be some scheme to get framing, of which the simplest is SLIP (serial line protocol), where, in essence, a particular byte value indicates the beginning of a frame. There's nothing like reading the real RFCs which define the internet, and the one which defines this is especially simple RFC1055.

There are very many other schemes for framing, such as "long time without signal" (used in DMX) or "no voltage at all means not inside a frame" (used in coax ethernet).

Ethernet is akin to the mechanism described, but much more complex. Especially the faster kinds, which are very much more complex. The simplest in current use is 10baseT, which uses "Manchester Encoding" (named after the university where it was developed). The basic idea is the same: wait for a particular type of transition, then wait a certain period, take a sample, repeat. But every detail is different. Wikipedia has a good article.

As said in comments, whole books on the subject of encodings: whole PhDs.

High performance framing and encoding schemes are all about

• errors -- what happens when noise or other problems mean the received signal isn't what was expected
• bandwidth -- how to get the most bits down the channel that we can
• money -- how to do it with cheapest materials
• reliability -- how to use parts which don't break

Seriously: if you understand RS-232, NRZ, SLIP, and that proper networking is much more complex, you know enough for a networking person. It's much more important to know about which kinds of networking have link detection than the details of how they work.

If you want more detail about how the circuits work, electronics.stackexchange.com is probably a better bet than here, but we're good for things like framing and CRC errors and similar.

• it's delightful to see the length of this post ..let me go through it . Thanks a lot :) Apr 11, 2019 at 17:31
• So by these schemes we collect the bytes, we store them at some place right so that we can process on them later to get the starting frame and the ending frame and the data received ? Apr 11, 2019 at 18:24
• It's more usually done on the fly: think of the bytes arriving. To collect a sentence what we'll do is ignore each byte until we get a full stop ".", then we collect (and store somewhere) bytes until we get another full stop: at this moment, the stored bytes are a sentence, or frame. At this frame-ending full stop, we process the frame (look for checksum, do next layer up processing). Then repeat. This is actually how SLIP works, but full stops are byte value 0xc0, and there's a mechanism for having the special character in the data. As said, this is only the simplest of the real protocols. Apr 11, 2019 at 19:49

Network line codes are not that easy to start with. They're designed for at least several dozen meters over (more or less) simple cabling. This requires elaborate coding schemes for high bit rates over copper (and for very high baudrates even over fiber). Generally, networking links don't use a separate clock signal, so the line codes need to be self-clocking and self-synchronizing.

The simplest code used in networking is the Manchester code used for 10 Mbit/s Ethernet: high-low = 1 and low-high = 0. Of course, this wastes a lot of bandwidth, but you can build custom hardware for this quite easily.

100 Mbit "Fast" Ethernet uses 4b/5b block code. Since 125 Mbit/s is too high for category 5 twisted pair copper (100BASE-TX), there's another sublayer coding with MLT3 (basically stepping through different voltage levels instead of jumping between just two). Custom hardware is doable but already pretty hard to build.

Gigabit Ethernet uses 8b/10b block code as the basic line code which is similar to 4b/5b but has some advantages. 1000BASE-T for twisted pair splits the stream into four lanes, uses additional PAM5 coding and scrambling to cope with the cable limits. Custom hardware is extremely hard to build if possible at all - one data bit translates to 1 nanosecond.

10G+ Ethernet generally uses the more efficient 64b/66b large block code. Twisted pair requires a very elaborate coding scheme in multiple layers involving Tomlinson-Harashima precoding (THP), PAM16 and DSQ128 "checkerboard" patterns to enable copper transmission. Even if you were able to custom hardware for 1000BASE-T, 10GBASE-T requires a sophisticated ASIC in any case - we've got 100 picoseconds per bit.

Except for the latest speeds, fiber generally just uses the basic line code and is much easier to code and decode than copper - but still.

All that just covers the physical layer. Networking standards usually cover the data link layer as well, so you need to build frames around your actual data (the network layer payload). This however, could be done in software with only a little hardware support.