File Transfer Issue after Reducing Bandwidth to 2.5MHz on E310V2 Board

[huangfu001206]

Hello, Mr. Jiao. Currently, we have reduced the bandwidth of openwifi to 2.5MHz. The main modifications were made to several parameters in rf_init_11n.sh:

• in/out_voltage_rf_bandwidth,
• in/out_voltage_sampling_frequency,
• out_altvoltage0/1_RX_LO_frequency.
• We have also designed a new filter.

After testing, the transmitted signal has a bandwidth of 2.5MHz, and we can successfully establish a ping connection. However, when sending files, we encounter a continuous FCS (Frame Check Sequence) verification failure on the receiving end, leading to a "stuck" state on the transmitting end.

Currently, we feel that the main reason for this issue is the reduction of clock synchronization on the PL side while the PS side remains unchanged. This causes a mismatch between the PS and PL sides, which may result in buffer overflow. Therefore, we would like to inquire about how the rate is negotiated between the PS and PL sides. Additionally, if there are other factors that may cause this error, we would appreciate your suggestions. Thank you very much!

[JiaoXianjun]

Seems that you have the theory of "buffer overflow" based on "we feel".

It is always a good practice to find out direct evidence to support your theory. Only after verifying that your theory is correct by that direct evidence, you can move forward to find out the fixing method based on your theory.

My suggestion is that reading our project document carefully: https://github.com/open-sdr/openwifi/tree/master/doc , especially the https://github.com/open-sdr/openwifi/tree/master/doc#Debug-methods .

Then try to "see" the driver and FPGA behavior by dmesg printing. Especially pay attention to the following code pieces, because they play the roles for the interfacing rate (driver-FPGA interaction by sequence number, back pressure, etc.)

https://github.com/open-sdr/openwifi/blob/17f1faaf26e29452bd8144f4b53a69169826bf8f/driver/sdr.c#L1328

https://github.com/open-sdr/openwifi/blob/17f1faaf26e29452bd8144f4b53a69169826bf8f/driver/sdr.c#L1215

https://github.com/open-sdr/openwifi/blob/17f1faaf26e29452bd8144f4b53a69169826bf8f/driver/sdr.c#L651

[huangfu001206]

Thank you very much for your response. We have also noticed another issue:

When using ad-hoc mode for communication with a bandwidth of 20Mbps and setting the rate to 6M using sdrctl, we can successfully ping the devices. However, when transferring files, we encounter a 'freeze' situation, where the receiving end consistently shows FCS0 errors. We would like to ask you about the possible reasons for this.

The basic steps we performed in our experiment are as follows: ssh root@192.168.10.122 cd openwifi ./wgd.sh ifconfig sdr0 up ./sdr-ad-hoc-up.sh sdr0 44 192.168.13.2 iwconfig sdr0 Set the transmission rate to 6Mbps: ./sdrctl dev sdr0 set reg drv_tx 0 4 By following the above steps, both devices are in ad-hoc mode with the same cell address, and we can successfully ping between them.

However, when using scp to transfer files, the sending end experiences a 'freeze' situation, and the receiving end consistently reports FCS0 errors for the retransmitted content. We would like to understand the possible reasons for this behavior.Thank you again for your reply

[huangfu001206]

The test script is as follows: test.txt then,using scp to transfer file. This test script differs from the official website in that it executes the following command: service network-manager stop The output is: Failed to stop network-manager.service: Unit network-manager.service not loaded. Everything else is done according to the documentation. Could you please Mr. Jiao to analyze the reason? Thank you very much.

[JiaoXianjun]

Can you try to limit the MTU size while doing file transder? Like 1500 --> 1000 --> 500 --> 200.

Can you also try to reduce the digital Tx gain? https://github.com/open-sdr/openwifi/blob/master/doc/README.md

Try to change tx_intf reg_idx 13:

13 | tx I/Q digital gain before dac | find the optimal value (and test record) in tx_intf.c: tx_intf_api->TX_INTF_REG_BB_GAIN_write -- | -- | -- 16 | tx antenna selection and cdd control | bit1: 0 or 1 to select ant0 or 1. bit4: 1 to enable simple cdd (two antennas have 1 sample tx delay) -- | -- | --

Can you also try to use fixed/manual Rx gain at the file receiver side? You can find out the best/usual rx gain during ping by:

https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/frequent_trick.md#Rx-gain-config

Then set a fixed gain to see whether the problem is resolved during file transfer.

The main difference between ping and file transfer is the packet length. Longer packet has more chances of big peak (PAPR), so gain might matter.

[huangfu001206]

Thank you very much for your reply, Teacher Jiao! The problem is solved! Amazing! When I tried to modify the size of the mtu, the same "stuck" situation still occurred. Then according to your suggestion, I lowered the bb_gain, which had a very magical effect. The file can also be transferred normally under the fixed BPSK modulation mode. The problem was solved. But I have some doubts, why does bbgain have such a great impact on file transfer? Or which part of the decoding did he affect? If the signal gain at the transmitting end is too large, normally the AGC at the receiving end should be able to restore the signal gain to the normal level, and there should be no impact unless the signal gain is too large, causing saturation at the receiving end.

[JiaoXianjun]

Like I said it is par. Peak to average ratio. With the same par, long packet has higher chance to have higher peak. Too high gain could enlarge this peak even higher, which means higher distortion while passing Ad9361 analog amplifier. This happens at transmitter.

[JiaoXianjun]

Thank you very much for your reply, Teacher Jiao! The problem is solved! Amazing! When I tried to modify the size of the mtu, the same "stuck" situation still occurred. Then according to your suggestion, I lowered the bb_gain, which had a very magical effect. The file can also be transferred normally under the fixed BPSK modulation mode. The problem was solved. But I have some doubts, why does bbgain have such a great impact on file transfer? Or which part of the decoding did he affect? If the signal gain at the transmitting end is too large, normally the AGC at the receiving end should be able to restore the signal gain to the normal level, and there should be no impact unless the signal gain is too large, causing saturation at the receiving end.

Another possible reason is that: due to the specific parameters of the packet for file transfer (packet length, etc.), high peak occurs in the SIGNAL field. We do observed that some specific parameters, such as the scrambling seed, packet length, MCS, etc. which go to the SIGNAL field, could lead to occasional high peak in time domain. (See my previous reply about the impact of high peak).

[huangfu001206]

OK, Mr. Jiao, thank you for such a quick reply! This problem has really troubled me for a long time. After your previous reply and the relevant verification from our experiments, we can ping successfully, but there is a problem when transferring files. Your explanation is very consistent with our experimental phenomena. But I still have a doubt. In order to verify whether it was a problem on the sending end or on the receiving end, we did an experiment like this. We used USRP to 'record' frames that failed FCS verification at the receiving end, and then used USRP equipment to ‘replayed’ them. The signal is 'replayed' and it is found that the receiving end can pass the verification normally. In addition, USRP can parse the frames that fail FCS verification normally, so we always thought that there was no problem at the sender. Because if there is a problem with the signal itself, then 'replay' should be impossible to parse. Of course, the hardware of USRP B210 is indeed different from that of E310V2, so the 'replay' frame is different from the previously sent frame. It may be different, but I'm not sure if this idea is correct, so I would like to ask Teacher Jiao to answer it again, thank you very much.

[JiaoXianjun]

"The signal is 'replayed' and it is found that the receiving end can pass the verification normally" -- here the "receiving end" you mean the openwifi FPGA?

If so, your doubt make sense. And you can play with the AGC gain (auto/manual/etc) at the receiver side according to: https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/frequent_trick.md#Rx-gain-config

[huangfu001206]

Yes, my statement above is not very clear. What I mean by 'receiving end' does refer to the FPGA of openwifi. I will try manual agc later, thank you very much Teacher Jiao.

[JiaoXianjun]

You can use this method https://github.com/open-sdr/openwifi/blob/master/doc/app_notes/packet-iq-self-loopback-test.md#iq-self-loopback-config while file transfering to check whether the IQ inside FPGA is already clipped.