wumrc / drive Goto Github PK

I want to modify changeVal function because your implementation requires redundant computations. I modified and optimized the calculation, but the problem is that you are working on this file and it is not reflected until you modified this function on your local file.
Thus, I request that you should reflect this change.

void changeVal(long value, uint8_t *fVals)
{
  fVals[5] = value % 100;
  value /= 100;
  fVals[4] = value % 100;
  value /= 100;
  fVals[3] = value % 100;
}

The code in AD5933_Library--AD5933.cpp, Line 29:
tTempVal = (tTemp[0] % (12 * 16)) * 16 * 16 + tTemp[1];

I think the author want to extract the lower 5 digits in tTemp[0], which means the D4-D0 in 0x92. However if use tTemp[0] % (1216), it is possible to extract the D5-D7 digits. For example, if the tTemp[0] = 0100 0000, the tTemp[0] % (1216) = 0100 0000, more than lower 5 digits.
I think this might be better:
"tTempVal = (tTemp[0] % (4*16)) 1616 + tTemp[1]"
or
"tTempVal = (tTemp[0] & 0x1F)1616 + tTemp[1]".

The function for setVolPGA has a slight error. The control register values for Range 2 and Range 4 are inverted. From the datasheet:

I'm going to rewrite the function to just setPGA and use setRange to set the output range. I.E, have different functions for each change to the AD5933..

@itkwon
I was confused on which one of the setCtrMode() functions to use. I assume the one with a single byte argument?

Also, am I right in guessing that the byte input actually starts as a string of the command (e.g. REPEAT_FREQ) which the function then converts to a byte to send to the control register? I've just never seen an input conversion like that before.

The function used for the per pixel tracking function currently relies on a filter matrix being passed to it, when it should instead rely upon a few commands.

For example, AD5258::readRDAC() doesn't return anything... needs "return" keyword before read8()

Hi there,
When I run Z logger I can get temperature but then it will stall. Is there something that you are supposed to do apart from press p to do calibration?

I am having issues measuring impedance using Z_LoggerComplex. My setup is pretty much the same as the one in the calibration thread (fritzing) but with a 5934 and 16 Mhz coming from a funcgen. I've also commented out the temperature read portions. After attaching 98kohm resistors to Rfb and Rcal, I went through the calibration procedure (pressing p and enter twice). The serial monitor reported a gain factor of 17690708.00 and a phase shift of 2.00. Here's a quick compilation of results with a variety of resistors:

Ractual: Zmeasured
inf (no connection): 100000
940k: 18100
98k: 1844
21.3k:1246
1.028k: 1080
324 ohm: 1081
10 ohm: 1081

Looks like I'm not calibrating correctly. How should it be done?
I've gone through Analog's CN-0217 document but nothing odd sticks out to me. Any other issues with my setup?

Dear @tunjid ,

I looked through your library, and I figured out that you added some function to change the voltage of the pulse for measuring the impedance. Did you ever tried to change the "Range?" (and measure?)

According to the datasheet, the error introduces generally by difference between the internal impedance of AD5933 (depends on the "Range") and the impedance to measure.

I think that, based on current impedance range, you can try 2Vpp or 0.2Vpp. (In addition, 0.2Vpp shows 0.15mA. It means that it works with potentiometers!)

If anyone have something to comment regarding my question, feel free to post here.
Thanks.

I spoke too soon about Z_Logger working consistently. When no load is placed across Vin and Vout (pins 5 &6), the impedance increases dramatically (as expected). However, when I try another resistor (e.g 10K, 1K), I get results near the calibration resistor value. I'll add some checks on the measurements after the gain factor calculation.

@itkwon
I'm getting conflicts now as I try to upload my latest code and I'm seeing extra changes. We should coordinate tomorrow.

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

@itkwon

I installed your library (AD5933.cpp and AD5933.h) into my local instal of Arduino, and received these errors from the compiler. I might be able to debug them myself, but thought this might help you with final tweaks. Please let me know if I need to include other libraries first.

In file included from Z_Logger.ino:38:
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:13: error: stray '\302' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:13: error: stray '\267' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:268: error: stray '@' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:570: error: stray '\342' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:570: error: stray '\200' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:570: error: stray '\230' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:570: error: stray '\342' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:570: error: stray '\200' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:570: error: stray '\231' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:615: error: stray '\342' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:615: error: stray '\200' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:615: error: stray '\246' in program
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:6: error: expected unqualified-id before '<' token
C:\Program Files (x86)\Arduino\libraries\AD5933/AD5933.h:774: error: expected unqualified-id before numeric constant

According to the user manual, the AD5933 chip provides "block read" function for reading a block of data. However, directly using this function seems no use in arduino. In AD5933 Files--Deprecated AD5933 Files--AD5933_Single_Temp, it provides a single test towards AD5933. In part 5:
//[5]-- Read the stored temperature data.
Serial.println("Checking temperature data registers...");//Send status message to the serial monitor.
Wire.beginTransmission(0x0D); //Open communications to to AD5933.
Wire.write(B10110000); //Send the "pointer" commmand.
Wire.write(0x92); //Send the address for the pointer (first temperature data register).
Wire.endTransmission(); //Close communications.
Wire.requestFrom(0x0D, 2); //Request the data byte stored in the register the pointer is at.
register_0x92 = Wire.read(); //Store the first byte in a variable.
register_0x93 = Wire.read(); //Store the second byte in a variable.
Serial.print("Temperature register 0x92 set to: "); //Display the data via the serial monitor.
Serial.println(register_0x92, BIN);
Serial.print("Temperature register 0x93 set to: "); //Display the data via the serial monitor.
Serial.println(register_0x93, BIN);
//--[3]
The code directly asked for 2 bytes data from AD5933: Wire.requestFrom(0x0D, 2); Then use the variable register_0x92/register_0x93 to store the data. I found that only the result in register_0x92 was correct, the register_0x93 maintained same (usually 0xCE at around 22℃) instead of change with real temperature.

I think the Wire library in arduino only allows us to read single byte every time.

Some folks using this repo have turned it into quite a mess with virtually everything kept in the root directory. Please put things in a better order or I will do it for us all.

Just curious as to why getGainFactor() returns the inverse of the gain factor as used in the datasheet. Or did I read that incorrectly?

I see the AD5933 library has a function to set the settling time number of cycles, but there didn't seem to be a function to calculate what number of settling time cycles to tell the AD5933 to use for a given operation.
Is this needed? I'm guessing there are rules of thumb, but it may be hardware dependent (i.e. require a finished device) to pin down exactly?

@itkwon
My code works until it tries to run getMagOnce(). I think this is because the getStatusReg() function never returns the value it expects. Two questions:

1. Should the bitwise AND (&) be replaced with a compound bitwise AND (&=) when you check the register to see if it equals 0x02?

while((getStatusReg() & 0x02) != 0x02) --> while((getStatusReg() &= 0x02) != 0x02)

Also, I don't understand why you use a bitwise AND with the getStatusReg() function...

return getByte(0x8F) & 0x07;

The default Arduino SoftwareSerial library proved to be non-tolerant with simple libraries when used for BLE communication, even more so with fairly complex libraries on top of that.

We switched to Paul Stoffregen's AltSoftSerial library and things have been great... till now. From the documentation:

Interrupt Latency Requirements

AltSoftSerial can withstand approximately 1 bit time of interrupt latency from other libraries or functions. Most libraries, HardwareSerial, and the millis() timekeeping interrupt are designed to minimize CPU time spend executing interrupts or accessing data with interrupts disabled.
However, some libraries may disable interrupts for longer than 1 bit time. If they do, AltSoftSerial will not work properly. If you discover erroneous results from AltSoftSerial, please try testing without other libraries.

SoftwareSerial would break with relatively low complexity I2C communication using Arduino's Wire library, it proved impossible to use with the AD5933 library for similar reasons.

AltSoftSerial works very well in this regard, but as we begin to write multiple sampling rates and frequency sweeps that request timer interrupts and reset commands to the AD5933 more frequently, the time window for interrupts to be handled shrink considerably.

With the sketch BLE_Debug_Timer that just carries a psuedo sine signal, setting a sampling rate of 90 Hz is no issue. Z_BLE_3 however that has to measure and send impedance values, breaks at sampling rates over 80 Hz and completely garbles serial communication with AltSoftSerial library, you only need to look at Arduino's serial monitor to see the gibberish it spouts and functions it calls that it really shouldn't.

We therefore probably need to move to the Arduino Mega for development and use the multiple hardware serial port it provides for BLE communication.

All this of course is a working hypothesis, I will be testing my claims tomorrow in lab, but I'm fairly certain they're right from past experience with SoftwareSerial and AltSoftSerial.

On we go again.

One of the current failings of the perPixelTrack function is its inability to correct/compensate for drifts and large net motions.

HI itkwon
Could you please share the connection diagram between ad5933 and arduino?
Thank you.

While the calibration sketch works as it should, there's the issue of not knowing exactly what resistor combination is engaged from the digital rheostats r1 and r2 at any one time.

The ideal case with each wiper position increasing linearly does not correspond with measured values from a multimeter or the LCR. The LCR at a fixed frequency (20 Hz) was then used to create a lookup table for each step for both rheostats. The Lookup tables are in the "Text Files" folder under Analysis/MATLAB. The data generated with this lookup tables is in the same folder with the name "Test".

After a brief test run, The values computed using the lookup table in the ideal model does not correspond to measured data by the AD5933. This is in contrast to previous tests with discrete r1, r2 and capacitor values measured by a multimeter.

I currently have two reasons this may be:

1. The lookup table generated from the LCR at 20 Hz is bad, and does not match the actual values from the rheostats.
2. As Il Taek mentioned in a previous issue, the AD5933 has to be used in Range 4 so the current injected is below 5 mA. This is because the rheostats are rated to an absolute maximum of 5 mA flowing through it continuously. Range 4 has an output impedance of about 600 Ohms, which is 3 times higher than Range 1 (The range used prior) whose output impedance is 200 Ohms. This should lead to a higher rate of accumulated errors as Il Taek pointed out.

The case may even be a combination of both reasons. As of right now, it needs to be ascertained what exactly the issue is before calibration can continue. My current plan is to somehow interface the LCR with the rheostats the same way I currently have the AD5933 and measure the rheostat values both with the LCR and AD5933.

The biggest challenge here is the software that can control both the LCR through the GPIB interface while simultaneously controlling the rheostats via i2c. LabView and Visual Basic are the current choices I have been able to narrow down so far, with my preference leaning towards Visual Basic.

Suggestions are very much welcome.

In the wiki, please just verify the input units of setStartFreq(long). I'm assuming it's just Hz based on the conversions used in the formula.

I just saw his code with using MSTimer library to coordinate the sampling frequency.

I think the incorporation should be done later after his code is completed. I can work on manipulating measurement cycles to modify the sampling time, but it is not sufficient.

After looking after his code, there is a some routine with if statement, if the writer is true. I saw that it is true when the timer is activated. I think the code for measuring impedance should be inserted in there.

Also, I need to work on to find a right cycles to measure the signal, and find a way to incorporate by modifying the library.

I want to know how the Arduino code know whether the acquisition rate is changed.
Is the change just affects within the Android device? Otherwise, the Arduino side know in some way?

getMagOnce(), which uses getMagValue(), only polls the registers for the real and imaginary data stored from a previous measurement and does not send a fresh "repeat frequency" or "increment frequency" command to acquire new data, right?