You are not logged in.
Hi, I am trying to add small modifications to the MAC state machine A, by using the postTx_timer1, which is not enabled in the reference code
By setting the postTx_timer1, I want to delay the transmission time of the packets.
I tried to follow the instructions mentioned here http://warpproject.org/trac/wiki/802.11/MAC/Support_HW.
first, I set a value to the Tx_timer1
then, I enabled it and used the corresponding wlan_mac_tx_ctrl_A_params().
But the generated output pattern is totally random.
I think I have mistakenly done the configuration.
Could you show me the general direction of using Tx-timer1?
Here is the code:
u32 value= 0x00001111 & 0x00007FFF; // the value is set to the postTx_timer1, in the unit of 100ns
wlan_mac_set_postTx_timer1(value);
wlan_mac_postTx_timer1_en(1); // enable this postTx_timer1
wlan_mac_tx_ctrl_A_params(mac_cfg_pkt_buf,mpdu_tx_ant_mask,n_slots,0,1,req_timeout); // setting the preWait_postTxTimer1 to be 1 for the FSM
Thanks in advance.
Sincerely
Offline
I don't track what behavior you're trying to implement.
Are you trying to transmit a second packet a fixed interval after transmitting a first packet? Or are you trying to delay a single transmission by a fixed interval?
The postTx timers only run immediately after a Tx event. The postTx timers are only "done" for 1 cycle, when the timer reaches its target value. The timer then resets and waits for the next Tx event. The Tx controllers that have "preWait" inputs should only be configured to use the "preWait" inputs when you're sure a corresponding Tx/Rx event has just occurred. For example, we use the Tx Controller B "preWait_postRxTimer1" condition to implement the SIFS interval between a DATA Rx event and ACK Tx. The Tx B state machine is enabled immediately after an Rx event completes, in a window where we're sure postRxTimer1 is currently running.
Offline
Thanks so much for the help!
My purpose is to delay a single transmission by a fixed interval.
I was confused about the word 'post'. So in the post-Tx and post-Rx timers, the 'post' means the timer after some events (Tx and Rx)? I thought I can delay the transmission of a single packet by seeting the postTxTimer1.
Thanks again for your precious time.
My previous idea is to change the Tx Controller A FSM, which handles the transmission of normal packets. For the state machine graph of Tx Controller A FSM, is it available to make some modifications of the PRE_TX_WAIT, while there is not existing TX/RX events?
Offline
I was confused about the word 'post'. So in the post-Tx and post-Rx timers, the 'post' means the timer after some events (Tx and Rx)?
Right. There are 2 postTx timers. These timers (if enabled) are started after every Tx event. There are 2 postRx timers, likewise started after every Rx event. The timers alone don't affect MAC state in any way. The 3 Tx controllers (A, B, C) can be configured to wait on the timers when the MAC needs to schedule an event relative to a previous Tx/Rx event. ACK Tx and CTS Tx, for example, occur T_SIFS after the previous Rx. The DATA Tx timeout occurs if a postTx timer expires without receiving an ACK.
The postTx/Rx timers will not be useful for delaying a standalone Tx (i.e. one not scheduled relative to a previous Tx/Rx event). A few alternatives:
-Add a usleep() in the lower MAC code before calling wlan_mac_tx_ctrl_A_start(1)
-Modify the backoff handling to implement your pre-Tx delay scheme. Keep in mind the backoff counter only decrements when the medium is idle, so starting a backoff of N slots only guarantees a pre-Tx delay >= N*T_SLOT.
Offline
Thanks so much for the comments.
I have tried these two methods before.
(1) I added the usleep() to delay the call of wlan_mac_tx_ctrl_A_start(), but this method seems to have troubles with other code, such as packet reception.
(2) I set the number to bacoff(time), but the actual delay depends on the wireless interference, and is uncontrollable.
Are there some other ways to do this?
If I want to add one timer in the FPGA for controlling such a process, do you have some suggestions (such as the learning strategy)?
Offline
How long of a pre-Tx delay are you trying to implement (10's of usec? msec?)? And what event represents the start of the delay? For example, are you trying to delay a Tx relative to a previous Tx? Or do you just want a delay between software calling wlan_mac_tx_ctrl_A_start() and the actual Tx?
Offline
I want to delay one single transmission by several milliseconds, and the delay is between the time when the packet enters the frame_transmit() to the time when the actual transmission is started (not related to a previous transmission).
Offline
I agree-- for something that long, you probably don't want to block the code with a usleep(). I'd suggest sticking with software modifications at first unless you figure out that you really need to alter the FPGA design.
The MAC Low Framework has wlan_mac_low_disable_new_mpdu_tx() and wlan_mac_low_enable_new_mpdu_tx() that control whether or not the framework is allowed to call frame_transmit() with a new transmission. Any new transmission request from CPU_HIGH that arrives after wlan_mac_low_disable_new_mpdu_tx() is called will be deferred until wlan_mac_low_enable_new_mpdu_tx() is called. Rather than delay your transmission after entering frame_transmit() and before wlan_mac_tx_ctrl_A_start(), you could effectively get the same behavior by delaying the call to frame_transmit() via these commands.
Rather than implement the delay with a usleep, I'd suggest polling the system usec time in the main() loop of the DCF alongside the other polls. You can use the get_system_time_usec() call to get the current time and check to see if enough time has passed before calling wlan_mac_low_enable_new_mpdu_tx(). If not, do nothing and let the main() loop continue to poll for new receptions, etc. That's basically what a usleep() does anyway. By unrolling it to allow for the other polling operations to take place you can prevent it from blocking other receptions.
Note: if you still want your code to be notified when frame_transmit() would have been called, you can call a function you write in the DCF in this else() clause. That's when the framework decides not to call frame_transmit() because you had previously called wlan_mac_low_disable_new_mpdu_tx(). So, for example, this could be where you set the criteria for the system time polling in main().
Offline
I am also interested in this topic. From previous discussion I know that the timers can only be started after a packet transmission. So it is not able to defer the transmission of a packet.
However, I am thinking is it possible to make a peudo packet transmission before transmitting the actual packet. I mean we pretend to transmit a packet by
wlan_mac_tx_ctrl_A_params(pktBuf, antMask, preTx_backoff_slots, preWait_postRxTimer1, preWait_postTxTimer1, postWait_postTxTimer2, phy_mode)
But we set pktBuffer to be a null pointer (or anything that won't actually been sent). The only goal is to start a postTxTimer. When the postTxTimer counts down to 0, we start a real packet transmission.
I am not sure whether such a design is possible, because the detail of wlan_mac_tx_ctrl_A_params is hidden in FPGA design.
Last edited by wenchao88 (2016-May-19 13:18:58)
Offline
I am also interested in this topic. From previous discussion I know that the timers can only be started after a packet transmission. So it is not able to defer the transmission of a packet.
However, I am thinking is it possible to make a peudo packet transmission before transmitting the actual packet. I mean we pretend to transmit a packet by
But we set pktBuffer to be a null pointer (or anything that won't actually been sent). The only goal is to start a postTxTimer. When the postTxTimer counts down to 0, we start a real packet transmission.
This is not a good approach. The MAC core's Tx controllers are designed to start the Tx PHY. Once started Tx PHY reads the designated packet buffer and creates a waveform using the information in the buffer. The Tx PHY must be configured with a valid packet buffer index (there is no "null" index), and that packet buffer must contain a valid header/payload.
Did you consider Chris' suggestion in post #8? Polling the System Time from the CPU Low main() loop is a good idea. This would allow scheduling a Tx at an arbitrary time while still performing CPU Low's normal handling of wireless Rx and IPC message Rx.
Offline
murphpo wrote:
Did you consider Chris' suggestion in post #8? Polling the System Time from the CPU Low main() loop is a good idea. This would allow scheduling a Tx at an arbitrary time while still performing CPU Low's normal handling of wireless Rx and IPC message Rx.
I tried Chris's suggestion to poll the system time from the main() loop. What I did is
while(1){
// Poll PHY RX start
wlan_mac_low_poll_frame_rx();
// use a global timer to control pkt transmission
if(global_timer_flag == 1){
global_toc = get_system_time_usec();
if(global_toc - global_tic > global_timer){ //global_timer is the time I want to perturb data packets, tic is the start mac time of the timer
global_timer_flag = 0;
}
}else{
// Poll IPC rx
wlan_mac_low_poll_ipc_rx();
}
// Poll the timestamp (for periodic transmissions like beacons)
poll_tbtt();
}I set "global_timer" and "global_tic" in the frame_transmit function, just before the actual packet transmission (because I want to accurately control the timing of data packets). In this way, I can accurately control time in main function. Is it right?
However, it doesn't work because when I set "global_time" and "global_tic", I am already in the frame_transmit function, just before the packet transmission. How can I jump the packet transmission command? I mean like an interrupt, when I decide to perturb data packets, I can jump to the main function. Then when I have waited enough time (global_toc - global_tic > global_timer), I can jump back to the original place.
I tried to use "goto" to jump to the end of frame_transmit function. However, the perturbed packet seems lost and will never be transmitted.
Last edited by wenchao88 (2016-May-23 22:55:14)
Offline
Trying to delay a transmission to sometime in the future from the frame_transmit() context isn't going to work. The MAC Low Framework expects frame_transmit() to exit once the transmission is "done." The key is to delay frame_transmit() itself from ever being called until you are ready for it. In addition to my suggestion of polling system time from the main loop(), my previous comment addressed this as well:
chunter wrote:
The MAC Low Framework has wlan_mac_low_disable_new_mpdu_tx() and wlan_mac_low_enable_new_mpdu_tx() that control whether or not the framework is allowed to call frame_transmit() with a new transmission. Any new transmission request from CPU_HIGH that arrives after wlan_mac_low_disable_new_mpdu_tx() is called will be deferred until wlan_mac_low_enable_new_mpdu_tx() is called. Rather than delay your transmission after entering frame_transmit() and before wlan_mac_tx_ctrl_A_start(), you could effectively get the same behavior by delaying the call to frame_transmit() via these commands.
...
Note: if you still want your code to be notified when frame_transmit() would have been called, you can call a function you write in the DCF in this else() clause. That's when the framework decides not to call frame_transmit() because you had previously called wlan_mac_low_disable_new_mpdu_tx(). So, for example, this could be where you set the criteria for the system time polling in main().
The process should look something like:
1) Call wlan_mac_low_disable_new_mpdu_tx() at boot
2) Call yourNewFunction() from url=https://warpproject.org/trac/browser/ReferenceDesigns/w3_802.11/c/wlan_mac_low_framework/wlan_mac_low.c?rev=5490#L919]in this else() clause[/url]. yourNewFunction() should set "global_timer" and "global_tic"
3) In the main() while loop, call wlan_mac_low_enable_new_mpdu_tx()[ after the correct amount of time has elapsed.
4) At the end of frame_transmit(), you could call wlan_mac_low_disable_new_mpdu_tx() again to start the process over again if you want to delay the next transmission as well.
Offline