DWM3000 CIR Amplitude Inconsistency

Hi!
We used a pair of Tx-RXs to send and receive consecutive frames, and collected the CIR magnitudes of Preamble per frame.
Despite the static environment, the value of CIR amplitude was not constant as shown in the figure below

  • We aligned plotted CIR amplitudes by adjusting FP_INDEX to 250 index, i.e. first path index is 250.
  • The plotted CIR amplitudes are calculated by accum_cir_amplitude / accum_count.
  • configured with Channel 9, 128 preamble length 128, and 9th preamble code

output

Frame Diagnosis Informations
[CIR 1]
{‘ipatov_rx_status’: 0,
‘ipatov_poa’: 5522,
‘xtal_offset’: 8190,
‘cia_diag1’: 40192,
‘ipatov_peak_amplitude’: 7029,
‘ipatov_peak_index’: 241,
‘ipatov_power’: 56,
‘ipatov_F1’: 5489,
‘ipatov_F2’: 7025,
‘ipatov_F3’: 4835,
‘ipatov_fp_index’: 239,
‘ipatov_accum_count’: 111,
‘dgc_decision’: 2}

[CIR 3]: received 100 ms later than [CIR 1]
{‘ipatov_rx_status’: 0,
‘ipatov_poa’: 4432,
‘xtal_offset’: 6,
‘cia_diag1’: 40192,
‘ipatov_peak_amplitude’: 5078,
‘ipatov_peak_index’: 239,
‘ipatov_power’: 30,
‘ipatov_F1’: 5083,
‘ipatov_F2’: 4704,
‘ipatov_F3’: 1545,
‘ipatov_fp_index’: 238,
‘ipatov_accum_count’: 113,
‘dgc_decision’: 3}

We assume that these problems are related to AGC or DGC. We want to adjust the scale of the CIR amplitudes. How can we do this?

Thanks!

Hi Jinew,

Thanks for reporting the issue. We are looking into this and will respond with feedback soon.
In order to properly evaluate this issue, can you share the details about which firmware are you using for this test and the test enviromnet?

Thanks & Regards,
LC

We used DWM3000evbs as a tx-rx pair.
They were separated by 1m distance, and frames were transmitted every 25ms from tx to rx in a static environment .

We used a python progroam to be reported CIR samples, diagnotics and DGC_DECISIONs from rx module through USB CDC.

=================================================================
[dwt_readdiagnotics code]

// rx_info->rx_diag : dwt_rxdiag_t variable
memset(&rx_info->rx_diag, 0, sizeof(rx_info->rx_diag));
dwt_readdiagnostics(&rx_info->rx_diag);
rx_info->dgc_decision = dwt_get_dgcdecision();

[dwt_readaccdata code]

       uint16_t num_samples;
	if (config->rxCode < 9) {
		num_samples = 992;
	}
	else {
		num_samples = 1016;
	}
	if (config->stsMode != DWT_STS_MODE_OFF) {
		if (config->pdoaMode == DWT_PDOA_M3)
			num_samples += 512 * 2;
		else
			num_samples += 512;
	
	}
	memset(rx_info->acc_data, 0, MAX_ACC_LEN);
	
	rx_info->acc_data_len = num_samples*6 + 1;
	dwt_readaccdata(rx_info->acc_data, rx_info->acc_data_len, 0);

===========================================================================

We made the mistake of not handling the fraction index part of FP_INDEX. After handling this, the result of collecting CIR again is shown in the figure below. Plotting was performed by aligning FP_INDEX to the 249~251 index.
CIR magnitude’s scales and values are determined according to DGC_decision value.
We want to calibrate these magnitudes ​​so that they are on a similar scale.

Thanks!

Hi LC,

I also encountered this problem. Can you explain this phenomenon now?
And how can I get constant CIR amplitudes when the environment is static?

Thanks!

I want to ask, how to change the position of FP_INDEX, and why the position in my program is about 750, which is about 3/4. Could you tell me please?

Hi, are there any updates? Anything will be greatly appreciated! Thanks!

Updates on what?
Why the FP index is always around 740? That’s been covered lots of times.
Why the CIR amplitude varies? It just does, welcome to the world of RF.

Sorry, I was referring to the inconsistency of the CIR reading. I think one reason is the DGC control, so I disable the DGC control when PRF 64MHz. After that the CIR do get consistent a little bit more.

Hi, could you tell me how to disable the DGC control? Thanks a lot.

If you go to the firmware folder, find Libs/dwt_uwb_driver/dw3000/dw3000_device.c, and locate function static int32_t ull_configure(dwchip_t *dw, dwt_config_t *config)

This part is about DGC control:

    // only enable DGC for PRF 64
    if ((config->rxCode >= 9U) && (config->rxCode <= 24U))
    {
        // load RX LUTs
        /* If the OTP has DGC info programmed into it, do a manual kick from OTP. */
        if (LOCAL_DATA(dw)->dgc_otp_set == DWT_DGC_LOAD_FROM_OTP)
        {
            dwt_kick_dgc_on_wakeup(dw, (int8_t)chan);
        }
        /* Else we manually program hard-coded values into the DGC registers. */
        else
        {
            ull_configmrxlut(dw, (int32_t)chan);
        }

        dwt_modify16bitoffsetreg(dw, DGC_CFG_ID, 0x0U, (uint16_t)~DGC_CFG_THR_64_BIT_MASK, (uint16_t)DWT_DGC_CFG << DGC_CFG_THR_64_BIT_OFFSET);
    }
    else
    {
        dwt_and8bitoffsetreg(dw, DGC_CFG_ID, 0x0U, (uint8_t)~DGC_CFG_RX_TUNE_EN_BIT_MASK);
    }

I just commented all these code out, and replaced with:

    // disable DGC all the time
    dwt_and8bitoffsetreg(dw, DGC_CFG_ID, 0x0U, (uint8_t)~DGC_CFG_RX_TUNE_EN_BIT_MASK);

By doing this I disable the DGC control on the RX side, testing with DWM3001CDK with the CLI build.

Best,