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.

TMS320F28379D: Code Composer Studio forum

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hi, 

So, I did applied an inbuilt example of FFT named as 2837x_RFFT_ADC_RT.

In which my main focus was to get phase of adc samples.

It is giving some output using phase buffer array "RFFTphaseBuff" but as of now I'm not able to understand what output it is giving. 

I'm giving input using function generator a sine wave of 1KHz frequency, 1 Vpp amplitude, offset of 1Vdc and phase of 0 degree.

Since the phase is 0 still the "RFFTphaseBuff" is changing continusly.

why this is happening??

here I'm attaching screenshot of array output. please go through to it and guide me to get the correct phase of adc sample from the example.

Thanking in anticipation.

Vishwas

https://drive.google.com/file/d/1xu5DG45mNKjFPO6051djCgJbXPo2k1JM/view?usp=sharing

  • Hi Aswin,

    Can you please close that one because of the link that shared here is an open while the link shared on that thread is a private.

    Thanks

    Vishwas

  • Hi Vishwas,

    I will close other ticket.

    Thanks

    Aswin

  • Hi Aswin,

    Thanks for that.

    After that please help me out regarding the problem.

    Vishwas

  • Vishwas,

    RFFTPhaseBuff contains the phase samples that correspond to the frequency range that the FFT covers. Your input is a 1kHz sinusoid with 0 phase, so you should see a 0 phase value at that frequency in RFFTPhaseBuff. But there will be random/non-zero values at other frequencies.

    Thanks,

    Sira

  • Sira,

    So you are saying that by looking at the RFFTphaseBuff[j] I'll get the particular phase.

    As per the example freq =  RFFTmagBuff[j] ; 

    So the j element of RFFTphaseBuff is the respective phase of that particular frequency.  

    Am I right?

    Or still I'm overlooking something!!!!

    Thanks,

    Vishwas

  • Each index corresponds to a specific frequency, so the index that corresponds to 1kHz is where you will find the corresponding phase (assuming there's an exact match). It depends on your sampling frequency.

  • Okay,

    The sampling frequency of ADC is 100 khz.

    I want to sample 60 khz sine wave and get the phase out of it.

    Now the problem is that whenever I give sine wave frequency higher than 25khz it is giving wrong output in freq variable.

    Second thing I want to ask whether the phase output in RFFTphaseBuff is in radians or in degree!!!

  • If sampling freq is 100kHz, the maximum input frequency you can use without aliasing is 50kHz.

    Based on your observation that frequencies higher than 25kHz are wrong, it seems like aliasing is occurring above 25kHz, which means your sampling freq. is 50kHz and not 100kHz.

    Radians.

  • Hi Sira,

    Actuallly I have resolved the frequency problem it was dependent on the sampling clock of adc generated from ePWM1A in example.

    So by decreasing the period to half and maintaing 50% duty cycle. Right now I'm getting exact frequency of my input sine wave till 100Khz in sampling freq of 200Khz.

    Thanks for that.

    But still I'm not clear about the phase part.

    As you said that the every index corresponds to a specific frequency and to get phase of my sample frequency, I have to find that particular index.

    but still after finding that particular index. Firstly the phase output is not correct(not equal to what I'm providing) and Secondly the phase should be constant as like minimal deflection is okay but the phase buffer output is varying by 3 radians which should not be happening right!!!!!

    Thanks 

    Vishwas

  • Vishwas,

    The index k where you can expect analog frequency f to show up are related by this equation

    k = N f /fs

    where N is the FFT size, and fs is the sampling frequency.

    Have you checked your results based on this relationship?

    If yes, let me know what f , fs, N are in your example, and what you are seeing at N f/fs , or if it isn't close to an integer, at indices one less and one more.

    You can also experiment with the phase of the input and see what happens to the phase at the above index/indices.

    Thanks,

    Sira

  • Hi Sira,

    Yes, I know about the equation and the index on which I'm getting my analog frequency is according to that equation.

    F= 60000(60khz)

    Fs=200000(200khz)

    N=512

    Acc. to above provided data the index on which the freq will be occurring is "154". So I looked for 153,154&155.

    On these indices the output is totally random. 

    Yes, I did try to find any pattern by changing the input phase but yet the output is totally random.

    Thanks 

    Vishwas

  • Please try changing the input frequency to 60,156 Hz, which corresponds to 154. Let me know what phase you are getting with this update.

  • Hi Sira,

    I tried what you suggested, but still the phaseBuff is showing random output like before.

    Thanks

    Vishwas

  • So I've stored the fundamental frequency(60,156 hz) index(154) in an array. To let you get the idea what data I'm getting for a constant phase(0 degree) frequency input in the RFFT block's RFFT_f32_phase function in RFFT_phaseBuff array Jth element(contains the fundamental frequency).

    drive.google.com/.../view

  • Vishwas, can you send it as an attachment here or even a screenshot. I can't access this drive due to security restrictions.

  • Ok got the data. 

    Is the magnitude peak as expected? Are you seeing a sharp peak at index 154?

    Below, I presume the computation is occurring in the TMU path. Can you try changing it to the non TMU path (by disabling the TMU support) and check if the results change?

    #ifdef __TMS320C28XX_TMU__ //defined when --tmu_support=tmu0 in the project
    // properties
    RFFT_f32_mag_TMU0(hnd_rfft); //Calculate magnitude
    RFFT_f32_phase_TMU0(hnd_rfft); //Calculate phase
    #else
    RFFT_f32_mag(hnd_rfft); //Calculate magnitude
    RFFT_f32_phase(hnd_rfft); //Calculate phase
    #endif //__TMS320C28XX_TMU__

  • Yes, the magnitude is as expected and it is giving a sharp peak at index 154.

    Actually I'm using non TMU path only. I had turn off the TMU support option.

  • Ok, that's good to know.

    I believe there's a different example where we have a simulated test input. Could you please try that and verify that it gives the expected phase at the expected index?

    Then we can narrow down the problem - whether it's the implementation or your test source.

  • Okay, I tried that example and the output is still same as the previous example.

    The index which should be containg the phase of fundamental frequency is continuously changing exactly as like in previous example.

    Here are the output data of the buffer array which contains the phase output index(RFFTphaseBuff[154]) of fundamental frequency.

    https://drive.google.com/file/d/1jBjJq_lLF8yiQTj7S1bdReuLe-y_I2Gd/view?usp=sharing

    https://drive.google.com/file/d/1BHgOpVNbpz0BLztUo1mKajzLL7nVciNO/view?usp=sharing

  • Vishwas,

    Which example did you try? Please tell me the name so I can give it a try. Presume you're running it on the F28379d.

    Thanks,

    Sira

  • Hi Sira,

    2837x_RFFT_ADC : is the one with test inputs.

    2837x_RFFT_ADC_RT : This is the previous one on which I had tried the implementation.

    Yes, I'm applying all this examples in LaunchXL-TMS320F28379D.

    Vishwas

  • Thanks Vishwas, please give me until Friday to check this out.

  • Hi Sira,

    Is there any update!!!!

    Thanks 

    Vishwas

  • Sorry for the delay, I will try to test this later today.

  • Sorry Vishwas, I have been busy with other projects, but I did begin looking into this using the rfft_f32 example (this also has a pre-defined test input with a golden test output). And I will look into the phase aspect and get back to you by tomorrow.

  • Vishwas,

    1. In the 2837x_RFFT_ADC example, are you setting USE_TEST_INPUT = 1. If this is 1, it's using a fixed input, so the output will be fixed, and so will the phase and magnitude. It's not clear to me how the phase can be continuously changing with a fixed input.

    2. Your google drive documents show 2 pictures but they don't show the phase of index 154. It cuts out at index 143. 

    3. At the moment, I don't have the right USB cable to run this example (it's at home, I will run it tonight), but I ran the rfft_f32 example (on F280015x) which also features a fixed input test case, and uses the same FPU DSP library. It passes, and the phase output is fixed. Just to test if the phase changes, I multiplied the input by (-1)^n i.e. exp(j pi n), and this reflects in the output phase.

    The code snippet for this is below:

    Fullscreen
    1
    2
    3
    for(i=0;i<TEST_SIZE;i++){
    test_input[i] = (i%2 == 0) ? test_input[i]: (-1.0f *test_input[i]);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Sira,

    1. Actually In my application I need to continuously check for the phase so I cannot do USE_TEST_INPUT = 1.

    As by doing that I'll get the phase once only. 

    And also by doing so I don't think so I'm getting input phase in the buffer.

    2. Sira that picture actually is an array of the data of phase index 154.

    I did saved phase buffer index154 in an array and just took the screenshot of data and put it here.

    3. Thanks for this, actually can I use this fixed point approach for my application where I continue need this phase value of my fundamental frequency. As of my knowledge I don't think it as....but correct me if I'm wrong.

    Thanks for your reply.

    Vishwas

  • Vishwas,

    Yes, 2837x_RFFT_ADC doesn't even perform Phase computations. Maybe the original developer missed adding this.

    "ctually can I use this fixed point approach for my application where I continue need this phase value of my fundamental frequency. As of my knowledge I don't think it as....but correct me if I'm wrong"

    I didn't understand your comment above. The rfft_f32 example is also a floating-point example, not a fixed-point example. What I meant is that rfft_f32 has a fixed input test vector, so we have a Pass/Fail output, and the Phase is computed as well. This shows that the FPU DSP library is correctly computing the Phase of the FFT data.

    Thanks,

    Sira

  • Sira,

    I'll look for that example rfft_f32 and try to make it happen same in 28379d.

    Till then it will help me alot if you share input, output, magnitude and phase buffer of the example rfft_f32.

    Thanks for your quick response.

    Vishwas

  • Vishwas, rfft_f32 example has built in test_input containing the FFT input, test_golden (containing expected values of FFT output, magnitude, phase), and test_output and test_phase containing actual outputs. After the magnitude calculation test_input contains the actual magnitude values

    Some detailed notes I made on this example:

    • Device – F280015x (C2000Ware 5.02.00), c28x_fpu_dsp_library_eabi.lib
    • 256-pt RFFT implemented using a 128-pt CFFT (CFFT_f32t followed by CFFT_f32_unpack)
    • N-pt RFFT uniquely specified by indices 0, 1, ..N/2 i.e. N/2 + 1 complex values, or N+2 real values (this is due to conjugate symmetry around N/2)
    • N-pt RFFT magnitude uniquely specified by indices 0, 1, …N/2 i.e. N/2 + 1 real magnitude values
    • N-pt RFFT phase uniquely specified by 1, 2, …N/2 i.e. N/2 real magnitude values (index 0 is DC)
    • Sum of the above is N+2 + N + 1= 2N + 3 = 515 (this is what is expected in the Pass count for the example)
    • However, test_golden[1024] i.e. 4N -> has more samples than above. (MATLAB generated data)
    • FFT values are present in test_golden[0,N+1] i.e. N+2 values; actual values are present in test_output
    • Magnitude values are present in test_golden[2N, 2N + N/2] i.e. N/2 + 1 values – actual values are present in test_input (this is because the output of the FFT calc. test_output becomes the input to the magnitude calc, and the input to the FFT calc. becomes the output of the magnitude calc.)
    • Phase values are present in test_golden[3N, 3N + N/2-1] i.e. N/2 values; actual values are in test_phase. However, it seems like the example starts with index 0 (DC phase of 0)
  • Sira,

    There is another example 2837x_RFFT_ADC_RT which consist phase calculation.

    Please can you go through that, If there's any possibilty to have output like the example you discussed above.

  • Vishwas,

    You would have to modify that example to fit your needs.

    Thanks,

    Sira

  • Sira,

    I did modify it to get the desired output.

    But still the phase is changing continously.

    So I just want your guidance how to get phase of fundamental frequency using this(2837x_RFFT_ADC_RT) example.

    Thanks,

    Vishwas

  • Vishwas,

    Phase changing continuously is not the expected behavior. As shown by the rfft_f32 example, the FPU DSP library is generating the phase correctly. 

    I suspect something is not right with your source.

    Thanks,

    Sira

  • Also, I will be out of office after tomorrow for 2 weeks.

  • That's what I'm asking your guidance for because I hadn't change anything in example source code.

    Even though the code is not giving fixed phase.

    If you once go through the example(2837x_RFFT_ADC_RT) it will be very helpful for me. 

    Thanks,

    Vishwas

  • Vishwas,

    I am sorry, I am not clearly following what you are saying:

    rfft_f32 - has a golden test vector, computes FFT, mag, and phase (using CFFT_f32_phase_TMU0 or CFFT_f32_phase) . Phase compared to expected value and Passes.

    2837x_RFFT_ADC - has golden test vector, computes only FFT and mag. Phase not computed.

    2837x_RFFT_ADC_RT - does not use golden test vector, computes FFT, mag, and phase (using RFFT_f32_phase_TMU0 or RFFT_f32_phase). Cannot generate Pass/Fail because input is a real-time input, so no reference to compare against.

    You are using the last example, providing an input from a source with a fixed phase and getting variable output phase. This is the problem.

    There are 2 possibilities:

    1. Your source's phase is not reliable. Please try changing the source to a different source and see what happens.

    2. There's some issue with RFFT_f32_phase_TMU0 / RFFT_f32_phase. I doubt this, but it needs to be verified. Perhaps you could try adapting the 2837x_RFFT_ADC_RT example to use CFFT_f32_phase_TMU0 or CFFT_f32_phase only for phase calculation, and see if that helps.

    Thanks,

    Sira