WARP Project Forums - Wireless Open-Access Research Platform

The LTG framework generates packets which are inserted into Tx queues. These are the same queues used for all wireless transmissions (management pkts, data from Etherhet, etc.). The LTG schedule controls the rate at which packets are en-queued. Setting the interval argument to 0 tells the LTG framework to generate a new packet every time the LTG scheduler fires, currently every 100usec (I think - Chris or Erik will correct me here if not). If the target queue for an LTG packet is full no new packet is created. Thus, setting interval=0 will quickly fill the target queue, resulting in fully-backlogged traffic to the target node.

Packets are de-queued from the Tx queues one at a time and passed down to CPU Low for processing by the DCF and eventual transmission. The DCF state machine treats LTG packets like any other MPDU. Unicast MPDUs wait for ACKs and re-transmit on timeouts; broadcast MPDUs don't. The interval of the LTG (the minimum interval at which LTG packets are enqueued) does not affect how the DCF handles the LTG packets.

A few clarifications-
-The event log at each node contains all Tx and Rx events seen by CPU High at that node, including (but not only) LTG Tx/Rx events

-LTGs are terminated with the 'node.ltg_stop(ltg_id)' method. The 'time.sleep()' calls only pause execution of the python script and do not affect any state at the nodes.

-By default only the MAC header and LTG headers are logged for each Tx/Rx event. To enable full payload logging you must call 'node.log_configure(log_full_payloads=true)'. However the LTG payloads are arbitrary; each LTG payload will be whatever data was left in the Tx queue entry where the LTG packet was created (i.e. the LTG code does not write any payload, it just sets the length and uses whatever data is already in DRAM).

-If you call 'node.log_get_all_new(log_tail_pad=0))' once it will fetch all log data from the node, starting from when the log was last reset (either from boot or when you last called node.reset_all())

Here I need the Rx data before Viterbi decoding, which means in the format (PHY header + MAC hearder + LTG payload), rather than decoded LTG payload.

The values before the decoder are not written to memory. The decoder inputs are soft bit values (log-likelihood ratios) calculated by the PHY's demodulation block.

The PHY header, MAC header and LTG payload are all post-decoder values. These bytes are the contents of the Rx packet passed up from CPU Low to CPU High for each reception.

(2) For a Tx/Rx log file, I wanna analyze its content in detail. For example, the timestamp value, node id information, PHY header part, MAC header part, etc. I wanna know the exact Tx/Rx time for each packet. Are there any functions provide in the log folder can do this kind of work?

Yes, these values are all included in the logs. See the txrx_log_analysis example for a good starting point. The full description of each log entry type is documented in the ref design user guide: /802.11/wlan_exp/log/entry_types.

1) If you look, the 'mac_payload' length is different for the LTG vs non-LTG entries (ie 44 bytes vs 24 bytes, as of release 0.96).  This stems from the fact that non-LTG entries only contain the MAC header, while the LTG entries contain the MAC header plus the ltg_packet_id.

In order to differentiate LTG vs non-LTG log entries, there are different entry types.  However, sometimes we want to just "process all TX packets" and do not care about the extra information contained in LTG entries.  Since LTG entries are a strict superset of non-LTG entries, it is easy to merge the entries together so that all entries can be processed at once.  In log_process_details.py, since we are trying to get TX and RX details from the log, we merge the LTG and non-LTG entries together for a given type (ie we merge TX and TX_LTG; RX_OFDM and RX_OFDM_LTG; etc.)  Just note, that when you merge entries, you should only use the subset of fields that are common to all the entries since those are valid for all the entries you merged. 

2) You can configure the filter between CPU low and CPU high with the set_low_to_high_rx_filter() command.

3) First, why do you need a more precise timestamp value?  Given the timeframes of 802.11, we did not see the benefit of a more precise timestamp but want to understand if there was something we missed.  Second, this would require a lot of work.  Currently, there is a microsecond counter that we use to timestamp everything.  You would need to modify the hardware design to increase the precision of this counter, then update every place that the value of that counter is used so that it deals with the new definition of the timer.

(1) Now I’m trying to make two nodes STA1 and STA2 always transmit simultaneously, with a time-offset no more than on one CP length (0.8μs). That’s why I need a more precise timestamp value. I want to ascertain that the simultaneous transmissions are indeed within-CP(0.8μs).

This is a challenging problem. Initiating transmissions from multiple nodes within the cyclic prefix may not work if you're relying on software polling the MAC timestamp to schedule transmissions. Timestamp offsets among nodes and jitter in the software execution will both contribute to offsets in the nodes' transmissions.

One alternative I would suggest exploring is to re-purpose the auto-tx logic in the MAC core. This logic is used to transmit ACK packets after the node receives a DATA packet with no bit errors. The standard requires the ACK be transmitted within ±10% of one slot (±0.9usec). Our implementation is even tighter than this, as the logic triggers the ACK transmission a fixed number of clock cycles after the DATA Rx completes.

You could re-use this logic to coordinate transmissions by multiple nodes, with each node transmitting in response to a particular packet reception. These transmissions should occur within a few clock cycles of each other (assuming the propagation time from the trigger-sending to each trigger-receiver is the same). The trigger packet could be anything- the conditions for starting the auto-tx are controlled from software. Take a look at frame_receive() in the DCF code to see how the auto-tx logic is setup for ACK transmissions.

(2) We’re using 4 WARPv3 (3 STA, 1 AP) to evaluate some physical technologies. Currently, there are many entries in .hdf5 Tx/Rx log files. How can I extract actual PHY Tx/Rx streams from these entries? Because I want to convert those Tx/Rx streams into a .datb file, and then import the file into a Matlab program, in order to check the performance of preamble correlation, channel estimation, and so on.

Look at the chan_est_viewer example - this demonstrates processing a raw log file for further processing in MATLAB.