WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2014-Nov-11 09:39:53

vbarsoum
Member
Registered: 2014-Sep-08
Posts: 25

AGC operation

After some practical experiments, we found that the AGC will stop working after some time ( roughly ~ 500 samples ), What is the reason for that? and how can we modify it to make it work continuously?

Also, I have some general questions about the AGC:-

1. How many samples do you average in order to generate the output bb gain and rf gain? ( for example, if the agc trigger delay is 200, do you average the whole 200 samples, or do you just average fewer samples at the beginning/end trigger delay?

2. Can you tell me the function of the following modules:-

w3_warplab_agc/agc_abcd/agc_a/dco_correction/butterworth_iir_hp/ ---> why do u need an iir filter here?

w3_warplab_agc/agc_abcd/agc_a/dco_correction/down_sample"1-4" ---> why do u need a down_sample here?

w3_warplab_agc/agc_abcd/agc_a/dco_correction/timing_entity

w3_warplab_agc/agc_abcd/agc_a/stage_ud/timout_count

w3_warplab_agc/agc_abcd/agc_a/stage_ud/sample_count

w3_warplab_agc/viq_entity/dual_channel_viq1-4

w3_warplab_agc/rssi_preprocessor/avg_rssi_db1-4

w3_warplab_agc/control_system

Offline

 

#2 2014-Nov-11 21:18:27

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: AGC operation

The AGC in WARPLab 7.4 estimates the amplitude of the I/Q signals using two 16-sample averages. The 16-sample average captures one full short symbol from th preamble. The preamble has many concatenated short symbols, so any 16-sample selection will capture the same sequence with some cyclic shift.

The trigger delay only affects the time between the trigger event (Ethernet packet, energy detection, external pin assertion) and the trigger output to the AGC core. The AGC core state machine runs the same process independent of the trigger delay- it just starts later if the trigger arrives later.

The IIR filter in the AGC core implements a high-pass filter with very low cutoff frequency. This helps reduce slowly varying DC levels during long Rx captures.

The AGC core in WARPLab 7.4 is designed in System Generator. Unfortunately the source model is not available due to an old NDA between Rice and Maxim. We are planning to use a re-designed AGC core in WARPLab 7.5 (coming soon), based on the wlan_agc core we built for the 802.11 Reference Design. You can look at the wlan_agc core for an idea of the gain selection state machine.

Offline

 

#3 2014-Nov-11 22:25:54

vbarsoum
Member
Registered: 2014-Sep-08
Posts: 25

Re: AGC operation

1. Is the state machine designed to adjust the gain once?
2. Which module contains the state machine?
3. Does this mean that you don't use the input value of rssi for gain evaluation? and only use the i/q values?

Offline

 

#4 2014-Nov-11 23:50:28

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: AGC operation

1. Is the state machine designed to adjust the gain once?

Yes. It first estimates the Rx power using RSSI. Based on the RSSI value it adjusts the RF gain. It then re-evaluates RSSI, in case the actual Rx power was so high it caused RSSI to saturate when the RF gain was at max. If necessary the RF gain will be reduced one step further.

After setting the RF gain the AGC core calculates the magnitude of the I/Q waveform and uses this to set the Rx baseband gain. Once the baseband gain is set the Rx DC offset is estimated by averaging the I and Q signals over 16 samples (the short symbol is zero-mean with period 16). The DCO estimate is subtracted from the I/Q streams, then the HPF filter I mentioned above is enabled.

After the HPF is enabled the AGC core de-asserts the MAX2829 RXHP signal to re-enable DC coupling through the Rx path. At this stage the AGC core will make no further changes until it is reset and re-triggered.

Offline

 

#5 2014-Nov-18 02:55:58

vbarsoum
Member
Registered: 2014-Sep-08
Posts: 25

Re: AGC operation

Thanks for that. Can you also describe the difference between the input control signals:
(mreset_in, packet_in, reset_in)?

Offline

 

#6 2014-Nov-18 11:40:36

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: AGC operation

If you look in the XPS project, you can see how the ports are connected.

The packet_in port is connected to the trigger 1 output of the trigger manager.  This is how the trigger manager indicates that the AGC core should start operation, as long as the AGC is enabled (ie warplab_AGC_WriteReg_AGC_EN(1)).

Both the mreset_in and reset_in ports are connected to ground.  We do not use any hardware level resets for the AGC.  Instead, we only use software resets.  The mreset_in port is equivalent to using the warplab_AGC_WriteReg_MRESET_IN() function, while the reset_in port is equivalent to using the warplab_AGC_WriteReg_SRESET_IN() function.  One thing to note is that the reset_in port is also equivalent to a timeout reset (see the BB_AGC_RESET_TIMEOUT command in wl_baseband.c).  The "mreset" is the "master reset" and should only be done once per power up.  The other "resets" are a packet level reset to clear the AGC state for computing the AGC of the next packet.

Hopefully, this helps.  You can get a decent sense of how everything is used if you study wl_baseband.c.  One thing to note (as Patrick said above) is that we will be replacing this AGC with an AGC based on the wlan_agc core in WARPLab 7.5.0.

Offline

 

#7 2014-Nov-19 02:16:43

vbarsoum
Member
Registered: 2014-Sep-08
Posts: 25

Re: AGC operation

Thanks a lot, there are fewer things that confuse me now:

1. whenever I want the AGC to rerun (through a new packet detection or through software), do I need to trigger both (packet_in) and (reset_in)? or only one of them is enough to restart the AGC?
2. Can you give more description about how the timeout works?
3. What does the (reset) output port of "agc_abcd" block means?
4. What does the (reset_ and (m_reset_out) ports of "control_system" subblock mean?

My analysis for the RTL is as follows:-

(packet_in) input port ORed with (packet_in) register will arrive to "control_system" subblock after a delay determined by (AGC_TRIGGER_DELAY).
(reset_in) input port ORed with (s_reset_in) input register ORed with the ANDing of (reset_no_timeout) and (reset) output port of "agc_abcd" block.
Inside "control_system" subblock,

en_blocking.en_in = ( not (m_reset_out) after 100 cycles ) AND ( rising_edge(packet_in) ) AND ( not (reset_in) )

which means (pakdet_in) will not be effective unless (reset_in == 0) and 100 cycles has passed after the last (m_reset), am I correct?

so for consequent packets, we need to one pulse on (reset_in), and after (clock_cycles >= 1) another pulse on (packet_in), assuming (m_reset == 0). please correct me if I am wrong.

Offline

 

#8 2014-Nov-19 15:59:16

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: AGC operation

Unfortunately, the reset of the AGC is a bit complex.

First, let me answer the connection questions to give you a bit of a better picture of how things are connected:

3. What does the (reset) output port of "agc_abcd" block means?

The output port of the "agc_abcd" is the logical OR of all the reset output of the AGC_* blocks (where * is [A,B,C,D].  For each block, the reset output is either the timeout reset or if the RF_settings indicate that RSSI is "Too Low" based on the programmed thresholds. 

4. What does the (reset_ and (m_reset_out) ports of "control_system" subblock mean?

The "reset" output of the control system goes to the RST input of the "agc_abcd" block and resets the state the gain calculations. 

The "m_reset_out" output of the control system goes to the "viq", "rssi_preprocessor" and "agc_abcd" blocks and acts as a "master reset" to reset all the averaging logic, dco, and agc timing.  Once initialized, there is not really a need to issue a "master reset" during normal operation since all of the parameters that require a "master reset" are not exposed to M code (see warplab_agc_init() for more information).


Now, a bit more on the reset logic:

1. whenever I want the AGC to rerun (through a new packet detection or through software), do I need to trigger both (packet_in) and (reset_in)? or only one of them is enough to restart the AGC?

For proper operation, you need to trigger both the packet_in and the reset_in.  However, in normal WARPLab operation, the reset timeout triggers the reset automatically after the packet has been received.  If you look at the warplab_agc_init() function, you can see that by default the reset timeout is 100 cycles longer than the RX buffer.  This means that 100 cycles after the RX buffer has been filled, the AGC will automatically be reset and ready to be triggered again.

2. Can you give more description about how the timeout works?

You can see the basic behavior with the "agc_reset_on_timeout" and the "agc_reset_timeout_value" commands in wl_baseband_buffers.m.  You set a counter value and whether or not the resets from the counter are allowed to reset the AGC.  When the AGC begins computing gains (ie when it gets a packet), the counter starts counting until it reaches the timeout value and then issues a reset.   Part of the reason for having this functionality is that with this you can perform multiple AGC calculations in a single RX buffer without needing Matlab in the loop since Matlab could not meet the real-time deadlines needed to reset the AGC within an RX buffer.  This is also why "AGC Done" is one of the trigger inputs so you could qualify the AGC trigger output (ie packet_in) with the state of the AGC. 


Hopefully this gives you a better understanding of the AGC.  In terms of your analysis of the RTL, you are correct.

Offline

 

Board footer