This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/OPT9221: Non linearity calibration

Part Number: OPT9221

Tool/software: TI C/C++ Compiler

Hello, TI!

I performed Non Linearity Calibration on our-self board base on OPT8221.

The board is set to LongRange mode. (f1 = 40 MHz, f2 = 60 MHz)

The raw calibration data are in attachment

nonlinear_data2.txt
0,235	476	92
0,469	472	292
0,703	738	416
0,937	987	814
1,172	1247	1194
1,406	1508	1542
1,641	1735	1907
1,875	80	100
2,109	337	425
2,344	590	838
2,578	855	1172
2,813	1117	1363
3,047	1397	460
3,281	1645	660
3,516	1898	970
3,750	2146	1346

Format: depth [m], phas1, phase2.

For phase1: ind_freq_data_en = true;  ind_freq_data_sel = false;

For phase2: ind_freq_data_en = true;  ind_freq_data_sel = true;

My question is:

Are these data realistics?

Because I get very strange behavior of phase-map after applying calibration.

  • Semenov,

    The data for phase1, phase2 doesn't look correct. A somewhat linear increase in phase is expected with an increase in distance. In your case, however, it seems that phase is going both up and down with distance.

    For Non-linearity calibration, you need to turn all other calibrations off, except Lens Calibration. You should capture the data again.

    Suramya
  • Suramya, Thank you for your answer!

    I remeasured calib data and got this:
    0,530 2505 80
    0,772 2750 325
    1,016 2990 580
    1,250 3215 780
    1,484 3430 1024
    1,718 3640 1260
    1,952 155 1490
    2,176 351 1611
    2,410 600 1880
    2,643 816 2050
    2,876 1038 2298
    3,110 1280 132
    3,336 1547 361
    3,572 1817 575
    3,799 1957 856
    4,033 2175 1116

    at distance about 1,8 m some phase leap takes place i.e. change phase value from ~4000 to ~100.
    I switched off all calibration but not lens calibration.
  • Semenov,

    This data looks okay. You can plug this in to the NonLinearityCorrection script and program the coefficients (phase_lin_coeff1_x and phase_lin_coeff2_x) accordingly.

    Suramya
  • Suramya, Thank you for your answer!

    So, is some phase leap normal effect for not calibrated board?

    And common offset calibration it's need to perform with applied nonlinearity parameters?

  • Semenov,

    Phase resolution is 12 bit. So, after 4096, the value wraps around. In this case, since there is a zero error (no Common Phase offset correction applied), this occurs at around 1.8 m for frequency 1. The frequency 2 data still looks a bit sketchy, from 2298, phase shouldn't jump to 132. You may want to look at that!

    Suramya

  • Suramya, Thank you for your answer!

    I remeasured non linearity calibration and got these values:
    0,235 2311 3850
    0,469 2659 38
    0,703 2918 407
    0,937 3205 858
    1,172 3424 1192
    1,406 3685 1576
    1,641 3918 1918
    1,875 219 2277
    2,109 339 2660
    2,344 589 2993
    2,578 853 3380
    2,813 1118 3984
    3,047 1395 369
    3,281 1651 681
    3,516 1887 977
    3,750 2150 1355

    calibration parameters are:
    phase_lin_coeff0 = 0 256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328 3584 3840 4096
    phase_lin_coeff1 = 2633.0 2661.0 2653.0 2660.0 2675.0 2667.0 2655.0 2651.0 2654.0 2656.0 2659.0 2662.0 2665.0 2667.0 2651.0 2630.0 2672.0
    using your python script.

    Data for 1 frequency is seem good, for 2-nd very strange.

    May be for each frequency it is need measure at {R(i) } distance with respective it frequencies?
  • Semenov, 

    There's a bug in the script. I'm working on fixing the problem - I'll get back to you on this by the end of this week. Also, the script takes distances in cm and not m, so this data is wrong for both the frequencies. 

    Suramya

  • Semenov, 

    I've fixed the script - it should give correct data now. Here's the latest commit: 

    This takes input data in meters.

    I've added a fix for handling corner cases, where the measured phase wraps around, while the expected phase does not. In such a case, the value of phase_lin_coeff0 is expected to be just less than 4096. 

    Suramya

  • Suramya, Thank you for your answer!

    Thank you for fixing scripts!

    It would be better some comment in script about distance in [m].

    IMHO.

    I got these data for 1-st and 2-nd frequency respectively after recalibration:

    84        4068

    163        1457

    517        406

    770        611

    1018 927

    1259 1196

    1506 1463

    1774 1752

    2034 2033

    2376 2305

    2570 2561

    2798 2842

    3036 3125

    3299 3379

    3568 3541

    3838 3679

    It is seem the function checkBoundaryConditions  does not influence to result calibrations values for my case. (first and last)

    "I've added a fix for handling corner cases, where the measured phase wraps around, while the expected phase does not. In such a case, the value of phase_lin_coeff0 is expected to be just less than 4096. "

    Does it means that max phase_lin_coeff_x value can not be about 4096 after calibration?

    So, I understand rightly that max phase_lin_coeff_x can be about 3840?

  • Hi Semenov,

    From the same script, when I use the data that you provided, I see the following results for phase_lin_coeff1:

    phase_lin_coeff1 = 4067.0 57.0 405.0 610.0 926.0 1194.0 1462.0 1751.0 2032.0 2303.0 2560.0 2840.0 3124.0 3377.0 3539.0 3678.0

    You're seeing something different. This is the data I'm using:

    0.235 2311 3850
    0.469 2659 38
    0.703 2918 407
    0.937 3205 858
    1.172 3424 1192
    1.406 3685 1576
    1.641 3918 1918
    1.875 219 2277
    2.109 339 2660
    2.344 589 2993
    2.578 853 3380
    2.813 1118 3984
    3.047 1395 369
    3.281 1651 681
    3.516 1887 977
    3.75 2150 1355

    These are the arguments being used: 

    python NonLinearityCalibration.py -f phases.csv -m 40 -n 60 -p 0 -q 0 -c TintinCDKCamera -e 2

    Phase_lin_coeff0 stays the same, while phase_lin_coeff_1 seems to have some better results. The first value (57) seems to be a bit odd, but it seems that a piecewise linear approach will give a value close to 57. 

    The max phase_lin_coeff will come close to phase_lin_coeff0, because 0 and 4096 are essentially the same point as a phasor. 

    Suramya

  • Suramya, Thank you for your answer!

    I found the bug in my c++ release this calibration.

    I have more questions:

    Is it important for calibration result if values Phase_lin_coeff_x is differ +/-2 from python scripts? ( in c++: 59, in python 57)

    (I understand it is "rounding" effects in own code realization)

    Is the parameter phaseCorr (input parameter for script) for common offset calibration?

    If yes, why it is used in non linearity calibration?

  • Semenov, 

    The difference in these values will have a small error in phase computation (+-2 would mean an error of +-2 mm at 37.5 MHz). 1 mm accuracy is difficult to achieve because of other calibration errors, so this shouldn't be much of an issue. 

    phaseCorr is added as an optional parameter because, sometimes, it is difficult to get non-linearity parameters from zero (0 distance does not correspond to a phase of 0). So, if someone captures the data with a non-zero phaseCorr, they can provide it as a parameter and it will be cancelled using the script. It is not needed for non-linearity calibration. 

    Suramya

  • Suramya, Thank you for your answer!
    It was helpful.