AWR1843AOP: Calculation of Virtual Antennas in mmwdemo_rfparser

onur emre uygun said:

1- When I examined the mmwdemo_rfparser.c function, when the tx antennas are sequentially opened as 1-2-4 in the chirpCfg parameters, the numTxAntAzim value is assigned as 2 and the numTxAntElev value is assigned as 1, and accordingly, the numVirtualAntAzim value is calculated as 8 and the numVirtualAntElev value is calculated as 4. I couldn't understand whether the calculated value matches with the Tx antenna arrangement on the AWR1843AOP chip. Why does it take numTxAntAzim = 2 and numTxAntElev = 1?

Doesn't the AWR1843AOP chip require numTxAntAzim to be 0 and numTxAntElev to be 3 in the mmwdemo_rfparser.c function? I would appreciate it if you could provide more detailed information.

onur emre uygun said:

2- mmwdemo_rfparser.c is used in other demos for other chips as well, and when the tx antennas are sequentially opened as 1-2-4 in the chirpCfg parameters, the numTxAntAzim value is also 2 and the numTxAntElev value is 1 for AWR6843AOP chip. AWR6843AOP and AWR1843AOP have different hardware arrangements, so how is this possible? Is this correct?

The situation I'm trying to describe is that in the mmwdemo_rfparser.c function, when Tx antennas are configured as 1-2-4 in the chirpCfg parameter, numTxAntAzim is assigned a value of 2 and numTxAntElev is assigned a value of 1, regardless of the antenna configuration on the chip. The mmwdemo_rfparser function operates based on the Tx antenna order specified in the chirpCfg parameters independently of the antenna configuration on the chip. How is this possible? Doesn't the hardware antenna configuration matter? Furthermore, when the second Tx antenna is not active, the numTxAntElev value becomes 0. I'd like to understand why elevation seems to be dependent on the second Tx antenna. If you could provide a detailed explanation, I'd appreciate it.

Can you explain/rephrase 1-- with pictures so that I can understand and respond to your question better? 

Zorah Ahmad said:

Can you explain/rephrase 1-- with pictures so that I can understand and respond to your question better?

The figure above shows the antenna positions of the AWR1843AOP chip. Based on this, I'd like to repeat my questions through a few different scenarios.

Below is the MmwDemo_RFParser_setAoAParams function found in the mmwdemo_rfparser.c file.

/**
 *  @b Description
 *  @n
 *      Helper function that parses chirp Tx antenna configuration and extracts parameters
 *      needed for AoA configuration depending on the AoA DPU needs
 *
 *  @param[inout]   outParams               Pointer to parameters generated after parsing configuration
 *  @param[inout]   pFoundValidProfile      flag to indicate if this is valid profile; if not, advance to the next one
 *  @param[in]      frameTotalChirps        Total chirps in the frame (used for looping through validChirpTxEnBits)
 *  @param[in]      validChirpTxEnBits      Array of chirp's txEn bits. Dimension is provided by frameTotalChirps
 *  @param[in]      bpmEnabled              BPM flag, 0 -disabled, 1-enabled
 *
 *  \ingroup MMWDEMO_RFPARSER_INTERNAL_FUNCTION
 *
 *  @retval
 *      Success -   0
 *      Fail        <0, one of error codes @ref MMWDEMO_RFPARSER_ERROR_CODE
 */
static int32_t MmwDemo_RFParser_setAoAParams
(
    MmwDemo_RFParserOutParams  *outParams,
    bool                       *pFoundValidProfile,
    int16_t                     frameTotalChirps,
    uint16_t                   *validChirpTxEnBits,
    bool                        bpmEnabled
)
{
    
    uint32_t    chirpLoopIdx;
    bool        validProfileHasOneTxPerChirp = false;
    uint16_t    validProfileTxEn = 0;
    int32_t     retVal = 0;
    bool        validProfileHasElevation = false;
    int32_t     i;
        

    /* now loop through unique chirps and check if we found all of the ones
       needed for the frame and then determine the azimuth/elevation antenna
       configuration
     */
    if (*pFoundValidProfile==true) {
        int16_t nonElevFirstChirpIdx = -1;
        for (chirpLoopIdx = 0; chirpLoopIdx < frameTotalChirps; chirpLoopIdx++)
        {
            bool validChirpHasElevation = false;
            bool validChirpHasOneTxPerChirp = false;
            uint16_t chirpTxEn = validChirpTxEnBits[chirpLoopIdx];
            if (chirpTxEn == 0) {
                /* this profile doesn't have all the needed chirps */
                *pFoundValidProfile = false;
                break;
            }

            /* check if this is an elevation TX chirp - if yes, it is assumed to be 4Rx, 3Tx case */
            validChirpHasElevation = (chirpTxEn == MmwDemo_RFParserHwCfg.elevTxAntMask);
            validProfileHasElevation |= validChirpHasElevation;

            /* if not, then check the MIMO config */
            if (!validChirpHasElevation)
            {
                uint8_t     log2TxEn;

                if(bpmEnabled)
                {   /* In case of BPM, check if both TX antennas are enabled*/
                    if(chirpTxEn != MmwDemo_RFParserHwCfg.azimTxAntMask)
                    {
                        /* The frame is configured as BPM but this chirp does not enable both TX antennas*/
                        *pFoundValidProfile = false;
#ifdef MMWDEMO_RFPARSER_DBG
                        System_printf("Bad BPM configuration. chirpTxEn=%d for chirp %d \n",chirpTxEn,chirpLoopIdx);
#endif
                        break;
                    }
                }
                else
                {
                    /* If only TX antenna is enabled, then its 0x1<< log2TxEn should equal chirpTxEn */
                    log2TxEn = mathUtils_floorLog2(chirpTxEn);
                    validChirpHasOneTxPerChirp = (chirpTxEn == (1 << log2TxEn));
                }

                /* if this is the first chirp without elevation, record the chirp's
                   MIMO config as profile's MIMO config. We dont handle intermix
                   at this point */
                if (nonElevFirstChirpIdx == -1) {
                    validProfileHasOneTxPerChirp = validChirpHasOneTxPerChirp;
                    nonElevFirstChirpIdx = chirpLoopIdx;
                }

                /* if this is the first chirp, record the chirp's
                   MIMO config as profile's MIMO config. We dont handle intermix
                   at this point */
                if (chirpLoopIdx == 0)
                {
                    validProfileHasOneTxPerChirp = validChirpHasOneTxPerChirp;
                }
                /* check the chirp's MIMO config against Profile's MIMO config */
                if (validChirpHasOneTxPerChirp != validProfileHasOneTxPerChirp)
                {
                    /* this profile doesnt have all chirps with same MIMO config */
                    *pFoundValidProfile = false;
                    break;
                }
            }

            /* save the antennas actually enabled in this profile */
            validProfileTxEn |= chirpTxEn;
        }
    }

    /* found valid chirps for the frame; mark this profile valid */
    if (*pFoundValidProfile == true) {
        uint32_t        numTxAntAzim = 0;
        uint32_t        numTxAntElev = 0;

        outParams->numTxAntennas = 0;
        if (validProfileHasElevation)
        {
            numTxAntElev = 1;
        }

        if (bpmEnabled == true)
        {
            /* BPM eanbled */
            numTxAntAzim = 2;
        }
        else if (validProfileHasOneTxPerChirp == true)
        {
            uint8_t log2TxEn;

            while(validProfileTxEn)
            {
                log2TxEn = mathUtils_floorLog2(validProfileTxEn);
                if ((0x1 << log2TxEn) & MmwDemo_RFParserHwCfg.azimTxAntMask)
                {
                    numTxAntAzim++;
                }
                validProfileTxEn &= ~(0x1<< log2TxEn);
            }
        }
        else /* i.e. SIMO case, all chirps have same one Tx antenna. */
        {
            /* in this case, for AOA, Tx Azimuth antenna is only 1. */
            if ((validProfileTxEn & MmwDemo_RFParserHwCfg.azimTxAntMask) != 0)
            {
                numTxAntAzim = 1;
            }
            else
            {
                numTxAntAzim = 0;
            }
        }

#ifdef MMWDEMO_RFPARSER_DBG
        System_printf("Azimuth Tx: %d (MIMO:%d), Elev Tx:%d\n",
                       numTxAntAzim,validProfileHasOneTxPerChirp,numTxAntElev);
#endif

        outParams->numTxAntennas = numTxAntAzim + numTxAntElev;
        if (outParams->numTxAntennas > SYS_COMMON_NUM_TX_ANTENNAS)
        {
            retVal = MMWDEMO_RFPARSER_EINVAL_NUM_TX_ANTENNAS;
            goto exit;
        }

        outParams->numVirtualAntAzim = numTxAntAzim * outParams->numRxAntennas;
        outParams->numVirtualAntElev = numTxAntElev * outParams->numRxAntennas;
        outParams->numVirtualAntennas = outParams->numVirtualAntAzim +
                                              outParams->numVirtualAntElev;

        /* Sanity Check: Ensure that the number of antennas is within system limits */
        if ((outParams->numVirtualAntennas <= 0) ||
           (outParams->numVirtualAntennas > (SYS_COMMON_NUM_TX_ANTENNAS * SYS_COMMON_NUM_RX_CHANNEL)))
        {
            retVal = MMWDEMO_RFPARSER_EINVAL__NUM_VIRTUAL_ANTENNAS;
        }

        /* txAntOrder[] will be needed for Rx Channel Phase Measurement/Compensation routines */
        if (validProfileHasOneTxPerChirp)
        {
            for (i = 0; i < outParams->numTxAntennas; i++)
            {
                outParams->txAntOrder[i] = mathUtils_floorLog2(validChirpTxEnBits[i]);
            }
        }
        else
        {
            for (i = 0; i < outParams->numTxAntennas; i++)
            {
                outParams->txAntOrder[i] = i;
            }
        }

        outParams->validProfileHasOneTxPerChirp = validProfileHasOneTxPerChirp;
        
#ifdef MMWDEMO_RFPARSER_DBG
        System_printf("Ant setting virtualAzim: %d , virtual Elev :%d\n",
                        outParams->numVirtualAntAzim, outParams->numVirtualAntElev);
#endif
    }
    
exit:
    return (retVal);        
}

Scenario 1

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 4

When I send the above values

numTxAntAzim = 2 

numTxAntElev = 1

outParams->numVirtualAntAzim = 8

outParams->numVirtualAntElev = 4 

outParams->numVirtualAntennas = 12

it receives the values.

Scenario 2

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 4
chirpCfg 2 2 0 0 0 0 0 1

When I send the above values

numTxAntAzim = 2 

numTxAntElev = 0

outParams->numVirtualAntAzim = 8

outParams->numVirtualAntElev = 0

outParams->numVirtualAntennas = 8

it receives the values.

Scenario 3

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 1

When I send the above values

numTxAntAzim = 1

numTxAntElev = 1

outParams->numVirtualAntAzim = 4

outParams->numVirtualAntElev = 4

outParams->numVirtualAntennas = 8

it receives the values.

why numTxAntElev value is 0 when the second antenna is switched off. when the antenna positions are examined, it is seen that the first, second and third antennas are aligned on the vertical axis. why does only the second antenna being switched off change the numTxAntElev value?

We have 3 antennas in elevation, we think that these 3 antennas act as a single antenna in azimuth, but we cannot use it in this way in the algorithm. RFparser code prevents us from using numTxAntElev 3 and numTxAntAzim 1. Is such a restriction correct?

We also want to run it with two antennas active to send a stronger signal.

example

chirpCfg 0 0 0 0 0 0 0 3
chirpCfg 1 1 0 0 0 0 0 5
chirpCfg 2 2 0 0 0 0 0 6 

However, when we set it in this way, the numTxAntElev value is assigned as 0. In such a situation, we lose the elevation directly, we are aware that this situation will have an effect on the positioning side. we regulate this effect on the AOA side. I want not to lose elevation information when two antennas are active, how can I fix this situation. I would appreciate if you give a detailed explanation to my questions.

Zorah Ahmad said:

AWR6843AOP and AWR1843AOP have the same antenna. The only difference being AWR6843AOP offers 60- to 64-GHz coverage vs AWR1843AOP offers 76 to 81 GHz coverage. 

Please see Table 5-1 in www.ti.com/.../awr6443.pdf

                       AWR1843AOP                                                                      AWR6843AOP

Since the antenna positions of the two chips are different, shouldn't numTxAntAzim and numTxAntElev parameters take different values? Antenna positions and MIMO structures are different. can you explain this issue?

example

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 4

when I use these parameters for both chips 

numTxAntAzim = 2 

numTxAntElev = 1

values are assigned. How is this the same for both chips?

Is it correct that the MmwDemo_RFParser_setAoAParams function is the same for two chips?

You are right, I was mistaken about 6843aop and 1843aop having the same antenna layout. While we look into your issue, what application are you using AWR1843aop/AWR6843aop for?

Hi, 

Thank you for getting back to us.

We are developing products for ECE Regulations 159, 158, and 151. We are using the AWR6843aop chip for in-vehicle solutions. We have an NDA with TI and we are also receiving support from them.

I'm awaiting your feedback on the issues.

Hi Onur, 

Thankyou for sharing. Redirecting your question to relevant subject matter experts for better visibility.

Hi,

Can you provide some more details on which software you are running, are you running one of our demo programs / is it modified?

To summarize your questions, are you mainly concerned about the below?

onur emre uygun said:

Since the antenna positions of the two chips are different, shouldn't numTxAntAzim and numTxAntElev parameters take different values?

Please make sure that you are also running the correct binary on the device (for 6843 or 1843) The correct antenna_geometry must be set and used, see in the code:

-----

onur emre uygun said:

chirpCfg 0 0 0 0 0 0 0 3
chirpCfg 1 1 0 0 0 0 0 5
chirpCfg 2 2 0 0 0 0 0 6 

For this, our SDK recommends the below. If we use multiple TX antennas, chirps should use the same TX antennas.

Regards,

Tim

Hi,

First of all, you started to go off-topic from the questions I asked. I'm using AWR1843AOP and using your DSP-based standard demos.

Tim Henderson said:

--define=XWR18XX_AOP_ANTENNA_PATTERN must be defined in the makefile.

Yes, this has to be done, I know that.

onur emre uygun said:

                       AWR1843AOP                                                                      AWR6843AOP

Since the antenna positions of the two chips are different, shouldn't numTxAntAzim and numTxAntElev parameters take different values? Antenna positions and MIMO structures are different. can you explain this issue?

example

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 4

when I use these parameters for both chips 

numTxAntAzim = 2 

numTxAntElev = 1

values are assigned. How is this the same for both chips?

Is it correct that the MmwDemo_RFParser_setAoAParams function is the same for two chips?

My question is whether there is an error in the MmwDemo_RFParser_setAoAParams function inside the mmwdemo_rfparser.c file. The expression I suspect to be the cause of the error is mentioned above. Please, let's proceed focusing on this specific topic.

onur emre uygun said:

why numTxAntElev value is 0 when the second antenna is switched off. when the antenna positions are examined, it is seen that the first, second and third antennas are aligned on the vertical axis. why does only the second antenna being switched off change the numTxAntElev value?

We have 3 antennas in elevation, we think that these 3 antennas act as a single antenna in azimuth, but we cannot use it in this way in the algorithm. RFparser code prevents us from using numTxAntElev 3 and numTxAntAzim 1. Is such a restriction correct?

That's another question, I'm looking for an answer to that too.

I am waiting for your feedback.

Onur Emre

Hi,

I appreciate the clarification - thank you!

I will need some time to talk to the right experts on this function. Would you mind sending the whole .cfg you are using? Is BPM enabled? I am seeing in that function that numTxAntAzim = 2 if bpmEnabled. I will need some time to determine why we set it to 2 for bpmEnabled.

On your second question, your logic appears correct, and I will need some time to look into that as well.

Can you check if outParams->numVirtualAntAzim and outParams->numVirtualAntElev seem to be holding the right values for both 6843 and 1843 when you are running it? These are the params that are actually used.

Regards,

Tim

Hi,

Thank you for your interest.

Tim Henderson said:

I will need some time to talk to the right experts on this function. Would you mind sending the whole .cfg you are using? Is BPM enabled? I am seeing in that function that numTxAntAzim = 2 if bpmEnabled. I will need some time to determine why we set it to 2 for bpmEnabled.

BPM is not enable, BPM enable is not useful for me anyway. Because when BPM is enabled for AWR183AOP, elevation resolution is lost.

When BPM is not enabled, numTxAntAzim = 2. When I send the following chirpCfg parameters, numTxAntAzim = 2, numTxAntElev = 1. I explained this situation in detail above. you can review it.

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 4

When the above chirpCfg values are sent when BPM is not enabled, numTxAntAzim = 2 is set with the following code fragment in the MmwDemo_RFParser_setAoAParams function.

        else if (validProfileHasOneTxPerChirp == true)
        {
            uint8_t log2TxEn;

            while(validProfileTxEn)
            {
                log2TxEn = mathUtils_floorLog2(validProfileTxEn);
                if ((0x1 << log2TxEn) & MmwDemo_RFParserHwCfg.azimTxAntMask)
                {
                    numTxAntAzim++;
                }
                validProfileTxEn &= ~(0x1<< log2TxEn);
            }
        }

I am sharing the .cfg file I used with you below.

Tim Henderson said:

On your second question, your logic appears correct, and I will need some time to look into that as well.

I'm waiting for your feedback on this matter.

Tim Henderson said:

Can you check if outParams->numVirtualAntAzim and outParams->numVirtualAntElev seem to be holding the right values for both 6843 and 1843 when you are running it? These are the params that are actually used.

I checked it before but I checked it again for you. it holds the same values for both 6843 and 1843.

The MmwDemo_RFParser_parseCtrlConfig function used in the demos for 6843 and 1843 stems from this common problem. this function (MmwDemo_RFParser_parseCtrlConfig) works hardware independent and I wonder if there is a reason for this.

Best regards,

Onur Emre 

onur emre uygun said:

I am sharing the .cfg file I used with you below.

sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 15 7 0
adcCfg 2 1
adcbufCfg -1 0 1 1 1
profileCfg 0 77 7 6.4 119.07 0 0 33.46 1 335 3000 0 0 48
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 4
frameCfg 0 2 24 0 100 1 0
lowPower 0 0
guiMonitor -1 1 0 0 0 0 0
cfarCfg -1 0 2 8 4 3 0 20 0
cfarCfg -1 1 0 4 2 3 1 15 0
multiObjBeamForming -1 1 0.2
clutterRemoval -1 0
calibDcRangeSig -1 0 -5 8 256
extendedMaxVelocity -1 0
bpmCfg -1 0 0 1
dbscanCfg 4 3 20 20 2 256
lvdsStreamCfg -1 0 0 0
compRangeBiasAndRxChanPhase 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
measureRangeBiasAndRxChanPhase 0 1.5 0.2
CQRxSatMonitor 0 3 4 63 0
CQSigImgMonitor 0 127 4
analogMonitor 0 0
aoaFovCfg -1 -1 1 0.25 2 -1 1
cfarFovCfg -1 0 0.2 4
cfarFovCfg -1 1 -3 3.00
staticBoundaryBox -1 1 0 1 0 0.5
boundaryBox -1 1 0 1 0 0.5
gatingParam 4 6 6 6 10
stateParam 4 10 60 600 20 600
allocationParam 30 30 0.5 3 2 2
maxAcceleration 0.1 0.1 0.1
trackingCfg 1 2 250 20 78 121 99
sensorPosition 0 0 0
presenceBoundaryBox -1 1 0 1 0 0.5
sensorStart

Thank you.

Please allow me a couple of days to look into this internally, and I will reply here.

Regards,

Tim

Hi Tim, 

Thank you for your interest, I will be waiting for your return. 

Regards

Onur Emre

Hi Onur,

I've done a little more investigation. So if you look at the code, the MmwDemo_RFParser_setAoAParams function is under an #ifdef for the USE_2D_AOA_DPU. The 2D FFT (Azimuth/Elevation) is what we use in the OOB demo for AOP because both AOP antennas are not intended for high accuracy in 1 of azimuth or elevation.

The #else condition where we see the values being set "incorrectly" is because we've anticipated the our x843 ISK antenna design to be used with this approach of doing Azimuth FFT, finding peaks, and then Elevation FFT from there. This, for a long narrow virtual antenna array, can provide higher angular accuracy for use cases that require it in azimuth direction.

Can you check in makefile is "USE_2D_AOA_DPU"  defined? For AOP use case it'd be recommended for it to be defined.

Let me know if this starts to clear things up and any follow-ups you have.

Regards,

Tim

Hi Tim,

Thank you for your return.

I have already done the "USE_2D_AOA_DPU" define you mentioned. I have no problem with the issue you mentioned. my problem is the values assigned to the numTxAntAzim and numTxAntElev variables in the MmwDemo_RFParser_parseCtrlConfig function. I have explained the problem in detail in my previous messages. Could you please read my messages once again? If my messages are not clear enough, I can make a more detailed explanation in order to solve the problem quickly.

I will be waiting for your return.

Regards

Onur Emre

Hi Onur,

This will take a couple of days for us to debug on our end, I will try and replicate. Can I ask, have you done performance testing with this and have you seen any incorrect or unexpected behavior when looking at collected radar data after angle estimation?

Regards,

Tim

Hi Tim,

Let me briefly talk to you about my thoughts and the tests I have done.

First of all, when I define USE_2D_AOA_DPU and send the chirpCfg parameters as chirpCfg 0 0 0 0 0 0 0 0 1- chirpCfg 1 1 1 0 0 0 0 0 0 2 - chirpCfg 2 2 0 0 0 0 0 0 4, I saw that numTxAntAzim = 2 and numTxAntElev = 1 values were assigned in the MmwDemo_RFParser_parseCtrlConfig function, I thought this was not correct for AWR1843AOP. Since the tx antennas for the AWR1843AOP chip are aligned on the vertical axis, I thought that numTxAntAzim = 0 and numTxAntElev = 3 should be assigned.
In this direction, I sent the chirpCfg parameters as chirpCfg 0 0 0 0 0 0 0 0 1- chirpCfg 1 1 1 0 0 0 0 0 0 2 - chirpCfg 2 2 0 0 0 0 0 0 4 and I assigned numTxAntAzim = 0 and numTxAntElev = 3 in MmwDemo_RFParser_parseCtrlConfig, Then I had to edit the doppler compansation and after making those edits, I ran the sensor and saw that the sensor worked better, especially I saw that there was an improvement in the angle.

As a result of these tests I have done, do you think there is no error in the MmwDemo_RFParser_parseCtrlConfig function?

In the AWR6843AOP chip, numTxAntAzim = 2 and numTxAntElev = 1 values are assigned in the MmwDemo_RFParser_parseCtrlConfig function. Although AWR6843AOP and AWR1843AOP antenna arrays and MIMO structures are different, how come the same values are assigned to numTxAntAzim = 2 and numTxAntElev = 1 variables?

I look forward to your feedback on this subject.

Regards

Onur Emre

Hi Onur,

One more clarification. numTxAntElev are only used if USE_2D_AOA_DPU is defined, so I'm unsure how they are getting set in your tests? In the USE_2D_AOA_DPU case, the virtual antennas in azim/elev are set to 0 as below (because they are unused), and the numTxAntElev variables are not even used.

Can you confirm that the correct code is being executed based on the #ifdef USE_2D_AOA_DPU in mmwdemo_rfparser.c?

I am also curious where you are setting the numTxAntAzim = 0 and numTxAntElev = 3. I do not see those being used or defined in that function. Only in the #else case MmwDemo_RFParser_setAoAParams function that is called from inside.

I do apologize for all the back-and-forth on this. I am making sure that we get the right team members to also help take a look at this.

Regards,

Tim

Hi Tim,

I am working on a topic to give you a more detailed presentation, I tried to finish it this week but it is not finished. I will get back to you as soon as possible.

I will share the test results.

Thank you for your attention.

Regards,

Onur Emre 

Hi Onur,

Thank you for the reply. Looking forward to the presentation.

Regards,

Tim