ECE 499 Poster
ECE499 Presentation
Software Feature 3: D/A and A/D conversion of wave data
A major design aspect of the software module which is essential to understanding the accuracy of the impulse response to the system is in the process of converting digital waveforms to analog, and recording the analog response with a conversion to digital.
This design problem was likely the most difficult to quantify throughout the term, with conflicting values of max sample rates for the AFM controller. Ultimately, values were found. The output waveform has a sampling frequency of 100KHz. The input waveform is 5MHz. This puts a limiting factor on defining the impulse excitation, as max are limited to their nyquist value, which is desired to be higher than 50KHz. For recording the input impulse response, their are not any design limitations posed with the 5MHz sample rate.
Software Feature 2: Low Level Asylum Code for Wave I/O
The next responsibility of the software module after a digital wave is defined is the output of the waveform to the desired AFM component. After scouring the Asylum framework, it is clear that the functions which work directly with the AFM controller and thus machine components are the “td_” functions. These functions are used in various purposes by the software, but generally speaking it is the driving force behind all AFM controller control.
For wave input and output, there is a “td” function which handles input and output of waveforms to various components of the AFM. “td_Xsetoutwave” and “td_xSetInWave” are the functions which handle input and output of waveforms built in to the low level operation of the AFM. They serve as the perfect vehicles for the needs of this project.
Their parameters specify which component will be manipulated, the sampling rate and interpolation desired, as well as a wave data structure (the definition and creation of which was outlined in the previous post). Together, these functions will provide the means to send input and record output signals from the machine. The output will be the impulse to the cantilever and tip, and the input from the machine is the system response.
Software Feature 1: Output Waveform Definition
On my list of the six major subsections of the impulse response software module. Here I will address some specifics about how this is implemented using IGOR framework and other features the built in software possesses.
- Feature 1: Define an output waveform in IGOR. To be used as excitation for impulse response.
Built into IGOR is the ability to define sine and cosine waves of various amplitude and wavelength. Using simple loop control flow available to the programming language, it is possible to create any wave desired. Another option for waveform definition is using the built in functions native to the language. There exists various noise signals. Furthermore, it is possible to import MATLAB files and use them directly in the program. Overall the challenges of waveform definition lie in how they will integrate with the low level Asylum framework, keeping in mind Nyquist theorem.
***Add some code
Update On Software Development: 6 Key Features
Through week 9 of Fall term, I had gained access to controlling the general functionality which this project aims to explore. This includes:
- Define an output waveform in IGOR. To be used as excitation for impulse response.
- Find a low level function within the Asylum framework which can output this waveform to the cantilever and tip.
- Recognize key parameters in the D/A conversion of this waveform.
- Identify parameters within Asylum framework to record the impulse response to this waveform.
- Recognize parameters in the A/D conversion of this response waveform.
- Find methods within IGOR for data analysis and export to other media.
In later posts, I will go into more detail about each of these six key aspects to the software module and how they are specifically addressed.
First Post: First Half of the Fall
Week 5 is here, and with it midterms and the harsh realization that senior year is flying by. Time flies when you’re having fun, especially when that fun is in the IRIS lab in the basement of Olin!
Union’s AFM, an Asylum research MFP3D model, is located in this remote nook. I have been trained on AFM operation and have outlined my strategy for designing and implementing a suite of custom functions for the AFM. I will post about the specific details of my progress with pictures and reflections at a later date, but for now it suffices to say that an initially daunting project has resolved itself to a task within my range of competence.
My weekly progress is being documented and discussed with my co-advisors Prof Catravas and Prof Dovidenko. These meetings are aimed to be reflective about my progress and challenges with recent work as well as formative in planning the next week’s goals.
So far, I believe that I have employed a consistent and efficient strategy to find success in the project. I will post the results of a small voltage/ microscope stage position program which will showcase my new ability to compile and run user defined functions on the AFM.