You are not logged in.
Hello.
We'd like to modify some part of the 802.11 reference design.
Specifically, we'd like to change the source coding part. Thus, we want to know how to change the input data.
For example, if input data is an image and we'd like send FFT(Fast fourier transform) of the image,
1. how can we change the input data?
2. how to add the functions(about datas) such as FFT?
Thank you.
Offline
WCSL wrote:
1. how can we change the input data?
The only "real" input data is the Ethernet portal. Ethernet frames are received and enqueued for transmission in DRAM. You can modify the contents of the payloads after they have been received and before they have been dequeued for transmission.
Perhaps more relevant, the other source of input data is dummy data used for performance testing via the Local Traffic Generator. The payload being sent is arbitrary, but you could potentially modify this feature to send your own custom data.
WCSL wrote:
2. how to add the functions(about datas) such as FFT?
Heavy signal processing tasks like an FFT are best suited for implementation as FPGA cores like like the PHY itself. You can use System Generator or any other Xilinx-supported tool flow to generate a custom FPGA core with your own processing.
Offline
Thanks for the reply.
From your reply, I have two questions.
1. Where can I put my modified payload? In other words, where is the code which encapsulates the Ethernet frame?
2. Similar to Question 1, where is the code which can modify the payload in local traffic generator?
Thank you.
Offline
1. The Ethernet packets get transferred into DRAM via DMA. This code is what processes each Ethernet reception. It calls wlan_eth_encap() to encapsulate the frame and then eth_rx_callback() to hand it off to the AP/STA/IBSS high MAC application.
2. Each high MAC application implements and ltg_event() function that is responsible for constructing an LTG frame and enqueueing it for transmission. For example, this is where the AP creates the dummy LTG frame.
Offline
Thank you. I have one more question.
when constructing LTG frame, does the pointer curr_tx_queue_buffer->frame pointing the LTG payload?
Offline
curr_tx_queue_buffer->frame points to the first byte of the MAC header in a Tx queue buffer in DRAM. The LTG packet creation function wlan_create_ltg_frame() constructs the MAC header and LTG payload in that buffer.
Offline
Thank you
In wlan create ltg frame() We found pointers about other headers but we can't find the pointer of LTG payload.
Where is the pointer of LTG payload in above code?
Offline
Line 735 casts the byte immediately following the 802.11 MAC header as the beginning of a ltg_packet_id_t struct. The payload of an LTG packet consists of this ltg_packet_id_t struct followed by an arbitrary number of bytes. By default the reference code does not write any data to the bytes after the ltg_packet_id_t. You can write whatever data you want in the LTG payload here, if needed.
Offline
Hello,
I have two questions.
1. If I want to transmit the payload of certain sequence, ex)"100020003...", should I modify the Line 743 to pkt_id->unique_seq = 100020003...?
2. After receiving the packet, how can I view the above sequence "100020003.." from the received packet ? Where should I add the 'printf' code to see the received payload("100020003...")?
Thank you.
Offline
WCSL wrote:
1. If I want to transmit the payload of certain sequence, ex)"100020003...", should I modify the Line 743 to pkt_id->unique_seq = 100020003...?
No, anything you put into that field is just going to get overwritten by the low MAC application prior to transmit. The high MAC application doesn't know what the current unique sequence number is. So, it just keeps that field zero and waits for the low MAC application to fill it in. You don't need to overwrite existing metadata to send something custom. I'd just put whatever custom payload you want after the "ltg_packet_id_t" in the MAC payload.
WCSL wrote:
2. After receiving the packet, how can I view the above sequence "100020003.." from the received packet ? Where should I add the 'printf' code to see the received payload("100020003...")?
Recognizing that prints are slow and you will degrade performance by performing them, you can print payload contents in either the low or high MAC applications in frame_receive() or mpdu_rx_process() respectively.
Offline
Thank you.
But we are so confused.
1. We think the payload as the data we want to transmit. Is it right?
2. What does 'after the "ltg_packet_id_t" in the MAC payload' mean?
I mean that If I want to add our custom payload like above sequence(100020003...), how can I add the code to transmit "100020003.."?
Offline
LTG packet payloads consist of a short LTG payload (the ltg_packet_id_t struct) followed by random bytes. The number of random bytes is set by the length of the LTG packet. These random payload bytes are not set explicitly in the code; instead the LTG packet uses whatever old bytes are in the packet buffer as the random payload.
If you want to define a custom LTG payload, you should add your custom bytes after the ltg_packet_id_t struct in the LTG payload, something like:
// Prepare the MPDU LLC header mpdu_ptr_u8 += sizeof(mac_header_80211); pkt_id = (ltg_packet_id_t*)(mpdu_ptr_u8); (pkt_id->llc_hdr).dsap = LLC_SNAP; (pkt_id->llc_hdr).ssap = LLC_SNAP; (pkt_id->llc_hdr).control_field = LLC_CNTRL_UNNUMBERED; bzero((void *)((pkt_id->llc_hdr).org_code), 3); // Org Code 0x000000: Encapsulated Ethernet (pkt_id->llc_hdr).type = LLC_TYPE_WLAN_LTG; pkt_id->unique_seq = 0; //make sure this is filled in via the dequeue callback pkt_id->ltg_id = ltg_id; // LTG packets always have LLC header, LTG payload id, plus any extra payload requested by user tx_length += ((sizeof(ltg_packet_id_t))); // Fill in some payload bytes after the ltg_packet_id_t struct mpdu_ptr_u8 += sizeof(ltg_packet_id_t); mpdu_ptr_u8[0] = 0x00; mpdu_ptr_u8[1] = 0x01; mpdu_ptr_u8[2] = 0x02; mpdu_ptr_u8[3] = 0x03;
Offline
Thank you.
I understand how can I add my custom data to ltg payload.
Now, we need to change frame_receive() or mpdu_rx_process() to see whether the custom data is received well.
1. But we cannot find the pointer which points the custom data at the above functions.
2. Also, if we use xil_printf at the above functions, can we see the custom data on Python? If not, how can we see the custom data on Python?
3. Can we see the above process result when we run Log Capture Example?
Offline
In frame_receive() the mac_payload_ptr_u8 variable is a pointer to the first byte of the MAC payload (i.e. first byte of the MAC header; the data follows the header).
Now, we need to change frame_receive() or mpdu_rx_process() to see whether the custom data is received well.
Can you clarify what you're trying to build? The 802.11 spec includes a 32-bit checksum covering the full MAC header+payload. If this checksum (called the Frame Check Sequence (FCS)) is valid, it is nearly certain that no bit errors occurred in the reception. You do not need to verify your custom payload byte-by-byte. If the Rx PHY says fcs_good==1, you can safely assume the entire MAC payload was received correctly.
Offline
Thank you.
Can you clarify what you're trying to build?
(1) We want to send custom data(ex. FFTed images), and want to check whether the data received well. Beyond this, we ultimately want to visualize our received data(ex. printf the payload byte or show the transmitted images).
(2) Now, we just want to send the fixed payload byte(like 0123), and want to printf the payload. This procedure is just for test.
3. Is C file(ex. wlan_mac_ltg.c) included in Python code of Log capture example?
Then, if we want to check (2), then what we have to do is to change above C code and just run the Log capture example?
We are biginner of SDR, so always thank you for your help.
Offline
Taking a step back, is it possible for you to use the existing Ethernet portal behaviors of the design to carry your custom data? For example, you could write a custom application on a host PC that generates UDP or TCP traffic from your custom data source and another application that consumes that traffic and displays it or analyzes it in some way. In between, the 802.11 Reference Design could be used as-is without modification to carry your custom data. This is basically what happens when you use the design to connect to the Internet like a commercial AP.
WCSL wrote:
(2) Now, we just want to send the fixed payload byte(like 0123), and want to printf the payload. This procedure is just for test.
3. Is C file(ex. wlan_mac_ltg.c) included in Python code of Log capture example?
Then, if we want to check (2), then what we have to do is to change above C code and just run the Log capture example?
xil_printf() is useful for debugging, but know that it is extremely slow. It's not a good option for displaying data "live" as its received.
Next, yes, that example winds up using the LTG framework on the node to generate CBR traffic. But since the data itself is meaningless by default, the log on the Rx side is only storing the header information and other metadata about the reception. As murphpo said earlier, simply knowing that the FCS checksum was calculated correctly is sufficient for knowing whether all the data was properly received, even if you aren't actually looking at the data.
If you do actually need to look at the data of received packets in the log, you can configure the node to log the full payload of every reception with log_full_payloads argument to the log_configure method. However, actually dealing with that data once you retrieve the log isn't easy. The basic limitation is that each reception can be a different length and the numpy processing we do on the Python side can't really deal with that. A workaround would be to modify the RX_OFDM event type as if it had a really long 1500 byte header. This will make each entry the same size and that size would be big enough to cover a full payload. Then in your processing you'd have to account for the fact that many of those 1500 bytes are garbage when packet lengths are short. You'll have to really dig into the Python side of things to see how log retrieval works if you want to go down this road.
Offline