Senior Design II paper
Audio Control and Switching Module
Download 0.59 Mb.
|
- Navigate this page:
- Headphone Tracking System
Audio Control and Switching ModuleFor audio testing of the headphone and master microcontroller design, the group will first use a DVD or VHS player as the sound source connected to the microcontroller through RCA cables. The microcontroller will have a test program to set the select lines on each headphone multiplexer to the input of the one connected sound source. The audio control and switching module (also called the master microcontroller) must be tested before the team sends it off for the assembly of the PCB. Each individual part must be tested for accuracy and efficiency. The main parts that must be tested are the Stellaris, the RF transmitters, and the IR receivers. The first test the team must make in the Stellaris is to figure out the power going into the microprocessor. The team will order the Stellaris development kit EKS-LM3S8962 and experiment with the code to make sure it is working correctly. This method will be used for each test the team will do on the main board. If the microcontroller is not able to transmit or communicate with these devices then the team must go back and fix either the software of the hardware setup. The development board will cut down on wasted parts and time. The RF transmitters must be tested. As explained in section 7.1, the team can test the transmitter and receiver together to confirm proper functionality. Once the team determines the headphones are receiving a signal from the transmitters. As discussed in 7.1, the team will put the transmitters on a breadboard and send an audio signal to the receivers on the headphones. After the transmitters are tested, it is time to test the IR receivers. The IR receivers will be connected to the Stellaris development board. They will first be tested alone with the LEDs. If the Stellaris can pick up the pulse of the headphones, the team can then move on to the next test. If they do not pick up the pulse, then the team must test the software on the Stellaris or the software on the headphones. Another issue that could happen is the LEDs or the receivers are not connected properly. After the IR receiver picks up the LED, the whole system test can begin. The receivers will be connected to the Stellaris with the MUXs. The headphones will output their LED pulse and the receivers should take them in. The Stellaris will then find out which headphone it is and switch it to the MUX if the team can switch seamlessly between televisions using only the IR, then the test will be complete. If the team is not receiving sound, then it is most likely a software problem with the Stellaris and should be easily corrected.
The headphone tracking system is based on wireless Radio Frequency transmission so the team has a lot of different components when testing and debugging. The components will be divided into the HP module which is on the headphone, the MX module which is three triangulation modules, and the MX module which is the master triangulation module. The first step is to check the power input of the board. The idea is to use a multi-meter to check the voltage going into the Voltage regulators and the voltage coming out of the regulators. The idea is to have an input voltage that is at least 3V higher than the required voltage to regulate to. The LM7805 should have an input voltage of at least 8V and the output should read a voltage close to 5V. The team will measure this by taking the positive side of the multi-meter and plugging it onto pin 1 of the regulator, the black or negative side of the multi-meter will then be plugged into the 2nd pin of the regulator. This reading should be exactly or an approximation to the input battery power or the input power of the wall plugging AC-DC converter. The regulated voltage is measured by putting the red or positive side of the multi-meter to pin 3 of the regulator and keeping the ground in the same pin. The output should be close to 5V regulated. The LD1085V33 should have an input voltage of at least 6V but 5V volts should regulate just fine. The output should be a voltage of 3.3V. The team will measure this input voltage by plugging the positive side of the multi-meter to pin 3 of the regulator and the negative side or black side to the 1st pin of the regulator. The regulated voltage is then measured by living the black input in the same ground but by putting the red or positive part of the multi-meter onto pin 2 of the regulator. After measuring the voltages the main components are ready to be connected. The Atmega328 needs to be tested to make sure that it is sending correct data through the Tx serial port. To test this, the team will build a small circuit that converts TTL to RS232 which the team can connect in the RS232 of a PC and by using the hyper terminal of windows XP the team can easily see what the output of that TTL data is. The team can use TeraTerm if the OS used is other than XP. The TeraTerm software is open source software that lets interprets the data obtained from serial ports. The software allows developers to change to different baud rates, number of data bits, parity, stop bits, and flow control. The software works well with windows vista, and 7 that do not have the hyper terminal that Windows XP does. The circuit of the convertor from TTL to RS232 is shown below in Figure 29, 
Figure : Diagram to convert TTL to RS232 The team will put the signal in the TTL pin 11 input and put the signal RS232 pin 14 into the PC. The mac232 uses a couple of capacitors of 0.1uF to clean of the input power signal going into the chip. The idea is that serial data is very susceptible to noise so the team needs to clean the up the power and data as much as possible so the team does not lose any data in the wireless transmission. The team needs an RS232 cable that is able to receive data and a ground and transferred this signal to the PC. The idea is that RS232 has input and output serial but since the team only cares about input into the PC then the cable manufacturing becomes easier. The RS232 cable can be seen below (Figure 30) on how to make it so that it can easily be used with the board.
Figure : Frequency Modulation Analog Signal into RS232 Connection Since the team does not care about transmit data from PC the team can live that input out. The data from the Max232 will go into the Receive Data to PC. The Hyper terminal has to be set up with certain parameters before it can interpret the serial data from the serial RS232 port. The team firsts make a new phone communication line. The data will come from the RS232 serial com port which the Com number will have to be found from the device manager in the windows operating system. Then the team will choose the baud rate which in this case is 4800 and the number of data bits is 8. The team then will choose a flow control of none, a parity of none, and stop bits to be 1. The external read hardware is set to none. The team will then click ok which will initialize the communication with the Atmega328 or any serial input that the team puts into the circuit. If no data is able to be read the team should then check the signal output with an oscilloscope to make sure that the team is getting a square wave output from the micro-controller serial port with a 5V pick to pick serial square wave. If there is no output then the team needs to re-check the programming of the micro-controller to make sure it is configured correctly. If the team does get data then the team can try reading the serial data wirelessly. The XBee RF transceiver will be tested by using the XBee explorer pc dongle. The idea is that the team will connect an XBee transceiver to the PC which will then be read by X-CTU. The team does this to test if the Atmega328 is actually able to interface with the XBee module. The XBees will first be programmed as said in section 5.3. The team will first test the MX module message send to the HP module by checking to see if the XBee receives the different HP module labels in the terminal screen of the X-CTU software which should be connected to one of the XBees that will be used by one of the HP moduleren. The way to do this is by first plugging in the dongle into a USB port of the PC. The team will go to device manager in windows OS and find the COM port that belongs to the USB port that the team just connected the dongle to. Once the team has this information then the X-CTU software can be opened. The team can then change the COM port to the one found in device manager. The team will then set the baud rate to the baud rate being used which should match the baud rate of the XBees. For this test, 4800 will be the baud rate used. The team will then choose the amount of data bits which is 8, a parity of none, stop bits of 1, and a flow control of none. After doing so, the team can then click the “Test/Query.” If it does not find the XBee, the XBee will need to be taken out of the dongle and put it back in. If the XBee does show up, then click ok and go to the terminal tab. Once in the terminal tab, if the com port is not opened, the button that says open com port will need to be pressed. Once all of this has been done, the team should be able to see the serial data coming into the XBee in the terminal. After setting up the terminal for reading the serial data that arrives to the XBee in X-CTU, the team can then go and test the communication between the Atmega328 with the XBee. The serial port of the Atmega328 will be connected to the input Din port of the XBee module. Once this is done, the team should be able to see the serial data in ASCII code in the terminal window of the X-CTU. If there is no transmission then the team has to recheck the parameters selected in the X-CTU to make sure they are correct in the sense of having same baud rate, 8 data bits, no parity, no flow controls, and a stop bit of 1. If the team continues to get issues then it is a circuit board issue that has to do with bad connections or bad soldering which will have to be further checked. If the team does get transmission then the interface is working properly, so the modules can be continued to be tested. The group will have to test the RSSI line before the triangulation setup can be tested as a whole. The team will first read the RSSI line coming from the XBee with the oscilloscope. After taking notes on the signal, the team will then figure out if there is too much fluctuation or if there is too much noise. If there is too much fluctuation or change the code will need to be changed to take into account the changes of the RSSI line. This will then fixed the issue by adding a filter or threshold that will take out the less important values of the RSSI line. An average of the signal will have to be done to get a closer estimate to the real value of the RSSI line. The team needs to create a list of data that will help analyze these values depending on distance, vibration, and motion. If a pattern emerges, then it will be easier to come up with a general equation for getting the RSSI value approximation, if not then the team will have to attenuate experimentally. If there is too much noise in the RSSI line then the team would have to check the filters in the 5V and the 3.3V regulators to make sure that they are soldered correctly or to make sure they capacitors that make up the filters are the correct values. Usually when working with wireless transmission and RF signals there tends to be a big gap for noise. Hence, this is a reason to keep testing before and after signals to figure out the component that is adding the noise. After the team approves of the RSSI line and how it interacts with the Atmega328 works then the triangulation can be tested. The triangulation will be tested by turning the modules on since the team already checked that each part of the module works. The team will first turn on the MX modules and then add the HP module one at a time. The idea is to see the output from the HP Xbee to the Xbee on the tablet. The team will check this the same way that the serial signals have been observed. If the signal comes out with non-expected characters or if for some reason nothing is happening then the team would have to go back and re-check each of the components again. The idea of testing is to figure out where exactly the problem originated, and since wireless communication is being implemented, the system will have issues. Assuming that everything came out correct and that the triangulation worked as was specified, it can be concluded that the triangulation modules are a success.
|
