WARP Project Forums - Wireless Open-Access Research Platform
You are not logged in.
#1 2014-Sep-18 16:02:43
- obch
- Member
- Registered: 2014-Sep-18
- Posts: 3
Multiple AGC reset/triggers per buffer in WARPLab 7.4
Hey guys,
Topology:
transmitter - 1 node with 4 transmitting antennas
receiver - 1 node with a single receiving antenna
I am trying to receive multiple 802.11 preambles from multiple transmitting antennas (all within one single buffer for scalability purposes).
That is, every time I read one buffer I need to read 4 time-staggered preambles from 4 different transmitters.
AGC seems to be triggered only on a "per-buffer" basis. Is it possible to modify WARPLab's reference design to reset and re-trigger AGC for
each preamble? If so, where would you suggest to begin modifying the system design?
Thanks!
Last edited by obch (2014-Sep-18 16:06:24)
Offline
#2 2014-Sep-19 13:20:46
- murphpo
- Administrator
- From: Mango Communications
- Registered: 2006-Jul-03
- Posts: 5159
Re: Multiple AGC reset/triggers per buffer in WARPLab 7.4
The AGC core in the WARPLab ref design has a single trigger input, driven by the trigger processor core. The AGC state machine starts when triggered and resets after a programmable timeout. If you want to trigger the AGC multiple times in one Rx cycle you will need to modify the trigger processor core to generate multiple trigger assertions for the AGC per trigger event (i.e. one Ethernet trigger -> multiple AGC triggers). You would also need to adjust the AGC timeout (in C or m) to reset its state before the next trigger assertion.
Offline
#3 2014-Sep-27 19:21:37
- obch
- Member
- Registered: 2014-Sep-18
- Posts: 3
Re: Multiple AGC reset/triggers per buffer in WARPLab 7.4
Thanks murphpo!
I gave it a try but something is not working as expected. I modified the w3_warplab_trigger_proc model so that AGC resets after certain number of samples, then waits for a short period of time, and starts again (at least that's what I tried to do). I made all these variables reachable from matlab (and I know that the C/matlab bindings are working fine).
I introduced this logic between the Addressable Shift Register2 (Trigger Output1) and the trig_1_out gateway (which supposedly starts the AGC). I added a mux to select between this logic and the default behavior.
Is this the correct place to make such modification? I am not very sure how the AGC_done and resets in the AGC core work so that makes it a little bit difficult when trying to debug. I believe the AGC core is protected by an NDA, right?
Last edited by obch (2014-Sep-27 19:22:30)
Offline
#4 2014-Sep-29 11:24:25
- murphpo
- Administrator
- From: Mango Communications
- Registered: 2006-Jul-03
- Posts: 5159
Re: Multiple AGC reset/triggers per buffer in WARPLab 7.4
Did you update the AGC timeout value in your C or M code? The trigger processor only starts the AGC state machine. Once started, the AGC core ignores all subsequent triggers until it is reset. The default timeout value is the normal duration of a Tx/Rx cycle (2^15 samples for WARP v3).
Offline
#5 2014-Sep-29 16:37:45
- obch
- Member
- Registered: 2014-Sep-18
- Posts: 3
Re: Multiple AGC reset/triggers per buffer in WARPLab 7.4
I do change the timeout value. When timeout is reached, does it produce a pulse or does it hold the value high? If you notice in the figure, this is the received waveform, it consists of a very long packet (1x1 system - all 802.11 short training symbols) but the timeout is only triggered once. I used the 'agc_reset_on_timeout' and 'agc_reset_timeout_value' commands (about 100microseconds). I was expecting to see that large drop and then a gain reset multiple times as it happens initially. 
Offline
#6 2014-Sep-29 22:37:36
- welsh
- Administrator
- From: Mango Communications
- Registered: 2013-May-15
- Posts: 612
Re: Multiple AGC reset/triggers per buffer in WARPLab 7.4
Yes, you are correct to put the logic between the Addressable Shift Register 2 and the trig_1_out.
The PACKET_IN port of the AGC does a rising edge detect to start the AGC state machine. Therefore, based on the trigger and the AGC Timeout (it would probably be a good idea to implement a separate register inside the Trigger Processor core that you will set similarly to the AGC timeout; This will give you a lot of flexibility if you need to shift parts of the waveform by a few cycles) you need to implement a state machine that will generate a pulse a few cycles after the AGC timeout (i.e. the value set in the new register inside the Trigger Proc core) and will stop after approx. 2^15 cycles (i.e. the total number of IQ samples you can collect).
Hopefully that helps. Based on your waveform, it does not look like the AGC core is getting a second rising edge on the PACKET_IN port during the sample window.
Offline