You are not logged in.
How would I log the number of packets Received with good/bad checksum using python script?
Is there any framework already implemented for calculating packet error rate?
Offline
The RX_OFDM log entry contains a flag for FCS status. By default the reference code creates RX_OFDM entries for all receptions, good and bad FCS. You can isolate the good-FCS receptions by filtering on the flags field. Our examples do this - see Rx packet filter conditions in log_process_throughput_vs_time.py.
When calculating PER you should compare the total number of transmissions to the number of successful receptions. Some transmissions will not result in RX_OFDM entries. These missing receptions should count as packet errors.
Offline
Thank you, i added these three lines to throughput_two_nodes.py
node1_to_node2_num_rx_pkt = float(node2_txrx_counts_for_node1_end['data_num_rx_packets'])
node1_to_node2_num_tx_pkt_success = float(node2_txrx_counts_for_node1_end['data_num_tx_packets_success'] )
node1_to_node2_num_tx_pkt_total = float(node2_txrx_counts_for_node1_end['data_num_tx_packets_total'])
The results of the above are all same even after enabling RX_OFDM filter (node.set_low_to_high_rx_filter('MPDU_TO_ME', 'GOOD')) as you suggested in previous post. i.e
Node 1 -> Node 2: rcvd_pkt = 10777.0 Num_pkt_tx_success = 10777.0 total_tx =10777.0
However, i can see red led movements on board suggesting that not all packets are transmitted successfully.
Offline
However, i can see red led movements on board suggesting that not all packets are transmitted successfully.
The Tx/Rx counts structs above are only counting packets between your nodes. The red LEDs increment on all bad FCS receptions, including receptions from other nodes. Are you conducting your experiment over-the-air? If so it's likely your nodes are detecting and receiving packets from Wi-Fi devices.
Offline
shanon wrote:
Thank you, i added these three lines to throughput_two_nodes.py
node1_to_node2_num_rx_pkt = float(node2_txrx_counts_for_node1_end['data_num_rx_packets'])
node1_to_node2_num_tx_pkt_success = float(node2_txrx_counts_for_node1_end['data_num_tx_packets_success'] )
node1_to_node2_num_tx_pkt_total = float(node2_txrx_counts_for_node1_end['data_num_tx_packets_total'])
Hi, I have some questions about the position of getting tx and rx pkts. Based on the notes in throughput_two_nodes.py, starting from line 200, it says that we need to get rx pkts at receiving side and get tx pkts at the transmitting side. If I wnat to calculate PER, I need to get rx pkts at sta(node2) side and get total tx pkts also tx success pkts at ap(node1) side. While in above codes, I found it seems that all tx pkts were got from the node2 side, because "node2_txrx_counts_for_node1_start = node2.get_txrx_counts(node1)" in line 211, I am not sure whether my understanding is right or not, but when I get the tx pkts at the node2 side the same as above codes and disable node2 ltg, the number of tx_success and tx pkts equals to 0. Thanks for any answer!
BTW, when I get the tx pkts value, I found that the value of tx_success pkts is much smaller than the one of total_tx pkts, is that commom? Need I use tx_success pkts to calculate PER?
Thanks again for your great help!
Offline
JannieLee wrote:
Hi, I have some questions about the position of getting tx and rx pkts. Based on the notes in throughput_two_nodes.py, starting from line 200, it says that we need to get rx pkts at receiving side and get tx pkts at the transmitting side. If I wnat to calculate PER, I need to get rx pkts at sta(node2) side and get total tx pkts also tx success pkts at ap(node1) side. While in above codes, I found it seems that all tx pkts were got from the node2 side, because "node2_txrx_counts_for_node1_start = node2.get_txrx_counts(node1)" in line 211, I am not sure whether my understanding is right or not, but when I get the tx pkts at the node2 side the same as above codes and disable node2 ltg, the number of tx_success and tx pkts equals to 0.
You can calculate the Packet Delivery Rate (PDR) as (# of successfully received packets / # of sent packets). PER is (1-PDR). Part of the confusion may come from the fact that # of "tx success pkts" is an indirect way of approximating the # of successfully received packets from the other node. When using the DCF, the "data_num_tx_packets_success" at the Tx node is an lower bound on the number of successful data receptions from the Rx node. They will be identical if no ACKs are lost.
"data_num_tx_packets_success" is useful if you don't have access to statistics at the Rx node (e.g. it's a commercial Wi-Fi device). However, since you do control both the Tx and Rx nodes, calculating the PDR is just a matter of retrieving "data_num_tx_packets_success" from your Rx node and "data_num_tx_packets_total" from your Tx node.
Offline
chunter wrote:
JannieLee wrote:
Hi, I have some questions about the position of getting tx and rx pkts. Based on the notes in throughput_two_nodes.py, starting from line 200, it says that we need to get rx pkts at receiving side and get tx pkts at the transmitting side. If I wnat to calculate PER, I need to get rx pkts at sta(node2) side and get total tx pkts also tx success pkts at ap(node1) side. While in above codes, I found it seems that all tx pkts were got from the node2 side, because "node2_txrx_counts_for_node1_start = node2.get_txrx_counts(node1)" in line 211, I am not sure whether my understanding is right or not, but when I get the tx pkts at the node2 side the same as above codes and disable node2 ltg, the number of tx_success and tx pkts equals to 0.
You can calculate the Packet Delivery Rate (PDR) as (# of successfully received packets / # of sent packets). PER is (1-PDR). Part of the confusion may come from the fact that # of "tx success pkts" is an indirect way of approximating the # of successfully received packets from the other node. When using the DCF, the "data_num_tx_packets_success" at the Tx node is an lower bound on the number of successful data receptions from the Rx node. They will be identical if no ACKs are lost.
"data_num_tx_packets_success" is useful if you don't have access to statistics at the Rx node (e.g. it's a commercial Wi-Fi device). However, since you do control both the Tx and Rx nodes, calculating the PDR is just a matter of retrieving "data_num_tx_packets_success" from your Rx node and "data_num_tx_packets_total" from your Tx node.
Hi, thanks for reply. I still need to calculate the bit error rate. One method I am working on is trying to extract payload and data frame from sender and compare with payload and data frame from receiver. But when I display the Rx_OFDM log entry and TX_LOW entry, I didn't find data frame. There is no data frame in 'mac_payload' either. I display the constants and their types of TX_LOW and RX_OFDM as below:
For receiver:
[('timestamp', '<u8'), ('timestamp_frac', 'u1'), ('phy_samp_rate', 'u1'), ('length', '<u2'), ('cfo_est', '<i4'), ('mcs', 'u1'), ('phy_mode', 'u1'), ('ant_mode', 'u1'), ('power', 'i1'), ('padding0', 'u1'), ('pkt_type', 'u1'), ('channel', 'u1'), ('padding1', 'u1'), ('rf_gain', 'u1'), ('bb_gain', 'u1'), ('flags', '<u2'), ('chan_est', '<i2', (64, 2)), ('mac_payload_len', '<u4'), ('mac_payload', 'u1', (24,)), ('addr1', '<u8'), ('addr2', '<u8'), ('addr3', '<u8'), ('mac_seq', '<u2')]
For sender:
[('timestamp', '<u8'), ('uniq_seq', '<u8'), ('mcs', 'u1'), ('phy_mode', 'u1'), ('ant_mode', 'u1'), ('tx_power', 'i1'), ('tx_count', 'u1'), ('channel', 'u1'), ('length', '<u2'), ('num_slots', '<i2'), ('cw', '<u2'), ('pkt_type', 'u1'), ('flags', 'u1'), ('timestamp_frac', 'u1'), ('phy_samp_rate', 'u1'), ('mac_payload_len', '<u4'), ('mac_payload', 'u1', (24,)), ('addr1', '<u8'), ('addr2', '<u8'), ('addr3', '<u8'), ('mac_seq', '<u2')]
I also changed the index filter to display data frame, but what I got still didn't contain data.
BTW, I have another question, when I use bitwise_xor to calculate the BER, it seems that the # of tx is different with the # of received, but I've set two fitler to display the packets which have the same 'mac_seq' as received ones.
##transmitted pkts filter
tx_ap_idx = ((tx_ap['addr1'] == 71297883448840) &
(tx_ap['mac_seq'].any() == rx_sta_from_ap['mac_seq'].any()))
tx_ap_to_sta = tx_ap[tx_ap_idx]
I don't know how to solve these two peoblems. Could you please give me some advice? Thanks a lot!
Offline
By default wlan_exp does not log full MAC payloads. You must enable this with n.log_configure(). This will write the full payload of every Tx/Rx packet to the log on the node.
The wlan_exp examples for processing logs do not use full payloads. You will need to modify the Python code to handle this. Start with the log entry type definitions in entry_types.py and expand the 'mac_payload' fields to be the maximum size of any wireless Tx/Rx (1600 bytes will work). Then update your Python scripts to use the 'mac_payload_len' value in each log entry to parse the 'mac_payload' field contents. Only the first 'mac_payload_len' bytes of each 'mac_payload' are valid.
The mac_seq value is a 12-bit integer - it wraps after 4096 packets. For longer experiments you cannot rely on the mac_seq value to align Tx/Rx events.
More generally, for Rx entries with FCS=bad, it is not fair to use any bytes in the mac_payload to align Tx/Rx events since the mac_payload itself might have bit errors. For example, if you use address and sequence numbers to align Tx/Rx events, a bit error in the MAC header could exclude an Rx event from analysis, biasing the BER result. It is slightly more fair to use the rate/length fields to filter Rx events since these values are carried in the SIGNAL (NONHT) or HT-SIG (HTMF) preamble fields.
p.s. the ndarray.any() method tests for non-zero values in an array; as used above it will not align the events in the Tx/Rx arrays. Refer to the numpy docs for more.
Offline