WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2018-Apr-11 23:42:15

piconsaiii
Member
Registered: 2018-Apr-11
Posts: 1

how to receive a specific frame precisely

Hi. everyone:

I am using a 802.11 reference design v1.2.0.
I want AP can transmit a frame (e.g beacon)at the specific time and STA can also do the  wlan_mac_low_poll_frame_rx() at the same time to receive it. just like synchronization

※ Our testing environment is using cable to replace antenna. and the cable connect 2 warpv3.

first, I modified something in v1.2:
     1. I add a timer at CPU low. so that i can use the scheduler to transmit a frame(here i use beacon(i create it at TX packet buffer 6) , and turn off beacon frame at CPU-high).
     2. I extend the beacon interval from 100us to (1min or 10sec)
     
In the original v1.2.0, the beacon go through lots of processing like enqueue, dequeue.....before PHY-TX transmit it. I want beacon to be transmitted every min. if I just extend beacon interval to 1min, it create the beacon packet every min but  it's not the way i want.  (here it's my guess, is that correct??) That's why i make this change.

Second, I record some variable:
    1. the delay of the beacon in scheduler (this one : sched_ptr->delay)
    2. the target of the beacon in scheduler(sched_ptr->target)
    3. num_coarse_checks in timer_handler()
    4. the reset value of Load register
    5. the value of Timer counter register
i add this 5 variable at the tail of the association response. when STA receive all this info,  CPU LOW  wil wait a value K
(I refer the formula you do synchronize-->timestamp_diff = mpdu_ptr_u8)->timestamp - (mpdu_info->timestamp) + PHY_T_OFFSET, so the value i assume it's
(K = the value of Timer counter register -  PHY_T_OFFSET)

then,
it will change the way CPU-LOW do wlan_mac_low_poll_frame_rx() & wlan_mac_low_poll_ipc_rx()

the original v1.2 ↓
while(1){
        //Poll PHY RX start
        wlan_mac_low_poll_frame_rx();

        //Poll IPC rx
        //wlan_mac_low_poll_ipc_rx();       
    }

the way i modified↓ (using scheduler to trigger)

wlan_mac_schedule_event_repeated(SCHEDULE_COARSE, (delay receive from ass_resp * SLOW_TIMER_DUR_US), SCHEDULE_REPEAT_FOREVER, A function);

A function(){
wlan_mac_low_poll_frame_rx()
wlan_mac_low_poll_ipc_rx()
}

here is my problem:
  1.if the beacon interval is very small, it seems like no problem, but when i extend longer like 10sec or 1min, the synchronization may not success. is there better way to
improve? or the value K i calculated it is not the good way??

2.from now on, the CPU-LOW I used DCF. or i should use NOMAC to reach my purpose??

Offline

 

#2 2018-Apr-12 09:52:19

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: how to receive a specific frame precisely

A few things:

-Please update to the latest 802.11 Ref Design (currently v1.7.5). Design v1.2 is more than 3 years old - we have made *many* improvements since that release (see the changelog). It is hard for us to provide meaningful support for 3-year-old code.

-In recent releases the beacon Tx process is implemented in CPU Low. CPU High still specifies the contents of the beacon, but CPU Low decides when to transmit a beacon based on the current MAC Time. This architecture is required because beacons can be transmitted in between re-transmissions of other packets (i.e. if a TBTT (target beacon Tx time) occurs during a re-transmission backoff).

-The default ref design code already implements synchronization of MAC Times using the TIMESTAMP field in becaons. For AP+STA networks, the AP MAC Time becomes the master time, and STAs adopt the TIMESTAMP value in every beacon they receive from the AP. In IBSS networks every node can transmit beacons; nodes adopt the TIMESTAMP value if it's larger than their own MAC Time. This results in the node with the fastest oscillator defining the networks MAC Time.

-Very long beacon intervals will result in more drift between node MAC Times. Oscillator frequencies vary randomly, usually in a range specified by the manufacturer in ppm. You can think of "ppm" as "usec drift per second", so an N ppm frequency difference between two nodes means their clocks drift apart by N usec per second. The TCXO on WARP v3 is accurate to ~3ppm.

Offline

 

Board footer