How I can disable Advanced Power Mode for the AD9670?
I want AD9670 to run countinously after TX_TRIG.
I became crazy but finally I solved the problem that the AD9670 don't run continously but stops after 3.8ms.
I explain the solution, can be useful for other people.
There is an error on my PCB, accidentally I have insert decoupling capacitor on the TX_TRIG+/- signal in this manner:
like clock signal. This should explain why the duration depends from TX_TRIG pulse duration.
I remove this capacitor and the system work continously with external trigger. It don't work with software trigger (writing 0x20 on the 0x10C register) but it's not important for me at the moment.
Thanks for your great help
I investigate the previous problem and I'm in this situation:
My setting are: ADC frequency is 24MHz, Decimation factor=32, RF 2x decimator enabled (total decimation is 64), FCO only during burst, profile POWER_START=0x0 and POWER_STOP=0x7FFE.
As expected the data stops when POWER_STOP occur ( 0x7FFE=2^15-1 then (2^15-1)/12MHz =2.73ms). Note that if RF 2x decimator is enabled, the counting from POWER_START to POWER_STOP are made at Fadc/2!! This is not reported in the datasheet.
Then the first question: Why FCO continue to out data if no extra sample in 0x19B register is selected (reg[0x19B]=0x40)?
I would have expected that FCO stops when DOUT stops. And why stops at about 3.8ms?
I made another test by set POWER_STOP=0x7FFF. If I understand well, this configuration shoud disable Advanced power mode.
As expected DOUT and FCO don't stops at 0x7FFF but stops both at about 3.8ms! Why?
What are the events that can stops FCO and DCO?
Any suggestion are well accepted.
You can disable the advanced power feature by setting power start=0x0000 and power stop=0x7FFF. I am not sure why your DOUT and FCO stops after 3.8 ms if programmed to run continuously.
I noticed your setting is very aggressive in terms of very low output data rate, 24 MHz, 64x decimation, and 1 ch/lane. I never tried this setup. Can you try other speeds? Also an you check the PLL status with register 0x00A?
I checked countinously the PLL status register and it's locked always.
For my project I need low output rate but, as you suggest me, I try to change the decimation factor (with many values) and the configuration 2,4,8 ch/lane. Always I have the same previous results: 3.8ms and stops all.
A this point there a two things that I don't understand:
1) Why the output frame stops at 3.8ms? (obviously)
2) If I try advanced power feature with this settings: set FCO only during burst (no extra sample at the end of burst), POWER_START=0x0 and POWER_STOP=0x7FFE (see figure A of previous post), why FCO don't stops at 2.73ms as the DOUT data?
Are this two question related?
Also I investigated the problem and I found an not understandable correalation between TX_TRIG pulse duration and burst data duration.
I disable advanced power feature with this settings: set FCO only during burst (no extra sample at the end of burst), POWER_START=0x0, POWER_STOP=0x7FFF and verified that if I change the pulse width of the TX_TRIG I have this data timing situation:
The same scale are used for the previous graph.
As you can see, the FCO and DOUT burst don't run continuously as expected but increase if TX_TRIG increase.
TX_TRIG pulse width Burst duration
#1) 50us -> 2.03ms
#2) 100us -> 2.93ms
#3) 200us -> 3.84ms
#4) 400us -> 4.76ms
#5) 800us -> 5.54ms
#6) 1600us -> 6.19ms
Why this appened?
The rising edge of TX_TRIG should reset NCO and write a profile index, then the falling edge put digital block into running state.
I investigated again the problem above and I have seen what happened at the end of burst, when it stops.
The AD9670 is set to run continuosly and FCO enable only during burst. The burst stops after about 3.8ms from a TX_TRIG signal. This time can change of about +/-0.1ms from a burst to another.
The figure below show only the end of any burst:
I repeated the test 4 times, and as you can see from the figure, the burst stops in a strange manner. It seems a chip malfunction but I have no idea about the reason. I checked the power supply near the AD9670 chip and it seems ok.
The FCO change it's frequency before stops.
Then if I set the FCO to run continously, it work correctly with a defined frequency and only the data (DOUT) stops.
Can you help me?
I am having hard time explaining the results you are sharing. Programming the part to run continuously should give you continuous FCO and DCO and it shouldn't be related to TX_TRIG.
I am attaching here our eval board setup files including the SPI macro we use. Can you program your board with this SPI sequence and see what behavior you get?
I am also attaching the schematics that you can compare against your board and see any major differences.
Thank you for your response, I haven't solved the problem yet.
As you suggest me, I investigated about the SPI macro for the EVB, I try several configurations, I set the register in the same order as show but there is the same problem.
I don't have the evaluation board to test, but I create a configuration file for the EVB with my settings. (See the attached file).
Can you test for me in the EVB? I don't insert in the macro the software TX_TRIG because I use external signal.
The profile 0 is set as:
<Add 0xF00> = 0xFF
<Add 0xF01> = 0x7F
<Add 0xF02> = 0x00
<Add 0xF03> = 0x80
<Add 0xF04> = 0xFC
<Add 0xF05> = 0x00
<Add 0xF06> = 0x00
<Add 0xF07> = 0x20
The ADC frequency is 24MHz, 32x decimation with 2x decimator enabled; then 375kHz as a result frequency.
I explain the behaviour: I want to configure the AD9670 and put it in "TxTrig waiting state". After the external trigger event (falling edge) the receiver must start and run indefinitely until I decide to stops with a write operation to the register in 0x10C address.
Now I'm checking my board schematics with the EVB one but I don't find relevant errors yet.
In my opinion, the very strange thing is the dependency of the DOUT stream duration from the lenght of the TX_TRIG pulse. (See the previous post of 13 september).
Thanks for your interest
I will try your settings on the eval board but I am on business trips until the week of Oct 17th.
That's great news Piero, thanks for sharing the fix!
Retrieving data ...