This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Calibration DLL for ZSC31050

Hi everybody,

we want to implement the Calibration.DLL for using the signal conditioner ZSC31050 for pressure sensors. By testing it with our parameter set using 15bit and 1/2 ADC range shift we realized an "range check error". Well, possibly this the "range check error" happens because there is no consideration of the ADC range shift setting in the functions of the Calibration.DLL.

What is needed that the Calibration.DLL can calculate in the right range which considers the ADC range shift, too?

Thnx in advane to everyone who could help me with that question with an response.

Best regards

JeyJey

  • JeyJey,

    There source code for the DLL and internal DLL math are not available.

    You can see a description of the SSC calibration math in the functional description,

    section 2- https://www.renesas.com/us/en/document/mah/zsc31050-functional-description

    There is also an application note for using the DLL - 

  • Thank you, Michael, for your fast response.

    We do not need the source code of the DLL because we just implement the DLL routine in our VI program (Labview).

    So far the math behind and also how to implement the DLL function we know and it works.

    But up to now we get the "range check error" back as returned error code (004Hex) as well as error code 102Hex if calculating with 3rd order. Probably the ADC range shift is not yet considered in the RBIC1.DLL function ZMD31050_cal1. I know that the range shift setting is written into the NVM but I am not sure if this setting is considered by the ZMD31050_cal1 function or not. If not it would be very probable that I get a "range check error" code back maybe because of using the wrong ADC shift assumption for the Correction Coefficient calculations.

    So in short my question is: How will the ZMD31050_cal1 function consider the selected ADC range shift setting for its coefficient calculations?  Could it be that we forgot to implement another DLL function or any other precondition which is needed that the ZMD31050-cal1 function is calculating with the correct ramnge shift setting?   

    e.g. for ADC range shift setting 1/2 with 15bit we used th following calculation:

    ZMD31050_cal1 (-11230, 8646, -1275, 3704, -10514, 8277, -11767, 9014, 0.003, 0.997, 0.748, 0.500, -7549, -6138, -8640, 15, &C0, &C1, &C2, &C3, &C4, &C6, &C5, &C7)

    By the way, I am wondering if the description in the Application Note is in correct order with Zp1m - Zp2m - Zp4m - Zp3m as well as &C1 - &C2 - &C3 - &C4 - &C6 - &C5 - &C7

    for Zp:     1 - 2 - 4 - 3 and not 1 - 2 - 3 - 4 (? described as in the RBIC header file)

    for C:      1 - 2- 3 - 4 - 6 - 5 - 7 (same in the header file RBC1.h) and not 1 - 2 - 3 - 4 - 5 - 6 - 7 (?)

    in Application Note page 6:

    ZMD31050_cal1 (Zp1m, Zp2m, Zp4m, Zp3m, Zp1u, Zp2u, Zp1l, Zp2l, A, B, M2, M, Ztmed, Ztupp, Ztlow, adc_res, &C0, &C1, &C2, &C3, &C4, &C6, &C5, &C7)

  • JeyJey,

    The 31050 dll functions only care about the final raw counts from the ADC. They don’t know anything about shift ranges. The user must select the correct gain and offset settings to make sure the raw counts are within the specified range for the ADC output. There is some margin like 10% on upper and lower values. You can see this in the 31050 GUI if you select the check range function while collecting calibration values. It will flag any out of range conditions.

     

    If we had a sreenshot of your settings or the EEPROM file I could check the values for the selected offset setting, but they can also do this easily with the GUI.

     The indexing order is correct as shown in the app note. I have no idea why they number them this way but my guess is that the first two values were for a 2-point calibration and they added the other indexes for higher order corrections. You can see how they labelled the points in the little plot of the 31050 GUI calibration window:

  • Thank you Michael, these facts have been rather valuable. So with the GUI I could check that the ZMD31050_cal  function provides exactly the same coefficient values as our EXCEL file in our old program. Fine!

    Now I still have two more questions. Up to now we have implemeted the cal functions from the RBIC1.dll in our Labview program but only simulated the coefficient calculation without a device connection. Reading the Application Note about the Calibration DLL it seems that the ZMD31050_cal function needs the AFE settings by connection to the ZSC31050. I mean the GUI takes the AFE value settings for the range limit calculation from the Configuration Setting GUI. The ZMD31050_cal function needs to take these values from the EEPROM of the µC. Is not it?

    In the Header of RBIC1 there I can find a line with

    ZMD31050_sim1(int c0, int c1, int c2, int c3, int c4, int c5, int c6, int c7, int adc_reso, float range_shift, int izmin, int izmax, int ZT, int ZTmin, int ZTmax )

    Here the range_shift is a given parameter. Not connecting a ZSC31050 before running the cal function needs probably that kind of simulation peraparation by the above mentioned function. Is that right?

    The following is what we tried but without a connection the an initialized  ZSC31050:

  • It seems like you have implemented a custom version of the dll function that simulates more than what our standard functions do.

     

    For our calibration function, the values of gain and offset are not needed or used. The only device parameter needed is the ADC resolution. The explicit function call for the calibration function, ZMD31050_cal1, only uses the acquired data at Zp and Zt levels, the corresponding target values, and the ADC resolution. Here is the syntax:

     

     

    There is no information given about AFE gain or offset.

    Without deeper understanding about your ZDM31050_sim1 function, we cannot tell why it is using extra information that our function does not.  My guess is that you are trying to model the Raw counts versus bridge voltage.

  • Hello Michael,

    pls excuse me my often replies. The ZMD31050_cal function for the calculation of the coefficients performs a range check because when running it I get an Error Code 004HEX back. The range limits of the ADC output of course depend on the range shift of my ADC set-up. Maybe something is wrong with our initialization of the device.

    We start with START_CM mode via I2C but do not get a response from the ASIC back that Command Mode is succesfully started. I am wondering if you could help us with the short list wich commands have to be sent via I2C after EEPROM setup for initializing the calibration routine until calling the ZMD31050_cal function? So that we do not have overseen anything.

    If that does not help do you think that there is a chance to have a short call for a 1:1 step debugging until the coefficient calculation runs without giving us HEX004 back?

    Best regards

    JeyJey

  • The 0x0004 error is referring to the internal math ranges of the digital signal processor. This is not the same as the ADC raw counts range.

     The only requirement for the START_CM to work is that this command must be the first one sent after a power on reset. Once the 31050 switches to NOM by receiving any other command, the START_CM command will not work. From the 31050 Functional Description document:

      

     So, the only steps needed to get the ZSC31050 into CM are to reset the device by power cycling, wait a minimum of 5 ms for the POR to complete, and then send the START_CM command (0x072).

     After the device is in CM, the “Dx” commands can be used to collect Raw data. Typically the START_AD_P_AZC and START_AD_T_AZC commands are used for this.

     The 31050 GUI will also build log files showing what commands are sent during a session. This can be helpful to see what is going on behind the scenes when setup and calibration are performed using the GUI. These files are described in the EVK user guide:

     

     Note that the GUI must be launched as Administrator so that Windows will allow these files to be created.

  • Being taken offline working directly with engineering as it appears to be a incompatibility with the software environment used.

  • Thnx a lot, Micheal, we run the debug file of the RBIC1.dll by replacing the file name. So we realized that not all necessary parameters were set to 4 bit floating character. Now we implemented it into our VI and it works excellent: We get exactly the same coefficients using the dll in Labview as from the GUI and the EXCEL calculation sheet as well. I want to thank to David Grice as well as to Steffen Bender, too, helping us with their patient  support.

  • Great JeyJey!  I will close this thread.