... | ... | @@ -11,4 +11,13 @@ If the ad9910 is not outputting a stable signal when the nco_reset signal is ass |
|
|
|
|
|
If the ad9910 **is** outputting a stable signal, when the nco_reset signal is asserted, the RF signal is observed from the front panel as shown below. It takes somewhere around 200 ns to achieve a stable RF signal. I have assumed that a pre-injection is available 300 ms before the nco_reset signal will be asserted.
|
|
|
|
|
|
![ad9910_warm_start](uploads/cf1f9f772a1414d88ce73877ad38e87f/ad9910_warm_start.png) |
|
|
\ No newline at end of file |
|
|
![ad9910_warm_start](uploads/cf1f9f772a1414d88ce73877ad38e87f/ad9910_warm_start.png)
|
|
|
|
|
|
## RFNCO versus Xilinx DDS, glitchy RF close 1 usec **after** nco_reset
|
|
|
|
|
|
In the following plot, I'm mixing the IQDAC and AD9910 DDS. On RF1 channel 1 (blue) I send a signal from a Xilinx DDS, whilst on channel 2 (green) I show the mixed output when deriving the IF via the RFNCO and IQModulation blocks.
|
|
|
The nco_reset (yellow) is the triggering cause for this plot. When using the RFNCO and IQModulation blocks there is a glitch close to 950 ns after nco_reset. This glitch in the RF is **not** present if I use the output from a Xilinx DDS.
|
|
|
|
|
|
We have to delay the trigger unit sync signal until we have stable RF, otherwise our trigger unit output will be glitchy too. For tracking the RF during a ramp we'd like this delay to be as small as possible but guaranteeing stable/reproducible RF.
|
|
|
|
|
|
![RF_versus_RFNCO_and_XilinxDDS](uploads/32fad08bcd0948b5006b234326b48018/RF_versus_RFNCO_and_XilinxDDS.png) |
|
|
\ No newline at end of file |