You are not logged in.
Hello,
I already posted about my problems with timeouts. I can't solve the issue. Here is what i have done:
In CSMA reference design i commented out the following line to disable autoresponder:
mimo_ofdmTxRx_setAction0(autoResp_action);
After this i added next two lines after creation of your ACK template packets to assign them destination address:
destNode = (myID+1)%2;
templatePkt.header.destAddr = (unsigned short int)(NODEID_TO_ADDR(destNode));
After this i created send_ack function that does the following:
void send_ack()
{
warpmac_prepPhyForXmit(&templatePkt, pktBuf_tx_ACK);
//Transmit the packet
warpmac_startPhyXmit(pktBuf_tx_ACK);
//Wait for it to finish
warpmac_finishPhyXmit();
return;
}
It just sends the ACK packet.
In phyRx_goodHeader_callback inside case PKTTYPE_DATA i replaced the line
warpmac_finishPhyXmit();
with this fuction call
send_ack();
THIS DOES NOT WORK.
If i change timeout from 120 which is default to 1000 then it works.
Can you please tell me what is it that im doing wrong?
Thank you
Offline
You need to tell us what "THIS DOES NOT WORK" means. Does your node transmit the ACK? At a minimum you should see the node's green Tx LED illuminate briefly. Does your Rx node receive the ACK too late? In this case it would exercise the following else{} clause:
phyRx_goodHeader_callback(...)
...
case PKTTYPE_ACK:
if(warpmac_inTimeout()) {...}
else {
//Got an unexpected ACK; ignore it
}You can add a print or LED toggle in that clause to see whether this is occurring.
Offline
Hello,
With timeout 120 ACks are coming late (this else statement is called). When i increase it to 200 everything is ok, and ACKs are coming in timeout. Is this the best it can do?
Offline
With timeout 120 ACks are coming late (this else statement is called). When i increase it to 200 everything is ok, and ACKs are coming in timeout. Is this the best it can do?
This suggests a timeout of 120 usec is too short for a software-generated ACK transmission. A software-generated ACK will always be slower (and have more jitter on the Rx-to-Tx time) than ACKs transmitted by the auto-responder. If you disable the auto-responder, it is reasonable to assume you would need to increase the timeout interval accordingly. I do not know the minimum timeout interval for a software-generated ACK; you would need to measure this experimentally by decreasing the timeout value until it becomes too small.
Offline
Ok thank you.
I found some papers on the Internet that claim that they were using timeouts of 50-100 usec which is clearly impossible. And if you add some other calculations you need more time. I tried to write to these people but they are not answering. But thay were all using WARP v2. Is it possible that WARP v2 was faster?
Offline
The Rx-to-Tx timing in the OFDM ref design is the same on all versions of WARP hardware. If you need to minimize the time between data Rx and ACK Tx, you should use the auto-responder logic. An ACK transmission started by software will always be slower.
Offline
Hello,
I'm trying to make communication in which every data packet is preceded with a handshake between boards. I managed to do this using only one channel. Now i want to send handshake packets on one channel and data on different channel. I did it like this:
send request packet with information about channel in his header and start timeout timer1-> receive this packet and reply with grant and move to channel on which data should come and start timout timer2 -> after receiving grant clear timout extract from header information about channel-> send data on that channel and start timeout timer1 and wait for ack-> receive data,clear timeout timer2 and send ack and move to channel for handshake.
I've put printfs and i can see that data packets are coming as well as ack packets but when i try to ping i get dest host unreachable or request timed out. What can be a problem. Also on this printfs i see a lot of data packets one after another or lot of acks one after another (not mix of acks and data)
Thank you
Offline
As we discussed in your other thread, this is not a problem we can debug for you remotely. You will need to isolate variables which change the behavior you're observing to understand what is responsible for the unexpected behavior. Keep in mind that xil_printf() statements take a long time to execute. This is a useful function for debugging individual functions and states, but you cannot safely use it inline with time-critical code.
when i try to ping i get dest host unreachable or request timed out
This is the expected response when the PC Ethernet interfaces are unable to exchange packets. One suggestion is to hard code the ARP entries on both PCs for the other PC's MAC and IP addresses (good explanation here). Most OS's (Windows especially) only attempt ARP every so often. If the link is unstable and ARP fails once, the PC might indicate a broken link even after the link stabilizes.
Offline
Ok, i understand. I just wanted to ask you for some guidance regarding this channel switching. For example when i send grant i switch to desired channel, start timeout and wait for data packet but it is possible that datafromnetworklayer_callback interrupts that and switch to another channel so i miss data. How can i lock other callbacks until timeut expires. Does disabling data from network can achieve this?
Offline
If your 'dataFromNetworkLayer_callback()' is capable of switching to a different channel, it should be made aware of when it is safe to do so. You probably don't want to explicitly disable the callback, but rather make it smarter through functions like warpmac_inTimeout() so it can determine whether or not channel switching is currently allowed. Alternatively, you could maintain a top-level global variable that holds this state and check it at various locations throughout your code base.
Offline