You are not logged in.
Pages: 1
Hi,
With reference to https://warpproject.org/trac/wiki/OFDM/ … toResponse
In this particular function, PHY_AUTORESPONSE_TXACTION_CONFIG(pktBuf, actionOptions, delay, conditions),
"delay: number of 0.25µs increments to delay the automatic transmission. The time starts when the final byte of the incoming packet is decoded, even if the actor doesn't depend on the payload error status "
The maximum value that we can specify is 255 ticks. 1 tick = 0.25µs, so I expect, 255 ticks = 63.5µs.
Contradictory to my calculations, I observed in OFDM reference design model, in the module AutoResponseProcessing/AutoResponseI/O,
The delay value that we pass is shifted left by 1 bit, acheived by concatenating 0 to the LSB, so 255*2 = 510, now that we have 510 ticks and OFDM module is on the bus which operates at plb_32b_40MHz, Therefore 1 tick = 1/40MHz = 0.025µs and not 0.25µs, thereby I get a delay of 0.025µs * 510 = 12.75µs instead earlier shown 63.5µs.
Could you please help me in understanding which is right ?
Regards,
Anil Gowda
RWTH Aachen
Offline
I think the 0.25µs unit on the wiki page is an error.
In the autoresponder logic the counter which implements the Rx-Tx delay is clocked at 20MHz, half the 40MHz system clock (i.e. if you enable sample time colors in the Simulink model the counter is green).
The counter output is compared to a user-specified 13-bit delay value. This 13-bit value is constructed as:
usr_dly = [usr_extra_delay[3:0] usr_autoResp_dly[7:0] 0]
where usr_autoResp_dly is the 8-bit value you pass to PHY_AUTORESPONSE_TXACTION_CONFIG and usr_extra_delay is the 4-bit value passed as the second argument to mimo_ofdmTx_setDelays(). The usr_autoResp_dly value is set per autoresponder action block. The extra delay is used by all autoresopnse actions.
Given this construction, the effective unit of usr_autoResp_dly is 100nsec (2 * 1/20MHz) and the effective unit of usr_extra_delay is 25.6µs (2^9 * 1/20MHz).
Offline
Thank you so much for your quick reply,
so as per your explanation, if I set delay to its max value 255, I can expect a delay of 25.6µs, with 1 tick equivalent to 100nsec.
let say for example, station X should send an acknowledgement for an incoming packet.
Condition for autoresponder to fire is : incoming packet should belong to station X
If I set a delay of 255, Is 25.6µs, the total auto-responder's response time ? or do we have an extra delay coming from the hardware turn around. If so, How do I monitor this extra timing offset ?
Offline
If I set a delay of 255, Is 25.6µs, the total auto-responder's response time ? or do we have an extra delay coming from the hardware turn around. If so, How do I monitor this extra timing offset ?
The autoResponder controls the "Tx start" signal for the Tx PHY. This signal initiates the Tx state machine. This first asserts the radio_controller start, which enables the radio Tx, the PA, ramps the Tx VGA gains, then sends a feedback signal to the Tx PHY. This feedback from the radio_controller starts the Tx PHY pipeline, which begins outputting samples to the Tx DACs. The timing of this entire process is deterministic, controlled by the radio_controller TxTiming parameters and the delays through the Tx DACs and radio circuits. I do not know the actual delay values from memory- I would guess it's a few usec all together.
Offline
I will try to add an offset of few µs may be 5µs to my system to counter such hardware turn around time, hope it should be sufficient.
or try to monitor using logic analyzer to accurately determine the time difference between a high on the Rx_pin and subsequent high on Tx_pin on the warp board directly,
I belive it should be equal to (the set delay + hardware turn around time).
Thanks again for your reply !
Offline
Pages: 1