With this project I worked with four other students to build separate wireless communication boards. The end goal was a device based off of an ATMEGA256FR2 Xplained Pro that would communicate between the different boards using ZigBee.

My responsibility in the project was to the design the circuitry to connect the board to a PC's serial port and to take everyone's schematics for their sections and combine them into one project. We however did our layouts and assembly separately.  This layout ended up being a little more trickier than that of my OBD-II Scanner. However I think this layout ended up better. I did notice after that I put some decoupling capacitors unnecessarily far away but I had the shortest distance to the antenna from the transceiver and the least number of vias.

For the assembly of the device I had the PCB tracing done externally but did everything else myself including soldering of parts in a reflow oven. During assembly it became apparent to me that one of the team members had made a mistake with the footprint for the debugger chip. Without that chip it became impossible to program the device trough USB. The device however could still be programmed through the serial port and powered by the USB. I didn't get around to programming however as a I ran out of time. The device should function as intended though once the short is found as the device is based on closely on the Xplained Pro.

This project allowed me to learn more about wireless communication, specifically ZigBee and the QPSK modulation scheme it uses. It especially opened my eyes even more to how important what I learned in linear systems analysis was to communication theory. Also since the continuity and coordination of the team I was working with wasn't as great as other teams I had been in. It gave me a great opportunity to learn about team coordination and management.

For this project I designed a LabVIEW program that can communicate using UART through a computer's serial port at a user defined baud rate. I started out by making a product brief  to set my goals and clarify what I was doing to my professor.  In the LabVIEW VI I put some preset commands that would send a preset command and parse the data sent back. These were commands specific to an STN1110 or ELM327 chip used to interpret between UART and various OBD-II signal protocols. However the raw output would still be displayed. Custom commands could also be sent to but the output would be as it is and not parsed. The program would run continuously and would stop when told to stop. This project allowed me to learn about designing LabVIEW VIs for testing that not only worked but were neat and commented.

I worked on a device with a mechanical engineer during undergrad that communicates with a 1999 Subaru Forester through the OBD-II port. The design goals I made at the beginning called for a device that could display different bits of information about the car and be easy to operate.

To do this my partner on I decided to set a reasonable size of 60 mm x 60 mm for the main PCB based on the size of components, available manufacturing abilities, and space constraints. My design called for the use of an STN1110 interpreter to translate between the ISO 9141-2 protocol of the Subaru and UART. For the microcontroller I decided to go with the TI MSP430G2553 as it is common and has a high voltage of 3.3 V. Since the STN1110 has a VDD voltage of 3.3 V I was able to simplify the design by only needing to put in a 3.3 V voltage regulator and not both 3.3 V and 5 V. Also on the PCB is a push button to cycle through commands, header pins for programming, and pins for output to a 16x2 LCD.

For the most part I tried to stick to using surface mount components, especially components in the 0603 package. But I had to use some through hole pin components and some non standard sized components which required the creation of custom footprints. Upon arrival the bare board and components I milled my own stencil, applied solder paste, and placed the PCB in a reflow oven. However afterwards an electrolytic capacitor was found to be off its pad and there was a also a missing connection with an IC, both of which were fixed with some hand soldering.

The device however didn't function as intended and I was required to troubleshooting. This included carefully looking over the datasheets to see how the components should be functioning and checking this against the actual device with an oscilloscope and multimeter. With the oscilloscope I checked to see if signals were actually being sent and if the STN1110 was functioning by checking the oscillator. I also checked the manufacturers forum for help and contacted them through their forum about my design. My design was confirmed to be a valid design for their chip to properly operate.

The device was able to display text on the LCD screen and send commands to the STN1110. However no response came back from the STN1110. The STN1110 was also supposed to send out a message over UART upon being awoken, but failed to do this. I decided to create a prototype on a breadboard using the same design. This design made it farther by having activity of the K and L lines used by the ISO 9141-2 standard and sending the data back over UART. The data returned didn't make sense however. I checked to see if it was the programming by adding a level converter and connecting the STN1110 to a PC through the serial port. This ended with similar results.

From this project I learned a lot. For one I learned about project management. In order to make sure my part was getting done at times that meshed with my partners we had to plan things out and make sure we were on the same page. I also learned that even the best laid plans can go bad and that when this happens it's an opportunity to learn more than you would have had things gone as planned. I also got more experience with schematic capture, PCB layout, and troubleshooting. I also was able to get exposed to related things such as the different OBD modes of operation, other protocols like CAN, and how ECUs are used in a vehicle.