Hi there,
In the SDK, it mentions there is a difference between "full" configuration and "minimal" configuration, as noted below in the screenshot... what is the difference between the two?
Is the difference like: minimal = configuration through CLI command line, while full configuration is through mmwave studio?
Thanks!
George
Hi Kyle,
Thank you very much for helping me debug my code!
I changed to code to include '0x0' and '0xF' and I did not get much different of a result. The correctly decoded signal [chip1+chirp2-chirp3-chirp4)/4] was fairly similar to the incorrectly decoded signal [chip1-chirp2+chirp3-chirp4)/4], which--if the signal actually transmitted [0011]--should have reduced the signal power significantly. See some preliminary graphs below:
**Signal = [0011]
Theoretically correct decoding: [chip1+chirp2-chirp3-chirp4)/4]
Incorrect decoding: [chip1-chirp2+chirp3-chirp4)/4]
What do you think of using the bpmAdvancedConfig CLI API to accomplish the [0011] bpm scheme on one Tx?
Thanks!
George
George,
Let me attach this snapshot of what the Chirp RAM looks like. What Kyle tried to explain is that when he reads the Chirp RAM, BPM_TX2 bit is enabled only for chirp 3,4. So, regarding the BPM phase shift, yes we are reading
chirp 1 - no phase shift
chirp 2 - no phase shift
chirp 3 - phase shift
chrip 4 - phase shift
Question
If yes to the above, does that mean that if we change chirp 1 and chirp 2 constBpmVal to 0U and chirp 3 and chirp 4 constBpmVal to 0x3, then we would still get the same chirp sequence [0011], but out of Tx1 (if we enabled the that channelCfg to be 1)?
Answer
Yes, this would be my expectation. If you want to make the code changes, we can try it
thank you
Cesar
Hi Kyle and Cesar,
Thank you for running the above test cases and getting back to me. There are a few things I am noticing, discussed below, that I am concerned about.
Correct me if I am wrong, but the Chirp RAM (where you are looking) is located before the BSS, correct? I honestly still think that while the chirp RAM has the correct configuration, the BSS is still not either 1) not receiving that configuration or 2) not updating the front end with with the correct configuration to transmit. Here is why:
- To confirm everything transmitted correctly, I changed the constBpmVal to 0U for all 4 chirps. I then ran a test with a corner reflector to see if there is no phase change across samples in consecutive chirps. Unfortunately, below show four screenshots, which depict the degrees I received for chirp 9-12 from Tx1, Tx2, Tx3, and Tx4. (**Assume indexes for the BPM decoding block is chirp1-chirp4**). I calculated these values by taking rad2deg(complex ADC samples) received at each receiver.
Rx 1:
Rx 2:
Rx 3:
Rx 4:
As you can see, the same samples across chirps (independent of Rx) are not 0 degrees. Is there a particular reason why you would say that the chirps in the RAM are not being transmitted with the correct phase shift?
If you look closer, chirp 1 and chirp 3 for Rx 1 and 3 were relatively 180 degrees apart from chirp 2 and chirp 4 on Rx 1 and 3. But for Rx 2 and Rx 4, they are about 21 deg off. Why would you say they are not consistent?
Furthermore, as you look in the spatial domain (rather than the time domain -- across chirps) across Rx for the same chirp, there is weird things happening across Rx's. Regardless of BPM, shouldn't we expect the degrees received on the same Rx to be the same across chirps (since the corner reflector is directly in front of the radar)? There is another weird pattern.
Thanks and I look forward to hearing your thoughts on these issues!
George
Hi Cesar,
Great, thank you for working with the team to help me solve this issue. I really appreciate the help!
You may also tell the team that as of yesterday morning, I received the desired BPM sequence (not the default [01] bpm sequence) as seen in screenshots below similar to my last post by using bpmCfgAdvanced in the Advanced Frame Mode. BUT, the received power for the 180deg BPM phase shifted chirps was in the negative dB. I worked all yesterday trying to figure out why. Please see the screenshots below confirming the sequence, but also the very low power. I have also attached the CLI script that I used to configure the AWR1642. If I can understand why the received power is so low and fix it, it seems like everything should work out.
Chirp Sequence: [chirp1 chirp2 chirp3 chirp4], where the values shown are received adc samples converted from complex numbers to degrees.
Range and Doppler FFT over all samples (no decoding):
Info for below graph: range_bin = 12; doppler_bin = 1; frameIndex = 20; rx_num = 1;
Range and Doppler FFT across a range bin (Pre-decoded) with low power:
Info for below graph: range_bin = 16; doppler_bin = 4; frameIndex = 20; rx_num = 1;
Also, for evidence that my code works, I have attached below plots for the monostatic (0 deg phase shift for all chirps) case using the same MATLAB code:
CLI Script used:
sensorStop flushCfg dfeDataOutputMode 3 channelCfg 15 3 0 adcCfg 2 1 adcbufCfg -1 0 0 1 0 profileCfg 0 77 7 7 160 0 0 20 1 512 6200 0 0 30 chirpCfg 0 0 0 0 0 0 0 1 chirpCfg 1 1 0 0 0 0 0 1 chirpCfg 2 2 0 0 0 0 0 1 chirpCfg 3 3 0 0 0 0 0 1 advFrameCfg 1 0 60 1 0 subFrameCfg 0 0 0 4 16 100 0 1 1 100 bpmCfgAdvanced 0 1 0 bpmCfgAdvanced 2 3 3 lowPower 0 1 guiMonitor -1 0 0 0 0 0 0 cfarCfg -1 0 2 8 4 4 0 5120 cfarCfg -1 1 0 8 4 4 0 5120 peakGrouping -1 1 0 0 1 224 multiObjBeamForming -1 0 0.5 calibDcRangeSig -1 0 -5 8 256 extendedMaxVelocity -1 0 clutterRemoval -1 0 compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 measureRangeBiasAndRxChanPhase 0 1.5 0.2 nearFieldCfg -1 0 0 0 CQRxSatMonitor 0 3 4 127 0 CQSigImgMonitor 0 63 8 analogMonitor 0 0 lvdsStreamCfg -1 0 1 0 sensorStart
Collected and Processed Data for above screenshots Attached as excel file: bpm_0011_BTxE.csv
MATLAB code to plot these samples and print out the BPM scheme: 5102.check_transmission.pdf
Looking forward to hearing all advice and recommendations you and your team have as soon as you have them. As always, keep sending questions when they pop up. Have a great day!
George
Hi,
As a follow up, I have noticed a few additional observations after doing more testing today that may help us all come to some answer as to how to make this all work:
1) The spikes in the graph may depend on how many bpm chirps there are in the sequence:
Ex: Sequence [00110010]
Exception: when I do all 0's, and still do bpmCfgAdvanced (but put the constBpmVal to 0), I get the below. No spikes... Also, all chirps in the 4 chirp sequence are the same degrees (ref. note #3)
2) Maybe the FFT does some sort of cancelation to the 0011 signal (screenshot in previous thread reply) since I ran a 0010 test and I got the below graph. I am thinking the chirp 3 and chirp 4 are canceled and chirp 1 and 2 make up the very positive power, normal looking doppler FFT and Range FFT (disregard spikes).
3) Since the all 0's exception worked (no spikes, high powered FFTs, and chirps that all correlate), I tried bpmCfgAdvanced where all 4 chirps have a 1. This was weird because I got the below graph and the below set of chirps.... If you look at the chirps, only 3 correlate to each other, and the fourth, usually the first one in the sequence/resolution block, is phase shifted differently than the others (which is not what I configured). Also, notice that the FFTs are very positive which proves maybe one was phase shifted (canceled with another through FFT operation?) then plotted two non canceling [11] chirps or [00] chirps (if the first chirp is the only one phase shifted).... I am unsure...
Thanks,
George
