AM62A7: TI-AM62A-AE parameter adaptation ox03f10- Consultation

Thank you for your support. I'm going to consult the supplier of ox03f10.

Hello. According to your guidance, our software engineers have adjusted mapped, and AE and ox03f10 seem to be working properly.
However, in the scene of light and dark changes, the adjustment speed of AE is very slow, taking approximately 2 to 3 seconds, as shown in the attachment "TI-AM62A-AE-speed-slow.png/mp4".
We check the code. It might be the reason for the slow update of the value of sink_pad->sensor_in_data in gsttiovxisp.c (see the attachment "sensor_in_data.png"). Please help confirm.
Please help see if there is a solution. Thank you!

Hi Lu,

Lu feng said:

It might be the reason for the slow update of the value of sink_pad->sensor_in_data in gsttiovxisp.c

No, that's not the reason. 

Please double check the exposure setting and also make sure the pipeline is running at the right frame rate.

Would you mind sharing the code for get_<sensor>_ae_dyn_params() and gst_tiovx_isp_map_2A_values()?

Regards,

Jianzhong

Hello, please check the attachments "get_ox03f10_ae_dyn_params.c" and "gst_tiovx_isp_map_2A_values.c".

ox03f10 is named X3F in gst_tiovx_isp_map_2A_values.c

static int32_t get_ox03f10_ae_dyn_params (IssAeDynamicParams * p_ae_dynPrms)
{
  int32_t status = -1;
  uint8_t count = 0;

  g_return_val_if_fail (p_ae_dynPrms, status);

  p_ae_dynPrms->targetBrightnessRange.min = 40;
  p_ae_dynPrms->targetBrightnessRange.max = 50;
  p_ae_dynPrms->targetBrightness = 45;
  p_ae_dynPrms->threshold = 5;
  p_ae_dynPrms->enableBlc = 0;
  p_ae_dynPrms->exposureTimeStepSize = 1;

  p_ae_dynPrms->exposureTimeRange[count].min = 41;     /* 6*16.67/2128*1000 micro sec */
  p_ae_dynPrms->exposureTimeRange[count].max = 15269;  /* (2128-30)*16.67/2128*1000 micro sec */
  p_ae_dynPrms->analogGainRange[count].min = 1024;     /* 1x gain - 16*64 */
  p_ae_dynPrms->analogGainRange[count].max = 15872;    /* 15.5x gain - 16*15.5*64 = 328*64 = 15872 */
  p_ae_dynPrms->digitalGainRange[count].min = 1024;     /* 1x gain - 16*64 */
  p_ae_dynPrms->digitalGainRange[count].max = 1024;     /* 15.9x gain - 16*15.9*64 = 328*64 = 15872 */

  count++;

  p_ae_dynPrms->numAeDynParams = count;
  status = 0;
  return status;
}

gst_tiovx_isp_map_2A_values (GstTIOVXISP * self, int exposure_time,
    int analog_gain, gint32 * exposure_time_mapped, gint32 * analog_gain_mapped)
{
  g_return_if_fail (self);
  g_return_if_fail (exposure_time_mapped);
  g_return_if_fail (analog_gain_mapped);

  if (g_strcmp0 (self->sensor_name, "SENSOR_SONY_IMX390_UB953_D3") == 0) {
    gint i = 0;
    for (i = 0; i < ISS_IMX390_GAIN_TBL_SIZE - 1; i++) {
      if (gIMX390GainsTable[i][0] >= analog_gain) {
        break;
      }
    }
    *exposure_time_mapped = exposure_time;
    *analog_gain_mapped = gIMX390GainsTable[i][1];
  } else if (g_strcmp0 (self->sensor_name, "SENSOR_SONY_IMX219_RPI") == 0) {
    double multiplier = 0;
    /* Theoretically time per line should be computed as:
     * line_lenght_pck/2*pix_clock_mhz,
     * here it is roughly estimated as 33 ms/1080 lines.
     */

    /* FIXME: This only works for 1080p@30fps mode */
    /* Assuming self->sensor_out_data.aePrms.exposureTime[0] is in miliseconds,
     * then:
     */
    *exposure_time_mapped = (1080 * exposure_time / 33);

    multiplier = analog_gain / 1024.0;
    *analog_gain_mapped = 256.0 - 256.0 / multiplier;
  } else if (g_strcmp0 (self->sensor_name, "SENSOR_OV2312_UB953_LI") == 0) {
    *exposure_time_mapped = (60 * 1300 * exposure_time / 1000000);
    // ms to row_time conversion - row_time(us) = 1000000/fps/height
    *analog_gain_mapped = analog_gain;
} else if (g_strcmp0 (self->sensor_name, "SENSOR_OX05B1S") == 0) {
    *exposure_time_mapped = (int) ((double)exposure_time * 2128 * 60 / 1000000 + 0.5);
    *analog_gain_mapped = analog_gain / 64;
  } else if (g_strcmp0 (self->sensor_name, "X3F") == 0) {
   double row_time_us = 20.25;
  printf("---------------exposure_time before is %d  -------------------------\n",exposure_time);
  printf("---------------analog_gain before is %d  -------------------------\n",analog_gain);
  *exposure_time_mapped = (int) ((double)exposure_time / 20.25 + 0.5);// +0.5为了浮点数四舍五入
  *analog_gain_mapped = analog_gain/4;
  printf("---------------exposure_time_mapped  is %d  -------------------------\n",exposure_time_mapped);
  printf("---------------analog_gain_mapped  is %d  -------------------------\n",analog_gain_mapped);
}

Hi Lu,

Your gain mapping doesn't look correct. Let me share some reference code offline.

Regards,

Jianzhong

We have no previous experience in debugging ox03f10. It would be great if there were reference codes for AM6A compatible with ox03f10. Thank you for your support!

Hi,
I haven't received the reference code or the related attachments yet. Please resend the reference code. Thank you!

I sent you a friendship request. Please check your email.

Thank you for your continuous support.We have received the reference code of the email.
When our software engineers are porting the generation, there are still a few details that need your help to confirm again. They have been sent by email. May I ask if you have received them? It would be great if you could reply to the email.

Yes, I've received and we can continue the discussion through email.

After testing, the issue still exists. I have sent an email with a new description, as follows:

According to the provided demo, we modified the driver by only changing Exp_DCG and AGain_HCG, while keeping dgain at its default value. However, the previously mentioned slow exposure response has not shown any significant improvement.

Currently, from the UART logs, we can observe that after a change in ambient light during testing, there is a delay of 2 to 3 seconds — the data is already delayed when it is retrieved from the GStreamer plugin. Could this be a problem with the GStreamer plugin? Would it be possible to provide the complete RTOS-adapted driver? We would like to use your driver as a reference and port it to the Linux platform for testing.

The current data path is:
sensor_in_data --> get_ox03f10_ae_dyn_params --> TI_2A_wrapper_process --> sensor_out_data --> gst_tiovx_isp_map_2A_values
This is then mapped and passed to the driver.

However, based on log observations during testing, it seems that the slow update of sensor_in_data is causing the delayed exposure response.
May I ask what this is related to?

Hi Zhang,

What frame rate are you running at? Can you share the configuration file used to generate the initial ISP configuration?

imaging/tools/default_DCC_profile_gen/scripts$ python ctt_def_xml_gen.py ../configs/ <configuration file>

I’d like to check the parameters you put in the configuration file.

Thank you.

Jianzhong

According to the specification of ox03f10, the frame rate is 60pfs. I checked the configuration file "ox03f10_properties.txt" but couldn't find the field for setting the frame rate.
Is the frame rate set elsewhere?
Does TI-AM62A have any serial port commands to display the frame rate received by the sensor or ISP?

SENSOR_ID 310
PRJ_DIR ../ox03f10_output
SENSOR_NAME X3F
SENSOR_DCC_NAME X3F

SENSOR_WIDTH 1920
SENSOR_HEIGHT 1536

# 0=RGGB; 1=GRBG; 2=GBRG; 3=BGGR, 4=MONO
COLOR_PATTERN 3

# sensor mode: 0 for linear (no decompanding), 1 for WDR (decompanding)
WDR_MODE 0

# raw sensor image BIT_DEPTH: it may be 8, 10, or 12 for linear sensors; typically 12 for WDR mode because of companding
BIT_DEPTH 12

# WDR BIT_DEPTH: WDR raw sensor image bitdepth after decompanding, typically 20 or 24
WDR_BIT_DEPTH 24

# WDR decompanding knee points (comma separated without spaces in between)
#WDR_KNEE_X 0,512,1408,2176,4095,65535
#WDR_KNEE_Y 0,2048,16384,65536,1048063,1048063
#ox03f10,plot pwl0
WDR_KNEE_X 0,1023,1279,1279,1535,1791,2047,2303,2431,2559,2687,2815,2943,3007,3071,3135,3199,3263,3327,3391,3455,3519,3583,3647,3711,3775,3839,3903,3967,3999,4031,4063,4095
WDR_KNEE_Y 0,1023,2047,2047,4095,8191,12287,16383,20479,24575,32767,40959,49151,57343,65535,81919,98303,114687,131071,163839,196607,262143,393215,524287,786431,1048575,1572863,2097151,3145727,4194303,8388607,12582911,16777215

# Sensor black level to subtract before decompanding (for linear sensors only and some Sony WDR sensors)
BLACK_PRE  64

# Sensor black level to subtract after decompanding (for most WDR sensors and all linear sensors)
BLACK_POST  0

# GAMMA value for compressing 20/24-bit WDR raw to 16-bit ISP internal
# typically around 50 (0.5) for 24-bit WDR sensors and 70 (0.7) for 20-bit sensors
GAMMA_PRE 70

# LSB location for H3A input bit range (from bit-H3A_INPUT_LSB to bit-H3A_INPUT_LSB+9) 
H3A_INPUT_LSB 0

# Choose the default gamma curve used for YUV output: 0 for BT709, 1 for a high contrast gamma curve
YUV_GAMMA 1

Hi Lu,

Lu feng said:

Does TI-AM62A have any serial port commands to display the frame rate received by the sensor or ISP?

Please check this Gstream command for reference of using fpsdisplaysink to report the fps:

https://github.com/TexasInstruments-Sandbox/edgeai-rgb-ir-app-examples/blob/main/gstreamer-pipelines/gst-command-rgb-display.sh

I noticed the following in your config file:

# sensor mode: 0 for linear (no decompanding), 1 for WDR (decompanding)
WDR_MODE 0

The OX03F10 is a HDR (WDR) sensor, so you should set WDR_MODE to 1.

Another thing you could try is to set H3A_INPUT_LSB to 3.

Regards,

Jianzhong

Hi Lu,

A few things to confirm and clarify:

1. Are you running the sensor in WDR mode or linear mode? If linear mode, then your don't need to set WDR_MODE.

2. If the sensor is running in linear mode and the raw output is 12-bit, then you can try to set H3A_INPUT_LSB to 2. 

3. If the sensor is running in WDR mode, you can try my previous recommendation.

This also could be a sensor driver issue. You can manually test your driver's exposure and analog gain programming. You can define a set of increasing exposure values, for example 20, and then set exposure to one value every frame and see if the image brightness changes accordingly. Similar for analog gain. I would recommend to do this testing first to ensure your sensor driver is programming the exposure and gain registers correctly.

Regards,

Jianzhong

Ok. I'll confirm first and conduct a manual test. Thank you!