-
Notifications
You must be signed in to change notification settings - Fork 0
Chapter 1 : Physical Layer in practise
Physical layer of OSI stack deals with getting data from point A to point B. This is were the software meets the physical hardware. In our case, our physical layer will use sound waves to propagate information though the air onto another system. Our computer's speaker and microphone will be used as the transmitter and receiver for this purpose. In a radio system, they use antenna to the same effect.
There are several reasons why we are implementing this stack using sound waves instead of radio waves. The main reason is that radio equipment and its use is tightly controlled in all countries and you often need to acquire R&D license even for hobby projects. Radio hardware is usually costly and with all its wires and connections is a messy thing to deal with. Since we are here to learn concepts lets skip the messy area. Sound and Radio waves belong on the same spectrum (although far away form each other) and therefore have a lot in common. The method of encoding and decoding data with sound waves and that with radio waves are essential same.
When it comes to a wireless system there are several terminologies that you ought to be familiar with viz.
Payload : The data that we wish to transmit. If we wish to send the plain-text "Apple" from A to B then "Apple" is our payload. This term will evolve as we go
Frame : Lets just say that it is a sequence of data that makes some sense to us. Like how "Apple" made sense before. This term will also evolve as we go.
Carrier : For a basic defenition lets think of this like a donkey which carries wood, here donkey is our carrier and wood is what is carried. In our case sound waves will carry our data, so sound waves can be considered as our carrier.
CRC : Cyclic Redundancy Check is a famous error detection code.
Baud Rate : Number of bits we will be transmitting per second.
0b11001100 : 0b at starting indicates that its a binary value.
0xCC : 0x at starting indicates that its a hex value.
noise : Since we are using sound waves, noise means noise in its literal sense. In RF systems though, it means unwanted signals. See the similarity?
Carrier Frequency : Since we are using sound waves to carry data, the sound wave used for this purpose will have a frequency and this value is carrier frequency.
number of Channels : The number of distinct carrier frequencies that we use in our system.
channel : Each individual carrier frequency can send and receive data and is therefore considered as one channel.
channel spacing : The gap in frequency between each of the channels is called channel spacing.
Since are intereseted in sending digital data, we have to develop a means of sending our binary digits 1 and 0 using our carrier.
One of the easiest ways in which this can be done is by a technique called On-Off Keying (OOK). As the name suggests, the idea is really simple, carrier wave is emitted for bit value 1 and is not emitted for bit value 0.
e.g. Sending 10101010 frame would be equivalent to CW_ON CW_OFF CW_ON CW_OFF CW_ON CW_OFF CW_ON CW_OFF (Carrier ON Carrier OFF ...). As you can see from the example the CW will be ON/OFF for a certain duration for each bit and this time period will utimately determine the number of bits we can transmit per second, which is nothing but our Baud Rate.
Q: What if our data is 0b00000000?
Yes we have a problem here as OOK will generate CW_OFF CW_OFF CW_OFF CW_OFF CW_OFF CW_OFF CW_OFF CW_OFF. Since the carrier wave if OFF by default, no data is transmitted and the reciever never gets our intended data 0b00000000.
Lets solve our problem first. How can we transmit 0b00000000? It is obvious now that we have to transmit at least 1 bit value which is 0b1 so that the receiver end knows the start of frame. In this case we always start our transmissions with 0b1 and our new frame is thus 0b100000000. Great now the receiver can figure out where the frame starts, but where does it end? Receiver can know this in two ways, the frame itself carries few bits which will tell how many data bytes are present or the sender and receiver has agreed to a payload size, which would be 1 byte in our case. Lets say that in our case we have told the receiver that we will always transmit 1 byte payload at a time. Now the receiver now knows where the frame starts and it can figure out where it would end by reverse calculating the time needed to deliver the payload.
Problem solved! The receiver can now receive any data byte we wish to send. But now there is a new problem. If we keep the system ON, Ambient noises would sometimes result in an accidental 0b1 and the receiver now thinks we have transmitted a payload and thus reads a junk payload from noise.
Ok, we can solve this problem by increasing the number of 0b1 or maybe even by using a 0b10101010 pattern. This pattern is called preamble and indicates the start of frame. Since picking up a 0b10101010 pattern out from noise is highly unlikely, our receiver will stop reading junk data out from noise.
I hate to be the bearer of bad news, but sadly this is not enough. Practically, the sender and receiver will be two different systems each aged differently under different circumstances. Their clock frequencies, value of carrier frequency, ... would be a little off from each other. Thus by the time the receiver catches on the the 0b10101010 pattern we could potentially miss a few bits. This could result in the payload getting dropped or few data bits of our payload being mistaken for preamble. To solve this we can add a pattern just after preamble and right before payload called a syncword. Let us consider this as 0xCC or 0b11001100. Our new frame thus becomes 0b10101010 11001100 00000000. Cool, now even if we drop a few bits from preamble we can still figure out where the payload starts exactly.
Normally, number of preamble bits that must be received is preset when we configure the system