Introduction
Laser communications systems are wireless connections through the atmosphere. They work similarly to fiber optic links, except the beam is transmitted through free space. While the transmitter and receiver must require line-of-sight conditions, they have the benefit of eliminating the need for broadcast rights and buried cables. Laser communications systems can be easily deployed since they are inexpensive, small, low power and do not require any radio interference studies. The carrier used for the transmission signal is typically generated by a laser diode. Two parallel beams are needed, one for transmission and one for reception. Due to budget restrictions, the system implemented in this project is only one way.
Laser communications have been a hot topic lately, as solutions for how to satisfy ever increasing bandwidth needs are in high demand. Some have suggested that bandwidth could be distributed in neighborhoods by putting laser communication systems on top of homes and pointing them towards a common transceiver with a fast link to the Internet. With possible transmit speeds of up to a gigabit per second, this is an exciting area. Other applications for this technology include temporary connectivity needs (e.g. sporting events, disaster scenes, or conventions), or space based communications.
The system can send arbitrary data at 27.7kbps baud. The system illustrated above is set up to send voice data. The microphone input is conditioned (amplified and biased) so that the full eight bit range of the analogue to digital converter is utilized. A fair amount of time was spent optimizing the amplifier for the mic input so as to minimize popping but maximize quality.
Once the digital signal is obtained by the ADC, the MCU passes the signal to the UART. The UART sets a transmit pin high or low according to the serial protocol. Some conditioning is applied to this signal as well in order to ensure constant current to the laser.
On the receiver side, the signal is read by a photo transistor. The signal coming off the transistor is put through a comparator to generate appropriate high and low signals. The UART reads these signals and generates a byte according to the serial protocol. This byte is applied to a port, sent through a digital to analogue converter, and applied to a speaker.
A description of the hardware and circuitry used in this project follows. Resistor, capacitor and diode values are ommitted because they need to tuned depending on the hardware used. The specific use for each component is documented.
Microphone Amplifier
The first step in transmitting sound is to digitize soundwaves. For this we used an electret microphone purchased from Radtronics. Frequent shoppers at Tito's place downtown know that finding spec sheets for products there is impossible. The microphone he sold us had three leads, which after considerable angst we decided were for power, ground, and signal. The signal coming off the mic was far too low to be read (with any degree of precision) by the analog to digital converter. So of course, an amplifier is needed. Before the signal is put through the amplifier however it is first put through a capicitor to remove DC, and then through a voltage divider to appropriately bias the signal. A LF353 op-amp is used to boost the signal, the gain is adjusted by the resistors and for the mystery microphone the gain is around 50-100 (depending on how much popping and how much quality you want).
Laser Driver
After the A/D converter translates the mic signal into 8 bits, the MCU generates the appropriate bits to send (including start and stop bits) and applies them to the laser driver circuit a 5V and 0V signals. The BJT in this circuit turns on at 5V and provides the proper current according to the diode and resitor values.
Receiver
A photo diode detects the laser pulses in a different (distant) location. This signal is put through a comparator in order to generate solid 5V and 0V values which are applied to the receive pin on the microcontroller.
Laser Driver
Once the signal is put through the DAC (not shown, it's a simple ladder), it is boosted and low pass filtered (to improve sound quality).
Half Duplex Software UART
In order to send and receive both text and audio data we decided to implement a software protocol which emulated the workings of a hardwareUART. This meant that we would be sending information in digital form over a serial data link. The laser would essentially constitute the “wire” in this link connecting our two software UARTs. We could easily reserve two pins of a port to be the receive and transmit pins for our software UART (in the final version of the code pins D.0 and D.1 for receive and transmit respectively). What remained was an implementation of a receive subroutine and a transmit subroutine. The development of these subroutines is described below.
UART 101
A Universal Asynchronous Receiver Transmitter (UART) operates on the premise that one can transmit an 8-bit (sometimes 9-bit) data message through a single wire link without time synchronization between source and destination. The resultant single wire link is known as a Serial Data Link because the bits of the 8-bit message are transmitted in series. The asynchronous part of the UART (which is what attracted us most to the idea of emulating a UART in our software) is achieved by sending known bits to denote the beginning and end of the data message. These bits are called start and stop bits and are 0 and 1 in the UART protocol respectively. When the UART is not transmitting data it maintains a logical high (1) on the wire. Thus, when a logical low (0) start bit is transmitted, the receiver knows that a message is being transmitted and starts “paying attention”. The 8 bits following the start bit are the contents of the message. The 8 bits are followed always by a logical high (1) stop bit (and in more complicated implementations a parity bit which we shall ignore for our purposes). In the hardware implementation of the UART on most Atmelchips the UART samples received bits 3 times in the middle of the bit and uses a “majority rule” process to determine the value of the bit. By contrast, our software UART will sample received bits only once in the middle to determine their value.
Also, another key difference between our software UART and most hardware UARTs is that it is a half duplex UART. This means that it can only transmit or receive at any given time rather than both transmit and receive at the same time (full duplex). A full duplex software UART would be much more complicated and is unnecessary for our application.
The measure of the rate at which bits are transmitted by a UART over a Serial Data Link is known as a baud rate (the term “baud” does not stand for anything but rather is a shortened form of the name of Emile Baudot, a pioneer in early telegraph systems whose work paved the way for the Modulator Demodulator (Modem)). Moreover, a data rate of 300 baud is analogous to a rate of 300 bits per second (bps). This data rate is important for two reasons: It determines how long the transmitting UART must maintain a bit’s value on the wire, and it determines how long the receiving UART must wait between sampling bits. These two lengths of time are actually the same and will be implemented in our software UART with a software delay call (referred to hereafter as a “delay”).
To calculate the length of time we need the delay to last we must know that getting into each of the transmit and receive subroutines and doing the necessary logical operations to change bit values or to determine received bit values take a total of about 1μs (or 16 operations) and so we must subtract this amount from our end result. In the following calculations we will denote our end delay as “delay” and our desired baud as “baud”:
We first must calculate the time length of a bit at the desired baud:
Then get the period in μs:
We then round this result and subtract 1μs to account for overhead and logical operations. This is our final delay:
This delay is denoted as “buadnum” in the final code. We also require “halfbuadnum” for the receiver (as a rule of thumb buadnum/2, round result up if buadnum is odd). Any timing errors associated with these calculations only persist for 8 bits because the messages are only 8 bits long. Such errors would be “reset” at the beginning of the next transmission, and as a result we noticed that the software UART was not terribly sensitive to errors on the μs level (especially at lower bauds). These discussions of delay calculations will make more sense to the reader after reading the descriptions of the transmit and receive subroutines. A table of some common delays is given below.
BAUD | baudnum | halfbaudnum |
110 | 9090 | 4545 |
9600 | 103 | 52 |
27777 | 35 | 18 |
38400 | 25 | 13 |
57600 | 16 | 8 |
115200 | 8 | 4 |
It should be noted that (although the code is nowhere near the same) many of the concepts we used in creating our software UART came from theAtmel Application Note on Half Duplex Compact Software UART for the AVR 8-bit RISC microcontroller family (App Note AVR305 athttp://www.atmel.com/dyn/products/app_notes.asp?family_id=607 ). The code provided with this App Note was written entirely in assembler language and so we were presented with the task of implementing a C version which mimicked its operation. What follows is a description of our end product.
The Transmit Subroutine put()
To transmit a byte (8 bits) over the serial data link we developed a subroutine called put. This subroutine takes the 8 bits of data in the character variable Txbyte and shifts each bit out on to the serial data link one at a time starting with the LSB. The data byte desired to be sent should be placed into Txbyte and then put must be called in order to send that data. It is important to note that a call to put destroys the contents of Txbyte.
We felt it was a good idea to invert Txbyte at the beginning of the put subroutine and then treat all 0s as 1s and all 1s as 0s in order to make what is shifted into Txbyte when we perform a right shift (which is a 0) look like a stop bit of value 1. This eliminates some logic at the end of the subroutine to make a stop bit. We also have a variable called carry which essentially keeps track of the last bit shifted out of Txbyte and is representative (i.e. the opposite) of the value of the bit currently being sent. Lastly, we have a variable called bitcnt which is a counter to keep track of what bit number we are currently sending. It is set to 9 + sb at the beginning of the subroutine and is decremented each time a bit is sent (sb is the number of stop bits being used which in the final version of the code is set to 1).
The first three things we do in put is to set the value of bitcnt, invert Txbyte, and set carry to 1 (for the start bit which should be 0). We then enter awhile loop which terminates when bitcnt reaches 0. Upon entering the loop we send the current bit. This is done by setting the transmit pin (PORTD.1) to the opposite value of carry. We then want to maintain that value on the pin for the appropriate amount of time (determined by the desired baud) and so we delay for buadnum μs (using a call to delay_us()). We then set carry to the value of the LSB of Txbyte, we shift Txbyteright 1 place¸ and we decrement bitcnt because we have sent a bit. At this point the loop will repeat until bitcnt reaches 0 and the stop bit has been sent. The reader should note that the time it takes to perform any of the logic, branching, shifting, or other calculations in the loop is accounted for in the delay (by subtracting 1 μs). We paid very close attention to the resulting assembler language to determine this correction and we even balanced the number of cycles required regardless of whether a 1 or a 0 was sent (the reason for the inserted nop).
A flow diagram of this subroutine can be seen below:
The Receive Subroutine get()
To receive a byte of data from the serial data link we developed a subroutine called get. This subroutine waits for a start bit and, when one is detected, receives bits from the serial data link one at a time and shifts them into the character variable Rxbyte starting with the LSB. After all 8 bits have been received the contents of Rxbyte represent the complete received byte. It is important to note that the next call to get will overwrite the contents of Rxbyte with the next byte to be received.
Timing is very important in the get subroutine because we must poll the receive pin (PIND.0) at the appropriate time to get the correct values for the received bits. To this end we must calculate two different delay lengths: one is the full bit delay length denoted as buadnum and the other is a half bit delay length denoted as halfbuadnum. The calculation of both of these delays is explained above.
The first thing we do in get is to set bitcnt to 8 + sb. The reason we use 8 here instead of 9 (as in put) is because we will already be past the start bit when we start to decrement bitcnt. We then enter a while loop which continuously polls the receive pin (PIND.0) checking for a 0 (i.e. the start bit). Thus, the subroutine can only continue once a start bit has been detected (consequently get must be called before the start bit is to be received). Once the start bit has been detected we then delay for half a bit to get to the middle of the start bit by calling delay_us(halfbuadnum). At this point we enter a while loop which will terminate only when bitcnt has reached 1. Upon entering this loop we delay for an entire bit to get to the middle of the first bit (and each successive bit on successive iterations of the loop) by calling delay_us(buadnum). After this delay we shiftRxbyte right 1 place. We then set the MSB of Rxbyte according to what we are receiving on the receive pin PIND.0 (0 if receiving 0 and 1 if receiving 1). We then decrement bitcnt because we have received a bit. The while loop will terminate when bitcnt reaches 1 (instead of 0 as in put) because we do not wish to shift into Rxbyte the stop bit which is not part of the data, however we must still delay for one bit after the while loop to get past the stop bit. As in put the time required for logic, branching, and shifting in get is accounted for in the calculation of the delay.
A flow diagram of this subroutine can be seen below:
The Programs
In order to test our software UART and our hardware setup we wrote 3 programs. One of these programs was used to test our system’s ability to transmit and receive text data from a HyperTerm session. This program was called echoer.c and contained both the put() and get() subroutines. The other two programs were used to test our system’s ability to transmit and receive audio. The program which transmits audio was called tx.cand contained the put() subroutine. The program which receives audio was called rx.c and contained the get() subroutine. A brief explanation of these programs is provided.
The Text Program echoer.c
As mentioned this program makes use both the put() and get() subroutines. The main method is fairly simple. We first set the data direction of the pins of PORTD to the appropriate settings. We indicate the use of 1 stop bit. We then send ASCII 0x12 to clear the HyperTerm window. Finally we enter an infinite while loop which executes a get() then transfers the received byte Rxbyte to the transmit byte Txbyte and then executes aput(). This essentially echoes whatever is received by the software UART. Our test setup was to program 2 Mega32s with this program. We would then have one of the Mega32s software UART receive pin connected (via RS232) to a computer with a running HyperTerm session and the transmit pin connected to the laser transmitter circuit. We would then connect the software UART receive pin of the second Mega32 to the photo diode circuit and connect the software UART transmit pin (via RS232) to a computer running a HyperTerm session. A user could then type on the firstHyperTerm session and see the typed text appear on the second HyperTerm session.
The Audio Transmitter Program tx.c
The tx.c program is responsible for two different things. The first of these is to sample the output voltage of the microphone circuit at the desired frequency and the second is to send the 8-bit result over the serial data link (thus it only requires put()). This process makes use of two features of the Mega32: Timer/Counter 0 and the Analog to Digital Converter (ADC). Timer/Counter 0 will essentially (through use of the overflow interrupt) control the frequency at which the ADC is told to make a conversion of the microphone voltage. Two interrupts are involved in this process: the Timer/Counter 0 overflow interrupt and the ADC conversion complete interrupt. The Timer/Counter 0 clock prescaler is set to 256 which effectivelyyields a clock period of:
The reload value (i.e. the value the counter is reset to in the overflow interrupt service routine) is 256-21. Thus Timer/Counter 0 overflows every:
We also have a task (task1) which we can have execute every t1 overflows of Timer/Counter 0. This task orders the ADC to begin a single conversion (i.e. take a sample) by setting bit 6 (ADSC) in the ADCSR register. If we desire a sampling frequency of about 3kHz then we wanttask1 to execute every time Timer/Counter 0 overflows and so we set t1 to 1. When the ADC completes the conversion it throws the ADC conversion complete interrupt. In the interrupt service routine for this interrupt we transfer the result of the 8-bit microphone voltage conversion (in ADCH) to the transmit byte Txbyte and then execute a put() to send the 8-bit voltage over the serial data link. The 8-bit voltage value produced by the ADC represents a voltage between 0 and 5V because the reference voltage of the ADC is set to AREF which is 5V.
The main method here is again rather simple. After the appropriate initialization of the Timer/Counter 0 and ADC registers and indicating the use of 1 stop bit we fall into an infinite while loop. There is one line of code in this loop: an if statement that assures that task1 executes every t1overflows of Timer/Counter 0. The interrupt service routines do all the rest of the work.
The Audio Receiver Program rx.c
The Audio Receiver rx.c is very simple and does not require the use of any timers or the ADC. Its sole responsibility is to receive the 8-bit voltage values off the serial data link and blast them out 8 bits at a time through a port (in the final version of the code PORTB) to the DAC circuit. Because of this rx.c only requires the get() subroutine. After the appropriate initialization (appropriate data direction on the ports and 1 stop bit) we fall into an infinite while loop where we execute get() continuously. The get() subroutine will wait for the start bit of a transmission before executing. Afterget() executes we blast the received byte Rxbyte out through PORTB to the DAC circuit before the next call to get(). Because get() waits for start bits the frequency of the output to the DAC (and in turn to the speaker) is all determined by the frequency of incoming transmissions which is in turn determined by the sampling frequency at the transmitter. Thus, it all fits nicely together.
The Audio Setup
The setup for audio transmission required the use of two Mega32 chips. One of the chips was programmed with the transmitter code tx.c and the other with the receiver code rx.c. The transmitter was connected to the microphone circuit through the ADC input pin (PORTA.0) and to the laser transmitter circuit through the software UART transmit pin (PORTD.1). The receiver was connected to the photodiode circuit through the software UART receive pin (PORTD.0) and to the DAC circuit through the output port (PORTB).
Mechanics
Focussing the laser turned out to be quite a challenge. When we ordered the laser diode, we presumed it would come focussed. Imagine our disappointment when it was not. Fortunately, we had an old laser diode to cannibalize. Bill Mutch used a razor saw to cut the lens off of it which we then placed over our laser diode at the appropriate distance using medical tubing and electrical tape. The diode still unfocusses when barely touched, but it's better than nothing.
Aiming the diode at the phototransistor is another problem. Because the diode is fairly focussed and the phototransistor is sensitive at particular angles, steady hands are needed to aim at distance. A typical setup involves two staplers (to lean the breadboards against) and lots of tape (to tape them at bizarre angles).
Receiver and Transmitter
Results
What would a project be without results?
By using the built in hardware UART to communicate with Hyperterm on a PC we have tested our project to transmit text at up to 38.4 kbps. At this rate it is entirely error free. The system can likely transmit much faster, but for text applications anything faster is overkill.
We can send arbitrary data at a rate of up to 27.7 kbps. Although we could not pin point the exact reason why the reliability of our audio transmission fell drastically at bauds higher than 27.7 kbps, we do suspect that is has something to do with a timing problem involving the time required by the ADC to complete a conversion since the biggest difference between the audio code and the text code is that the audio utilizes the ADC and transmits continuously. We did not have sufficient time to test this hypothesis, but as we did have the ADC clock turned up as fast as it could go (125 kHz) we do not believe there would have been much we could do about this problem anyway. In the end, 27.7 kbps is plenty fast enough to transmit our voltage values if the sampling rate is 3 kHz. So ultimately the baud limitation did not degrade the quality of the transmitted audio.
On the other hand we were somewhat surprised by exactly just how poor the 8-bit audio sampled at 3 kHz sounded (even though we knew it would not be great). Even after some liberal low pass filtering the audio was still of poor quality. One definitely would not be able to hear a pin drop over this line.
Performance
If the laser is properly aimed at the phototransistor as discussed in the mechanics section, the bit stream is received perfectly. As such text transmission works flawlessly at our largest test distance, across the Digital Systems Lab. Unfortunately, the quality of our focus application (voice transmission) is limited by 3 kHz sampling and 8 bit sound. The speaker on one end is clearly audible on the other, but it takes a trained ear to decipher what he or she is saying.
The Next Go Round
All of our dreams and wishes for the next go round lie mainly with the ADC. If we had more time we would do well to utilize all 10 bits of resolution that the ADC affords instead of just 8. It would be fairly simple to modify the UART code to transmit 10 bits instead of 8 (although this would be a departure from the serial standard). Also (though we realize ADCs are more difficult to build than DACs) we would wish for a faster ADC. This would allow us to sample faster and, if our suspicions are correct, to transmit at a higher baud. All of these would improve the quality of the sound.
Another thing we would have done differently would be to implement a full duplex software UART in order to establish a 2-way link. This would require the UART to both receive and transmit simultaneously and would likely involve some clever use of interrupts. Because our budget and the availability of only one collimating lens only allowed us to build a 1-way link in the first place we did not pursue the full duplex software UART idea. (Note that we could have implemented a 2-way link using the Mega32 hardware UART which is full duplex, so the decision to make a 1-way link was purely because of a budget and supply limitation.)
One wish we have that would not require new hardware would be to spend more time optimizing the use of the 8 bits of information we do have. As of now only about 4 or 5 bits are effectively being used with the microphone gain settings as they are. If we were to use closer to 8 bits the audio quality would improve noticeably (for a while we were only using 3 or 4 bits and were able to improve it slightly by fiddling with the gain resistors in the microphone circuit). This is a problem which just involves time spent fiddling around with values to get the bit usage just right and would be especially important to do in order to gain anything if 10 bits were used instead of 8.
Interference, Safety and Usability
We did experience some interference in the final testing of our system, although the interference did not come from within our system, nor did it come from other peoples’ projects. It came from other people. As one might expect, when we tested our system to see if it was capable of trans-room operation if someone walked through the laser beam the transmission was interrupted. The interruption was only momentary and had no lasting effects. Obviously if such laser communication systems are to ever become widely used they will have to be placed where they will not be obstructed.
Having people walk through the beam brings up another point: safety. We did our best to emphasize the dangers to everyone in the room at the time (with the help of Prof. Land) to be sure no one accidentally looked into the laser beam of any of its reflections. Laser light can be very harmful to the eye if shined directly into it and so we had to be very careful with this aspect of our system.
The most difficult thing to master about the usability of our system was aiming the laser diode at the photodiode on the receiver. Once the laser was aimed and appropriately focused the use of our system was fairly straightforward: talk into the microphone and listen at the other end.
Intellectual Property Considerations
The only intellectual property consideration is to not that some of the concepts we utilized in the development of our software UART were borrowed from the Atmel App Note 305 (Half Duplex Compact Software UART) at http://www.atmel.com/dyn/products/app_notes.asp?family_id=607. As mentioned before, the code provided was written entirely in assembler language and so we decided to develop our own version in C.
Task Division
We worked very closely throughout this whole project, and as such a division of tasks is hard to do. Keith probably spent more time on the actual design of the web page while Mike spent more time writing the content. Keith spent more time figuring out the analog components of the project while Mike was more the software guru. We both feel very comfortable with the amount of work each of us put in.
Final Conclusions
Ultimately we believe that we achieved what we initially set out to do. Even though the sound quality was not as good as we may have liked we did still transmit audio over the link and so we feel quite satisfied with what we have accomplished.
0 comments:
Post a Comment