In the system for the ADRV9009-ZU11EG, does anyone understand the mapping between the two ADRV9009, two channels per ADRV9009, two DDS tones per channel, two numbers for complex data into the sdr.dds_frequencies[...] vector? I understand why it is 16 elements long, because 2*2*2*2=2^4 =16, based on the accounting from the sentence above. Here is the code that references the dds_frequencies ...
The example shows, sdr.dds_frequeincies = [20e6, 0, 20e6, 0,0,..., 0] and sdr.dds_phases=[0,0,90000,0,0,0,90000,0,0,...,0]
I can see on the freq. domain plots that, that gives a single spike at -20MHz and none or very small amount at 20MHz.
I can get the frequency to go to positive frequencies by changing the phase to 90 degrees associated with the 1st frequency.
sdr.dds_frequeincies = [20e6, 0, 20e6, 0,0,..., 0] and sdr.dds_phases=[90000,0,0,0,0,0,90000,0,0,...,0]
Is this the correct way to sweep between positive and negative frequencies and only get a single frequency (and not the positive and negative)?
I tried putting in negative frequencies but that did not work.
The dds_frequencies and dds_phases properties are the direct API to the DDS driver, which is the most flexible but most difficult to use.
Negative frequency does not really make much sense for purely real signals, or in reference to a single DDS. To get to negative frequency requires complex signal or multiple sinusoids with phase control. If you look at the helper methods you can see how to use the phases and frequencies to together to set the DDSs:
I would recommend using these methods rather than trying to use dds_frequencies/phases directly (if possible). Here is their generated doc: https://analogdevicesinc.github.io/pyadi-iio/fpga/index.html#direct-digital-synthesizers
When I run this ... https://github.com/analogdevicesinc/pyadi-iio/blob/master/examples/adrv9009_som.py
but with the #Create Radio line changed from local to over ip address ... sdr = adi.adrv9009_zu11eg(uri="ip:10.0.1.31")
I get the following error ...
[ 5801.878054] adrv9009 spi1.0: ERROR: 43: TALISE_gpIntHandler(): PA Protection Channel1 Reports Error
I also get the same error when I change set the frequency using single tone
I'm trying to read out 4 contiguous buffers of data based on your feedback that the circular buffers are of the discard type and not the overwrite type. I left the circular buffer length set to 4, which should be the same as this ... sdr._rxadc.set_kernel_buffers_count(4).
When I do the following read,
I would expect the data to be contiguous, with no skips or discontinuities, but what I get back has discontinuity between the four reads of the buffer of length 256. See below. Am I doing something wrong here? I have the Fs = ~245.76MHz, and I'm reading over the ethernet.
This is not what I would expect.
I see that Jon Kraft was using the python iio module rather than the python adi module which I have been using, and that the iio module seems to have some extra flexibility, and has an rxbuf.refill() and seperate rxbuf.read() command. Does the adi module have similar refill() and read() commands?
Hi Nathan, I believe that the first 4 buffers, after the buffer is created, will always be contiguous. But then after that it will depend on your transfer speeds. See p. 67-71 here:
So if you are not reading the first 4 buffers after the buffer was created, then new buffers will get filled as shown in those slides--which may not be contiguous if you're interface can't keep up.
Travis can clarify the different buffer refill commands, but I thought they both behaved the same. Perhaps I'm wrong though.
Perhaps another option for you is to destroy the buffer, and then recreate? That would give 4 continuous buffers. Albeit with a lot of overhead....
Yes Jon is correct. After the first 4, all bets are off.
pyadi-iio is using the libiio bindings under the hood, so the behavior should be the same. It does the refill and read: https://github.com/analogdevicesinc/pyadi-iio/blob/master/adi/rx_tx.py#L170
then some extra things to interpret the data for you.
The destroy methods are documented here: https://analogdevicesinc.github.io/pyadi-iio/buffers/index.html
Do you all know how to change the sample rates (DAC's and ADC's) on the ADRV9009-ZU11EG with pyadi-iio?
I tried writing to the registers with something like this ... but gave me an error, saying "Can't set attribute"
NathanB said:Do you all know how to change the sample rates (DAC's and ADC's) on the ADRV9009-ZU11EG with pyadi-iio?
You need to use profiles to change any of the clock and filter settings: https://wiki.analog.com/resources/tools-software/linux-drivers/iio-transceiver/adrv9009#filter_and_signal_path_configuration
Attributes are only available for reading things back.
NathanB said:My second question is with regard to synchronization btw two ADRV9009 parts on the ADRV9009-ZU11EG. I changed my python code, to set the RFSOM to FHM (Frequency Hop Mode) with Multichip sync set to 1. I hooked up a splitter ZX10-2-183-S+ (with matched phase within 2 degrees) then sampled a window of data on Rx1a and Rx1b (a indicates the first ADRV9009 and b indicates the second ADRV9009), but when I do this the phases are not lined up
They are not expected to be aligned. They will have a fixed but random offset. Be sure you are running the tracking cals and give them time to converge.
I switched back to using the ADI O-scope app in windows, to get some data that makes more sense. See the attached plots below. I hooked up a 1 to 4 equal splitter, run into each of the RX input channels and driven from one of the DAC outputs. I then set the DDS=5MHz, 90 degrees, and the LO=305MHz, 2000MHz then 5900MHz.
You can see several things from these plots ...
This data is what I would expect to see, where the 4 Rx phases are mostly aligned at low frequencies then have some spread towards higher frequencies. A reboot also does not nominally effect the relative phases.
When, I run python code from the host with same configuration of DDS=5MHz, 90 degrees and LO= 305MHz, I see the following ...
You can see that the phases within the transceiver "a" and within the transceiver "b" are in phase, but between transceivers the phases seem to have a random phase relationship. Also after a reboot the relationship between the "a" and "b" transceivers changes like they are not locked together.
Do you know what needs to be done in the python code in order to get the two transceivers synchronized? I am running in frequency hopped mode I believe and have explicitly enabled MCS (multipchip sync).
ps Do you know why the I and Q data is nominally equal amplitude for each channel ?
Can you make a new thread for this discussion as it's outside the bounds a bit of the original post. Plus long threads become hard to follow.