You are not logged in.
Actually, I just figured the tx_attempt and num_tx log entries can help me find out the timestamp of the first attempt, second attempt, etc.
In case anyone has the same question, the TX_LOW log entries contain the timestamp of the actual PHY transmission. This timestamp is captured by the MAC hardware when the Tx PHY actually begins transmitting, after any MAC deferrals. You can associate TX_HIGH and TX_LOW entries with the uniq_seq value. As you noted, the TX_LOW entries for re-transmissions contain incrementing values in the tx_attempt field.
Offline
Hi Chris & Patrick,
When running our wireless experiment, at the end of an iteration, the experiment terminates and gives the error:
node.configure_bss(channel=CHANNEL)
File "C:\LiRa_Experiments\Mango_802.11_RefDes_v1.5.2\Python_Reference\wlan_exp\node_ap.py", line 119, in configure_bss
msg += " Channel {0} was invalid.\n".format(self.channel)
AttributeError: 'WlanExpNodeAp' object has no attribute 'channel'
We have included all the relevant channels in the C code. Do you know what could be causing this error?
Thanks,
Sharan
Offline
Did you update the wlan_channels array in util.py? This is the channel list the wlan_exp Python code enforces before sending any commands to the node.
Offline
Yes, we have all the channels (1, 14, 48) we used updated in util.py.
Last edited by Erica (2016-Dec-17 21:02:48)
Offline
Ironically, the reason you are getting the AtrributeError is that there is an error within the error print in node_ap.py. The actual error is that the node is returning cmds.ERROR_CONFIG_BSS_CHANNEL_INVALID in its response to your call to configure_bss().
The error is happening on the C side of things. Here are the lines that raise the BSS_CONFIG_FAILURE_CHANNEL_INVALID bit in the return value that gets sent to Python. You'll need to change wlan_verify_channel() to include any extra channels that you have added.
Offline
Hello Chris,
Thanks for the help. The channel implementation problem is solved. Here I have another problem.
I previously asked how to delay the dequeuing of a packet from CPU high on the AP side for a specific time period after transmission of the previous packet is complete. You suggested the following approach, which worked well on the AP side:
chunter wrote:
3. This is out there, but do you really need the packets to be created and enqueued at a specific time? Or is it equivalent to say the AP shall not de-queue any packets for a certain amount of time after each transmission? If so, you could just let the LTG enqueue stuff at its leisure but only upon the spigot in poll_tx_queues() after your scheduled event has expired. It's pretty goofy, but imagine setting a global variable to 1 in your implementation of IPC_MBOX_TX_MPDU_DONE. If this variable is 1, then force wlan_mac_high_is_dequeue_allowed() to return 0. Then set the global variable back to 0 after your scheduled event expires and manually call poll_tx_queues(). At this point, the application will see that it is allowed to dequeue the next packet. This would in effect force a minimum time after a transmission before any future transmission occurred. Just an idea.
Now I'm trying to do the same thing on the STA side. Namely, I would like to flag the tx_frame sent from a specific STA node and delay its dequeuing from CPU high. I'm wondering if the same method still works. I noticed that while both AP and STA share the same wlan_mac_high, they have their own implementation of poll_tx_queues() in wlan_mac_ap and wlan_mac_sta, respectively. Could you please give me some instruction on how I could implement this approach on the STA side?
Thank you very much!
Last edited by Erica (2016-Dec-20 00:12:34)
Offline
Hi Chris and Patrick,
Earlier in this discussion thread, we had flagged any data packet successfully transmitted from AP's lower MAC and delayed the dequeueing of next frame from AP's higher MAC by a configurable parameter. Recently, we tried to implement something similar on STA side. My network has two types of nodes, type A is a typical 802.11g node and type B is the node which will have the earlier described upper MAC dequeuing delay functionality with the help of a configurable parameter.
To differentiate between these two types of STA nodes at C level, we fixed the payload size of type A nodes to a particular value and ensure none of our type B nodes transmit packets of that set payload size. Accordingly, when a transmission happens from a STA, we check the payload size and accordingly delay the dequeueing or not.
We used similar implementation at C level as you had suggested for AP side earlier in this thread, as Erica pointed out. Unfortunately, we are unable to get any transmissions from the type B nodes for unknown reasons. Our TX_LOW and TX_HIGH both are empty for type B STA nodes. This isn't the case for type A STA nodes.
I hope this has provided you with more information to give us feedback. We greatly appreciate your help!
Thanks,
Sharan
Last edited by sharanmanu91 (2016-Dec-22 02:38:01)
Offline
You'll have to dig deeper into the behavior of your custom C code - the absence of TX entries from the logs is a high-level symptom, but doesn't provide sufficient detail to understand the behavior of your code. Verifying behavior in C is a good place to use the UART. xil_printf() calls take a _long_ time - prints are great for debugging but must be removed before running any timing-sensitive experiments.
Offline
Thanks Patrick,
I will update you once we figure out what's preventing the transmissions.
Thanks,
Sharan
Offline