• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 417 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.

IWRL6432AOP: FFTs implementation in the vital signs open source lab

Juan José González Torres
Prodigy 50 points
Part Number: IWRL6432AOP

Tool/software:

Hello,

I have a question regarding the implementation of the FFTs in the code of the vital signs lab. For what I'm seeing in the code, the dpc.c file implements functions like DoaProc_configParser to send data to some DPUs, which I assume would be the ones responsible for computing some FFTs (Doppler, elevation and azimuth in this case). However, in the vitalsign.c code, in the MmwDemo_runPreProcess() function, I see that you manually apply 2 FFTs to the range data for obtaining the elevation and azimuth. I would like to know why we need this data. Wouldn't it be simpler to just take them from the radar cube, like the process you do in the function MmwDemo_runVitalSigns() with the vsDataPerFrame variable? There might be some part of the code that I'm not correctly understanding, so I would appreciate some clarification.

Regards.

  • 0
    TI__Genius 11750 points

    Hi

    Thanks for your query. Please allow us a couple of days to respond.

    Regards

  • 0 in reply to Abhishek Karkisaval
    TI__Genius 11750 points

    Hi

    To determine the vital signs, it is essential to track the person first. In DoaProc_configParser, elevation and azimuth fft is done to determine the point cloud after cfar.

    DBSCAN algorithm is run on this point cloud to determine the existence of tracks. FFTs performed in DoaProc_configParser are done every frame to determine the point cloud. 

    For vital signs only one sample data is taken per frame. Vitals signs frame spans across 128 frames. The ffts performed in mwDemo_runPreProcess()  are run only at the position of tracker centroid and not on the entire FOV to determine point cloud

    Regards

  • 0 in reply to Abhishek Karkisaval
    Prodigy 50 points

    Hi

    Thanks for your reply. I understand now the first part of the process (FFTs and DBSCAN to locate the person). However, the last paragraph is not very clear to me. First, by "one sample data is taken per frame", do you mean that samples from only one chirp are used as input for the FFTs?

    Then, for what I understand in the code, runPreProcess() is run on every frame. As I said, this is the function running 2 FFTs, also for elevation and azimuth, but I understand that this is only applied to the range+angle bin where we located the person with the previous FFTs in dpc.c, is that right? So, could we say that what we are doing is getting more detailed information about that bin?

    And finally, with the REFRESH_RATE frequency, we call the computeVitalSignProcessing to make the last FFT on the phase differences between samples in chirps, and get the frequencies corresponding to the vital signs. Is this reasoning correct?

    Regards.

  • 0 in reply to Juan José González Torres
    TI__Genius 11750 points

    Hi

    For Vitals signs chain, only 1 sample per frame is taken and inputs from 128 frames are used to determine the phase differences which correspond to the chest movement. That is the reason that a person needs to be stationary for 20s, so that valid values from 128 frames are considered for vitals computation

    Yes, In runPreProcess(), at the location where the person is present, azimuth and elevation fft is run to locate the presence of the person. This process is run for 128 frames and based on the location where the peak is determined for azimuth and elevation fft, values from each frame at that bin are taken for phase difference computation. 

    Refresh rate determines the rate at which the HR/BR values get updated. Values correspond to the running window of past 128 frame data for the vitals computation

    Regards

  • 0 in reply to Abhishek Karkisaval
    Prodigy 50 points

    Hi,

    Thanks for your answer. I understand that the information from the 128 frames has to be used for determining the vital sign values. But I still don't get why we need the angle ffts of runPreProcess if we already have the position of the person from the DBSCAN algorithm (after having done elevation and azimuth ffts already in the DoaProc_configParser). In other words, for me, the pipeline "range+elevation+azimuth ffts -> CFAR and DBSCAN -> arctangent demodulation+phase unwrapping+ fft on phase differences" would make sense, but there are still these second azimuth and elevation ffts done in runPreProcess that I can't see how they fit in the process. Could you please indicate to me where they are placed, and what their input is and where their output goes?

    Regards.

  • +1 in reply to Juan José González Torres
    TI__Genius 11750 points

    Hi,

    Tracking will only provide the location where the person is present. But it is not possible to extract the input for phase difference calculation just based on the tracker location. You will need the I/Q values corresponding to the range of the tracker. These I/Q values cannot be used directly as it only corresponds to the range of the tracker without the azimuth or elevation information. This necessitates another azimuth and elevation fft to be performed from the range inputs corresponding to a tracker

    Regards

  • 0 in reply to Abhishek Karkisaval
    Prodigy 50 points

    Hello,

    Going through the algorithm, I found another doubt regarding the implementation of the phase fft. We are computing the fft of the phase difference between the last 128 frames for concrete range bins and chirps (frame samples). Then, the input of the fft are real values, therefore the spectrum we obtain from that is symmetric. So, of the 128 points that the spectrum would have, only the first (or the last) 64 are relevant. However, in the code you define some constants BREATH_INDEX_START (3) BREATH_INDEX_END (50), HEART_INDEX_START (68) and HEART_INDEX_END (128) that are the indexes you use for going through the spectrum looking for the maximum. My question is, is there any reason for these 2 pairs of constants to be on different halves or sides of the spectrum, even if it is symmetric?

    Regards

  • 0 in reply to Juan José González Torres
    TI__Genius 11750 points

    Hi

    We compute a 512 point fft after the phase unwrapping. After the FFT output we have 512 samples out of which breath rate and heart rate spectrum are separated out. We have put the index based on our experiment, however, you can tweak the indices based on you need of the spectrum. Typically we have a large range for breath rate and we report heart rate only above 60

    Regards