WuMRC/drive

Errors in returning Real and Imaginary values

Closed this issue · 23 comments

Hello @itkwon .

It appears there are some errors when using the getComplexOnce(double gainFactor, double &realComp, double &imagComp, double &ZVal) function.

While the overall magnitude of the impedance measured seems correct, the values of the real and imaginary components are wrong. Specifically, the size of the imaginary component is too big when compared to the LCR meter in lab. This results in phase shifts of -0.93 rads or so for regular resistors when they really should be in the order of micro-rads.

Please look into it.

@barrybelmont: AD5933 product guide: http://dkc1.digikey.com/us/en/tod/ADI/AD5933_NoAudio/AD5933_Noaudio.html

I know that the components are shown as you described. I think I need to measure this again with LCR meters, the development board and the AD5933.(Double Checking) It might stem from the electrical properties of measurement time (I am not sure), and it might take a lot of time to inspect the reason, to verify which is true, and to fix. (If it is true.)

The other possible reason is if my formula in the library is defective, if it happens, It can be done in (up to) a week.

Anyway, I will work on this problem tomorrow. Thanks. (I might read your document today if I have a time.)

I read the last document, and it says just broad introduction and things in the datasheet.

Oh, yes. I know you know what's on there, the link was for Barry.

If this document is for Barry, please do not post it on my issue. Just send an e-mail to him or post another article to deal this. Posting multiple topics make readers confused.

Il Taek. I had asked TJ to post this bug and to post that document for my reference. Two birds, a stone.

Okay. Sorry about that, TJ.
However, it made me confused, but thank you for notifying me.

2014-10-15 11 35 53
FYI: The reason might be the system inherent phase to be calibrated. Further investigation necessary.

No problem Il Taek.

Figured out that the gain factor and the system phase shift differs in the frequency.

TODO

  1. Develop calibration method with different frequencies. (Skipped, analyze linear model first.)
  2. Develop a linear function model for the gain factor and the system phase shift, which are the functions of the frequency.
  3. Develop two-point calibration method to get Gainfactor and phase shift.
  4. (Near Future) Develop a solution for multiple calibration setting for more accuracy. (Using multiplexer.)
  5. Research appropriate MUX (Probably ADG709)
  6. Order Breakout board
  7. Program it!

System Phase Shift is a linear function of the frequency.
Gain Factor is a polynomial function of the frequency, but the approximation in a linear function is also available.
Thus, two-point calibration is best I think.

Hi @itkwon

On the data sheet, the linear approximation was shown for a 10 KHz frequency range (55 KHz - 65 KHz, interpolated for a value at 60 KHz).

Is it possible to repeat the frequency response curve for 10 frequency ranges, each of range size 10 KHz? That way we'll have 10 functions to cover 0 - 100 KHz that we can then fit a curve through to get our gain factor for a particular calibration resistor. In this case 554.72 Ohms.

The gain factor will then be one function defined by the curve obtained as described.

  1. I cannot find what you mentioned. Could please refer the page number or phrase you mentioned?
  2. Yes. We can implement this. However, it might be a redundant process. I think just two point is sufficient to make a linear function.

There is some trade off between calculating calibration factors and remembering this.

  1. Calculating calibration factors can minimize memory space because it do not require array of the gain factors and phase shifts.
  2. Calculating those can impact execution time because every time we need to calculate it. (I might be solved if we calculate once to save at array.)
  3. Gain factor is not a linear function of the frequency. If we calculate, it might result in inaccuracy.

Actually, I am working on implementing two-point calibration to get a function. (Also, I am working on the calibration with using array, too.) Due to my schedule, I might work on again after Wednesday 5pm. Sorry about that.

I need to restructure the library, and test those function to work properly. I am sorry again.

It's on page 18.

The major downside to two point calibration is the range over which the function is linear. In the example provided on page 18 in the data sheet, the frequency response was approximately linear over a 10 KHz range; it likely won't be over 100KHz.

The array method is good too, but I share your concerns about memory allocation.

However, if we had a curve that described the frequency response over a 100KHz range, when prompted by the Bluetooth communication from my end with the start frequency, step size and number of increments, an array can be dynamically created with a size specified by the number of increments + 1.

The array would then contain the gain factors described by the function and save them. This would need a calculation only once; when the Bluetooth triggers a change in frequency parameters.

This would solve the issue of repeated calculations and unoptimized memory allocation.

What do you think?

  1. To solve your concern about how the gain factor and the system phase shift, I am now doing experiment about how they differs in the frequency. I might offer intermediate result if you want.(https://umich.box.com/s/ekcwukpqzl8vuoj8rq7l) I estimate that the function is linear until 100kHz range.
  2. Array method with measuring whole or calculating do not make difference in memory allocation.
  3. I suspect that you think the behavior of the system phase and the gain factor is non-linear. However, on the experiment (I will do some more to clarify.), the system phase is definitely linear, and the gain factor is "close to" linear. If you want to get 10 curve data to perform estimate, we can do it, but I think it is "overkill."
  4. I read you mentioned, and understood. What they did is just an example. There is no guarantee about the frequency duration to perform two-point calibration.
  5. I think we should have time to discuss your questions briefly. (We might set up time.) I think something we think is not clear or the definition in our minds are slightly different.

Finally, Implemented complex sweep and calibration. However, there are some issues.

  1. Two-Point calibration might result in some inaccuracy.
  2. Multiple calibration might result in inaccuracy. (Now tracing the cause.)
  3. Speed might be slower due to the usage of trigonometric functions.
  4. I might use alternative math function with look-up table mathod.
  5. We might send magnitude and phase to calculate values in Android Phone.

Next, we should incorporate them into main program.

That's excellent! Can't wait to try it today.

@itkwon Could you distinguish between

GetGainFactorC,
and
GetGainFactorS_Set, GetGainFactorS_TP

You've described the difference between GetGainFactorS_Set, and GetGainFactorS_TP, but I'm not sure how they differ with GetGainFactorC.

Also in the new Sketch Z_Logger_complex, you call the following:

AD5933.setStartFreq(start_frequency);
AD5933.setIncrement(5000);
AD5933.setNumofIncrement(numofIncrement);

However in the loop function you have the AD5933 control mode in REPEAT_FREQ.

Does this sketch perform frequency sweeps? If not, how have you implemented the procedure within the library?

Thanks.

@itkwon We need to meet to discus the implementation of the frequency sweep.

The current implementation of AD5933.compFreqSweep(params) saves the value for each sweep into an array. The problem is during this process, as each value is written, I can't access the values as they are generated and write them to the BLE device. Also the sample rate rate will have no meaning in this context (Arduino loop context) as the flag for sampling rate is changed from interrupt context and I have no idea the amount of time it takes to populate the array, nor have any control over it.

I think what we may have to do is change the frequency at each step in the process when the flag is generated. In other words; right now for a specified repeating AC frequency, at a sampling rate of 50 Hz, the Z_Value and phase shift are generated at 50 Hz...

...however, if we're using a frequency sweep with a sampling rate of 50Hz, start AC frequency of 10KHz, with 4 increments at a step size of 10 KHz each (max AC frequency of 50 KHz), then each unique Z_Value associated with it's unique AC frequency should be written at a rate of 10 KHz.

Are you available tomorrow? Sorry for the short notice.

@barrybelmont Is what I proposed above for data acquisition during frequency sweeps acceptable?

Thanks.

  1. I think I need to document those new functions later. However, I will explain sample code later.
  2. Z_Logger_Complex is a example of data acquisition mode in same frequency.
  3. compFreqSweep(params...) is designed to perform frequency sweep, and get data at one time. If you want to acquire one data, send, and proceed to next frequency, I might need to devise new process in library, and you need to understand how it works.
  4. Honestly, I cannot understand most of your words. You can change the settings of frequency sweep. (but it takes a time with communication overhead.)

Hi @itkwon

I wrote a function that uses linear interpolation to calculate the gain factor and phase shifts and it seems to be very accurate. I first calculate the gain factors and phase shifts at the start and end frequency, find the slope of the line and use the slope to calculate the values at all other points of interest.

It's based on yours, so it shouldn't differ much, but I used it to test as I know the inner workings of it better.

Could you take a look at it? I've linked it here: Link to function.

We finished this issue on several months ago. We developed the solution and debugged it as TJ mentioned.