Closed kirateys closed 2 years ago
What do you mean by "that is now modified, increased length to 304 Bytes randomly" ? Can you describe exactly how do you modify the tx_intf.mem to "increased length to 304 Bytes randomly"?
According to: https://www.candelatech.com/downloads/802.11-2016.pdf 17.3.2 PPDU format: When you extend the PSDU in tx_intf.mem, you should also change the LENGTH (12bit) field in the PHY header (also in tx_intf.mem), and possibly also the Parity (1bit) field in the PHY header.
Hello @JiaoXianjun
Only the data field is a random data used for simulation. The PHY header follows the format as I modified the 12-bits length field: Originally it was 64'h0000_0000_0000_09EB length field bits [16:5] = 12'h04F = 79 Bytes
Now it is 64'h0000_0000_0000_260b length field bits [16:5] = 12'h130 = 304 Bytes
The parity bit is zero as there are even numbers of 1's in the field [16:0].
Hello @lewiz-kiratey,
I have simulated (using the latest dot11zynq branch) the IQ samples you provided for the non-working part and I get a positive result (fcs=OK).
Which branch and commit did you use for the openofdm_rx repo?
Hello @mmehari
Thank you for your response. Yes, for you it seems to be working correctly. The 4-Bytes of CRC part is also correct.
I was working on the dot11zynq branch. Still, I re-tried to git clone it again today and here is the commit: f83d179cbe0496dd1db1c46c2ab8f737b668f07d and it still doesn't work for me for the IQ samples provided in the non-working part.
Can you please give me the steps you followed to make it work? Although, it should not affect the functioning, for the Vivado project, I tried it with both: 'openofdm_rx.tcl' and 'openofdm_rx_ultra_scale.tcl'.
Thanks
You are also using the latest commit as I do and the only difference I see between the two of us is the OS version which in my case is UBUNTU 18.04.
I don't know why your system is behaving the way it is but you can do a bit of debugging by comparing your part with mine.
For doing that, find attached the VCD file of my simulation and download the file locally as the link expires within a week period. https://we.tl/t-Lqn4r5jHuq
You can use GTKWave to view the content. Mine looks the following
@lewiz-kiratey when you do simulation with https://github.com/open-sdr/openwifi-hw/files/7523173/dot11_tx_legacy_iq_mod.txt, you have changed the line in https://github.com/open-sdr/openofdm/blob/dot11zynq/verilog/dot11_tb.v:
`define SAMPLE_FILE "../../../../../testing_inputs/simulated/iq_11n_mcs7_gi0_100B_openwifi.txt"
to
`define SAMPLE_FILE "../../../../../testing_inputs/simulated/dot11_tx_legacy_iq_mod.txt"
Thank you very much @mmehari and @JiaoXianjun for your help. The VCD was really helpful. It was the problem of NUM_SAMPLE in the testbench that wasn't letting all the IQ samples come in and hence, corrupting last few Bytes.
Thanks again!
You mean this: `define NUM_SAMPLE 8560
To simulate your iq correctly, what should be the minimum value of NUM_SAMPLE?
@lewiz-kiratey
Hello @JiaoXianjun
Yes, its the `define NUM_SAMPLE 8560 My IQ Sample file has 9740 samples. I set the value to 10000 and it worked for me.
@mmehari when you do the simulation, you never change `define NUM_SAMPLE 8560 ?
I did change the definition to a larger value above 9740 and indeed that makes the difference
Hello,
I am trying to simulate 2 projects separately, the 'openofdm_tx' and the 'openofdm_rx' modules in Vivado 2018.3. I wanted to run some tests for the legacy type packets. So I have a file that consists of a packet in the legacy format and I feed that to the 'openofdm_tx' project simulation. It captures the IQ data in: /openofdm_tx/openofdm_tx/openofdm_tx.sim/sim_1/behav/xsim/dot11_tx.txt I then take this IQ file and apply as an input to the 'openofdm_rx' module.
***ISSUE: for small legacy type packet, the entire packet including the CRC on the receive side on signal 'byte_out' in 'dot11.v' matches ('fcs_ok' pulse can be seen coming out) but, if I modify the data in the packet, the data part on the RX side matches but the last 4 Bytes of CRC on the 'byte_out' signal does not match (causing 'fcs_ok' to not come out).
Our image is used directly or you build your own image? YES, your image is used directly.
What is your own modification? Only the memory input files for the simulation.
Versions: OS, Vivado, openwifi/openwifi-hw repo branch and commit revision UBUNTU 14.04 VIVADO 2018.3 Latest GitHub commit: 868aad30fe3cc1bee141fb21e2aa9a7cc51d8b12
Board/hardware type 'ADRV9361-Z7035 + ADRV1CRR-BOB'
WiFi channel number TX1A/RX1A
Steps to reproduce the issue, and the related error message, screenshot, etc.
WORKING PART:
This will be transmitted out on the IQ Bus.
Either copy the contents of the IQ Data or use this: dot11_tx_legacy_iq.txt
Apply this file as an input to the 'openofdm_rx' project. On the 'byte_out' bus, we should be able to see the data coming byte-by-byte including the last 4 Bytes of the CRC. We can also see the 'fcs_ok' coming out.
NON-WORKING PART:
In the 'openofdm_tx' project, copy the legacy packet (that is now modified, increased length to 304 Bytes randomly) to the file 'tx_intf.mem' from: tx_legacy_pkt_mod.txt
Run the simulation, check the 4 Bytes of CRC generated: 32'hE14A2D84
This will be transmitted out on the IQ Bus.
Either copy the contents of the IQ Data or use this: dot11_tx_legacy_iq_mod.txt
Apply this file as an input to the 'openofdm_rx' project. On the 'byte_out' bus, we should be able to see the data coming byte-by-byte, but, in this case, the last 4 Bytes of the CRC will not match. Causing the 'fcs_ok' signal to not come out.
Can you please help me understand why would this happen? What can be done to receive the correct data on the receive side in its entirety (including the CRC)? NOTE: In some cases for simulation, there are times where the last 4 Bytes of the CRC plus some (last 1 to 4) Bytes of the data does not match.
Describe your debug efforts by Linux native tools, such as tcpdump and "cat /proc/interrupts"
Describe your debug efforts by: https://github.com/open-sdr/openwifi/blob/master/doc/README.md#Debug-methods
Any other thing we need to know for helping you better?