Open EuclidGH opened 7 years ago
Hi there,
Actually, our tool will calculate the CSI for all the valid 11n packet from the sender with our tool installed. So, it is OK for you to receive some packet with different payload length. The packet may not be transmitted by the sendData. It could be some control packet or whatever packet from the sender.
Our matlab should be fine to deal with packets with different length. Why it will destroy the log.dat?
Yaxiong
Hi Yaxiong,
the problem is that the payloads with len 1924 don not contain any csi data. It means csi is empty, for example when there is a csi, it looks like this csi: 3x2x114. When payload len 1924 occurs, the csi looks like this csi: [ ]. Accordingly, the matlab plots nothing.
One more problem. We use a box in which we put our antennas (3x3) and we close the box. in the next step we send 50 packets 10 times and we write log.dat for every 50 packets. Why are they always different, when even nothing is between antennas?
Unforchantly, we can not wait, because we have also a deadline for our thesis.
Then what's the CSI_len when you receive the packet with payload length 1924? The tool will record all packets including both correctly decoded and corrupted packets. And corrupted packets will come with NO CSI data (CSI matrix will be empty) and the CSI_len will be 0.
I don't know what do you mean by a box? A metal box or what? I don't quite get it.
On Mon, Mar 13, 2017 at 3:28 PM EuclidGH notifications@github.com wrote:
Hi Yaxiong,
the problem is that the payloads with len 1924 don not contain any csi data. It means csi is empty, for example when there is a csi, it looks like this csi: 3x2x114. When payload len 1924 occurs, the csi looks like this csi: [ ]. Accordingly, the matlab plots nothing.
One more problem. We use a box in which we put our antennas (3x3) and we close the box. in the next step we send 50 packets 10 times and we write log.dat for every 50 packets. Why are they always different, when even nothing is between antennas?
Unforchantly, we can not wait, because we have also a deadline for our thesis.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/xieyaxiongfly/Atheros-CSI-Tool-UserSpace-APP/issues/22#issuecomment-286033072, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-RQz3sATx5NInXW0QE5TYkLafPAydKks5rlPAhgaJpZM4MaLyh .
Hi there,
So, here is an example of the recv_CSI terminal output: ubuntu@Latitude-E6320:~/csi-tool/recvCSI$ sudo ./recv_csi exp7.dat
Recv 1th msg with rate: 0x8e | payload len: 1040 Recv 2th msg with rate: 0x95 | payload len: 1924 Recv 3th msg with rate: 0x94 | payload len: 1924 Recv 4th msg with rate: 0x94 | payload len: 1924 Recv 5th msg with rate: 0x94 | payload len: 1924 Recv 6th msg with rate: 0x94 | payload len: 1924 Recv 7th msg with rate: 0x94 | payload len: 1924 Recv 8th msg with rate: 0x94 | payload len: 1924 Recv 9th msg with rate: 0x94 | payload len: 1924 Recv 10th msg with rate: 0x94 | payload len: 1924 Recv 11th msg with rate: 0x94 | payload len: 1924 Recv 12th msg with rate: 0x94 | payload len: 1924 Recv 13th msg with rate: 0x94 | payload len: 1924 Recv 14th msg with rate: 0x94 | payload len: 1924 Recv 15th msg with rate: 0x94 | payload len: 1924 Recv 16th msg with rate: 0x94 | payload len: 1924 Recv 17th msg with rate: 0x94 | payload len: 1924 Recv 18th msg with rate: 0x94 | payload len: 1924 Recv 19th msg with rate: 0x94 | payload len: 1924 Recv 20th msg with rate: 0x94 | payload len: 1924 Recv 21th msg with rate: 0x94 | payload len: 1924 Recv 22th msg with rate: 0x94 | payload len: 1924 Recv 23th msg with rate: 0x94 | payload len: 1924 Recv 24th msg with rate: 0x94 | payload len: 1924 Recv 25th msg with rate: 0x94 | payload len: 1924 Recv 26th msg with rate: 0x94 | payload len: 1924 Recv 27th msg with rate: 0x94 | payload len: 1924 Recv 28th msg with rate: 0x94 | payload len: 1924 Recv 29th msg with rate: 0x94 | payload len: 1924 Recv 30th msg with rate: 0x94 | payload len: 1924 Recv 31th msg with rate: 0x94 | payload len: 1924 Recv 32th msg with rate: 0x94 | payload len: 1924 Recv 33th msg with rate: 0x94 | payload len: 1924 Recv 34th msg with rate: 0x94 | payload len: 1924 Recv 35th msg with rate: 0x94 | payload len: 1924 Recv 36th msg with rate: 0x94 | payload len: 1924 Recv 37th msg with rate: 0x94 | payload len: 1924 Recv 38th msg with rate: 0x94 | payload len: 1924 Recv 39th msg with rate: 0x94 | payload len: 1924 Recv 40th msg with rate: 0x94 | payload len: 1924 Recv 41th msg with rate: 0x94 | payload len: 1924 Recv 42th msg with rate: 0x94 | payload len: 1924 Recv 43th msg with rate: 0x94 | payload len: 1924 Recv 44th msg with rate: 0x94 | payload len: 1924 Recv 45th msg with rate: 0x94 | payload len: 1924 Recv 46th msg with rate: 0x94 | payload len: 1924 ^Cubuntu@Latitude-E6320:
I sent 50 packets from send_Data. As you can see, only 46 packets hase been received and all are with 1924. The matlab says _Error using read_logfile (line 53) Wrong endian format. I call it that hte csi is destroyed because of payload len 1924.
So, Why it happens and why I do not receive all 50 packets?
you can find ten experiments here https://www.dropbox.com/s/r1e4r3lu50eh7lm/exp%2012.03%20from%20pc%20to%20lap.rar?dl=0
For all experiments, I used 50 packets.
Please check and give some comments, please.
About the box, we use a metal box, but in the next step, we want to replace it with an alu box. The idea is to do measurements inside of the box, where is no influence on the measurement environment.
Thank you very much and waiting for your reply.
I checked your data. First of all, I think there should be some problem in the kernel when processing the data. I am not sure what's the problem since I am not able to recreate the problem you met.
I think the problem may be caused by the data rate. You can check the data is very high 0x94 which means it will use 3stream to transmit the data. Can you try to lower the data rate to 1 stream, redo the experiment and give me output?
Furthermore, you can check the terminal output. When the data rate is 0x8e, it works fine. However when the data rate changed to 0x94, it goes wrong.
It may be my fault. There could be some bugs when processing the data with 3 streams. I am not sure at this moment. But I think it will work if you lower the data rate which is the fast way to fix it at this moment.
Hi there,
how can I lower the data rate from myself? Since the packets have been sent, during processing will be defined the data rate. I have no influence.
What about the packages updates and upgrades? On PC and Laptops run Ubuntu 14 LTS and there are now two kernels 4.1.10+ and 4.2.0.42. I start both systems with 4.1.10+ kernel, but after last system reinstallation I didn't do any package upgrade, I just installed CSI-tool. Have I to do upgrades or is it ok without upgrades? Also, how do you think, if I will start the installation again and I will overwrite the installed csi-tool, could it help or this would make no sense?
Please tell me, how can I lower the data rate and I will send you experiments again.
Thank you.
Hi there,
I debugged read_log_file.m and found some strangers. Line 42: Why are you dividing by 420? Line 167: Why are you adding 420 to cur? Your script does not write or read the last csi data. I moved count=count+1 (line 172) and ret{count}=csi_matrix (line 173) before if statement (line 169) and next I changed line 176 from count-1 to count, why are you subtracting 1? Now I get all written csi datas from log.dat. Before it did not work. For example, when I have 10 received packets in the terminal, I should have the same number of packets in the Matlab. Before changing I did not have the same number. After changes from above, I have the same number. Next, I debugged the main.c in the recvCSI directory. Line 100 – 102: you have fclose(fp) (line 101) and close_csi_device(fd) (line 102) after return. These lines will be never executed. This is dead code. You should move them before return. I think, you should add to these lines also free(csi-status) (But I am not sure, if it changes something greatly). Line 130-133: Is it needed to add here fflush(fp)? Line 137-139: This lines will be never executed because the program run in while loop (line 98-136) and it will be terminated using CTRL+C and these lines will be never reached.
Next, I printed sendbuf in the sendData.c to see, what exactly will be sent to the receiver. Also, I printed the data_buf in the csi_fun.c. So, the sendbuf is built like this dst_MAC || src_MAC || ether_type || 1000 times 0xaa After that it will be sent to receiver and on the receiver’s side will be built a string like this 4 Bytes || dst_MAC || src_MAC || dst_MAC || 12 Bytes || ether_type || 1000 times 0xaa || 4 Bytes So, I do this comparison because we want to have the same packet back as a response. Therefore, I want to implement the function sendData to send a response back to the transmitter using the received packets. I could not understand, how is built the string from above in the data_buf and where from come these bytes 4, 12 and again 4 at the end. Could you explain and also tell why these bytes are always different?
For example, when we measure using 10 packets and nothing change during measuring, we have actually to get always the same results, if a packet has not been lost. But the results are always different because of bytes from above.
In addition, you told me that I should lower the data rate. How can I do it, if I do not have any control over the rate, or I do?
So, the debugging has been done when the payload len was 1040. Since we got len 1924, we stoped and tried to get 1040 again while sending many packets. But, it without any succes. We do not know, how we can restart or may be clean the system from 1924 len.
Please check my report and give me some comments with explanations. I know, this is too much, but I need your help. Also, please let me know about changing of rate. After it, I will send you the experiments again.
And in addition, since the problem with payload len 1924 Bytes has been occurred again, even the restart of the whole system (PC and Laptop) does not help to come back to the 1040 payload len.
Hi, there,
Because I use a different Linux system, so it will be difficult for me to tell you how to lower the data rate in Ubuntu or OpenWRT.
So I write a program myself to control the data rate, the antenna number, bandwidth and so on. I can add more if you need it. But to add one functionality and test it takes a long time.
Currently, I succeed in controlling the rate, antenna number and bandwidth. I will integrate it into our CSI tool soon. And I will write a tutorial for it.
Sorry for the delay.
It could be better if you will add you or show us how you exactly control the rate. Aso, please comment the last post here https://github.com/xieyaxiongfly/Atheros-CSI-Tool-UserSpace-APP/issues/26
thanks
如何调整速率,您解决了吗@EuclidGH
@EuclidGH I would like to ask if you have found the way to control the data rate. I think @xieyaxiongfly has not added this functionality, I can see still packets are being sent with different data rates.
@EuclidGH I would like to ask if you have found the way to control the data rate. I think @xieyaxiongfly has not added this functionality, I can see still packets are being sent with different data rates.
@muhmaz3 I'm sorry, it was more than two years ago. So fa I can remember, we could not control the rate and we just implement a function which could detect and filter only the needed rates out. However, it is not excluded that we really could find a solution. The Project has been given to other PhD students. Sorry.
@EuclidGH Thanks for the quick response. I have found a way to control it from Luci web interface at the moment. At higher data rates, I was able to reproduce the error that you have mentioned in your original post.
@muhmaz3 Great! If you could somehow share your way to control it, I would like to take a look in. Thank you.
I am currently using TL-WDR 4300 as AP and transmitter. After flashing OpenWrt with CSI tool provided by @xieyaxiongfly. One can SSH to the router. The following commands can be used to display information about the radios and set the mcs bitrates.
This will return supported MCS rate indexes.
iw phy <phyname> info | grep "MCS rate indexes"
The command below will set ht-mcs-bit rate index. These indexes are given in Appendix 1 of the this document.
iw dev <devname> set bitrates [ht-mcs-<2.4|5> <MCS index>]
Payload len 1924 is actually a bug in the csi extraction module of CSI Kernel Driver. It is not the payload, but a part of CSI buffer that is split into 2 and is not handled properly inside csi extraction driver in Linux kernel. Total transmission is actually 1924 + 641 = 2565 bytes.
This error occurs if you are receiving the largest possible payload: 114x3x3.
Please see csi_len0.patch on how to receive 3x3x114 payload successfully
Hi all,
why I get payloads with len 1924? How can I avoid them? They destroy the whole log.dat. And I also get other payloads with different len, even when the recv_csi is started, but nothing has been sent to it from send_Data.
Why it happens? Please help me to find a solution.
Best wishes