Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Unwanted frequency shift in DA-converted signal

Hi,

i use Matlab/Simulink and DSP Builder for my project.

In Matlab, I generate a digital source signal and program it in a LUT-Block in Simulink. This Block then sends the data to my DACs.

The source signal is an overlayed signal of 10, 20 and 30 MHz.

When I now check the analog signal with a spectrum analyser I can see a shift in my frequencies. The 10 MHz signal is actually at 9,99564 MHz, 20 MHz actually at 20,00656 and the 30 MHz signal at 30,00220 MHz.

It is very important to reach the frequencies precisely. An ~100 Hz offset would be ok, but more than 2 KHz is too much. Why is there this frequency shift. How to avoid it?

I use a 125 MHz crystal and a PLL the generate a 125 MHz clock inside the Cyclone II EP2C70. All internal and external components use the same clock.

The crystal should not be the cause of this, as the frequency shift is not linear (different shift at different frequencies).

Any hints on that? Thank you for your time!

Leo

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Ok, that's it. The not continuous states when jumping to the start of the LUT cause these problems. With a frequency that leads to a continuous signal, as the ones in post# 11 the frequency shift is gone.

    The DDS solution also works perfekt.

    Now, I'm able to generate signals which are shifted only about 100 Hz. That remaining shift could be because of the crystal is not exactly at 125 MHz. But it's fine for my project.

    Thank you again for your help guys. Saved the end of my work day ;)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Great and thanks for the feedback. I have seen broken vectors causing high frequency spikes due to sudden changes but never checked frequency accuracy itself.

    Another related case of continuity of test vectors is the case of filtered data vector.

    Initially a filter produces zeros then catches up after some delay (delay pipe). In hardware filtering (not vector based input), this occurs once at the start only and can be ignored but if you produce vector then you must delete the zeros. If you do that then vector will lose continuity. The remedy is to add extra samples before filtering the vector then chopoff zeros and wrap up correctly.