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.

  • Resolved

x-axis for FFT of raw ADC data in CW mode

Intellectual 500 points

Replies: 12

Views: 158

Part Number: DCA1000EVM

I am having problem with displaying the result of a FFT on the raw data I get from the DCA1000.

I run a IWR6843 with the following config:

(In short, I run a CW wave of 61.250200GHz, sampling the input at digOutSampleRate or Fs of 2000Ksamples per second, 128 ADC samples at a time.)

(We have support for sampling raw ADC data using DCA1000 in continuous mode)


    - flushCfg
    - dfeDataOutputMode 2
    - channelCfg 15 1 0
    - adcCfg 2 1
    - adcbufCfg -1 0 1 1 1
    - lowPower 0 0
    - contModeCfg 61.250200 0 0 6000 0 0 30 1 128
    - guiMonitor -1 1 1 1 0 0 1
    - cfarCfg -1 0 2 8 4 3 0 100 0
    - cfarCfg -1 1 0 4 2 3 1 100 0
    - multiObjBeamForming -1 1 0.5
    - calibDcRangeSig -1 0 -5 8 256
    - clutterRemoval -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. 0.2
    - aoaFovCfg -1 -90 90 -90 90
    - cfarFovCfg -1 0 0 45
    - cfarFovCfg -1 1 -10 10
    - extendedMaxVelocity -1 0
    - CQRxSatMonitor 0 3 4 63 0
    - CQSigImgMonitor 0 127 4
    - analogMonitor 0 0
    - lvdsStreamCfg -1 0 1 0
    - bpmCfg -1 0 0 0

The Tx is turned off on this receiving IWR6843 with its DCA1000 and I use another IWR6843 (call it "the transmitter")  running at a CW of 61.25 (that is 0.2MHz below the receiver).

The result in the receiver after the initial input steps should be a wave of 0.2MHz samples at 2000Msamples/s.

Export is through DCA1000 as raw data and I then run it through a FFT in our python script.

But I have problems when I try to interpret the data and set the x-axis of the FFT plot for displaying the result.

I get a good plot in general from the FFT, showing a clear peak which is the result of the transmitters frequency (I have tested removing the transmitter).

The peak resides in one of the 256 FFT-bins.

But when I try to translate that FFT-bin to a frequency, I do not get the 0.2MHz as I expected.

I must be missing something with either of the following:

-I/Q sampling is causing something to differ from a normal FFT on real valued samples are translated into a frequency spectrum.

-The frequency of the transmitter and receiver drifts a lot, I have seen drifting of about 1MHz in CW mode due to temperature maybe.

-Am I missing to do a FFT-shift of the data, translating it somehow thus getting the wrong frequencies? I refere here to the translation as: [1 2 3 4 5] -> [ 4 5 1 2 3] to get the DC centered in the graph.

Can you explain how to translate the output of the FFT on complex data (I set Complex 1x in adcCfg adcOutputFmt) to frequency?

As far as I understand it, the translation function from FFT-bin to frequency is as follows:  freq (fft_bin_number) = fft_bin_number * Fs / length_of_fft

I see the peak in FFT-bin number 78 which translates to (78*2000 000 / 256 = 610KHz ) which is not the 0.2MHz which I expected.

With a fft shift the FFT-bin 78 is shifted to 78+128 = 206.

Which also does not give the expected frequency. It gives 1.609MHz not 0.2MHz.

I guess everything can be explained with the fact that the frequency drifts in CW mode with up to 1MHz I think, so it is really hard to come to any conclusion I guess.

  • In reply to Johanwww:

    When I start the transmitter the peak is in FFT-bin 200 or so, and then it drifts down during one minute, to FFT-bin 65, and stays there.

    FFT--bin 65 corresponding to something like 476KHz, still far of 0.2MHz.

  • In reply to Johanwww:

    I thought your ADC sampling rate is 6M instead of 2M from your configuration:

    contModeCfg 61.250200 0 0 6000 0 0 30 1 128

    Did you get 128 complex samples? why are you using 256 point FFT?     

    FFT for complex value is straight forward in MATLAB as: fft( adcOutVec_real + 1j*adcOutVec_imag, adcOutSize)

    Best,

    Zigang

  • In reply to zigang Yang:

    My mistake, I am using 2000 sample rate:

        - flushCfg
        - dfeDataOutputMode 2
        - channelCfg 15 1 0
        - adcCfg 2 1
        - adcbufCfg -1 0 1 1 1
        - lowPower 0 0
        - contModeCfg 61.250200 0 0 2000 0 0 30 1 128
        - guiMonitor -1 1 1 1 0 0 1
        - cfarCfg -1 0 2 8 4 3 0 100 0
        - cfarCfg -1 1 0 4 2 3 1 100 0
        - multiObjBeamForming -1 1 0.5
        - calibDcRangeSig -1 0 -5 8 256
        - clutterRemoval -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. 0.2
        - aoaFovCfg -1 -90 90 -90 90
        - cfarFovCfg -1 0 0 45
        - cfarFovCfg -1 1 -10 10
        - extendedMaxVelocity -1 0
        - CQRxSatMonitor 0 3 4 63 0
        - CQSigImgMonitor 0 127 4
        - analogMonitor 0 0
        - lvdsStreamCfg -1 0 1 0
        - bpmCfg -1 0 0 0

    I attach 2 images that I got using this chirp configuration, one at the start when the transmitter has not run for a long time, at most 20 seconds, and one where it has run for about 3 minutes (and gotten warm).

    The peak has moved a lot to the left since the start.

    I am running python, but my mistake might be that I run a 256-bin FFT.  I will look into this.

    In short, without any python details, what I do to process the data:

    # Multiply ADC data with window function

    # adc_cube contains the ADC data from the DCA1000 in the form of [ samples in complex form, chirps, Rx' ]

    fft_length = 256

    r_win = numpy.blackman( fft_length )

    r_cube = numpy.fft.fft( adc_cube * r_win.reshape(-1, 1, 1), axis=0, n=fft_length )

    # Set x-axis resolution of FFT plot

    fs = 2000      # ADC sample rate in kHz

    df = fs / fft_length

    # Create x-axis ranging from 0-fft_length in steps of df.

    # And then plot r_cube against x-axis, for simplicity pick one chirp and one Rx to display.

    # Leaving this code out since it is self explanatory.

  • In reply to Johanwww:

    To better avoid the impact of temperature variations in the transmitting frequency from the antennas in CW mode I moved up to higher frequency differenec between the transmitter and receiver, hoping to see a smaller change in frequency as temperature increases.

    Transmitter still transmits 61.25GHz.

    Receiver runs 61.256150 GHz

    Difference in frequencies has thus increased to 6150 MHz.

    If the temperature makes the frequency differ with some few MHz, this should not impact the measurement as much as in the case of a frequency difference of 0.2MHz as before.

    I increase sample frequency to 12500 K samples, necessary to sample the bigger frequency difference.

    A cold transmitting unit gives rise to a peak at 4700 kHz

    and then moves up towards 5400 kHz as it gets warmer.

    This is inline with my assumption that the antenna can differ about 1MHz due to temperature in CW mode.

    The range of the FFT does not affect where the peak appears.

    Do you know if this difference in frequency in CW mode is reasonable?

    It seems the frequency of the antennas goes down with increasing temperature. (Letting the transmitter cool down makes the peak in the FFT which indicates the difference in frequencies between transmitter and receiver go down towards lover differences).

  • In reply to Johanwww:

    Good to see that you have resolved your problem. 

    Yes, the oscillator frequency will change over temperature by the variation they defined in ppm.   If you want to restrict the frequency error to a smaller value and ensure that the average frequency error across multiple boards is centered around 0ppm, then you can try the idea in this link below:

    https://processors.wiki.ti.com/index.php/CC3100_&_CC3200_Frequency_Tuning

    Best,

    Zigang

  • In reply to zigang Yang:

    A quick measurement gave the following results:

    Unit 1 (ES2):

    Configured to CW at 61.25.

    Started out cold at: 61.248611GHz.

    Ended up drifting to about: 61.245641GHz after about 3 minutes.

    Configured to CW at 61.256150GHz

    Started out cold at: 61.254101GHz

    Ended up drifting to about: 61.251761GHz after about 3 minutes.

    Unit 2 (ES2):

    Configured to CW at 61.25.

    Started out cold at: 61.24292GHz.

    Ended up drifting to about: 61.240826GHz after about 3 minutes.

    Configured to CW at 61.256150GHz

    Started out cold at: 61.249623GHz

    Ended up drifting to about: 61.246991GHz after about 3 minutes.

    Total drift unit 1:

    61.25GHz:             2.97MHz

    61.256150GHz:    2.34MHz

    Total drift unit 2:

    61.25GHz:            2.094MHz

    61.256150GHz:   2.632MHz

  • In reply to Johanwww:

    HI, 

    Thank you for your information.  Is there any conclusion from your measurement?   

    The oscillator on TI EVM board has a spec of 100ppm.   Which means the frequency variation can be as large as 60G * 1e-4 = 6MHz. 

    Best,

    Zigang

  • In reply to zigang Yang:

    We can now verify that our script in python works correct even if the frequency peak is a bit off. We will use a higher frequency difference for the measurement to make the relative  variation smaller.

  • In reply to Johanwww:

    Hi, 

    I could not find the documentation on the continuous mode support.  Can you direct me to the right document or the right person?

    Best,

    Zigang

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.