AGC and Coarse offset tuning RRS feed

  • Question

  • Hi all, 

    The critical problems of SORA is not support mobility environments. 

    Because SORA does not include intra packet AGC and coarse timing/freq offset tuning which should be done by short symbols of OFDM preamble. 

    Therefore, we have to use dut.exe to find the appropriate freq offset and rx/tx gain.

    As far as I know, fine tuning is already implemented. 

    Is there any plan to implement the AGC and coarse freq offset compensation?

    Thank you.


    • Edited by Okhwan Lee Monday, May 13, 2013 6:07 AM
    Monday, May 13, 2013 6:06 AM

All replies

  • Hi Okhwan,
    If you check the 'umxsdrbrick.exe' source code in SoraSDK v1.8, you will find related code.
    1. Per-packet AGC: Check_RxGain (only working in 802.11a in client mode, ie. communicating with access point)
    2. freq offset tracking: print_status (only working in 802.11a in client mode, ie. communicating with access point)

    • Proposed as answer by Qi LuoEditor Tuesday, May 14, 2013 3:38 AM
    Tuesday, May 14, 2013 3:38 AM
  • Hi Luo,

    That is not the case what I want.

    The AGC and freq offset of commercial NIC works as follows:

    1. Estimate the channel by using short symbol (known symbol, L-STF).

    2. And perform automatic gain control convergence, timing acquisition, and coarse frequency acquisition by using the estimated channel information

    3. And decode DATA symbols while compensating phase distortion by using pilot subcarrier

    In Sora code, 

    "1" is implemented to detect 802.11a signal and sync timing. 

    "3" is also implemented as well 

    However, "2" is not implemented. 

    What I mean, the Sora find the rxgain in try-and-error manner. It just try to decoding with a rxgain value. if fail to decode, it decreases the rxgain value for the next packet. This is not AGC. 

    Sora cannot decode any packets in high mobility environments or time-varying fading channel because even if sora finds the appropriate rxgain via the previous packet, sora cannot use the rxgain for the next packet. 

    As far as I know, sora supports fine frequency offset tuning (channel_11a.hpp) and timing offset acquisition (symtiming.hpp).

    However I cannot find any code for AGC and coarse freq offset tuning.

    If 11a_brick support AGC and coarse freq offset tuning, the umxsdrbrick (with 11a) can tx/rx without rxgain control and manual freqoffset setting (dut.exe freqoffset --value 8000)

    Please refer the signal processing of actual receiver presented in " Transmitter modulation accuracy (EVM) test" of IEEE 802.11n-2009 standard.

    1. a)  Detect the start of frame.

    2. b)  Detect the transition from short sequences to channel estimation sequences, and establish fine timing (with one sample resolution).

    3. c)  Estimate the coarse and fine frequency offsets.

    4. d)  Derotate the frame according to estimated frequency offset.

    5. e)  Estimate the complex channel response coefficients for each of the subcarriers and each of the transmit chains.

    6. f)  For each of the data OFDM symbols, transform the symbol into subcarrier received values, estimate the phase from the pilot subcarriers in all spatial streams, derotate the subcarrier values according to estimated phase, group the results from all the receiver chains in each subcarrier to a vector, multiply the vector by a zero-forcing equalization matrix generated from the channel estimated during the channel estimation phase.

    7. g)  For each data-carrying subcarrier in each spatial stream, find the closest constellation point and compute the Euclidean distance from it.

    8. h)  Compute the average of the RMS of all errors in a frame. It is given by Equation (20-89). 

    Thank you for your answer. 


    • Edited by Okhwan Lee Tuesday, May 14, 2013 6:30 AM
    Tuesday, May 14, 2013 6:28 AM
  • Hi Okhwan,
    Thanks for your suggestions. We don't have plans to implement the intra-packet AGC and intra-packet coarse freq offset tuning as you expected in SoraSDK sample code, in the near future. Those are definitely good directions to improve, if the baseband will be used in pactice mobile environment. We are strongly welcome contributes to our code base on those features.


    • Proposed as answer by Qi LuoEditor Tuesday, May 14, 2013 8:01 AM
    Tuesday, May 14, 2013 8:00 AM