• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 618 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AIF2 support for LTE UE Downlink timing offset

Shivatejas Bettadapura
Prodigy 70 points

Dear Albert,

I am trying to solve a similar problem. I have a setup in which the Ue Rx receives samples and calculates a frame boundary offset. Instead of correcting for this frame boundary offset by software, I am trying to use AT2 events to appropriately delay the arrival of interrupts to the DSP. At first, AT Evt 2 is enabled and upon estimation of the frame boundary offset, AT evt 1 is initialized and enabled. I first convert the required frame boundary offset into nanoseconds and then translate that into byte clocks using the IQN2 LLD. I paste a code snippet below:

at_evt2->EventSelect   = IQN2_AT2_EVENT_1;                    // Evt 1
at_evt2->EventOffset   = (frame_offset)*130;// Offset from frame boundary in nanoseconds

at_evt2->EvtStrobeSel =IQN2_getRadioTimerFrameStrobe(radtId);

at_evt2->EventModulo   = 500000;               // 0.5ms in ns (lte slot)
// Convert to byte clocks prior to IQN2_initAt2Event()

IQN2_initNanoSecsToByteClocks(pIqn2LldObj,at_evt2);

Would this approach work?

Thanks,

Regards,

Shiv.

  • 0
    TI__Guru* 81335 points

    Hi Shiv,

    This thread has been split from below e2e thread,

    Note: We strongly recommend you to create new e2e thread for your queries instead of following up on an old/closed e2e thread, new threads gets more attention than old threads and can provide link of old threads or information on the new post for clarity and faster response.

  • 0
    TI__Mastermind 21025 points
    It seems reasonable, but from past experience with Ue downlink (not on Keystone devices) you have to constantly adjust the timing to account for movement of the device. I don't think you can predict future delays with a static offset (meaning you will have to be making adjustments continually). But perhaps I don't understand what you are trying to do. If you think it should work, give it a try. As they say, "the proof is in the pudding."