-
Notifications
You must be signed in to change notification settings - Fork 12
Jake and Andrew Project
Vector Network Analyzers are used to test component specifications and verify design simulations to make sure systems and their components work properly together. These devices are very useful during while designing circuits that have various components that must interact with each other. However, vector network analyzers are very expensive; in the thousands of dollars range. Dr. Frohne wanted to design and build a vector network analyzer that would provide accurate results while being affordable. For the past few years, he has been trying to improve his VNA design by assigning the VNA as a class project. Picking up from the progress made by previous classes, the goal has to been to reduce the noise during high frequency testing that is causing poor performance. The main attempts at a solution are a combination of hardware and software improvements.
This project has been in development for a few years now; being worked on by Dr. Frohne's "ENGR 357" classes each spring quarter. The project goal was to design, improve, and calibrate a "Vector Network Analyzer", VNA, device. The previous classes from years before had come far with their designs with each year improving the previous. Now, picking up where the previous year left off, testing needs to be done to determine how the VNA can be improved to be an accurate and reliable device as its purpose is a precision measurement tool.
In order to begin testing, a PCB from a previous design needed to be assembled and attached to an MSP432. Shown below is the schematic of the design and the PCB layout:
After the PCB was assembled, software testing was conducted as described below; however, the ref was not receiving any information. First, the software was checked to ensure it was properly configured since it was possible that the data being sent to the board was not reaching the ADC due to not being configured properly; however, this didn't seem to be the case. Since the software seemed to be working properly the next step was to test the PCB at each test point. Testing showed proper waveforms on the oscilloscope at the first two test points and on the oscillator itself. However, when testing the pins on the mixer, the results were not as desired. It was found that there was a two solder bridges on the mixer and one solder bridge on the other mixer. Once the solder bridges were fixed, the correct data was now being measured in CCS.
The board needed to be tested after the build was complete to verify it was assembled correctly. Since the PCB is driven by the MSP432, which is a Texas Instruments development board, "Code Composer Studios", CCS, was used during software development. To get started, an "Energia" sketch designed by Dr. Frohne was imported to CCS, this allowed CCS to know exactly how the MSP432 development board is configured and its exact specifications. This is important because when writing code for the MSP432, if a specific component or GPIO pin is referenced, CCS needs to know where and how to send signals to the specified references. Next the MSP432 with the PCB attached is flashed with the VNA program designed by Dr.Frohne and the previous class. This software tells the MSP432 how to interact with any information that it receives and how to interact with PCB. To ensure that the PCB was assembled correctly and the software was properly flashed, an "Octave" script was run, which sends data to the VNA. To check whether the VNA is receiving the data, the ADC on the MSP432 can be measured in CCS. The ADC input is known as "ref" in the VNA software. During initial testing, the ref can be plotted in CCS and should look like a sine wave; showing the device was assembled correctly and properly flashed. After being properly flashed the octave script serial_test_time.m can be run to produce graphs such as the ones shown below. One for the measured channel and one for the Reference channel.
After building the PCB, fixing hardware issues, and the first run of the software was done. Measurements were taken using the python script TestTime.py on the revision 0.4 board. It was found that the measurements were not very repeatable. This sparked testing revision 0.4 for the accuracy of the ADC, noise from processor or other source, aliasing, and using windowing functions in the fft.
The first test that was done was to determine the accuracy of the ADC converter. This was done by putting a DC power supply into pins A14 and A13 on the MSP432P401R. Then running a python script to run the command (^TIME,1000000$) and collect data from the MSP. Using the data it sent back a standard deviation and average were found at various input voltages and are outlined in the table.
Therefore it was concluded that the ADC was not the issue since it was giving such accurate readings.
The power supply had a very low impedance which is not reflective of our board. Therefore it was a good test for the accuracy of the ADC but not very characteristic of our board. The next test to be done would be to use a 50 Ohm sinusoidal source at frequencies varying between 0Hz to 600Hz in order to see how well the ADC will perform under conditions closer to that of our board.
The simplest source of noise that we could think of was noise coming from the processor. Since the board is mounted above the MSP432 and many of the low pass filtering components are on the bottom of the revision 0.4 board it is possible that clocking frequency of the processor was leaking into the low pass filter. To test this theory a grounded piece of aluminum was placed in between the processor and the bottom of the board. One test using the python script determined that there was a slight improvement. It was not investigated further as changes to the new board would just include moving all components on the bottom of the board to the top of the board. This was a very easy implementation and can be seen in revision 0.5.
The use of the aluminum foil shielding proved effective. Therefore, all components on the bottom of the board were moved to the top of the board to better establish a ground plate on the layer closest to the MSP432 processor.
The investigation of the aluminum foil test were not very extensive so for the future perhaps more concrete evidence could be found.
A ferrite bead or ferrite choke is a passive electric component that suppresses high frequency noise in electronic circuits. Ferrite beads employ high frequency current dissipation in a ferrite ceramic to build high frequency noise suppression devices. The use of a ferrite bead in the context of this board was to employ its high impedance properties in higher frequencies in order to supplement the low pass filter that already exists on revision 0.4. The beads were meant to reduce the noise coming into the ADC as well as any other place noise might occur. However, these ferrite beads were not a cure all as the values for them had to be chosen in such a way that targeted the noise frequencies we are experiencing. Due to a lack of time these values were not chosen specifically. Instead, a common value was used. Below the graphs of revision 0.5 can be seen which include the measured and reference channels.
It is concluded that the ferrite beads did help; although not as much as expected.
Investigate the correct value for the ferrite beads that targets the undesired frequencies.
During testing with the Spectrum Analyzer, we found at 500Hz, the aliases align with the sampling frequency(8000Hz); this will cause poor measurements. This occurs because we are digitizing an analog signal and analyzing it in a Fourier analysis, the power contained in the frequencies above the Nyquist Frequency (half the sampling rate) of 4000Hz are added to the lower frequency components. These aliases are indistinguishable from lower frequency noise. To fix this problem, we worked with Dr.Frohne and changed the IF frequency up and found 155Hz to be much better. By changing the IF frequency to 155Hz we were able to decrease the effects of aliasing.
Changing the IF frequency improved our results significantly since 155Hz aliases don't align with the sampling frequency.
Although 155Hz had a great improvement in results, we still recommend that more testing be done to find the absolute optimal IF frequency by comparing the standard deviation of repeatability for each IF frequency tested.
After changing the IF frequency, we looked into using different window functions in in order to clean up some wide harmonic peaks. For window testing we wanted consistent results to compare to our other improvements so we used the orginal PCB during window testing.
It appears to us that the Hanning window provides the best results. Thus, we will be using the Hanning window for future testing.
As future designs change and different frequencies are used, we suggested revisiting each window function to ensure you're getting the best results.
Our new board design had to include the implementations of how to fix the each of the issues that were potentially causing the non-repeatable measurements. To better implement the noise from the processor the components that were on the bottom of revision 0.4 were moved to the top. Then, to prevent noise getting into the ADC ferrite beads were placed in series with the input of the ADC. The rest of the changes were done in software. The hardware changes can be seen below.