P13071: Non-invasive Blood Glucose Monitor
/public/

Build, Test, Document

Table of Contents

Following the design process began the build. Over a period of 6 weeks we assembled our PCB with surface mount components, troubleshot each sub system of our board, and validated all code related to the operation of our device.

Build, Test, and Integrate

Build

The build process itself took approximately a week to complete and was executed using the SMT lab located on campus. Using this lab, we were able to mount all surface mount ICs and also verify that all connections to the chips were good.

Test

Each sub system of the device had to be tested and verified before the device itself could be tested.

Power Regulation

image:Photo Gallery/Power System.JPG

It was found that our voltage regulator chip did not support the amount of current required for our system. As a fix for this, we removed the chip and decided that the best solution would be to power the board from a power supply set to 3.3 volts. We also found that the inductors used to separate the power planes and ground planes had nearly 20 ohms of resistance, which resulted in inconsistent voltages provided to our board. To remedy this, the inductors were replaced with shorts.

Microcontroller

image:Photo Gallery/Micro System.JPG

In order to verify the proper operation of the microcontroller, we used a JTAG interface to connect the device to TI's Code Composer IDE. We were able to successfully communicate with the MCU and run simple code that flashed LEDs to verify that the MCU was working properly.

USB Interface

image:Photo Gallery/USB System.JPG

The USB interface was an integral part of our device; without it, communication and processing via the host PC would not be possible. Upon testing the USB interface several issues were discovered. The first was that the USB connector had the Power and Ground connection backwards. After fixing this issue, we then realized that the RX and TX UART connections between our MCU and UART-USB bridge were flipped as well. After fixing this, we were able to verify that the device could send and receive data through the USB connection from a host PC utilizing RealTerm and sending arbitrary data and verifying that the MCU registers received the correct data.

RF Synthesizer

image:Photo Gallery/RF Synth System.JPG

The RF Synthesizer proved to be the most difficult system to test because there were many configuration values that could be set on the chip and specific settings were required in order to get the desired output. We were able to verify that the MCU could communicate with the RF Synthesizer via its SPI connection by toggling the output of one of the pins; however, we were unable to set the desired output frequency of 800 MHz. In order to debug this issue, we purchased the development board for the ADF4351 and set about determining exactly what configuration values had to be set in order to get the output. Finally, we determined the correct configuration and were able to verify using a Spectrum Analyzer that we were setting the correct frequency of 800 MHz on our device.

RF Path

Testing of the RF Path consisted of verify continuity throughout the path using a digital multimeter. We then verified that the MCU was correctly controlling the sets of RF switches so that the output could be directed down the correct path.

Vector Measurement System

image:Photo Gallery/Vector System.JPG

The last system that was tested was the vector measurement system utilizing the AD8302 magnitude and phase measurement chip. To test this chip, we input a 20 MHz sin wave into the input A and input B pins and measured the magnitude and phase output from each chip. As expected the output of each was ~0.9 Volts indicating 0dB and 0 degree phase shift. The ADC register was then verified in the MCU to be the correct value to ensure that we were measuring the signal correctly.

MCU Code

The MCU code was tested throughout the testing of each individual subsystem. As bugs were found in the code, they were immediately fixed so that testing could continue. Overall, the modular design of the software allowed for quick fixes to be easily implemented in a singular location and without much difficulty.

MATLAB Code

image:Photo Gallery/MATLAB GUI.JPG

The MATLAB Code which runs on the host PC was one of the final things to be tested once all other sub-systems and software had been verified. Using the MATLAB GUIDE GUI builder, we were able to quickly bring up the GUI and implement the sweep functionality. Using the plots within the GUI, were able to verify that the device was in fact sweeping.

Test Plans & Test Results

Test Plan

After verifying each sub-system we realized that something was not functioning correctly with our device. We were never able to get the correct resonant frequency of our antenna. In an effort to trace the route of our problem, we connected our device to the network analyzer and found that our RF path was not matched for to 50 ohms, and we could therefore not use it to determine the resonant frequency of the antenna.

Home | Planning & Execution | Systems Design | Detailed Design | Photo Gallery