search

bastibl / gr-ieee802-11

IEEE 802.11 a/g/p Transceiver
https://wime-project.net/
GNU General Public License v3.0
752 stars 293 forks source link

Problem with E310 #27

Closed aler86 closed 8 years ago

aler86 commented 8 years ago

Hi Bastian, i'm trying to run wifi_rx but the output is :

Generating: '/home/alex/gr-ieee802-11/examples/wifi_rx.py'

Executing: '/usr/bin/python2 -u /home/alex/gr-ieee802-11/examples/wifi_rx.py'

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-113-g6b367da7

Using Volk machine: avx2_64_mmx_orc -- Initializing core control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Setting time source to internal -- Asking for clock rate 16 MHz -- Actually got clock rate 16 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass

UHD Warning: The requested decimation is odd; the user should expect passband CIC rolloff. Select an even decimation to ensure that a halfband filter is enabled. Decimations factorable by 4 will enable 2 halfbands, those factorable by 8 will enable 3 halfbands. decimation = dsp_rate/samp_rate -> 3 = (16.000000 MHz)/(5.000000 MHz)

UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 10.000000 MSps Actual sample rate: 8.000000 MSps

Can you help me about this ?

Thanks in advance

bastibl commented 8 years ago

Hi, this is just a warning, informing you that your particular device will not produce a perfect flat spectrum in this setting. CIC rolloff will attenuate the frequencies towards the end of the spectrum. You might want to set a higher sample rate that plays well with your device and resample in software.

aler86 commented 8 years ago

Ok, but i don't see nothing...

bastibl commented 8 years ago

sorry, but "I don't see nothing" is not a proper bug report. Apart form that, I'm not sure whether the ARM on the E310 is able to run the code in real-time. My guess is, it's not. The E310 is more tuned towards FPGA-based stuff with RFNoC.

aler86 commented 8 years ago

Sorry, but I meant that the flow graph don't work. E310 is equipped with a network mode, and i think that it is able to run the code...

bastibl commented 8 years ago

The network mode of the E310 is more of a debugging interface, and AFAIC the bandwidth is very limited. You should first make sure that 5MHz are actually supported. Btw, regarding the clock, another option might be to manually set the clock rate to let's say 20MHz then you should not experience problems with the CIC filter. (I think the master clock rate of the E310 is configurable like with the B210). If you still run into problems, please, elaborate on what you do, how you do it, and what exactly goes wrong.

aler86 commented 8 years ago

Ok, I solved a clock rate problem, but my very problem is that the flowgraph don't work, when i run "wifi_grc.rx", my output is the following:

linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-119-g42a3eeb6

Using Volk machine: avx2_64_mmx_orc -- Initializing core control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Setting time source to internal -- Asking for clock rate 16 MHz -- Actually got clock rate 16 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Asking for clock rate 30.72 MHz -- Actually got clock rate 30.72 MHz -- Performing timer loopback test... pass -- Performing timer loopback test... pass

UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 5.000000 MSps Actual sample rate: 5.120000 MSps

schermata del 2016-01-20 14 44 04

bastibl commented 8 years ago

Unfortunately, this warning tells you that you did not solve the sample rate problem

UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 5.000000 MSps
Actual sample rate: 5.120000 MSps

This is too far off.

But still you should see something happening. You can see if you network mode is working by switching to the Autocorrelation tab. This tab should always show something, even if no frame was detected.

aler86 commented 8 years ago

Unfortunately, also Autocorrelation tab is blank :(

bastibl commented 8 years ago

That means the E310 is not streaming samples. Try creating a new flow graph only with UHD Source and a Scope Sink; I guess it will not show anything. If it shows something, compare the options of the UHD Source blocks,

aler86 commented 8 years ago

The flow graph only with UHD source and scope sink is blank, do you think that is a firmware problem? because i updated the uhd version on E310 to make it consistent with my host pc, and I noticed that in network mode don't light more leds on E310.

bastibl commented 8 years ago

Sorry, I don't have an E310 and cannot help you with this. If you don't find something in the docs of Ettus, you can ask on the UHD mailing list how to use the network mode.

aler86 commented 8 years ago

thank you so much!!

tuf22191 commented 4 years ago

Hi, @aler86 and @bastibl , did you get Wifi capture to work with E310? Can you share the working .grc file? I have checked the datasheets between E310 and B210 (what this module has been tested with) -> as I am a little new to this, my impression is that the key aspects of the RF front end that need to be the same are the ADC rate (both B210 and E310 have 61.44 MS/s) and resolution (both B210 and E310 have 12 bit res but N210 has 14). Ideally E310 should be able to run this module and demodulate the Wifi. Background Info for My Question: I need some help to get this Wifi capture running. I have modified the wifi_rx.grc into 2 files -> host_receiver.grc for laptop and sdr_receiver.grc for E310. Reason: I don't think that E310 has enough processing, rather I am capturing the IQ samples, buffering with ZeroMQ, and then sending over socket to my host where I actually demodulate everything. If I want to change any of the parameters, I have a Remote Procedure Call (RPC) from my host to the E310 over ethernet if I want to change any parameters.
My Question;

I have attached the 2 files (I added .txt to the .grc extension so that Github's web app would let me attach it - please take the .txt extension off). If you don't mind, can you tell me what I am doing wrong here, my code doesn't seem to modulate the wifi packets correctly? I mean, I can see the changing constellation (I go into channel 11 2.4 GHz spectrum and pick up the energy).

I also suspect that my laptop might not be powerful enough (I read from @bastibl that "O"'s indicate that data is being dropped. That might not be happening all the time though so I wanted to investigate if there is something else (mainly the DC offset problem - which I don't understand the technical foundations for - if you have some theory text, I'd like to see it). Thanks!!

host_receiver.grc.txt sdr_receiver.grc.txt

tuf22191 commented 4 years ago

@bastibl We all appreciate the work you have put into this module -> I want to learn exactly what is going in the blocks (preamble synchronization, OFDM, etc.) - do you have a resource you can provide? When I look at the wifi_rx.grc or the hierarchical block file I can't really follow why certain blocks are positioned the way they are. I am going to try to go through your code - looks like everything is in /include and /lib folders but I was wondering that SWIG would have generated a python file (for the Python API), but I don't see anything.

In general, do you have any textbook/pdf that gives information on how to demodulate Wifi - I came across this: https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf . If you think there is something else I can read, please let me know.

Great work all around btw!

bastibl commented 4 years ago

Unfortunately, the E3XX series is just the wrong platform for this module. This module implements the whole PHY on the CPU. The E310, however, cannot decode the data on the ARM and the interface to the host rather limited. So neither option is going to work. (Btw, the E310 has a special mode to act as a normal SDR for the host, i.e., you don't have to adapt the flowgraph at all).

There is some more (and a bit more up-to-date) information in my thesis: https://www.bastibl.net/bib/bloessl2018physical/

Apart from that, I'd just look at the standard. Most of the design decisions are a direct result from the frame format that is documented in detail in the standard.

tuf22191 commented 4 years ago

@bastibl I really appreciate the feedback. The way I see it (as you've mentioned) E310 just doesn't have the CPU power to demodulate the signal and I don't think my host does either. I think I will just do a recording to a file and just do a playback. As for the special mode, I think you are talking about the MPM (https://files.ettus.com/manual/page_usrp_e3xx.html) . I don't feel comfortable enough to be using that - still a beginner. However, I am glad you made me aware of this!

Thanks for the additional information! Vehicular ad-hoc networks is an amazing subject to get your PhD thesis in. I myself just finished up my MS (I am a data science/machine learning guy but my undergrad is in EE-CE concentration but that was some time ago). If I have further questions, I will certainly post another question (if you don't mind). Thanks again!