PGA305EVM-034: Computing Calibration coefficients

Hi Igor,

The GUI algorithm may have slightly different results than say the DLL that was mentioned in the other post.  The reason is the computation can actually have multiple possible outcomes with the differences having better linearity fits.  Within the firmware, the values in the EEPROM are all normalized to 2^22.  In the referenced post the EEPROM values are scaled to 2^30 when comparing coefficients.  The reason for this is difficult to explain, but the end result is the final DAC computation is right-shifted by 8 for the final DAC output.  This then requires the start of the computation to be 2^30 (22+8) for the EEPROM settings.

As to the computation when trying to determine the correct coefficients, the actual computation in firmware (in the 3P1T use case) first takes the pressure measurement, and depending on the OFFEN setting in the EEPROM, multiplies the digital gain setting from EEPROM (PADC Gain) times either the pressure conversion code and then adds the offset PADC Offset) or multiplies the gain times the combination of the conversion result code and PADC Offset EEPROM value.

So to think about the computation in the most simplest of terms, the h0 coefficient directly relates to the offset and the g0 relates to the gain.  Keep in mind that the h0 term is after the initial computation of the previous paragraph.

So the PADC value you show in your equation you provided is after the computation of the digital gain and offset that are applied from the EEPROM values.  A couple other considerations are the EEPROM values are binary two's complement values.  So the GUI may calculate negative coefficients.  Also when comparing the GUI to coefficients you calculate you must make sure that the values are in the same numeric values.  This means the values you calculate and determine as coefficients must fit into a value that fits within the 24 bits of the EEPROM values (when multiplied by 2^30).  The last thing is to ensure that the values do not overflow within the firmware as 32-bit signed integers.  That is why the values internally are normalized by 2^22 within firmware.

The last thing I wish to mention is the outcome following the computation must be a positive value and it must fit to 14-bits as that is the resolution of the DAC.  If the value is negative the DAC output will be 0.

Best regards,

Bob B

Hello Bob,

Thank you for your response.

However, your response is not answering my question.

It is understood that there may be different ways and results to get calibration coefficient.

I do understand that ho is the first term of second order polynomial.

My issue is that there is no ONE scale factor that work for all 3 coefficients (h0, g0 and n0).

I have chosen the case that has only one valid solution:

When 3 reading are taken and 3 coefficients are computed è there is only 1 valid solution of 3x3 linear system.

Image that I attached show that “g0” coefficient has scaling of 2^30 (this is the second term).

However, “h0” and “n0” do not scale to 2^30.

Please help me understand how to correctly scale, determine correct PGA305 coefficients:

Measured 1T3P data is shown in table below:

I computed calibration coefficients and compared with coefficients computed by PGA305 GUI.

Equation: DAC (decimal) = h0 + g0*PADC + n0*PADC^2

Single Solution coefficients (show prefect calibration with ZERO error): 

h0=8132.309438

g0=0.00136606

n0=1.28E-12

PGA computed GUI coefficients:

h0=1FEEBD (DECIMAL 2089917)

g0=1661AC (DECIMAL 1466796)

n0=FFFE46 (DECIMAL -442)

TADC GAIN=1

TADC OFFSET=0

PADC GAIN=1

TADC OFFSET=3CA0 (DECIMAL 15520)

There is no direct correlation to h0, g0 & n0.

I have seen that somebody setup a live session, which made easier to resolve problem that is difficult to communicate vi email.

Thank you for your help.

Regards,

Igor

Hi Igor,

I was pretty sure I did answer your question, but apparently I was not clear.  The actual coefficient values (h0, g0, n0) may calculate as floating point values but due to the limitations I outlined previously and the fact that the coefficients are normalized to 22 bits (plus the 8 bits to force to the DAC output of 14 bits) the coefficients before expanding to 2^30 requires that the true coefficients themselves be smaller than +/- 1 / (2^8) or (.0039) to prevent overflow.  As I stated initially, the EEPROM values are written as the coefficient value multiplied by 2^30.  When the firmware is calculating the DAC value it takes the EEPROM value and divides to the internal values shown in the table below:

I used the P2 setting of 4750 decimal and computed the result as:

This missed by 31 codes as the initial is 8160 when calibrating.  Based on experience this most likely can be improved as I think that the GUI just finds a fit error that is less than 1 and not necessarily the best fit.

With respect to the values you computed, you need to make sure that the values align with exactly how the PGA305 is computing the DAC values.  This means that the h0 value cannot be as large as you show.  As the EEPROM values are all divided by 2^22 before computations begin, the equation is not as simple as you are showing and cannot be a floating point value.  The DAC value relates to (PADC + PADC Offset) and not just PADC alone.  Notice that the calculated value for h0 by the PGA305 is 0.498275042 and not 8132.

Interestingly enough 8132 is approximately 1/2 of the DAC output and when you divide by 2^14 the result becomes 0.496337890625.  Here there is a similarity.  As far as the gain g0 coefficient, if you multiply you g0 value times 2^8 you end up with the value of 0.3497216.  Notice that there is some symmetry to the values.  The n0 value is somewhat confusing as the value uses a square of the pressure.  So the value does not align with the square root of your n0 times 2^8.

So I agree in general that your values work mathematically, but will not work as input to the PGA305 without some modification so that the values fit within the framework of the PGA.

Best regards,

Bob B