WARP Project Forums - Wireless Open-Access Research Platform

Hi Murphypo,

I really wish to create my own packet which contains the BER and PER information and use warpmac_sendRawEthernetPacket() to send my packet via Ethernet to my PC to print out the statistics. ( According to some other posts, I think using Ethernet is my best shot.) However, I can't fine this function in either WarpMac.c in XPS folder or in the above link. Could you provide this function to me?

Another question is about how to create the custom packets. After reading couple of posts, I think there are two ways to do that:
1) Use memcpy() to copy whatever data directly to the packet buffer(pktBuf_tx_DATA, for example). However, if my packet is very large(say 1470 byte Ethernet packet), can I still use memcpy() without degrading the performance?
2) The second way is to create a custom packet in the PC and first use EMAC to transmit it to FIFO and then use DMA to move the data to the Tx buffer. I'm not sure whether my understanding about this is correct. In this way, which software should I use to generate custom packet and call EMAC driver to transmit the generated packet to the FIFO?
By the way, is there a way to directly generate a custom packet in a buffer? Actually, the BRAM is divided into 32 sub-buffers. According to the most updated CSMA, buffer 0, 1, 2 are occupied for Rx, Tx and Ack. Can I directly write a packet(say I create a char string) to another buffer(buffer 4, for example) and use DMA to move it to buffer 1(tx buffer) to transmit later?

Thanks a lot,

Tan

You can easily send arbitrary Ethernet packets from a node using these functions:

	warpmac_prepPktToNetwork((void *)pktPtr, pktLen);
	warpmac_startPktToNetwork(pktLen);

These replace warpmac_sendRawEthernetPacket() (if you look at the old source code, warpmac_sendRawEthernetPacket() was a line-for-line copy of the functions above, just using a pointer instead of a packet buffer index).

1) It depends on where in your code you do it. In the good header handler, for example, there's a "bubble" in the pipeline between the good header event and the good/bad payload event. The length of this idle time depends on the packet length, of course. But for long packets, there's plenty of time to construct and send an Ethernet frame before good/bad payload asserts.

2) You can definitely use the other packet buffers for arbitrary Ethernet stuff. We do this extensively for more complicated MAC designs and for WARPnet stuff (for constructing statistics packets before sending them to the server). Just be careful to keep track of which buffers contain what packets in software; the hardware doesn't provide any coordination of occupied/vacant buffers.

If you construct an ethernet packet on the warp node on your own you have to make sure that its content complies to the respective rules (e.g. TCP, IP checksums are calculated correctly, or that you do a htons etc. where necessary).

Furthermore, you should take care of the size of the ethernet packet you're about to construct. If you send only small amount of information in the body part of the ethernet packet, then you can definitely use a simple memcpy to move the information from your code to the emac pkt buffer. But if you use really long packets (1000bytes++) you should consider using DMA to copy around the packet content. On the other hand, if you want to send a large packet but you only change a small fraction of it every time you can create a template in one of the pkt buffers, then memcpy your information to the correct location within this buffer, and then tell the EMAC to use this pkt buffer instead of the default one:

//...
warpmac_prepPktToNetwork((void *)warpphy_getBuffAddr(templateBufferID)+NUM_HEADER_BYTES, length);
//...

==
Side note regarding general data packet transmission:
The WARP node takes whatever packet comes from the ethernet port, encapsulates it with a WARP MAC header, sends it over the air according to the employed MAC protocol, removes the WARP mac header, and forwards it to the other station.
==

When sending a data packet you have to distinguish between two cases:
(1) You are sending a packet to a PC: You have to make sure that the data packet complies to the TCP/UDP, IP, ETH rules (checksums, header layout, packet ids, etc.). To send a packet to a PC, it is usually easier to use (forward) a packet sent from a PC attached to the source WARP node.
(2) You want to send a packet only to the WARP node: You can send arbitrary information from one node to the other since the destination node will most likely not forward this data packet to the PC, but just uses it to collect some other implicit information (timing, channel estimates, PER, BER).

If you want to send a packet to a PC and if you want the source/destination WARP node to modify the packet content (add some measurement results), you can:
- either create a packet entirely from scratch (no need for an attached source PC), or
- in a setup phase in the very beginning, you send a series of "template packets" from the PC to the node which then stores them in different pktBuffers (later on, modify parts of it on the WARP node, and then send it), or
- send a packet directly from a source PC to the destination PC and modify it "on the fly" on the warp nodes.

In either case, you have to implement kind of a bufferID management on the WARP nodes, and you have to make sure that (1) is fulfilled.


PS: regarding DMA:
I experimented a little bit with my WARP boards with DMA (waitForDMA before and after the copy process) and memcpy:
a) Copying from a 1000B char array to another took:
- 24us with DMA
- 94us with memcpy
b) Same setup with 1500B:
- 33us with DMA
- 143us with memcpy

Whereas DMA has another advantage: your code could do other stuff while the content is copied (except directly modifying/working with the source or destination memory), while the memcpy is a blocking call. The severity of the copy-process length (timing sensitivity) depends on your code / mac protocol, meaning that one mac protocol might be able to tolerate another 140us delay while another might not.

We just posted OFDM Reference Design v15.0, with includes support for the WARPnet Measurement Framework I mentioned earlier. One of the examples shows how to run a real-time BER test using dummy packet mode as the data source, with the Tx and Rx nodes sending their packets via Ethernet for BER processing. We're still working on the documentation, but the code is ready to use. Getting the WARPnet server running will take a little effort (it's all Python, and has a few dependencies), but it's definitely worth it if you're looking to run real-time experiments.

p.s. I created a guest account with write permissions to the Trac wiki (user/pass = guest/warpWiki). If you give the framework a try and notice something missing from the docs, please feel free to update it directly. We've been working on this code for a while, and I'm sure we've forgotten some of the steps we followed to get it up and running.

I honestly haven't tested 64-QAM in the v15 PHY. I've tested QPSK and 16-QAM at length (v15 is actually a snapshot of the project I'm using to run experiments for a paper), and they work fine.

In our BER testing example, the Tx and Rx nodes both send their packets via Ethernet to a programming running on a PC, the ber_processor. This app compares the packets, calculates the numbers of bits received and in error, then sends this calculation to the WARPnet server for logging. The Tx node generates its own packets using WARPMAC's dummy packet mode and the PHY's random payload generator.

Sorry. I wrongly copied my posts twice. Please delete them...

Tan