You are not logged in.
Continuing my tests with the dual-AGC four-antenna project, occasionally I needed to make the I and Q channels of individual radios zero (at the input of the ofdm core). Instead of doing this through registers, I tried a shortcut and did this by physically removing the corresponding radio board from its slot. This seemed to work as I/Q channels of that radio, at the input ports of ofdm core, became digitally zero as verified through chipscope.
However, this led to another observation. Specifically, if the radio connected to "port b" of the AGC is removed, the total AGC gain reported for that radio becomes 47. However, removing the radio connected to "port a" results in an out of range AGC gain of -15. Finally removing both radios leads to a gain of -15 for both radios. Any insight as to what may cause this discrepancy?
Offline
How are you reading the "total AGC gain" reported by a radio? Does your ChipScope ILA have access to the RSSI input? AGC bases a lot of its decisions on that; if it's varying (even when no radio is connected), the AGC core could make bogus gain choices.
Offline
I read the AGC gains through serial port according to an earlier thread: http://warp.rice.edu/forums/viewtopic.php?id=91.
On a different note, a SISO version of the AGC core was mentioned in a previous thread but I couldn't find it anywhere in the repository. I want to try four independent SISO AGCs to see if it behaves differently.
Offline
The SISO AGC core was built for the very old PHY, back when things were sampled 5x (50MHz clock, 10MHz bandwidth). You could try using the current AGC core as a SISO AGC by instantiating four copies but connecting only the A ports. If you ground the unused inputs and leave unused outputs open, most of the unused logic will get optimized away.
Offline
I tried that but the design ended up being too dense and unroutable.
On a different note, I think I've made some progress in narrowing down the issue. I used the original reference design with only two radios in slots 2 and 3 (both Rx enabled) and a single AGC core. I included the I and Q channels of each radio, both before and after the AGC, in the chiscope inputs. To remove any uncertainty, I connected the two boards using coax with only an attenuator and a splitter in between. Now here's my observation:
1- In general, the outputs of the two radios have a phase rotation with respect to each other. Interestingly, this rotation only seems to take on integer multiples of pi/2 (0,+/- 90 or 180 degrees), e.g. Radio2_I = Radio3_Q & Radio2_Q = - Radio3_I, etc..
2- The relative phase of the two radios' outputs remains constant for all packets as long as the radio operates. However, it changes each time the bit-stream is reloaded onto the board.
3- This does not seem to be caused by the AGC as the issue persists even after disabling the DCO correction and controlling the radio gains and HPF in software.
Could this be caused by the two radio PLLs locking with a phase offset?
p.s. The only timing violation was the usual HOLD violation of the first constraint with a timing score of 114.
Last edited by Amir (2008-Dec-10 12:29:48)
Offline
As I had suspected in the previous post, the problem seems to be caused by the independent radio PLLs. I was able to reproduce the observations of the previous post on-the-fly, without reloading the bit-stream, by disconnecting and then reconnecting either of the MMCX cables going to the two radio boards. Each time, after reconnecting the cable, the phase rotation (between the outputs of the two radios) changes as I earlier described.
Offline
There will definitely be a phase offset between any two radios which share a reference clock. Each radio board's transceiver (MAX2829) generates its own carrier using its own PLL. The generated carriers will always be frequency locked, but the phase offsets will be random.
The transceiver has a configuration bit (MIMO Mode) that controls whether the PLLs keep running when the chip is in standby mode. We enable this mode by default. If this bit gets turned off, the phase offsets between radios would change per-Tx/Rx event. When it's enabled, only a power-cycle or radio reset will reset the PLLs. The radio controller issues a reset during initialization, which is why you saw the phases change after reconfiguring the FPGA.
Offline
Yeah that's what I gathered after reading the Maxim datasheet and the radio controller driver. What I don't understand is why this phase rotation only takes on integer multiples of pi/2 instead of a continuous range.
Offline