AWR1843: bpmCfg command

Hi Jairo,

I would need a couple of days to get this information, let me get back to you by Friday.

Regards,

Aayush

Hi, do you have any info about this question?

I also want to add that the semantically correct usage of what you are trying in the second case would be "bpmCfg -1 0 0 1", which formally affects chirps 0 and 1. "bpmCfg -1 0 0 0" only affects chirp 0, however, the chirps have a 0 phase by default to begin with, so it would probably end up having the same effect.

Regards,

Aayush

Aniket Mahajan said:

bpmCfg in itself does not configure the transmitters to transmit simultaneously.

I do not understand why do you say that, the SDK user guide says:

from SDK guide:

bpmCfg

BPM MIMO configuration.
Every frame should consist of alternating chirps with
pattern TXA+TxB and TXA-TXB where TXA and
TXB are two azimuth TX antennas.

This is alternate
configuration to TDM-MIMO scheme and
provides SNR improvement by running 2Tx
simultaneously.

so I understand that when I set 1 in the second parameter of the bpmCfg command I am enabling  2 tx simultaneously

Aniket Mahajan said:

This is done by the last argument of the chirpCfg command.

Ok I agree with this because the SDK guide talks about it:

BPM enabled:
If BPM is enabled in previous
argument, this is the chirp index for
the first BPM chirp. It will have
phase 0 on both
TX antennas (TXA+ , TXB+). Note
that the chirpCfg command for this
chirp index must have both TX
antennas enabled.

but, if the guide mentions the chirpCfg command inside the bmpCfg command I understand that both commands depend on each other to enable the tx simultaneously, I mean, ok I need the last argument of the chirpCfg command but I also need to set 1 the second argument in the bpmCfg command, is this right?

Aniket Mahajan said:

I also want to add that the semantically correct usage of what you are trying in the second case would be "bpmCfg -1 0 0 1", which formally affects chirps 0 and 1. "bpmCfg -1 0 0 0" only affects chirp 0, however, the chirps have a 0 phase by default to begin with, so it would probably end up having the same effect.

I don´t understand this, could you explain it better, please?

thanks

Aniket Mahajan said:

bpmCfg -1 0 0 0 means that both chirps will be transmitted with two antennas simultaneously with 0 phase between txa and txb for the chirps in the range [chirp0Idx..chirp1Idx]

This is also correct*.

So according to what you have explained to me, this is no correct, bpmCfg -1 0 0 0 does not mean that I am tx simultaneously even if I have both tx enables in the chirpCfg command, so I have understand this:

here I enable 2tx simultaneously (BPM mimo) because I set the same 3 antennas in both chirps and enable the bpmCfg command

chirpCfg 0 0 0 0 0 0 0 3
chirpCfg 1 1 0 0 0 0 0 3
bpmCfg -1 1 0 1

here I enable TDM mimo because I set the same different antennas in both chirps and bpmCfg command is disabled

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
bpmCfg -1 0 0 1

I think this would not be a valid config:

here I enable 2tx simultaneously because I set the same 3 antennas in both chirps but I am disabling the bpmCfg command, so if I disable bpmCfg I am trying to do TDM mimo, but TDM mimo uses different antennas for each chirp so this is a contradiction

chirpCfg 0 0 0 0 0 0 0 3
chirpCfg 1 1 0 0 0 0 0 3
bpmCfg -1 0 0 1

what do you think?

Hi Jairo,

Let me start over with the explanation.

The chirpCfg is solely responsible for which antennae are enabled for a particular chirp. bpmCfg has a role to play to enable BPM as well, but it is not needed to enable multiple transmitters. bpmCfg just sets the phase shift of the antennae (it programs the phase shifters in the RF via mmwavelink). So, it is assumed that chirpCfg will take care of enabling the transmitters, and bpmCfg can then set the phase shifts for them. bpmCfg is applied in MmwDemo_bpmConfig via a call to MMWave_addBpmChirp, which takes rlBpmChirpCfg_t as an argument.

MmwDemo_bpmConfig calls MMWave_addBpmChirp twice, once for chirp 0 (setting TX phases to 0, 0 degree) and once for chirp 1(setting TX phases to 0, 180 degree).

Definition of rlBpmChirpCfg_t:

typedef struct rlBpmChirpCfg
{
    /**
     * @brief  Chirp Start Index, Valid Range 0 -511
     */
    rlUInt16_t chirpStartIdx;
    /**
     * @brief  Chirp End Index, Valid Range from chirpStartIdx to 511
     */
    rlUInt16_t chirpEndIdx;
    /**
     * @brief  b0  CONST_BPM_VAL_TX0_TXOFF \n
                     Value of Binary Phase Shift value for TX0, when during idle time \n
                     b1  CONST_BPM_VAL_TX0_TXON \n
                     Value of Binary Phase Shift value for TX0, during chirp \n
                     b2  CONST_BPM_VAL_TX1_TXOFF \n
                     Value of Binary Phase Shift value for TX1, when during idle time \n
                     b3  CONST_BPM_VAL_TX1_TXON \n
                     Value of Binary Phase Shift value for TX1, during chirp \n
                     b4  CONST_BPM_VAL_TX2_TXOFF \n
                     Value of Binary Phase Shift value for TX2, when during idle time \n
                     b5  CONST_BPM_VAL_TX2_TXON \n
                     Value of Binary Phase Shift value for TX2, during chirp \n
                     b15:6 Reserved \n
     */
    rlUInt16_t constBpmVal;
    /**
     * @brief  Reserved for future
     */
    rlUInt16_t reserved;
}rlBpmChirpCfg_t;

As you can see, this structure only contains information about the phase shift of various TX. It will set phase shifters for different TX to either 0 degree or 180 degree.

When bpmCfg is enabled, for a start and end index of chirp, MmwDemo_bpmConfig function populates this structure (once for each chirp) for the antennae to have the appropriate phase needed for BPM. When disabled, it still registers the BPM config, but with 0 degree phase for all TX (which has no effect as profile config already sets the phase shift of all antennae to 0 in OOB demo).

Your understanding of all three configs you listed in your last reply is correct. The first two configs are valid, the third one is invalid for the OOB demo. Note that the device itself has no issues with having multiple transmitters enabled at any phase for any chirp, but there are processing constraints in place which render the third configuration invalid for the OOB demo.

Now, for this statement:

Aniket Mahajan said:

I also want to add that the semantically correct usage of what you are trying in the second case would be "bpmCfg -1 0 0 1", which formally affects chirps 0 and 1. "bpmCfg -1 0 0 0" only affects chirp 0, however, the chirps have a 0 phase by default to begin with, so it would probably end up having the same effect.

The proper usage of bpmCfg in the disable case should be "bpmCfg -1 0 0 1". "bpmCfg -1 0 0 0" is technically incorrect if two chirps are set up, but I think it would still work. This is because the purpose of this command in the disable case is to set the TX antenna phase shifts to 0. But, profile configuration already does this for all chirps. So "bpmCfg -1 0 0 0" would set chirp 0's phase to 0 and omit chirp 1, but chirp 1's phase has already been set to 0 in its profile configuration.

I hope that cleared up the role of bpmCfg a little.

Regards,

Aayush

Hi,

Aniket Mahajan said:

bpmCfg has a role to play to enable BPM as well, but it is not needed to enable multiple transmitters

So, is this an errata?

from SDK guide:

bpmCfg

BPM MIMO configuration.
Every frame should consist of alternating chirps with
pattern TXA+TxB and TXA-TXB where TXA and
TXB are two azimuth TX antennas.

This is alternate
configuration to TDM-MIMO scheme and
provides SNR improvement by running 2Tx
simultaneously.

Hi,

I don't see an issue with the SDK documentation's statement. bpmCfg does indeed configure BPM enable/disable, and enabling BPM does have the overall effect of running 2TX, it's just that if BPM is enabled, chirpCfg needs to ensure that both TXs are enabled for the BPM chirps to be configured properly. 

Regards,

Aayush

Hi,

Aniket Mahajan said:

Note that the device itself has no issues with having multiple transmitters enabled at any phase for any chirp, but there are processing constraints in place which render the third configuration invalid for the OOB demo.

what are those processing constraints?

How could I know if a lab is able to tx simultaneously?, e.g. the awr1642 oob lab does not mention that simultaneous tx could be enable, every time we generate a 2tx config we get something like this:

chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
bpmCfg -1 0 0 1

and in the bpm example you provide in awr1642 profiles in sdk 3.5.0.4, this:

chirpCfg 0 0 0 0 0 0 0 3
chirpCfg 1 1 0 0 0 0 0 3
bpmCfg -1 1 0 1

I never have seen an example where we have the same antennas configured in chirpCfg with bpmCfg disabled or even, without the bpmCfg, always the multiple antenna config is with bpmCfg to 1

and always the chirpCfg with different antennas has bpmCfg to 0 (disabled) or no bmpCfg command, that is why I say that bpmCfg enables the simultaneous tx in addition to the phase of the chirps, of course, your document also mentions the same