WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2014-Jan-30 11:31:28

nanand
Member
Registered: 2014-Jan-30
Posts: 3

"Pausing" WARPLab7 AGC

I am attempting to pause WARPLab 7's AGC for every other transmission. 

My loop consists of two transmissions.  For the first transmission, I would like to have the AGC enabled.  For the second transmission, I would like the receiving nodes to keep the same gain settings as the previous transmission.

I am trying to accomplish this by using the 'output_config_hold' trigger configuration setting.  I believe this will force the specified trigger to stay triggered until I manually clear it.  Thus, this is what I'd like to do:

Code:

/* .. snip .. */

// Setup
wl_triggerManagerCmd(rxNodes,'output_config_input_selection',[T_OUT_BASEBAND,T_OUT_AGC, [T_IN_ETH,T_IN_REG]);
wl_triggerManagerCmd(rxNodes, 'output_config_hold_mode',[T_OUT_AGC],'enable');

while(1) {

   // load samples
   eth_trig.send();

  // process samples
  // load new samples
  eth_trig.send();

  wl_triggerManagerCmd(rxNodes, 'output_state_clear',[T_OUT_AGC]);

}

However, whenever the AGC completes, it resets to maximum gains to ensure reception of the next packet.  The only way I can currently overcome this is to switch to MGC halfway through and do the following:

Code:

/* .. snip .. */

// Setup

while(1) {
    
   
   // load samples
   eth_trig.send();

  agcState = wl_basebandCmd(allRx, RFA, 'agc_state');                           // Save State
  wl_interfaceCmd(rxNodes, RFA,'rx_gain_mode','manual');                        // Disable AGC
  wl_interfaceCmd(rxNodes(1), RFA,'rx_gains',agcState{1}(1), agcState{1}(2));   // Set previous gains
  wl_interfaceCmd(rxNodes(2), RFA,'rx_gains',agcState{2}(1), agcState{2}(2));


  // process samples
  // load new samples
  eth_trig.send();

 wl_interfaceCmd(rxNodes, RFA,'rx_gain_mode','automatic'); // Re-enable AGC
}

This process adds additional latency between the two transmissions that I am trying to avoid.  I was going to attempt modifying your warplab AGC pcore but it is not part of the repository.  Is there another way for me to explicitly control the AGC behavior that resets the gains to maximum at the end of the packet?

Thanks,

Naren

Offline

 

#2 2014-Jan-30 19:39:23

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

Re: "Pausing" WARPLab7 AGC

When a trigger output is in "hold" the trigger manager core will ignore trigger inputs. This is designed to allow an energy detection event to trigger an Rx, then ignore new triggers until the PC has retrieved the captured samples.

I believe you could achieve your reset-trigger-hold-agc behavior by modfiying only the w3_warplab_trigger_proc core. Instead of clearing the agc_start signal when the source trigger is un-held, you could add logic to clear its from software (or on every-other trigger, or whatever other condition you need).

(I should add that I didn't actually design the w3_warplab_trigger_proc core- Chris will correct me if I got something wrong here)

Offline

 

#3 2014-Jan-31 10:57:52

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: "Pausing" WARPLab7 AGC

Try changing your m-code to this:

Code:

/* .. snip .. */

// Setup
wl_triggerManagerCmd(rxNodes,'output_config_input_selection',[T_OUT_BASEBAND,T_OUT_AGC], [T_IN_ETH,T_IN_REG]);

while(1) {

wl_triggerManagerCmd(rxNodes, 'output_config_hold_mode',[T_OUT_AGC],'enable');

   // load samples
   eth_trig.send();

  // process samples
  // load new samples
  eth_trig.send();

  wl_triggerManagerCmd(rxNodes, 'output_state_clear',[T_OUT_AGC]);

}

i.e., move the agc trigger hold command to the top of the while loop. We just ran a test and verified that will have the agc stick with its gains across the two triggers. It will then choose new gains on the next iteration of the loop.

The "output_state_clear" does more than just clear the output state. It also changes the behavior of the trigger so that the next time it is called it won't be held. This counterintuitive behavior wasn't intended -- we intended it to work the way you were doing it originally. We'll fix that in a future release, but in the meantime simply re-applying the hold at the top of the loop should work for you. Also, it doing this won't affect latency between your transmissions since you are doing it before the first one.

Offline

 

#4 2014-Jan-31 11:55:07

nanand
Member
Registered: 2014-Jan-30
Posts: 3

Re: "Pausing" WARPLab7 AGC

I changed my loop to do as you suggested.  I used the 'agc_state' command to read the RF and BB gain settings after the first and second transmission--they are identical.

However, the actual gain on the received signal is not identical.  For example, if I set my agc_target value low enough to get a ~[-0.2, 0.2] signal during the first transmission, the second transmission will have a saturated [-1 1] signal even though the agc_state is read as the same value (I made sure to do two identical transmissions, no reloading of the buffers with new data).  Can you guys double check this?

I'm assuming that this is because the agc_state function reads the set RF and BB set gain values from the agc pcore instead of directly from the RF interface's register itself.  I noticed that your manual 'rx_gains' interface command does not have a readback function (its a TODO).  Would this be the "correct" way to double check the gain settings?  Is there a way for you guys to verify the on-chip registers?

If the agc_state function actually does read the true gain settings value, then I am obviously doing something wrong.  What functions or signals to the agc core would result in the gains being reset to maximum?  (all I can think of is agc_reset and I made sure that wasn't being called in my code in the loop).

Offline

 

#5 2014-Jan-31 13:10:21

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: "Pausing" WARPLab7 AGC

When the gains are being controlled externally, there is no way to pull the last-used gains from the radio controller. Any chance it was a fluctuation in the channel? Can you try the same experiment but over a wire with attenuation? Does the second transmission still spike upwards like gains are being reset back to higher values?

Offline

 

#6 2014-Jan-31 15:10:57

nanand
Member
Registered: 2014-Jan-30
Posts: 3

Re: "Pausing" WARPLab7 AGC

I am positive it is not a channel fluctuation.  When I try to do the same experiment but explicitly set the manual gain control, I receive a stream in an expected range.  Did you guys just read the agc state or did you look at the received signals from two subsequent transmissions?  If you did the latter, I am definitely doing something wrong. 

I was looking through the pcores and it appears that the only way for the agc pcore to be reset and write default gains from hardware is the PACKET_IN line.  That line is connected to trigger output 1 in the trigger_proc pcore.  It appears that one way to solve my problem is to add a warplab command that simply calls warplab_AGC_WriteReg_TrigEn(0) to disable the global enable and thus ignore the pkt after the first transmission and then warplab_AGC_WriteReg_TrigEn(1) after the second.  However, I am still looking for a way to do this without the extra commands.

I am looking through the trigger proc's Trigger Output 1 and I can't tell why my system isnt working.  As long as there is no additional rising edge coming out of Trigger Output 1, the agc's Packet In shouldnt trigger.  When in output hold mode, the reset on the S-R latch is released so whenever the latch goes high, it will stay high until the reset is re-enabled.  Where is the rising edge coming from?

Offline

 

#7 2014-Jan-31 15:52:36

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: "Pausing" WARPLab7 AGC

You're totally right. I wasn't actually looking at the received waveform before. It's definitely still resetting. We're looking into it...

Offline

 

Board footer