• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 597 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DCA1000EVM: Number of ADC Samples for raw data capture

Mario
Prodigy 85 points
Part Number: DCA1000EVM
Other Parts Discussed in Thread: AWR1843BOOST, MMWAVE-SDK,

Dear Support Team,

I am using an AWR1843Boost developement board together with a DCA1000 card. Iam trying to capture the raw data stream with LVDS using the upd protocol (without mmWave Studio).  The application running on the AWR1843Boost is the demo-application provided by the mmWave-SDK version 3.6. The configuration file that I am using is as follows:

sensorStop
flushCfg
dfeDataOutputMode 1
profileCfg 0 77 7 7 57.14 0 0 70 1 250 5209 0 0 30
channelCfg 15 1 0
adcbufCfg -1 0 1 1 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
frameCfg 0 0 10 1 1342 1 0
adcCfg 2 1
lowPower 0 0
guiMonitor -1 1 1 0 0 0 1
cfarCfg -1 0 2 8 4 3 0 15 1
cfarCfg -1 1 0 4 2 3 1 15 1
multiObjBeamForming -1 1 0.5
clutterRemoval -1 0
calibDcRangeSig -1 0 -5 8 256
extendedMaxVelocity -1 0
lvdsStreamCfg -1 0 1 0
compRangeBiasAndRxChanPhase 0.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 5 121 0
CQSigImgMonitor 0 127 4
analogMonitor 0 0
aoaFovCfg -1 -90 90 -90 90
cfarFovCfg -1 0 0 8.92
cfarFovCfg -1 1 -1 1.00
calibData 0 0 0
sensorStart

According to the user manual each udp-packet has a header of 10 bytes. 

My Question is as follows:

When I set the number of adc samples to 256, I receive 28 UDP-Packets with 1466 bytes each plus one packet with 202 bytes. The total number of data bytes received is therefore: (1466 - 10) * 28 + (202 - 10) * 1 = 40960 Bytes. According to the cofiguration (see configuration file above) this is the exakt number of bytes that I am expecting:

1tx-channel * 4rx-channel * 1frame * 10chirps * 4bytes (16Bit complex number) * 256 ADC-Samples = 40960 Bytes

However, when I set the number of adc samples to for example 250, I receive  27 UDP-Packets with 1466 bytes each. The total number of data bytes received is therefore: (1466 - 10) * 27 = 39312. According to the configuration (see configuration file above) this is NOT the number of bytes that i was expecting: 

1tx-channel * 4rx-channel * 1frame * 10chirps * 4bytes (16Bit complex number) * 250 ADC-Samples = 40000 Bytes

Do you know, why there is some data missing when I use a diffrent number of adc samples? According to the documentation, there is no restriction to the number of adc samples other than a minimum and maximum number:

I have also experimented with other parameters. Like increasing the number of tx-channels. I always seem to get the same results: As long as the number of samples is 256 I get the expected number of bytes. If it is set to 250 I dont.

Do you know what might be the problem here? Am I missing somethink?

Kind regards 

Mario

  • 0
    TI__Mastermind 20605 points

    Hi Mario,

    I would like you to try the following experiments:

    • In your capture log file, can you check if there are any missing packets?
    • If you interpret your data, can you see which dimension along which has the data been dropped?

    Regards,

    Kaushik

  • 0 in reply to Kaushik Gowda
    Prodigy 85 points

    Hi Kaushik,

    thank you very much for you answer. I have recopied the configuration file from the mmWave-Online Demo and now the above mentioned issue does not apply anymore. Maybe i have mixed up some of the configuration data in the configurtion file above.

    However unfortunately i now experience some other issues. Maybe you could assist me solving those: 

    1) As I mentioned above I now do receive the expected number of bytes when i try to capture the data. The status command message after the transmission always has the following payload : [0x5A 0xA5 0x0A 0x00 0x00 0x01 0xAA 0xEE]. According to the "DCA1000EVM CLI Software Developement Guide" the transmitted status means STS_LVDS_BUFFER_FULL. Do you know what i can do the resolve the warning. 

    2) When I configure the number of chirps to be less than 10, the radar does not seem to start the sensor for some reason. In that case no transmission is done at all. Do you know why? Generally speaking I should be able to set the number of chirps as low as 1, right? 

    And just to be abolutely clear about my test-setup: I use the Demo-Application for the radar sensor and manually try to capture the data without the mmWave Studio.

    I would very much appreciate your help on those issues.

    Kind regards,

    Mario 

  • 0 in reply to Mario
    TI__Mastermind 20605 points

    Hi Mario,

    Glad to hear your issue old issue is resolved. From here on, please create a new thread for a different issue to track the same better. 

    1) As I mentioned above I now do receive the expected number of bytes when i try to capture the data. The status command message after the transmission always has the following payload : [0x5A 0xA5 0x0A 0x00 0x00 0x01 0xAA 0xEE]. According to the "DCA1000EVM CLI Software Development Guide" the transmitted status means STS_LVDS_BUFFER_FULL. Do you know what i can do the resolve the warning. 

    I'm not aware of when a warning such as this could arise. Can you confirm the following?

    • Are you using fixed number of frames for capture or are you capturing in infinite mode?
    • Does the warning disappear if you change your data size?
    • Does the warning disappear if you change your data rate?
    • Does this warning appear only after the transmission is fully completed?

    2) When I configure the number of chirps to be less than 10, the radar does not seem to start the sensor for some reason. In that case no transmission is done at all. Do you know why? Generally speaking I should be able to set the number of chirps as low as 1, right?

    Yes, you should be able to capture data with number of chirps as low as 1. To debug these, you can try the following debug steps:

    • Is the number of chirps the only differentiating parameter between the normal and abnormal case?
    • Have you correctly configured the number of chirps to be used in the frame cfg?
    • Are there any other configurations that you have added that could affect the num chirps ultimately programmed?
    • If you aren't able to get more insight after your debug with the above points, please share the high level chirp cfg you are using.

    Regards,

    Kaushik